(ITS#6281) Duplicate entries when changing DN on newly created consumer
by tjaviss＠gmail.com
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"
12 years, 8 months
(ITS#6280)
by Donald.Lewis＠Teradata.com
Howard,
This is actaully about libldap_r, not libldap. Does that change
anything?
Regards,
Jeff
12 years, 8 months
Re: (ITS#6280) Race condition in TLS/SSL init code
by hyc＠symas.com
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/
12 years, 8 months
Re: (ITS#6280) Race condition in TLS/SSL init code
by Donald.Lewis＠Teradata.com
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>
<!-- Converted from text/rtf format -->
<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--
12 years, 8 months
(ITS#6280) Race condition in TLS/SSL init code
by donald.lewis＠teradata.com
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.
12 years, 8 months
Re: (ITS#6277) Missing documentation for cn=config
by gavin.henry＠gmail.com
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
12 years, 8 months
Re: (ITS#6277) Missing documentation for cn=config
by hyc＠symas.com
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/
12 years, 8 months
Re: (ITS#6277) Missing documentation for cn=config
by ghenry＠OpenLDAP.org
----- 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/
12 years, 8 months
Re: (ITS#6277) Missing documentation for cn=config
by ryans＠aweber.com
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
12 years, 8 months
