openldap-devel December 2010

openldap-devel@openldap.org

9 participants
12 discussions

OpenLDAP git repo?
by Volker Lendecke 29 Mar '11

29 Mar '11

Hi! Out of several rumors I've heard that OpenLDAP converted it source repo to git. Is that true? www.openldap.org still speaks about cvs. If you changed to git, is the repo publically available? Thanks, Volker

5 12

librewrite & co vs. logging & ldap-int.h
by Hallvard B Furuseth 13 Jan '11

13 Jan '11

The ITS#6625 patch causes preprocessor warnings about conflicts with ldap-int.h, so I'm looking again at old ITS#5421 to kill off #include "...libldap/ldap-int.h" These occur in librewrite, rwm, back-ldap and back-meta. The #include is for two things: Expose struct ldapmsg & LDAP_FREE, the need of which I've just removed in HEAD, and set up libldap logging. I expect the slapd components just as well can drop the #include and use slapd logging? back-*/search.c then need lber-int.h instead. librewrite still needs the #define ldap_debug in ldap-int.h. Instead we could either: (1) use liblber logging in librewrite, (2) or throw the code LDAP_INT_IN_KERNEL .. #endif /* LDAP_DEBUG */ out of ldap-int.h to a separate file, either include/ldap_log.h or something like libldap/ldap-int-log.h. This file would not expose structs with different definitions depending on LDAP_R_COMPILE & co. Since the file when not LDAP_INT_IN_KERNEL does need to refer ldap_debug to ldap_int_global_options.ldo_debug, that can be done with: /* This struct starts with the same members as ldapoptions */ struct ldapoptions_prefix { short ldo_valid; int ldo_debug; }; #define ldap_debug \ (*(int *) ((char *) &ldap_int_global_options \ + offsetof(struct ldapoptions_prefix, ldo_debug))) struct ldapoptions; LDAP_V ( struct ldapoptions ) ldap_int_global_options; Opinions? Put it in ldap-int.h, or ldap_log.h? Maybe the latter only if #defined LDAP_LIBRARY_LOGGING (defined by the user)? -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel December 2010