openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6281) Duplicate entries when changing DN on newly created consumer
by tjaviss＠gmail.com 03 Sep '09

03 Sep '09

Full_Name: Tyler A Version: 2.4.11-1 OS: Debian/stable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.77.112.211) When a consumer is created from a clone of the master (slapd off, DB directory cleared. dumped to LDIF on master, LDIF imported on consumer, slapd started), a subsequent transaction that changes the DN of a entry will result in duplicate entries (1 with old DN and 1 with new DN). This might be related to the DB apparently missing the "entryUUID" field on entries, but these do not appear to be created despite the slapd config having "lastmod on"

1 0

(ITS#6280)
by Donald.Lewis＠Teradata.com 03 Sep '09

03 Sep '09

Howard, This is actaully about libldap_r, not libldap. Does that change anything? Regards, Jeff

1 0

Re: (ITS#6280) Race condition in TLS/SSL init code
by hyc＠symas.com 03 Sep '09

03 Sep '09

donald.lewis(a)teradata.com wrote: > Full_Name: Jeff Lewis > Version: 2.4.17 > OS: SuSE Linux, ES9& 10 > URL: > Submission from: (NULL) (153.65.16.10) > > > There appears to be a race condition in SSL/TLS setup in the LDAP client library > bind fucntions. We have workarounds for the problem in 2.3 and 2.4 which we > plan to use until we can get a proper fix so there is no time pressure on you > from my end. Since we have a viable workaround, we're happy leaving the choice > to address the issue or not to you. libldap is not documented to be thread-safe, nor is it intended to be. > 2. If, before the first bind attempt, I invoke ldap_set_option passing a NULL > LDAP pointer, LDAP_OPT_X_TLS_NEWCTX and a value of 0, I do not experience the > problem. We're quite happy with this as a workaround. This supports my belief > that the race is somewhere in the TLS initialization code. > > In 2.3.39 (our current OpenLDAP client), the problem is more severe. When > multiple threads collide in the TLS setup logic, the problem causes TLS to > become completely unusable and no connection can be established to the server. > We've repaired this problem in libraries/libldap/tls.c by calling > ldap_pvt_tls_init through pthread_once and we're quite happy to live with this > until we can get a 2.4 OpenLDAP imported. Your app is responsible for making sure that all libldap init functions are processed before multiple threads are created. Using pthread_once or whatever approach you take is up to you. Closing this ITS. -- -- 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

Re: (ITS#6280) Race condition in TLS/SSL init code
by Donald.Lewis＠Teradata.com 02 Sep '09

02 Sep '09

This is a multi-part message in MIME format. ------_=_NextPart_001_01CA2C19.8E008473 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Forgot to say the the bind functions return -1 when the problem occurs. ------_=_NextPart_001_01CA2C19.8E008473 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>Re: (ITS#6280) Race condition in TLS/SSL init code</TITLE> </HEAD> <BODY>  <P><FONT SIZE=3D2 FACE=3D"Arial">Forgot to say the the bind functions = return -1 when the problem occurs.</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01CA2C19.8E008473--

1 0

(ITS#6280) Race condition in TLS/SSL init code
by donald.lewis＠teradata.com 02 Sep '09

02 Sep '09

Full_Name: Jeff Lewis Version: 2.4.17 OS: SuSE Linux, ES9 & 10 URL: Submission from: (NULL) (153.65.16.10) There appears to be a race condition in SSL/TLS setup in the LDAP client library bind fucntions. We have workarounds for the problem in 2.3 and 2.4 which we plan to use until we can get a proper fix so there is no time pressure on you from my end. Since we have a viable workaround, we're happy leaving the choice to address the issue or not to you. In OpenLDAP release 2.4.17, there is a race condition of some sort when SSL or TLS is used. When two or more threads collide in the SSL/TLS setup code, one or both threads fail to connect. I believe this to be some sort of a one-time initialization problem because it is the first few bind attempts that seem to fail and once one bind succeeds, the rest seem to succeed. We observe this with simple binds using ldap_sasl_bind_s, ldap_simple_bind_s, or ldap_bind_s. We observe it on connections protected with SSL. We also observe it on connections protected with TLS. We do not observe any problems involving normal, unprotected LDAP connections. It would appear that SSL or TLS has to be in play. I've got two workarounds: 1. If I serialize the binds with a mutex, the problem disappears. This is not something we'd want to do in our product because of the large number of binds we have to do in a short period of time. 2. If, before the first bind attempt, I invoke ldap_set_option passing a NULL LDAP pointer, LDAP_OPT_X_TLS_NEWCTX and a value of 0, I do not experience the problem. We're quite happy with this as a workaround. This supports my belief that the race is somewhere in the TLS initialization code. In 2.3.39 (our current OpenLDAP client), the problem is more severe. When multiple threads collide in the TLS setup logic, the problem causes TLS to become completely unusable and no connection can be established to the server. We've repaired this problem in libraries/libldap/tls.c by calling ldap_pvt_tls_init through pthread_once and we're quite happy to live with this until we can get a 2.4 OpenLDAP imported.

1 0

Re: (ITS#6277) Missing documentation for cn=config
by gavin.henry＠gmail.com 02 Sep '09

02 Sep '09

Of course, but Ryan also mentioned the password policy overlay here and loading overlays in general via cn=config. On 01/09/2009, hyc(a)symas.com <hyc(a)symas.com> wrote: > ryans(a)aweber.com wrote: >> Gavin, >> >>> Well there are two places that talk about how to convert from slapd.conf >>> to cn=config formats. In the guide and man pages, so that is the best >>> way to do a full conversion and see the end result. >>> >>> Where would you like to see these added? >>> >>> Thanks for the feedback as always! >> >> My vote would be section 5.2.2.3 of the Admin Guide. Currently, it has 2 >> examples of loading modules consisting of >> libtool libraries, but I would think that it would be good to give an >> example which, for pedagogical purposes, explained >> how to instantiate an overlay in cn=config. For example, ppolicy and >> autogroup: > > autogroup is a contrib module. We only document usage of core features in > the > Admin Guide. > >> dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcPPolicyConfig >> olcOverlay: ppolicy > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: (ITS#6277) Missing documentation for cn=config
by hyc＠symas.com 01 Sep '09

01 Sep '09

ryans(a)aweber.com wrote: > Gavin, > >> Well there are two places that talk about how to convert from slapd.conf >> to cn=config formats. In the guide and man pages, so that is the best >> way to do a full conversion and see the end result. >> >> Where would you like to see these added? >> >> Thanks for the feedback as always! > > My vote would be section 5.2.2.3 of the Admin Guide. Currently, it has 2 examples of loading modules consisting of > libtool libraries, but I would think that it would be good to give an example which, for pedagogical purposes, explained > how to instantiate an overlay in cn=config. For example, ppolicy and autogroup: autogroup is a contrib module. We only document usage of core features in the Admin Guide. > dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcPPolicyConfig > olcOverlay: ppolicy -- -- 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

Re: (ITS#6277) Missing documentation for cn=config
by ghenry＠OpenLDAP.org 01 Sep '09

01 Sep '09

----- ryans(a)aweber.com wrote: > Gavin, > > > Well there are two places that talk about how to convert from > slapd.conf > > to cn=config formats. In the guide and man pages, so that is the > best > > way to do a full conversion and see the end result. > > > > Where would you like to see these added? > > > > Thanks for the feedback as always! > > My vote would be section 5.2.2.3 of the Admin Guide. Hi Ryan, Thanks for the time you spent replying in length. Oh, maybe that time could have been spent writing a patch to docs! ;-) I'll take on board your suggestions and make some changes when I can. Patches welcome! Cheers. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#6277) Missing documentation for cn=config
by ryans＠aweber.com 01 Sep '09

01 Sep '09

Gavin, > Well there are two places that talk about how to convert from slapd.conf > to cn=config formats. In the guide and man pages, so that is the best > way to do a full conversion and see the end result. > > Where would you like to see these added? > > Thanks for the feedback as always! My vote would be section 5.2.2.3 of the Admin Guide. Currently, it has 2 examples of loading modules consisting of libtool libraries, but I would think that it would be good to give an example which, for pedagogical purposes, explained how to instantiate an overlay in cn=config. For example, ppolicy and autogroup: dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy dn: olcOverlay=autogroup,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutomaticGroups olcOverlay: autogroup olcAGattrSet: groupOfNames labeledURI member Perhaps it would also be good to emphasize the need for overlay-specific objectclasses, such as the aforementioned 'olcOverlayConfig' and 'olcPPolicyConfig'. It probably also wouldn't hurt to mention that there are certain overlay-specific attributes, i.e. olcAGattrSet, that are necessary to make full use of the module, and that grepping through the contrib module's source can help one identify said attributes' names in lieu of adequate documentation. Something like: grep -C3 NAME contrib/slapd-modules/autogroup/autogroup.c, maybe? Thanks as always, Ryan

1 0

(ITS#6279) autogroup overlay causes slapcat segfault
by ryans＠aweber.com 31 Aug '09

31 Aug '09

Full_Name: Ryan Steele Version: 2.4.17 OS: Ubuntu URL: http://pastie.org/600973 Submission from: (NULL) (71.230.37.172) When the autogroup overlay directives are included in slapd.conf, it seems to work okay. When adding it to the cn=config DIT, however, it causes segfaults on slapcat. This is version 1.6 of the autogroup overlay (which fixed segfaults when using slapd.conf). Steps to reproduce (starting from a pristine installation) and strace of slapcat are in the pastebin linked below.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs