openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: commit: ldap/contrib/slapd-modules/cloak cloak.c
by Hallvard B Furuseth 04 Jan '11

04 Jan '11

ando(a)OpenLDAP.org writes: > fix cloak behavior; plug leak (ITS#6762) Oh, there actually was a leak?:-) What I meant in ITS#6762 was I assumed my workaround would have have introduced a leak. -- Hallvard

2 1

LDIF wrapping (Was: ITS#6645)
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

I'd like to resolve the ITS#6645 issue, either by committing or wiping out this patch from my working directory, as it conflicts with ITS#6737. Comments? p.

3 5

CSN of delete operations
by Rein Tollevik 30 Dec '10

30 Dec '10

The bdb/hdb and ldif backends assigns CSNs to delete operations that lacks it, which causes problems in forwarding replication configurations. During the refresh phase there may be legitimate delete operations that should not have any CSN. When the forwarder adds its CSN it might leave the forwarded and its consumers with a CSN set that includes a SID not present on the provider, and they will never be able to resync. syncrepl_del_nonpresent() queues the minimum CSN received from the provider, which partly obscures this problem but in return introduce other :-( The CSN set received may include updates to more than one CSN, and only one if these can be added on the queue. Much worse, the first delete will commit the queued CSN. If there are more than one entry that should be deleted this leaves an open window where the forwarder (and its consumers) have an apparently up-to-date CSN set without actually being in sync with the provider. Running the new test061 with sync debugging shows traces of these problem in the logs. In back-bdb/delete.c, the CSN of the delete operation appear to be added as a value in the entryCSN index, which really puzzles me. If that index is to be modified I would expect that it should delete the entryCSN value of the entry being deleted, not to add anything. Why this is only done in non-shadowed databases I cannot tell either. I would fix these problems by assigning the CSN of delete operations in the frontend, i.e on the server where ordinary delete operations where done. syncrepl_del_nonpresent() should not queue the CSN, updating it should be left to the syncrepl_updateCookie() call which takes place when the refresh phase completes. But what to do about the index manipulation I cannot tell. Anyone? Rein

2 1

LDAP Verify Credentials operation
by Kurt Zeilenga 30 Dec '10

30 Dec '10

I'm going to add a LDAP 'Verify Credentials' operation to the client side in OpenLDAP (as that's I'll I need). The operation behaves like LDAP Bind excepting it has no impact upon the underlying LDAP session (no change to the authorization associations, no change of layers, etc.). No spec yet, want to have a working implementation first. The operation is intended to be used by LDAP clients which are application protocol servers to authenticate application protocol users. For instance, a web server could authenticate it's users via this operation. Multiple operations can be executed in parallel on a session. SASL can be used. Could also be used by a DSA to authenticate users whose entries (or complete entries) are not held by the DSA. Wondering if there are any volunteers to implement the server side? Should be relatively straight forward. -- Kurt

2 1

vc function names (was: commit: ldap/include ldap.h)
by Hallvard B Furuseth 28 Dec '10

28 Dec '10

ldap.h declares ldap_parse_verify_credentials_result(), but the .c files define and use ldap_parse_verify_credentials(). I guess the first name is most formally correct, but rather long. I suppose you could s/credentials/creds/ in the operation name. -- Hallvard

2 1

Re: commit: ldap/tests/scripts test054-syncreplication-parallel-load
by Quanah Gibson-Mount 21 Dec '10

21 Dec '10

--On Sunday, August 29, 2010 4:11 AM +0000 ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/tests/scripts > > Modified Files: > test054-syncreplication-parallel-load 1.6 -> 1.7 > > Log Message: > s/provider/producer/ I think this should be reverted. The master server(s) are providers. The replicas are consumers. The master(s) provide the data. The replicas consume them. End admins/users produce the data by modifying the master(s), not the master(s) themselves. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

back-ldif robustness hack (was: Filesystem & backend options for embedded openldap)
by Hallvard B Furuseth 20 Dec '10

20 Dec '10

Moved from openldap-technical. Hallvard B Furuseth writes: > [back-ldif] can leave behind a temporary file if you pull the plug on > slapd at just the wrong moment, when an entry is being written. That > won't affect the entry, but the parent entry cannot be deleted when > there are temporary files in its directory. Could fix this as follows. I guess it's worth the price of slowing down LDAP Delete: If a Delete operation would fail with notAllowedOnNonLeaf (rmdir gave ENOTEMPTY), read the first directory entries. If we find an .ldif or a directory, return notAllowedOnNonLeaf. Remove any temporary files encountered until then, and try again if we removed them all. back-ldif serializes write operations, so there won't be a conflict unless the admin runs slapadd and slapd at the same time. There could be files someone else has stored there which should not be deleted, e.g. a README, so tempfiles should have recognizable names like "<rdn>.tmp<6 random chars>" instead of just "<rdn>.<6 random chars>". -- Hallvard

1 0

Re: commit: ldap/ CHANGES
by Hallvard B Furuseth 13 Dec '10

13 Dec '10

Let's try to keep CHANGES talking in user-visible rather than source-code-visible terms when that makes sense. Something like this: Index: CHANGES @@ -14 +14 @@ - Fixed slapd modify leaving rc uninitialized (ITS#6715) + Fixed slapd 'sortvals' of attributes with 1 value (ITS#6715) @@ -17 +17 @@ - Fixed slapd-ldap uninitialized tv_usec (ITS#6721) + Fixed slapd-ldap debug output of timeout (ITS#6721) @@ -21 +21 @@ - Fixed slapd-null back-config support (ITS#6624) + Added slapd-null cn=config support (ITS#6624) @@ -27 +27 @@ - Fixed slapo-syncprov properly mutex filter (ITS#6708) + Fixed slapo-syncprov filter race condition (ITS#6708) -- Hallvard

2 1

autoconf version update?
by Quanah Gibson-Mount 11 Dec '10

11 Dec '10

We are currently generating configure with autoconf 2.61. Is there any objection to updating to autoconf 2.65? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: commit: ldap/libraries/libldap result.c
by Howard Chu 10 Dec '10

10 Dec '10

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > result.c 1.176 -> 1.177 > > Log Message: > ITS#6744 - plug leak This patch fixes things and doesn't appear to break anything else. However, during testing I noticed something a bit odd. The referral I used pointed to a server with an empty database, so the sub search always returned error 32. The result printed by the ldapsearch command was usually 0 (Success) but occasionally it returned 32, and the outcome seems to be random. This behavior is the same both before and after applying the above patch. I'm somewhat disturbed that we're not getting completely deterministic results out of this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel