openldap-devel August 2008

openldap-devel@openldap.org

12 participants
11 discussions

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

23 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

Re: commit: ldap/servers/slapd/back-bdb add.c back-bdb.h bind.c cache.c compare.c config.c delete.c dn2entry.c dn2id.c filterindex.c id2entry.c idl.c init.c key.c modify.c modrdn.c proto-bdb.h referral.c search.c tools.c
by Howard Chu 25 Sep '08

25 Sep '08

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb > > Modified Files: > add.c 1.173 -> 1.174 > back-bdb.h 1.173 -> 1.174 > bind.c 1.54 -> 1.55 > cache.c 1.180 -> 1.181 > compare.c 1.57 -> 1.58 > config.c 1.107 -> 1.108 > delete.c 1.172 -> 1.173 > dn2entry.c 1.35 -> 1.36 > dn2id.c 1.156 -> 1.157 > filterindex.c 1.75 -> 1.76 > id2entry.c 1.86 -> 1.87 > idl.c 1.134 -> 1.135 > init.c 1.291 -> 1.292 > key.c 1.24 -> 1.25 > modify.c 1.176 -> 1.177 > modrdn.c 1.200 -> 1.201 > proto-bdb.h 1.159 -> 1.160 > referral.c 1.50 -> 1.51 > search.c 1.265 -> 1.266 > tools.c 1.127 -> 1.128 > > Log Message: > Use read-only txn's instead of read lockers. Support BDB 4.4-4.7 Please test... At the moment I've only run it with BDB 4.7.25. I'll be testing with older releases over the next couple of days. In particular, take note of any LDAP_OTHER/Internal Error results in the test suite. Right now it passes all tests for me on bdb and hdb. If push comes to shove we can probably create a new BerkeleyDB4.2.patch file to get 4.2 working again, but at this point most people should already be on something newer, and people stuck on 4.2 probably won't compile their own anyway. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 4

postalAddress matching rule
by Brett ＠Google 05 Sep '08

05 Sep '08

Hello, I've just submitted a patch to help make the collect overlay (attribute inheritance) a bit more useful (ITS#5659). As part of my testing work for the above i once accidentally created a postalAddress attribute with two values. When i tried to remove the extra attribute value it failed, the error i got was something like that there is no matching rule for postalAddress, which if there really isn't then it's probably a reasonable thing for slapd to complain about, as it wont be able to tell the individual values of postalAddress apart. So to put it in a nutshell, i'm willing to have a go implementing a postalAddress matching rule, but i was wondering if anyone has any thoughts where i might begin, and/or any pointers as to which file(s) implement the matching rules. Cheers Brett

4 13

poll/epoll patch for libldap?
by Nicholas Dronen 29 Aug '08

29 Aug '08

Hi: I work on a commercial server application, a gateway, which uses pam_ldap to authenticate users in some situations. As a server application, it can easily exceed the 1024 default file descriptor limit of select(2), which has bitten us recently. Since the server application ships in an appliance, we can provide a patch in the form of an OpenLDAP RPM that's been recompiled with -DOPENLDAP_FD_SETSIZE. That fixes the immediate problem for us, but would you be willing to accept a patch to libldap that gave developers a programmatic way to use poll or epoll instead of having to recompile? Regards, Nick

5 8

Re: commit: openldap-guide/admin replication.sdf
by ghenry＠OpenLDAP.org 18 Aug '08

18 Aug '08

----- ghenry(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > replication.sdf 1.62 -> 1.63 > > Log Message: > To do list review: small typo quick fix. This means the following list I've just compiled whilst reviewing the current state of the admin guide and my own todos: # OpenLDAP Test suite * Go through Samba stuff again # OpenLDAP contrib scripts for generating LDIF etc. # OpenLDAP Admin Guide - * Intro o Tighten "LDAP vs RDBMS" o Check "What is slapd and what can it do?" o "Replicated Directory Service" - add MultiMaster picture. * "Configuring slapd" - check DIT layout is right * "The slapd Configuration File" - check backends are correct and in above * "Access Control" - Finish "Converting from slapd.conf(5) to a cn=config directory format" * Backends section to finish * Overlays section to finish * Maintenance section to finish * Monitoring section to finish * Tuning section to finish * More in Troubleshooting section * More in Upgrading from 2.3.x section * Check "Recommended OpenLDAP Software Dependency Versions" section * Do some "Real World OpenLDAP Deployments and Examples" * "OpenLDAP Software Contributions" to complete * "Configuration File Examples" to complete Just e-mailing here for reference. If anyone sees any quick grabs they are interested in ;-) Thanks, Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

What happened to cvs.openldap.org?
by Michael Ströder 17 Aug '08

17 Aug '08

HI! Since yesterday I can't reach the pserver on cvs.OpenLDAP.org anymore. $ cvs up -Rd . cvs [update aborted]: connect to cvs.OpenLDAP.org(204.152.186.56):2401 failed: Connection refused Ciao, Michael.

2 3

Re: commit: ldap/libraries/libldap ldap-tls.h tls2.c tls_g.c tls_m.c tls_o.c ldap-int.h
by Howard Chu 13 Aug '08

13 Aug '08

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > ldap-int.h 1.189 -> 1.190 > Added Files: > ldap-tls.h NONE -> 1.1 > tls2.c NONE -> 1.1 > tls_g.c NONE -> 1.1 > tls_m.c NONE -> 1.1 > tls_o.c NONE -> 1.1 > > Log Message: > Modular TLS support, proof of concept. tls2.c would replace tls.c, > but I'm leaving tls.c intact for now. The GnuTLS and OpenSSL support are working fine; the MozillaNSS support is still pretty broken; it can't initialize itself. (However, it sort of works when linked into a Mozilla app that already does the NSS initialization. See the patch here https://bugzilla.mozilla.org/show_bug.cgi?id=292127 for one example of to accomplish that.) -- -- 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

HEADS UP: tls restructuring
by Howard Chu 13 Aug '08

13 Aug '08

I've split all of the OpenSSL and GnuTLS-specific code into their own separate source files, to clean up some of the #ifdef mess that was in tls.c before. This approach actually allows support for both to be compiled in at the same time. I'll probably add an LDAP_OPT_X option to select which implementation to use at runtime. (It might make sense to make these dynamically loadable modules, but for now I don't want to make libldap dependent on ltdl/dlopen/whatever.) I have not committed these changes yet. Probably will in the next day or two unless there are objections. There's one user-visible change: get_option(LDAP_OPT_X_TLS_SSL_CTX) now returns a pointer to a privately defined structure. For GnuTLS this is in fact the same behavior as before. For OpenSSL this is a change; it used to return the actual (SSL *). If this is going to break something of yours, holler now... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 4

reduced DEFAULT_SEARCH_STACK_DEPTH
by Suhel Momin 12 Aug '08

12 Aug '08

Hi, I want to understand what is the impact of changing following #defines #define DEFAULT_SEARCH_STACK_DEPTH 16 #define MINIMUM_SEARCH_STACK_DEPTH 8 I can see that this value is used to allocate search_stack. I modified these values to #define DEFAULT_SEARCH_STACK_DEPTH 4 #define MINIMUM_SEARCH_STACK_DEPTH 2 This helped in reducing memory footprint however I am not sure about the wide range impact. Thanks, Suhel

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel August 2008