openldap-devel June 2008

openldap-devel@openldap.org

19 participants
18 discussions

contextCSN of subordinate syncrepl DBs
by Rein Tollevik 22 Nov '09

22 Nov '09

I've been trying to figure out why syncrepl used on a backend that is subordinate to a glue database with the syncprov overlay should save the contextCSN in the suffix of the glue database rather than the suffix of the backend where syncrepl is used. But all I come up with are reasons why this should not be the case. So, unless anyone can enlighten me as to what I'm missing, I suggest that this be changed. The problem with the current design is that it makes it impossible to reliably replicate more than one subordinate db from the same remote server, as there are now race conditions where one of the subordinate backends could save an updated contextCSN value that is picked up by the other before it has finished its synchronization. An example of a configuration where more than one subordinate db replicated from the same server might be necessary is the central master described in my previous posting in http://www.openldap.org/lists/openldap-devel/200806/msg00041.html My idea as to how this race condition could be verified was to add enough entries to one of the backends (while the consumer was stopped) to make it possible to restart the consumer after the first backend had saved the updated contextCSN but before the second has finished its synchronization. But I was able to produce it by simply add or delete of an entry in one of the backends before starting the consumer. Far to often was the backend without any changes able to pick up and save the updated contextCSN from the producer before syncrepl on the second backend fetched its initial value. I.e it started with an updated contextCSN and didn't receive the changes that had taken place on the producer. If syncrepl stored the values in the suffix of their own database then they wouldn't interfere with each other like this. There is a similar problem in syncprov, as it must use the lowest contextCSN value (with a given sid) saved by the syncrepl backends configured within the subtree where syncprov is used. But to do that it also needs to distinguish the contextCSN values of each syncrepl backend, which it can't do when they all save them in the glue suffix. This also implies that syncprov must ignore contextCSN updates from syncrepl until all syncrepl backends has saved a value, and that syncprov on the provider must send newCookie sync info messages when it updates its contextCSN value when the changed entry isn't being replicated to a consumer. I.e as outlined in the message referred to above. Neither of these changes should interfere with ordinary multi-master configurations where syncrepl and syncprov are both use on the same (glue) database. I'll volunteer to implement and test the necessary changes if this is the right solution. But to know whether my analysis is correct or not I need feedback. So, comments please? -- Rein Tollevik Basefarm AS

2 6

dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder 21 Mar '09

21 Mar '09

HI! Discussed this very briefly with Howard at LDAPcon 2007 based on an idea of Steve: Support for dITStructureRules and nameForms is still in OpenLDAP's TODO. In the meanwhile slapd could accept definitions for both in slapd.conf and simply pass them on to a schema-aware LDAP client for informational purpose without enforcing them. Same function like rootDSE <file> in slapd.conf. Opinions? Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

2 4

Compile warning using additonal CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W'
by John Smith 30 Jun '08

30 Jun '08

i, Ive just downloaded and compiled openldap-2.4.10, but when I add the CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W' I get the following warnings that may require further investigation of an developer : - declaration of 'foo' shadows a global declaration - cast discards qualifiers from pointer target type - missing initializer - signed and unsigned type in conditional expression - comparison between signed and unsigned - comparison of unsigned expression >= 0 is always true - comparison of unsigned expression < 0 is always false - declaration of 'foo' shadows a previous local - `foo' is deprecated; use `foobar' or `foo_r' instead - Perhaps this warrants some investigation by the developers ? Ive attached the complete build log for the full details. Regards, John Smith.

2 1

[BUG,PATCH] slapd unable to import CRL using GnuTLS backend
by arno＠natisbad.org 24 Jun '08

24 Jun '08

Hi, When openldap is linked with gnutls for TLS support, a file containing CRL in PEM format can be provided (in slapd.conf, using TLSCRLFile parameter). The following code in ldap_int_tls_init_ctx() (librairies/libldap/tls.c) prevents the daemon to start when the option is used: if ( lo->ldo_tls_crlfile ) { rc = gnutls_certificate_set_x509_crl_file( ((tls_ctx*) lo->ldo_tls_ctx)->cred, crlfile, GNUTLS_X509_FMT_PEM ); if ( rc < 0 ) goto error_exit; } because gnutls_certificate_set_x509_crl_file() returns the number of CRL files that have been imported which is stored in rc and returned later in the function. Caller expects 0, otherwise it reports an error, the value of rc (below, with 3 CRL in the file) and slapd fails to start: .... main TLS init def ctx failed: 3 The patch below is for 2.4.10, but should apply against all versions (it applies fine against current Debian version available under Unstable). Tell me if you have issues. I recompiled the Debian version with the patch applied and it works as expected. Cheers, a+

3 2

test suite data
by Howard Chu 18 Jun '08

18 Jun '08

I'm currently trying to run "make test" with back-ndb and most of the comparisons fail even though the backend is behaving correctly. 1) back-ndb always fills in all objectclasses in the objectclass chain, while the test.ldif files omit most of the superior classes. 2) back-ndb always returns attributes in the order they were defined in their corresponding objectclass definition, instead of preserving whatever order they were submitted in. Any thoughts on how to address 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/

4 8

managing OpenLDAP / back-config
by Ralf Haferkamp 17 Jun '08

17 Jun '08

With the great features that back-config provides to configure OpenLDAP servers at runtime it seems logical to start thinking about providing tools that could help to leverage those features. Currently to manage an OpenLDAP server through back-config you have the option to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or homegrown software using one of the available LDAP APIs. I think it would be helpful to have some more sophisticated management tools (Commandline and/or GUI). In order to get there I think it could be helpful to create an API dedicated to provide an easy way to access the OpenLDAP configuration (databases, overlays, schema, access control, ...). This API could then be used to create different flavors of management tools. I have not yet spend too much time thinking about the design of such an API. Neither about the programming language that I'd use to implement something like this (Python, C, C++, ?). I first like to get a feeling how others think about this and if anybody is interested in collaborating on such an API. So please feel free to reply with your comments and suggestions :) -- regards, Ralf

7 24

Re: commit: ldap/contrib/slapd-modules README
by Hallvard B Furuseth 16 Jun '08

16 Jun '08

ghenry(a)OpenLDAP.org writes: > Read over, update using work from hallvard and spell check. Actually we both got that wrong. The posixgroup README says compile it as plugin acl-posixgroup. -- Hallvard

1 1

[Fwd: LDAP Content Synchronization Operation (rfc4533)]
by Gavin Henry 16 Jun '08

16 Jun '08

Another use outside the project. -------- Original Message -------- Subject: LDAP Content Synchronization Operation (rfc4533) Date: Sat, 14 Jun 2008 21:01:36 +0200 From: Mathieu PARENT <math.parent(a)gmail.com> To: perl-ldap(a)perl.org Hi, I have implemented LDAP Content Synchronization Operation (rfc4533) in perl-ldap (See the attached patch). This is used by the OpenLDAP server and provide features similar to Persistent Searches in a more consistent way. This is my first try in this code, any feedback is welcome. I don't know how to handle the Sync Info Message which is an LDAP Intermediate Response Message (see 2.5 in RFC). perl-ldap doesn't seems to support intermediate responses in response to LDAP::Search. What is the way to correct this ? thanks Mathieu Parent -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Subschema missing entryCSN
by Michael Ströder 13 Jun '08

13 Jun '08

HI! Any particular reason why attribute type 'entryCSN' is still missing in the subschema? (testing with 2.4.10) Ciao, Michael.

1 0

Deleting overlays from cn=config
by Ralf Haferkamp 12 Jun '08

12 Jun '08

Hi, as back-config does currently not have support for the delete operation (config_back_delete() just returns LDAP_UNWILLING_TO_PERFORM currently) I am trying to figure out what is needed to get at least delete support for simple overlays (e.g. ppolicy or memberof) running. What I am currently doing is: - renumber the indexes of the siblings of the overlay that's going to be deleted - remove the CfEntryInfo of the overlay from the internal config tree - remove the Entry from the underlying LDIF database Additionally I need to remove the overlay's slap_overinst structure from the overlay list of the backend and in case it was the last overlay, restore the original BackendInfo structure and delete the SLAP_DBFLAG_GLOBAL_OVERLAY flag from the BackendDB structure of the underlying database (for global overlays). Currently I use the overlay_destroy_one() function for this task. This also calls the db_destroy() hook of the overlay which should take are of free resources held by the overlay. I am a bit unsure about the db_destroy() part. Is that enough or is it needed to call the db_close() hooks (when provided by the overlay) before calling db_destroy()? Did I miss something else? Is anybody else currently working on this? Up to now I am testing this only with some simpler overlays (memberof, pcache), I assume that deleting overlays that instantiate their own databases (like pcache, translucent(?)) might get a little more hairy. -- Ralf

7 17

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel June 2008