- openldap-bugs - openldap.org

(ITS#8381) Proposing new mirror for OpenLDAP sources
by dcoutadeur＠linagora.com 07 Mar '16

07 Mar '16

Full_Name: David Coutadeur Version: 2.4.44 OS: Debian 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.103.166.6) Linagora (France) is now hosting a new mirror for OpenLDAP sources. It is available at: http://repository.linagora.org/OpenLDAP/ http://repository.linagora.com/OpenLDAP/ The latter (.com) will not be supported in the long term. Please update MIRRORS file accordingly. Regards, David

1 0

Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro 07 Mar '16

07 Mar '16

On 06/03/16 23:02, Howard Chu wrote: > Daniel Pocock wrote: >> >> >> On 06/03/16 20:49, Howard Chu wrote: >>> Daniel Pocock wrote: >>>> >>>> >>>> On 06/03/16 20:00, Howard Chu wrote: >>>>> daniel(a)pocock.pro wrote: >>>>>> Full_Name: Daniel Pocock >>>>>> Version: >>>>>> OS: Debian >>>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>>> Submission from: (NULL) (2001:1620:b22::2042) >>>>>> >>>>>> >>>>>> There are a few protocols that use a HA1[1] password hash, such as >>>>>> HTTP >>>>>> DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than >>>>>> DIGEST) >>>>>> >>>>>> Is there a standard LDAP attribute name for storing a HA1 value or >>>>>> should it be stored in a regular userPassword attribute as >>>>>> described in >>>>>> the manual[4]? >>>>> >>>>> The ITS is not for usage questions. You already asked this and were >>>>> answered on the discussion mailing list. >>>>> >>>>> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html >>>>> >>>>> There is nothing here that requires any OpenLDAP development activity. >>>>> It's all already handled by the SASL Digest mechanism, as I already >>>>> noted in the above email. >>>>> >>>>> Closing this ITS. >>>> >>>> >>>> I didn't open this feature request to ask for somebody to implement it, >>>> I'm simply trying to track a number of items that I'm working on >>>> myself. >>>> Normally I open a bug/feature request in anything I work on in case >>>> somebody else wants to work on the same thing, it helps avoid >>>> duplication. >>>> >>>> The email thread doesn't fully resolve the issue, it does appear to >>>> require some plugin to be created for the server side, especially if >>>> the >>>> LDAP server doesn't keep plain text passwords. Given the fairly >>>> generic >>>> nature of the DIGEST algorithm, I also felt that when implemented, this >>>> code should be contributed to the OpenLDAP repository and not hosted >>>> elsewhere. >>> >>> Take the hint: RTF SASL Digest code. All the code you're asking for has >>> already been implemented in Cyrus SASL and is of zero concern to >>> OpenLDAP. >>> >>> The most important skill of a programmer is being able to *read* - not >>> being able to write. Any fool can spew code. >>> >> >> I'm not sure if you've seen my reply to the list, it looks like it got >> stuck in moderation >> >> I understand your point about DIGEST and that may well work for HTTP and >> SIP. TURN, however, uses HMAC-SHA1 and that involves sending a copy of >> the entire message body to the authentication server for use in the >> algorithm: >> https://tools.ietf.org/html/rfc5766#page-51 > > You continue to fail to read. > > Pasting this again > > http://www.openldap.org/lists/openldap-technical/201507/msg00073.html > > The required parameters cannot be passed in a Simple Bind request. The > only way to be able to pass what you want and have the server > authenticate it is to use a SASL mechanism. For TURN you may need to > define your own SASL mechanism. > > None of this has anything to do with OpenLDAP. I fully agree with that - the HMAC-SHA1 message verification for TURN, like the DIGEST-MD5 code, would be in Cyrus SASL or in the TURN server (LDAP client). The OpenLDAP manual, s15.2.3 about DIGEST-MD5 explains "it needs access to the plaintext password". The DIGEST-MD5 code that uses the password is here: https://cgit.cyrus.foundation/cyrus-sasl/tree/plugins/digestmd5.c#n440 and it takes the plaintext password and transforms it into a HA1 string. Notice that: HA1 = MD5(user:realm:password) This is a repetitive calculation that does not involve the nonce, salt or any other transient value. HA1 is always the same value for any given user/realm/password permutation. Therefore, OpenLDAP could store HA1 values instead of plaintext values. In fact, Apache already does the same thing with a flat file maintained by the htdigest utility: $ htdigest -c /tmp/test.ha1 example.org daniel instead of storing plaintext values in a file. The HA1 values, not being salted, are still sensitive but some sites may prefer to store the HA1 values instead of plaintext values. So section 15.2.3 could actually be changed: "it needs access to the plaintext password or a password that has already been hashed in HA1" An alternative is that the TURN server process could bind to the LDAP server and then query the HA1 attribute for any user or the HA1 values could be periodically extract into a flat file similar to that created by the htdigest utility. I agree that people who have plaintext passwords don't need to store any HA1 attribute, but if somebody does not have plaintext passwords and does not want to have plaintext passwords, it appears that the HA1 hashing needs to be done in OpenLDAP on password changes. This would also appear to require a change to the Cyrus code so that it can accept either the plaintext or HA1 from the LDAP entry and the slapd auxprop plugin would need to be able to return either attribute. > >> CRAM-MD5 from SASL does HMAC but it does not appear to transfer entire >> message bodies in the manner required for TURN. >> >> DIGEST-MD5 and HMAC-SHA1 both use a HA1 value (or a cleartext password) >> as the lowest common denominator but otherwise they are not the same. >> >>> Your mention of smbk5pwd is totally off base as well. The reason the >>> smbk5pwd module was needed was because Samba 3 and the Kerberos5 KDC >>> both stored their secrets in separate and incompatible formats but >>> everyone wanted central coordinated administration for these separate >>> attributes. If you're writing something from scratch there is no reason >>> to use your own separate and incompatible attribute, and thus there is >>> no reason to require any special synchronization or coordination. >>> >> >> The reason I mentioned that is because it was the closest thing I could >> find to the concept of storing multiple password hashes, but I'm not >> locked in to that strategy. If there are cleartext passwords in LDAP >> then they can be used for all of these algorithms. If the administrator >> does not want to store cleartext values, however, then the salted >> password strings used for UNIX logins are not interchangeable with HA1 >> hashed values, in that case, isn't it necessary to store and synchronize >> multiple values, hashed with each algorithm? > > Once again you're back to software usage questions which is not what the > ITS is for. >

1 0

Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by hyc＠symas.com 06 Mar '16

06 Mar '16

Daniel Pocock wrote: > > > On 06/03/16 20:49, Howard Chu wrote: >> Daniel Pocock wrote: >>> >>> >>> On 06/03/16 20:00, Howard Chu wrote: >>>> daniel(a)pocock.pro wrote: >>>>> Full_Name: Daniel Pocock >>>>> Version: >>>>> OS: Debian >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (2001:1620:b22::2042) >>>>> >>>>> >>>>> There are a few protocols that use a HA1[1] password hash, such as HTTP >>>>> DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than >>>>> DIGEST) >>>>> >>>>> Is there a standard LDAP attribute name for storing a HA1 value or >>>>> should it be stored in a regular userPassword attribute as described in >>>>> the manual[4]? >>>> >>>> The ITS is not for usage questions. You already asked this and were >>>> answered on the discussion mailing list. >>>> >>>> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html >>>> >>>> There is nothing here that requires any OpenLDAP development activity. >>>> It's all already handled by the SASL Digest mechanism, as I already >>>> noted in the above email. >>>> >>>> Closing this ITS. >>> >>> >>> I didn't open this feature request to ask for somebody to implement it, >>> I'm simply trying to track a number of items that I'm working on myself. >>> Normally I open a bug/feature request in anything I work on in case >>> somebody else wants to work on the same thing, it helps avoid >>> duplication. >>> >>> The email thread doesn't fully resolve the issue, it does appear to >>> require some plugin to be created for the server side, especially if the >>> LDAP server doesn't keep plain text passwords. Given the fairly generic >>> nature of the DIGEST algorithm, I also felt that when implemented, this >>> code should be contributed to the OpenLDAP repository and not hosted >>> elsewhere. >> >> Take the hint: RTF SASL Digest code. All the code you're asking for has >> already been implemented in Cyrus SASL and is of zero concern to OpenLDAP. >> >> The most important skill of a programmer is being able to *read* - not >> being able to write. Any fool can spew code. >> > > I'm not sure if you've seen my reply to the list, it looks like it got > stuck in moderation > > I understand your point about DIGEST and that may well work for HTTP and > SIP. TURN, however, uses HMAC-SHA1 and that involves sending a copy of > the entire message body to the authentication server for use in the > algorithm: > https://tools.ietf.org/html/rfc5766#page-51 You continue to fail to read. Pasting this again http://www.openldap.org/lists/openldap-technical/201507/msg00073.html The required parameters cannot be passed in a Simple Bind request. The only way to be able to pass what you want and have the server authenticate it is to use a SASL mechanism. For TURN you may need to define your own SASL mechanism. None of this has anything to do with OpenLDAP. > CRAM-MD5 from SASL does HMAC but it does not appear to transfer entire > message bodies in the manner required for TURN. > > DIGEST-MD5 and HMAC-SHA1 both use a HA1 value (or a cleartext password) > as the lowest common denominator but otherwise they are not the same. > >> Your mention of smbk5pwd is totally off base as well. The reason the >> smbk5pwd module was needed was because Samba 3 and the Kerberos5 KDC >> both stored their secrets in separate and incompatible formats but >> everyone wanted central coordinated administration for these separate >> attributes. If you're writing something from scratch there is no reason >> to use your own separate and incompatible attribute, and thus there is >> no reason to require any special synchronization or coordination. >> > > The reason I mentioned that is because it was the closest thing I could > find to the concept of storing multiple password hashes, but I'm not > locked in to that strategy. If there are cleartext passwords in LDAP > then they can be used for all of these algorithms. If the administrator > does not want to store cleartext values, however, then the salted > password strings used for UNIX logins are not interchangeable with HA1 > hashed values, in that case, isn't it necessary to store and synchronize > multiple values, hashed with each algorithm? Once again you're back to software usage questions which is not what the ITS is for. -- -- 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#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro 06 Mar '16

06 Mar '16

On 06/03/16 20:49, Howard Chu wrote: > Daniel Pocock wrote: >> >> >> On 06/03/16 20:00, Howard Chu wrote: >>> daniel(a)pocock.pro wrote: >>>> Full_Name: Daniel Pocock >>>> Version: >>>> OS: Debian >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (2001:1620:b22::2042) >>>> >>>> >>>> There are a few protocols that use a HA1[1] password hash, such as HTTP >>>> DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than >>>> DIGEST) >>>> >>>> Is there a standard LDAP attribute name for storing a HA1 value or >>>> should it be stored in a regular userPassword attribute as described in >>>> the manual[4]? >>> >>> The ITS is not for usage questions. You already asked this and were >>> answered on the discussion mailing list. >>> >>> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html >>> >>> There is nothing here that requires any OpenLDAP development activity. >>> It's all already handled by the SASL Digest mechanism, as I already >>> noted in the above email. >>> >>> Closing this ITS. >> >> >> I didn't open this feature request to ask for somebody to implement it, >> I'm simply trying to track a number of items that I'm working on myself. >> Normally I open a bug/feature request in anything I work on in case >> somebody else wants to work on the same thing, it helps avoid >> duplication. >> >> The email thread doesn't fully resolve the issue, it does appear to >> require some plugin to be created for the server side, especially if the >> LDAP server doesn't keep plain text passwords. Given the fairly generic >> nature of the DIGEST algorithm, I also felt that when implemented, this >> code should be contributed to the OpenLDAP repository and not hosted >> elsewhere. > > Take the hint: RTF SASL Digest code. All the code you're asking for has > already been implemented in Cyrus SASL and is of zero concern to OpenLDAP. > > The most important skill of a programmer is being able to *read* - not > being able to write. Any fool can spew code. > I'm not sure if you've seen my reply to the list, it looks like it got stuck in moderation I understand your point about DIGEST and that may well work for HTTP and SIP. TURN, however, uses HMAC-SHA1 and that involves sending a copy of the entire message body to the authentication server for use in the algorithm: https://tools.ietf.org/html/rfc5766#page-51 CRAM-MD5 from SASL does HMAC but it does not appear to transfer entire message bodies in the manner required for TURN. DIGEST-MD5 and HMAC-SHA1 both use a HA1 value (or a cleartext password) as the lowest common denominator but otherwise they are not the same. > Your mention of smbk5pwd is totally off base as well. The reason the > smbk5pwd module was needed was because Samba 3 and the Kerberos5 KDC > both stored their secrets in separate and incompatible formats but > everyone wanted central coordinated administration for these separate > attributes. If you're writing something from scratch there is no reason > to use your own separate and incompatible attribute, and thus there is > no reason to require any special synchronization or coordination. > The reason I mentioned that is because it was the closest thing I could find to the concept of storing multiple password hashes, but I'm not locked in to that strategy. If there are cleartext passwords in LDAP then they can be used for all of these algorithms. If the administrator does not want to store cleartext values, however, then the salted password strings used for UNIX logins are not interchangeable with HA1 hashed values, in that case, isn't it necessary to store and synchronize multiple values, hashed with each algorithm? Regards, Daniel

1 0

Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by hyc＠symas.com 06 Mar '16

06 Mar '16

Daniel Pocock wrote: > > > On 06/03/16 20:00, Howard Chu wrote: >> daniel(a)pocock.pro wrote: >>> Full_Name: Daniel Pocock >>> Version: >>> OS: Debian >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (2001:1620:b22::2042) >>> >>> >>> There are a few protocols that use a HA1[1] password hash, such as HTTP >>> DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) >>> >>> Is there a standard LDAP attribute name for storing a HA1 value or >>> should it be stored in a regular userPassword attribute as described in >>> the manual[4]? >> >> The ITS is not for usage questions. You already asked this and were >> answered on the discussion mailing list. >> >> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html >> >> There is nothing here that requires any OpenLDAP development activity. >> It's all already handled by the SASL Digest mechanism, as I already >> noted in the above email. >> >> Closing this ITS. > > > I didn't open this feature request to ask for somebody to implement it, > I'm simply trying to track a number of items that I'm working on myself. > Normally I open a bug/feature request in anything I work on in case > somebody else wants to work on the same thing, it helps avoid duplication. > > The email thread doesn't fully resolve the issue, it does appear to > require some plugin to be created for the server side, especially if the > LDAP server doesn't keep plain text passwords. Given the fairly generic > nature of the DIGEST algorithm, I also felt that when implemented, this > code should be contributed to the OpenLDAP repository and not hosted > elsewhere. Take the hint: RTF SASL Digest code. All the code you're asking for has already been implemented in Cyrus SASL and is of zero concern to OpenLDAP. The most important skill of a programmer is being able to *read* - not being able to write. Any fool can spew code. Your mention of smbk5pwd is totally off base as well. The reason the smbk5pwd module was needed was because Samba 3 and the Kerberos5 KDC both stored their secrets in separate and incompatible formats but everyone wanted central coordinated administration for these separate attributes. If you're writing something from scratch there is no reason to use your own separate and incompatible attribute, and thus there is no reason to require any special synchronization or coordination. -- -- 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#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro 06 Mar '16

06 Mar '16

On 06/03/16 20:00, Howard Chu wrote: > daniel(a)pocock.pro wrote: >> Full_Name: Daniel Pocock >> Version: >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:1620:b22::2042) >> >> >> There are a few protocols that use a HA1[1] password hash, such as HTTP >> DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) >> >> Is there a standard LDAP attribute name for storing a HA1 value or >> should it be stored in a regular userPassword attribute as described in >> the manual[4]? > > The ITS is not for usage questions. You already asked this and were > answered on the discussion mailing list. > > http://www.openldap.org/lists/openldap-technical/201507/msg00073.html > > There is nothing here that requires any OpenLDAP development activity. > It's all already handled by the SASL Digest mechanism, as I already > noted in the above email. > > Closing this ITS. I didn't open this feature request to ask for somebody to implement it, I'm simply trying to track a number of items that I'm working on myself. Normally I open a bug/feature request in anything I work on in case somebody else wants to work on the same thing, it helps avoid duplication. The email thread doesn't fully resolve the issue, it does appear to require some plugin to be created for the server side, especially if the LDAP server doesn't keep plain text passwords. Given the fairly generic nature of the DIGEST algorithm, I also felt that when implemented, this code should be contributed to the OpenLDAP repository and not hosted elsewhere. Regards, Daniel

1 0

Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by hyc＠symas.com 06 Mar '16

06 Mar '16

daniel(a)pocock.pro wrote: > Full_Name: Daniel Pocock > Version: > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:1620:b22::2042) > > > There are a few protocols that use a HA1[1] password hash, such as HTTP > DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) > > Is there a standard LDAP attribute name for storing a HA1 value or > should it be stored in a regular userPassword attribute as described in > the manual[4]? The ITS is not for usage questions. You already asked this and were answered on the discussion mailing list. http://www.openldap.org/lists/openldap-technical/201507/msg00073.html There is nothing here that requires any OpenLDAP development activity. It's all already handled by the SASL Digest mechanism, as I already noted in the above email. Closing this ITS. > I came across smbk5pwd for keeping SMB password attributes in sync. Is > there a similar facility for keeping HA1 passwords in sync when a user > changes the password or how could a developer go about adding that, > would the smbk5pwd source be a useful model? > > Discussed on the mailing list already[5] > > 1. http://tools.ietf.org/html/rfc2617#section-3 > 2. https://tools.ietf.org/html/rfc3261#cection-22.4 > 3. https://tools.ietf.org/html/rfc5389#section-15.4 > 4. http://www.openldap.org/doc/admin24/security.html#Password%20Storage > 5. http://www.openldap.org/lists/openldap-technical/201507/msg00039.html > > -- -- 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

(ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro 06 Mar '16

06 Mar '16

Full_Name: Daniel Pocock Version: OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:1620:b22::2042) There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST) Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]? I came across smbk5pwd for keeping SMB password attributes in sync. Is there a similar facility for keeping HA1 passwords in sync when a user changes the password or how could a developer go about adding that, would the smbk5pwd source be a useful model? Discussed on the mailing list already[5] 1. http://tools.ietf.org/html/rfc2617#section-3 2. https://tools.ietf.org/html/rfc3261#cection-22.4 3. https://tools.ietf.org/html/rfc5389#section-15.4 4. http://www.openldap.org/doc/admin24/security.html#Password%20Storage 5. http://www.openldap.org/lists/openldap-technical/201507/msg00039.html

1 0

(ITS#8379) URL changes for funded and managed
by mhardin＠symas.com 02 Mar '16

02 Mar '16

Full_Name: Matthew Hardin Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.109.202.222) Thank you for the attribution for the management and hosting of the openldap.org website. We respectfully request the following changes to the URLs for the logos: 1. Please change the link URL for the "Site funded and managed by" logo to: https://symas.com/about-openldap/?utm_source=OpenLDAP&utm_medium=ctr&utm_ca… 2. Please change the link URL for the "Hosting provided by" logo to: http://symas.com/?utm_source=openldap&utm_medium=ctr&utm_campaign=OpenLdapH… Thanks

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 01 Mar '16

01 Mar '16

Oh, and one more observation, the result is intermittent. The starttls connection actually fails as it is supposed to, something like 1/100 attempts. Martin....

1 0

Re: (ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
by jonathan＠phillipoux.net 29 Feb '16

29 Feb '16

The patch I originally sent works only for MODRDN operations, but causes a segfault on plain old ADD operations in some cases. This is caused by the hdb_dn2id_children function trying to update dkids inside a non-initialised structure. I figure that if we don't have the structure we don't need to update it, since this function is mostly a "search" function. Hope that makes sense. A new patch is here: ftp://www.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete-2… Jonathan

1 0

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 29 Feb '16

29 Feb '16

This patch fixes a problem in the closing of timed-out connections to targets in back-asyncmeta. If a a_metaconn is still in use for another target, the connections to other targets might not be reset while the mc is still active, even if these targets are no longer in use. This patch introduces counters for pending operations per a_metasingleconn, and resets a metasingleconn if it has timed out and has no pending operations. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160229.patch

1 0

Re: RE : Re: Fwd: (ITS#8331) Download mirror list needs updating
by hyc＠symas.com 26 Feb '16

26 Feb '16

For tracking: David Coutadeur wrote: > > Hi Howard, > > Job done. The repository is available at: > http://repository.linagora.com/OpenLDAP/ > > > Regards, > > David > > Le 17/02/2016 14:59, Howard Chu a écrit : >> David Coutadeur wrote: >>> >>> Hi Howard, >>> >>> I didn't came back on you with that, but the proposition is still opened >>> if it is ok for you. >> >> Sure, sounds great. >> >> It turns out to be very simple, just use rsync. The set of available >> targets can be seen using >> rsync --list-only rsync://openldap.org >> >> The releases are in OpenLDAP-ftp. The CVS repo is also available but >> that's only of historical interest since we're now on git. >> >>> >>> David >>> >>> >>> Le 10/12/2015 09:08, dcoutadeur a écrit : >>>> Ok, thank you for the reply. >>>> Let me know when you have the information. >>>> >>>> David >>>> >>>> >>>> >>>> <br><br>-------- Message d'origine --------<br>De : Howard Chu >>>> <hyc(a)symas.com> <br>Date : 08/12/2015 17:49 (GMT+01:00) <br>À >>>> : David Coutadeur <dcoutadeur(a)linagora.com> <br>Objet : Re: >>>> Fwd: (ITS#8331) Download mirror list needs updating <br><br> >>>> >>>> >>>> >>>> David Coutadeur wrote: >>>> > >>>> > Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>> > >>>> > Linagora (France) would be very interested to host a new mirror >>>> for OpenLDAP. >>>> > Do you have an idea of how many connections we should support ? >>>> And what >>>> > bandwidth ? I have made some statistics on an active mirror to >>>> find out the >>>> > data volume. For now it is about 1GB, so I assume 10 GB will be >>>> sufficient for >>>> > many years ? >>>> > >>>> > If you have one, can you also give me a procedure / indications >>>> for building >>>> > the platform ? >>>> > >>>> > Regards, >>>> > >>>> > >>>> > Le 04/12/2015 16:04, Howard Chu a écrit : >>>> >> A number of the mirror sites have gone offline over the years. >>>> Anyone >>>> >> interested in running a new mirror for us? >>>> >> >>>> >> -------- Forwarded Message -------- >>>> >> Subject: (ITS#8331) Download mirror list needs updating >>>> >> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>> >> From: andrew.findlay(a)skills-1st.co.uk >>>> >> To: openldap-its(a)OpenLDAP.org >>>> >> >>>> >> Full_Name: Andrew Findlay >>>> >> Version: >>>> >> OS: >>>> >> URL: ftp://ftp.openldap.org/incoming/ >>>> >> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>> >> >>>> >> >>>> >> The Netherlands mirror has vanished: ftp.nl.uu.net does not >>>> resolve in DNS. >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>>> -- >>>> -- Howard Chu >>>> CTO, Symas Corp. http://www.symas.com >>>> Director, Highland Sun http://highlandsun.com/hyc/ >>>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>>> >>>> >>>> >>>> David Coutadeur wrote: >>>>> >>>>> Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>>> >>>>> Linagora (France) would be very interested to host a new mirror for >>>>> OpenLDAP. >>>>> Do you have an idea of how many connections we should support ? And >>>>> what >>>>> bandwidth ? I have made some statistics on an active mirror to find >>>>> out the >>>>> data volume. For now it is about 1GB, so I assume 10 GB will be >>>>> sufficient for >>>>> many years ? >>>>> >>>>> If you have one, can you also give me a procedure / indications for >>>>> building >>>>> the platform ? >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Le 04/12/2015 16:04, Howard Chu a écrit : >>>>>> A number of the mirror sites have gone offline over the years. Anyone >>>>>> interested in running a new mirror for us? >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: (ITS#8331) Download mirror list needs updating >>>>>> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>>>> From: andrew.findlay(a)skills-1st.co.uk >>>>>> To: openldap-its(a)OpenLDAP.org >>>>>> >>>>>> Full_Name: Andrew Findlay >>>>>> Version: >>>>>> OS: >>>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>>> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>>>> >>>>>> >>>>>> The Netherlands mirror has vanished: ftp.nl.uu.net does not resolve >>>>>> in DNS. -- -- 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

(ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
by jonathan＠phillipoux.net 23 Feb '16

23 Feb '16

Full_Name: Jonathan Clarke Version: 2.4.44 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.182.31.158) Hi there, I found a bug in the handling of idl_cache when doing a MODRDN operation on an entry with children. The existing code to add an entry in hdb_dn2id_add (dn2id.c) cleverly updates any existing IDL caches on the new parent and any grand-parents, both for "one" and "sub" level searches by adding the new entry in those cache lists. However, if you MODRDN an entry that also has children, this same hdb_dn2id_add function is called, and will erroneously update the "sub" level search caches on the new parent and any grand-parents, adding only the new entry, and not it's children. The result is that a search that hits that IDL cache will return partial results, including the entry that was moved, but missing it's children. You can observe this behaviour by compiling a standard OpenLDAP server, configuring a simple hdb backend, including a non-zero idlcachesize and running the following commands: 1) ldapadd < tesldldif 2) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit 3) ldapmodrdn -s "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" "ou=1234,ou=Pending Inventories,ou=Inventorie2C2Ccn=rudder-configuration" "ou=1234" 4) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit It is important to run the initial search in step 2, before the MODRDN operation itself, to ensure an IDL cache entry is created for that search. The final search in step 4 will not show the sub-entry ou=1234-sub,ou=1234. The test.ldif file is here: ftp://ftp.openldap.org/incoming/test.ldif I've created a quick'n'dirty patch to hide this issue, which detects the situation (if adding an entry that already has children, this is when the bug occurs) and simply removes the IDL cache to avoid future searches using it. It's available here: ftp://ftp.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete.p…. A better solution would probably be to write the code to add each child of the new entry to existing caches, but I couldn't immediately see how to do this. Hopefully my patch above will easily show where this needs doing. Regards, Jonathan

1 0

(ITS#8377) Normalized 'olcDbIndex' values
by michael＠stroeder.com 22 Feb '16

22 Feb '16

Full_Name: Version: master OS: URL: Submission from: (NULL) (213.240.182.49) A suggestion for 2.5: Index lines read from slapd.conf should be converted to normalized 'olcDbIndex' values. With this approach it would be possible to determine index configuration for a certain attribute type. Likewise the format of accepted attribute values should be constrained. Example from slapd.conf: index foo,bar eq,sub would be normalized to 4 values: olcDbIndex: foo eq olcDbIndex: foo sub olcDbIndex: bar eq olcDbIndex: bar sub

1 0

(ITS#8376) Use getaddrinfo to resolve FQDN
by hguo＠suse.com 22 Feb '16

22 Feb '16

Full_Name: Howard Guo Version: 2.4.44 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.135.221.2) In a pure IPv6 environment, if LDAP is used as the host resolve, the host may hang when it attempts to resolve its own host name due to usage of gethostbyname*, in the following sequence of events: nss_ldap: locks mutex nss_ldap: calls libldapA-A-> libldap: gethostbyname -> nss_ldap: lock mutex and hang See patch file "howard-guo-160222.patch".

1 0

(ITS#8375) paged results control results in full db search?
by geert＠hendrickx.be 22 Feb '16

22 Feb '16

Full_Name: Geert Hendrickx Version: 2.4.44 OS: Linux URL: http://www.openldap.org/lists/openldap-technical/201602/msg00094.html Submission from: (NULL) (2a02:1810:4d03:d00:18e9:3ca5:a68f:c7f4) We found an odd issue when using LDAP Admin (www.ldapadmin.org), which by defaults uses the paged results control (RFC 2696) to limit search results. This client initially issues an objectclass=* search with one-level scope to list the first-level objects/trees on the LDAP DIT, which you can then browse/expand by clicking on them. On a large db, we noticed this initial search hits the timelimit, even though the equivalent command line search is instant. I found the difference is in using the paged result control: ldapsearch -s one -E \!pr=100 objectclass=\* objectclass => slow ldapsearch -s one objectclass=\* objectclass => fast The slapd stats+trace logging of each is in attachment. Notice the large number of objects being skipped with "scope not okay" in the first, where this does not happen in the second. This slows down the search, and on a very large db, makes it exceed the configured 60 seconds timelimit. A third variant, setting the sizelimit explicitly, avoids the issue: ldapsearch -s one -E \!pr=100 -z 100 objectclass=\* objectclass => fast Is this expected behaviour?

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 21 Feb '16

21 Feb '16

Ok, retested with latest code built from source. I also reconfirmed using a publicly available openldap server, to make sure it isn't something stupid I am doing locally. So you can reproduce easily, the test pseudo code is: ldap_initialize (ldaps://ldap.andrew.cmu.edu) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_sasl_bind_s ldap_initialize (ldap://128.2.11.104) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_start_tls_s ldap_sasl_bind_s The results are: Server with valid certificate, all values of LDAP_OPT_X_TLS_REQUIRE_CERT for both ldaps and ldap+starttls connect. This is what I would expect. Server with invalid certificate (IP does not match the cert FQDN), only NEVER and ALLOW values of LDAP_OPT_X_TLS_REQUIRE_CERT succeed for ldaps (this is what I would expect) however all values of LDAP_OPT_X_TLS_REQUIRE_CERT for ldap+starttls succeed, which is not what I would expect: I think that the certificate check should fail the connection, as per the ldaps behaviour. Martin...

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 21 Feb '16

21 Feb '16

Hi, This is a piece of code that I'm working on, rather than any bundled commands. The code works just fine (has for months) however I noticed in unit testing the operations empirically that the LDAP_OPT_X_TLS_REQUIRE_CERT option was handled differently depending on whether the TLS was provided implicitly over an ldaps: URI, or explicitly on an ldap: URI with STARTTLS. The pseudo sequence of functions is as follows: ldap_initialize ldap_set_option (various) if uri != ldaps: then ldap_start_tls_s ldap_sasl_bind_s Martin...

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by hyc＠symas.com 20 Feb '16

20 Feb '16

dog(a)pavlov.com wrote: > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then drop you a line with the results. What commands are you testing with? Are you using STARTTLS as a critical extension? If not, failures will be ignored. Note that this is already documented. -- -- 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#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by quanah＠zimbra.com 20 Feb '16

20 Feb '16

--On Saturday, February 20, 2016 6:06 PM +0000 dog(a)pavlov.com wrote: > > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap > to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then > drop you a line with the results. Again, you could just install the builds from the LTB project. In any case, all options work fine for me with a self-signed cert with ldaps:/// URIs. (2.4.44, linked to OpenSSL). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 20 Feb '16

20 Feb '16

Hi, The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. If I get time I'll run up a test platform and install from source, then drop you a line with the results. Martin...

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by quanah＠zimbra.com 20 Feb '16

20 Feb '16

--On Friday, February 19, 2016 4:02 PM +0000 dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 As already noted by Michael, that is an ancient release. In addition, since you're using a build provided by Debian/Ubuntu, it links to GnuTLS which has its own numerous issues. I'd strongly advise you: (a) Use a current OpenLDAP release (b) Use an OpenLDAP release that is linked to OpenSSL rather than GnuTLS If after both of those conditions are true you can still reproduce a problem, please follow up. If building OpenLDAP software is not in your line of expertise, you may wish to examine the options from the LTB project or Symas. <http://ltb-project.org/wiki/download#openldap> <https://symas.com/products/openldap-directory/> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by michael＠stroeder.com 20 Feb '16

20 Feb '16

dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 Note that 2.4.31 is almost for years old. Hence the standard question: Can you reproduce this with current release 2.4.44? Ciao, Michael.

1 0

(ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 19 Feb '16

19 Feb '16

Full_Name: Martin O'Neal Version: openldap-2.4.31 OS: ubuntu wily URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.68.2.190) The handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with a self-signed certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK try Error: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK try OK

1 0

Re: (ITS#8373) replica with multiple providers hits errors
by quanah＠zimbra.com 19 Feb '16

19 Feb '16

--On Friday, February 19, 2016 12:37 AM +0000 quanah(a)zimbra.com wrote: > --On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: So I can trivially reproduce this. I make a change on each master, and boom, they go out of sync and everything's broken. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8373) replica with multiple providers hits errors
by quanah＠zimbra.com 19 Feb '16

19 Feb '16

--On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: > Master SID1: > [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w > zimbra -s base -b "" contextCSN > dn: > contextCSN: 20160218220547.523250Z#000000#001#000000 > contextCSN: 20160218220604.321502Z#000000#002#000000 > > [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w > zimbra -s base -b "cn=accesslog" contextCSN > dn: cn=accesslog > contextCSN: 20160217223749.648918Z#000000#001#000000 > contextCSN: 20160218220604.321502Z#000000#002#000000 Ooops, clearly a difference here between the main db and the accesslog DB. However, nothing was logged, error wise. Here is this modification: Feb 18 16:05:47 zre-ldap005 slapd[10555]: slap_queue_csn: queueing 0x3ce84c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap005 slapd[10555]: slap_graduate_commit_csn: removing 0x3ce84c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap005 slapd[10555]: syncprov_sendresp: cookie=rid=100,sid=001 Feb 18 16:05:47 zre-ldap005 slapd[10555]: syncprov_sendresp: to=002, cookie=rid=100,sid=001 On the other master, we have: Feb 18 16:05:47 zre-ldap003 slapd[6947]: do_syncrep2: rid=100 cookie=rid=100,sid=001 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_queue_csn: queueing 0x36d58c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_queue_csn: queueing 0x36d5800 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncprov_matchops: skipping original sid 001 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_graduate_commit_csn: removing 0x36d5800 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_graduate_commit_csn: removing 0x36d58c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncrepl_message_to_op: rid=100 be_modify cn=admins,cn=zimbra (0) Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncprov_sendresp: cookie=rid=101,sid=002,csn=20160218220547.523250Z#000000#001#000000 In the accesslog, we have: dn: reqStart=20160218220547.523064Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20160218220547.523064Z reqEnd: 20160218220547.523558Z reqType: modify reqSession: 1027 reqAuthzID: cn=config reqDN: cn=admins,cn=zimbra reqResult: 0 reqMod: description:= admin accounts reqMod: entryCSN:= 20160218220547.523250Z#000000#001#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20160218220547Z reqEntryUUID: c3fbf53a-6a0c-1035-9563-ef445d2cc3b6 entryCSN: 20160218220547.523250Z#000000#001#000000 entryUUID: 822e1680-6ad7-1035-8bac-2751986a6fb8 creatorsName: cn=config createTimestamp: 20160218220547Z modifiersName: cn=config modifyTimestamp: 20160218220547Z --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8373) replica with multiple providers hits errors
by quanah＠zimbra.com 19 Feb '16

19 Feb '16

--On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: After stopping all servers, and restarting the masters, I see the same error (53) being returned when zre-ldap003 tries to connect to zre-ldap005. So this is not specific to the replica or the change to cn=config I made on the replica. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8373) replica with multiple providers hits errors
by quanah＠openldap.org 19 Feb '16

19 Feb '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 3.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) I have a MMR setup, with two providers, zre-ldap003 and zre-ldap005. I have a single replica, zre-ldap002, which is configured to pull updates from both providers. However, it continually gets an error 53 from zre-ldap005 after writing an update to zre-ldap003. As far as I can tell, all contextCSN data is correct on all nodes. replica: zimbra@zre-ldap002:~$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 Master SID1: [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "cn=accesslog" contextCSN dn: cn=accesslog contextCSN: 20160217223749.648918Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 Master SID2: [zimbra@zre-ldap003 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 [zimbra@zre-ldap003 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "cn=accesslog" contextCSN dn: cn=accesslog contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000%%0 Note all contextCSNs have the same value everywhere. However, when the replica attempts to replicate off of zre-ldap005, we get the following error: Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 fd=18 ACCEPT from IP=10.137.242.52:38979 (IP=10.137.242.55:389) Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=0 STARTTLS Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=0 RESULT oid= err=0 etime=0.000071 text= Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 fd=18 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.2 tls_cipher=SEED-SHA Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" metho3D3D128 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=1 RESULT tag=97 err=0 etime=0.000154 text= Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=2 SEARCH RESULT tag=101 err=53 etime=0.000177 nentries=0 text=consumer state is newer than provider! Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=3 UNBIND Feb 18 16:50:34 zre-ldap5 5 slapd[10555]: conn=1191 fd=18 closed This started happening after I made a modification on zre-ldap005 followed by a modification on zre-ldap003. In that case, the following was logged on zre-ldap002: Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=101 cookie=rid=101,sid=002,csn=20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3589880 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 cookie=r%3=100,sid=001,csn=20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3589880 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: syncrepl_message_to_op: rid=101 be_modify cn=admins,cn=zimbra (0) Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3589740 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3589740 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 CSN pending, ignoring 20160218220604.321502Z#000000#002#000000 (reqStart=20160218220604.326527Z,cn=accesslog) So we see the write accepted from one master, and correctly rejected (not replayed) from the other. After this, there were no more modifications made to either master. However, I *did* make a modification to cn=config on the replica. After that was done, is when the error(53) started getting triggered: Feb 18 16:27:12 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3587a40 20160218222712.155976Z#000000#000#000000 Feb 18 16:27:12 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3587a40 20160218222712.155976Z#000000#000#000000 Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 (53) Server is unwilling to perform Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrepl: rid=100 rc -2 retrying

1 0

(ITS#8372) Incomplete members from dynlist group when Paged Results control is specified
by subbarao＠computer.org 15 Feb '16

15 Feb '16

Full_Name: Kartik Subbarao Version: 2.4.41 OS: Ubuntu 14.04.3 LTS URL: ftp://ftp.openldap.org/incoming/kartik-subbarao-160215.tgz Submission from: (NULL) (173.75.228.155) When the Paged Results control (1.2.840.113556.1.4.319) is specified, dynlist groups after the first page return fewer numbers than should be present. I have uploaded slapd.conf and example.ldif files that can be used to reproduce the problem. Search with a page size of 1 and the filter (objectclass=groupOfURLs). The member for group1 is returned successfully, whereas no members for group2 are returned. If the page size is set to 2 or higher, the member for group2 is properly returned. ftp://ftp.openldap.org/incoming/kartik-subbarao-160215.tgz: slapd.conf example.ldif For additional context, see this post to the openldap-technical mailing list: http://www.openldap.org/lists/openldap-technical/201602/msg00102.html

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by quanah＠zimbra.com 12 Feb '16

12 Feb '16

--On Friday, February 12, 2016 1:40 PM -0600 kevin martin=20 <ktmdms(a)gmail.com> wrote: > > Hmm, the configure command I used was: > > > ./configure --with-tls=3Dopenssl --enable-modules --enable-syncprov > --enable-seqmod =C2=A0--enable-sssvlv --enable-ppolicy --enable-accesslog > --enable-passwd --enable-monitor --enable-bdb --enable-syslog > > > > but when I get to "make install" no contrib get's made or installed. > =C2=A0sha2 is part of contrib/slapd-modules/passwd and I don't see = anything > in configure that allows you to source in any of the contrib stuff so > yes, I appear to have missed compiling and installing the updated sha2 > modules. Right, contrib items are not built as part of the overall process. They=20 are contributions, not part of the core product. You have to individually=20 build and install the ones you want. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by ktmdms＠gmail.com 12 Feb '16

12 Feb '16

--001a113f36ea472c2d052b97d94d Content-Type: text/plain; charset=UTF-8 Hmm, the configure command I used was: ./configure --with-tls=openssl --enable-modules --enable-syncprov --enable-seqmod --enable-sssvlv --enable-ppolicy --enable-accesslog --enable-passwd --enable-monitor --enable-bdb --enable-syslog but when I get to "make install" no contrib get's made or installed. sha2 is part of contrib/slapd-modules/passwd and I don't see anything in configure that allows you to source in any of the contrib stuff so yes, I appear to have missed compiling and installing the updated sha2 modules. Thanks for the help; I was hard pressed to figure this out myself! Kevin --- Regards, Kevin Martin On Fri, Feb 12, 2016 at 1:33 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, February 12, 2016 7:29 PM +0000 ktmdms(a)gmail.com wrote: > > --001a113f36ea7f617e052b97afc7 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: quoted-printable >> >> So after installing with STRIP=3D"" I noticed that the pw-sha2.a and .so >> were a bit older than the openldap software so I recompiled that as well >> and installed it and the crashing stopped. I've since installed the >> stripped version again and it doesn't crash so I think the problem ended >> up being in the pw-sha2 module. >> > > Sounds like your build process doesn't correctly install/update all the > components you're using then. ;) > > Closing this ITS. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > --001a113f36ea472c2d052b97d94d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hmm, the configure command I used was:<div><br></div><div>= ./configure --with-tls=3Dopenssl --enable-modules --enable-syncprov --enabl= e-seqmod =C2=A0--enable-sssvlv --enable-ppolicy --enable-accesslog --enable= -passwd --enable-monitor --enable-bdb --enable-syslog<br></div><div><br></d= iv><div>but when I get to "make install" no contrib get's mad= e or installed. =C2=A0sha2 is part of contrib/slapd-modules/passwd and I do= n't see anything in configure that allows you to source in any of the c= ontrib stuff so yes, I appear to have missed compiling and installing the u= pdated sha2 modules.</div><div><br></div><div>Thanks for the help; I was ha= rd pressed to figure this out myself!</div><div><br></div><div>Kevin</div><= /div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail_= signature"><div dir=3D"ltr">---<div><span style=3D"font-size:12.8px"><br></= span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><spa= n style=3D"font-size:12.8px">Regards,</span></div><div><div><br></div><div>= Kevin Martin</div></div></div></div></div> <br><div class=3D"gmail_quote">On Fri, Feb 12, 2016 at 1:33 PM, Quanah Gibs= on-Mount <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target= =3D"_blank">quanah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex">--On Friday, February 12, 2016 7:29 PM +0000 <a href=3D"mailto:k= tmdms(a)gmail.com" target=3D"_blank">ktmdms(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --001a113f36ea7f617e052b97afc7<br> Content-Type: text/plain; charset=3DUTF-8<br> Content-Transfer-Encoding: quoted-printable<br> <br> So after installing with STRIP=3D3D""=C2=A0 I noticed that the pw= -sha2.a and .so<span class=3D""><br> were a bit older than the openldap software so I recompiled that as well<br= > and installed it and the crashing stopped.=C2=A0 I've since installed t= he<br> stripped version again and it doesn't crash so I think the problem ende= d<br> up being in the pw-sha2 module.<br> </span></blockquote> <br> Sounds like your build process doesn't correctly install/update all the= components you're using then. ;)<br> <br> Closing this ITS.<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Platform Architect<br> Zimbra, Inc.<br> --------------------<br> Zimbra ::=C2=A0 the leader in open source messaging and collaboration<br> A division of Synacor, Inc<br> </div></div></blockquote></div><br></div> --001a113f36ea472c2d052b97d94d--

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by quanah＠zimbra.com 12 Feb '16

12 Feb '16

--On Friday, February 12, 2016 7:29 PM +0000 ktmdms(a)gmail.com wrote: > --001a113f36ea7f617e052b97afc7 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > So after installing with STRIP=3D"" I noticed that the pw-sha2.a and .so > were a bit older than the openldap software so I recompiled that as well > and installed it and the crashing stopped. I've since installed the > stripped version again and it doesn't crash so I think the problem ended > up being in the pw-sha2 module. Sounds like your build process doesn't correctly install/update all the components you're using then. ;) Closing this ITS. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by ktmdms＠gmail.com 12 Feb '16

12 Feb '16

--001a113f36ea7f617e052b97afc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So after installing with STRIP=3D"" I noticed that the pw-sha2.a and .so were a bit older than the openldap software so I recompiled that as well and installed it and the crashing stopped. I've since installed the stripped version again and it doesn't crash so I think the problem ended up being in the pw-sha2 module. Kevin --- Regards, Kevin Martin On Fri, Feb 12, 2016 at 11:41 AM, Michael Str=C3=B6der <michael(a)stroeder.co= m> wrote: > ktmdms(a)gmail.com wrote: > > Should I add STRIP=3D"" in the Makefile or is there a way to add that o= n > the > > configure line? > > You can simply use > > make install STRIP=3D"" > > Ciao, Michael. > --001a113f36ea7f617e052b97afc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">So after installing with STRIP=3D"" =C2=A0I noti= ced that the pw-sha2.a and .so were a bit older than the openldap software = so I recompiled that as well and installed it and the crashing stopped.=C2= =A0 I've since installed the stripped version again and it doesn't = crash so I think the problem ended up being in the pw-sha2 module.<div><br>= </div><div>Kevin</div></div><div class=3D"gmail_extra"><br clear=3D"all"><d= iv><div class=3D"gmail_signature"><div dir=3D"ltr">---<div><span style=3D"f= ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px"><br= ></span></div><div><span style=3D"font-size:12.8px">Regards,</span></div><d= iv><div><br></div><div>Kevin Martin</div></div></div></div></div> <br><div class=3D"gmail_quote">On Fri, Feb 12, 2016 at 11:41 AM, Michael St= r=C3=B6der <span dir=3D"ltr"><<a href=3D"mailto:michael@stroeder.com" ta= rget=3D"_blank">michael(a)stroeder.com</a>></span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"><span class=3D""><a href=3D"mailto:ktmdms@gmail.com">ktmd= ms(a)gmail.com</a> wrote:<br> > Should I add STRIP=3D"" in the Makefile or is there a way to= add that on the<br> > configure line?<br> <br> </span>You can simply use<br> <br> make install STRIP=3D""<br> <br> Ciao, Michael.<br> </blockquote></div><br></div> --001a113f36ea7f617e052b97afc7--

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by michael＠stroeder.com 12 Feb '16

12 Feb '16

ktmdms(a)gmail.com wrote: > Should I add STRIP="" in the Makefile or is there a way to add that on the > configure line? You can simply use make install STRIP="" Ciao, Michael.

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by ktmdms＠gmail.com 12 Feb '16

12 Feb '16

--001a113a557a968d8d052b96215c Content-Type: text/plain; charset=UTF-8 Should I add STRIP="" in the Makefile or is there a way to add that on the configure line? Thanks. Kevin --- Regards, Kevin Martin On Fri, Feb 12, 2016 at 11:32 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, February 12, 2016 11:22 AM -0600 kevin martin < > ktmdms(a)gmail.com> wrote: > > >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7f6f7664d700 (LWP 30978)] >> 0x0000000000467f2f in passwd_extop () >> (gdb) thr apply all bt full >> > > Hi Kevin, > > You appear to be running a stripped binary lacking debug symbols. You > need to ensure your slapd build is not stripped nor lacking debug symbols > (-g as one of the CFLAGS). Adding STRIP="" to the make install bits will > prevent the stripping. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > --001a113a557a968d8d052b96215c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Should I add STRIP=3D"" in the Makefile or is th= ere a way to add that on the configure line?<div><br></div><div>Thanks.</di= v><div><br></div><div>Kevin</div></div><div class=3D"gmail_extra"><br clear= =3D"all"><div><div class=3D"gmail_signature"><div dir=3D"ltr">---<div><span= style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:= 12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Regards,</sp= an></div><div><div><br></div><div>Kevin Martin</div></div></div></div></div= > <br><div class=3D"gmail_quote">On Fri, Feb 12, 2016 at 11:32 AM, Quanah Gib= son-Mount <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target= =3D"_blank">quanah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"><span class=3D"">--On Friday, February 12, 2016 11:22 AM -0600 k= evin martin <<a href=3D"mailto:ktmdms@gmail.com" target=3D"_blank">ktmdm= s(a)gmail.com</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> <br> Program received signal SIGSEGV, Segmentation fault.<br> [Switching to Thread 0x7f6f7664d700 (LWP 30978)]<br> 0x0000000000467f2f in passwd_extop ()<br> (gdb) thr apply all bt full<br> </blockquote> <br></span> Hi Kevin,<br> <br> You appear to be running a stripped binary lacking debug symbols.=C2=A0 You= need to ensure your slapd build is not stripped nor lacking debug symbols = (-g as one of the CFLAGS).=C2=A0 Adding STRIP=3D"" to the make in= stall bits will prevent the stripping.<div class=3D"HOEnZb"><div class=3D"h= 5"><br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Platform Architect<br> Zimbra, Inc.<br> --------------------<br> Zimbra ::=C2=A0 the leader in open source messaging and collaboration<br> A division of Synacor, Inc<br> </div></div></blockquote></div><br></div> --001a113a557a968d8d052b96215c--

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by quanah＠zimbra.com 12 Feb '16

12 Feb '16

--On Friday, February 12, 2016 11:22 AM -0600 kevin martin <ktmdms(a)gmail.com> wrote: > > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7f6f7664d700 (LWP 30978)] > 0x0000000000467f2f in passwd_extop () > (gdb) thr apply all bt full Hi Kevin, You appear to be running a stripped binary lacking debug symbols. You need to ensure your slapd build is not stripped nor lacking debug symbols (-g as one of the CFLAGS). Adding STRIP="" to the make install bits will prevent the stripping. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by ktmdms＠gmail.com 12 Feb '16

12 Feb '16

--001a113a557a0b02ca052b95eb6f Content-Type: text/plain; charset=UTF-8 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f6f7664d700 (LWP 30978)] 0x0000000000467f2f in passwd_extop () (gdb) thr apply all bt full Thread 4 (Thread 0x7f6f77e4f700 (LWP 30977)): #0 0x00007f6f7d62c753 in epoll_wait () from /lib64/libc.so.6 No symbol table info available. #1 0x0000000000433cd3 in ?? () No symbol table info available. #2 0x00007f6f7d8fbdc5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007f6f7d62c17d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 3 (Thread 0x7f6f7664d700 (LWP 30978)): #0 0x0000000000467f2f in passwd_extop () No symbol table info available. #1 0x0000000000466996 in fe_extended () No symbol table info available. #2 0x000000000046671e in do_extended () No symbol table info available. #3 0x000000000043810e in ?? () No symbol table info available. #4 0x000000000043898b in ?? () No symbol table info available. #5 0x00000000005306f9 in ?? () No symbol table info available. #6 0x00007f6f7d8fbdc5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #7 0x00007f6f7d62c17d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 2 (Thread 0x7f6f75e4c700 (LWP 30979)): #0 0x00007f6f7d8ff6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x000000000053074b in ?? () No symbol table info available. #2 0x00007f6f7d8fbdc5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007f6f7d62c17d in clone () from /lib64/libc.so.6 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- Thread 1 (Thread 0x7f6f7eb53840 (LWP 30975)): #0 0x00007f6f7d8fcef7 in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x0000000000435909 in slapd_daemon () No symbol table info available. #2 0x000000000041eccf in main () No symbol table info available. --- Regards, Kevin Martin On Fri, Feb 12, 2016 at 11:01 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, February 12, 2016 4:30 PM +0000 ktmdms(a)gmail.com wrote: > > Full_Name: Kevin Martin >> Version: 2.4.44 >> OS: Oracle Linux 7 >> URL: >> Submission from: (NULL) (160.34.110.215) >> > > What else would you like to help figure this out? >> > > As noted in <http://www.openldap.org/faq/data/cache/59.html>, when slapd > crashes, one should provide a backtrace from gdb. > > I.e.: > > Start slapd > > gdb /path/to/slapd pid > > (gdb) cont > > Then execute your ldappasswd command in another window. When slapd > crashes, it'll drop back into gdb. > > (gdb) thr apply all bt full > > Provide that output back to the ITS. > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > --001a113a557a0b02ca052b95eb6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Program received signal SIGSEGV, Segmentation fault.<= /div><div>[Switching to Thread 0x7f6f7664d700 (LWP 30978)]</div><div>0x0000= 000000467f2f in passwd_extop ()</div><div>(gdb) thr apply all bt full</div>= <div><br></div><div>Thread 4 (Thread 0x7f6f77e4f700 (LWP 30977)):</div><div= >#0 =C2=A00x00007f6f7d62c753 in epoll_wait () from /lib64/libc.so.6</div><d= iv>No symbol table info available.</div><div>#1 =C2=A00x0000000000433cd3 in= ?? ()</div><div>No symbol table info available.</div><div>#2 =C2=A00x00007= f6f7d8fbdc5 in start_thread () from /lib64/libpthread.so.0</div><div>No sym= bol table info available.</div><div>#3 =C2=A00x00007f6f7d62c17d in clone ()= from /lib64/libc.so.6</div><div>No symbol table info available.</div><div>= <br></div><div>Thread 3 (Thread 0x7f6f7664d700 (LWP 30978)):</div><div>#0 = =C2=A00x0000000000467f2f in passwd_extop ()</div><div>No symbol table info = available.</div><div>#1 =C2=A00x0000000000466996 in fe_extended ()</div><di= v>No symbol table info available.</div><div>#2 =C2=A00x000000000046671e in = do_extended ()</div><div>No symbol table info available.</div><div>#3 =C2= =A00x000000000043810e in ?? ()</div><div>No symbol table info available.</d= iv><div>#4 =C2=A00x000000000043898b in ?? ()</div><div>No symbol table info= available.</div><div>#5 =C2=A00x00000000005306f9 in ?? ()</div><div>No sym= bol table info available.</div><div>#6 =C2=A00x00007f6f7d8fbdc5 in start_th= read () from /lib64/libpthread.so.0</div><div>No symbol table info availabl= e.</div><div>#7 =C2=A00x00007f6f7d62c17d in clone () from /lib64/libc.so.6<= /div><div>No symbol table info available.</div><div><br></div><div>Thread 2= (Thread 0x7f6f75e4c700 (LWP 30979)):</div><div>#0 =C2=A00x00007f6f7d8ff6d5= in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div= >No symbol table info available.</div><div>#1 =C2=A00x000000000053074b in ?= ? ()</div><div>No symbol table info available.</div><div>#2 =C2=A00x00007f6= f7d8fbdc5 in start_thread () from /lib64/libpthread.so.0</div><div>No symbo= l table info available.</div><div>#3 =C2=A00x00007f6f7d62c17d in clone () f= rom /lib64/libc.so.6</div><div>No symbol table info available.</div><div>--= -Type <return> to continue, or q <return> to quit---</div><div>= <br></div><div>Thread 1 (Thread 0x7f6f7eb53840 (LWP 30975)):</div><div>#0 = =C2=A00x00007f6f7d8fcef7 in pthread_join () from /lib64/libpthread.so.0</di= v><div>No symbol table info available.</div><div>#1 =C2=A00x000000000043590= 9 in slapd_daemon ()</div><div>No symbol table info available.</div><div>#2= =C2=A00x000000000041eccf in main ()</div><div>No symbol table info availab= le.</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br= clear=3D"all"><div><div class=3D"gmail_signature"><div dir=3D"ltr">---<div= ><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font= -size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Regard= s,</span></div><div><div><br></div><div>Kevin Martin</div></div></div></div= ></div> <br><div class=3D"gmail_quote">On Fri, Feb 12, 2016 at 11:01 AM, Quanah Gib= son-Mount <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target= =3D"_blank">quanah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex">--On Friday, February 12, 2016 4:30 PM +0000 <a href=3D"mailto:k= tmdms(a)gmail.com" target=3D"_blank">ktmdms(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Kevin Martin<br> Version: 2.4.44<br> OS: Oracle Linux 7<br> URL:<br> Submission from: (NULL) <a href=3D"tel:%28160.34.110.215" value=3D"+1603411= 0215" target=3D"_blank">(160.34.110.215</a>)<br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What else would you like to help figure this out?<br> </blockquote> <br> As noted in <<a href=3D"http://www.openldap.org/faq/data/cache/59.html" = rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/faq/data/cache= /59.html</a>>, when slapd crashes, one should provide a backtrace from g= db.<br> <br> I.e.:<br> <br> Start slapd<br> <br> gdb /path/to/slapd pid<br> <br> (gdb) cont<br> <br> Then execute your ldappasswd command in another window.=C2=A0 When slapd cr= ashes, it'll drop back into gdb.<br> <br> (gdb) thr apply all bt full<br> <br> Provide that output back to the ITS.<br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Platform Architect<br> Zimbra, Inc.<br> --------------------<br> Zimbra ::=C2=A0 the leader in open source messaging and collaboration<br> A division of Synacor, Inc<br> </blockquote></div><br></div> --001a113a557a0b02ca052b95eb6f--

1 0

Re: (ITS#8371) slapd crashes with ldappasswd
by quanah＠zimbra.com 12 Feb '16

12 Feb '16

--On Friday, February 12, 2016 4:30 PM +0000 ktmdms(a)gmail.com wrote: > Full_Name: Kevin Martin > Version: 2.4.44 > OS: Oracle Linux 7 > URL: > Submission from: (NULL) (160.34.110.215) > What else would you like to help figure this out? As noted in <http://www.openldap.org/faq/data/cache/59.html>, when slapd crashes, one should provide a backtrace from gdb. I.e.: Start slapd gdb /path/to/slapd pid (gdb) cont Then execute your ldappasswd command in another window. When slapd crashes, it'll drop back into gdb. (gdb) thr apply all bt full Provide that output back to the ITS. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8371) slapd crashes with ldappasswd
by ktmdms＠gmail.com 12 Feb '16

12 Feb '16

Full_Name: Kevin Martin Version: 2.4.44 OS: Oracle Linux 7 URL: Submission from: (NULL) (160.34.110.215) Running Openldap 2.4.42 and/or 2.4.44 I am able to crash slapd at will running ldappasswd as root changing another users password. On another openldap server running 2.4.42 the same change works flawlessly. Here's my setup: Command run: ldappasswd -d1 -ZZ "uid=chaliburt,ou=People,dc=ccd,dc=com" -D "cn=Manager,dc=ccd,dc=com" -H ldap://ldapx.mgt.ccd -W -S New password: Re-enter new password: Enter LDAP Password: ldap_result: Can't contact LDAP server (-1) Bad Server: Oracle Linux 7 3.8.13-118.2.5.el7uek.x86_64 openldap 2.4.44 ]# ldd /usr/local/libexec/slapd linux-vdso.so.1 => (0x00007ffca8b85000) libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f8a8ea45000) libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f8a8e687000) l libssl.so.10 => /lib64/libssl.so.10 (0x00007f8a8e41a000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8a8e033000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8a8de19000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8a8dbfd000) libc.so.6 => /lib64/libc.so.6 (0x00007f8a8d83f000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8a8d63b000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f8a8d3ef000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f8a8d10a000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f8a8cf06000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f8a8ccd4000) libz.so.1 => /lib64/libz.so.1 (0000007f8a8cabe000) /lib64/ld-linux-x86-64.so.2 (0x00007f8a8ec4f000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f8a8c8af000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f8a8c6ab000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8a8c487000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f8a8c226000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f8a8c001000) last bits of an strace of slapd shows: [pid 26360] sendto(3, "<167>Feb 11 15:30:01 slapd[26357"..., 109, MSG_NOSIGNAL, NULL, 0 <unfinished ...> [pid 26359] epoll_wait(6, <unfinished ...> [pid 26360] <... sendto resumed> ) = 109 [pid 26360] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- [pid 26361] +++ killed by SIGSEGV +++ [pid 260%5] +++ killed by SIGSEGV +++ [pid 26359] +++ killed by SIGSEGV +++ +++ killed by SIGSEGV +++ slapd.log shows: Feb 12 06:53:48 ldapx slapd[30367]: conn=1000 fd=19 ACCEPT from IP=172.17.206.55:42250 (IP=0.0.0.0:389) b b 12 06:53:48 ldapx slapd[30367]: conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 12 06:53:48 ldapx slapd[30367]: conn=1000 op=0 STARTTLS Feb 12 06:53:48 ldapx slapd[30367]: conn=1000 op=0 RESULT oid= err=0 text= Feb 12 06:53:48 ldapx slapd[30367]: conn=1000 fd=19 TLS established tls_ssf=256 ssf=256 Feb 12 06:53:56 ldapx slapd[30367]: conn=1000 op=1 BIND dn="cn=Manager,dc=ccd,dc=com" method=128 Feb 12 06:53:56 ldapx slapd[30367]: conn=1000 op=1 BIND dn="cn=Manager,dc=ccd,dc=com" mech=SIMPLE ssf=0 Feb 12 06:53:56 ldapx slapd[30367]: co%3=1000 op=1 RESULT tag=97 err=0 text= Feb 12 06:53:56 ldapx slapd[30367]: conn=1000 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1 Feb 12 06:53:56 ldapx slapd[30367]: conn=1000 op=2 PASSMOD id="uid=chaliburt,ou=People,dc=ccd,dc=com" new then ththing after this. Good openldap server: Oracle Linux 7 3.8.13-118.2.5.el7uek.x86_64 openldap 2.4.42 # ldd /usr/local/libexec/slapd linux-vdso.so.1 => (0x00007ffd17779000) libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f5e152e2000) libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f5e14f24000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f5e14cb7000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f5e148d0000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f5e146b6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5e1449a000) libc.so.6 => /lib64/libc.so.6 (0x00007f5e140dc000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f5e13ed8000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f5e13c8c000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f5e139a7000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f5e137a3000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f5e13571000) libz.so.1 => /lib64/libz.so.1 (0x00007f5e1335b000) /lib64/ld-linux-x86-64.so.2 (0x00007f5e154ec000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f5e1314c000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f5e12f48000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f5e12d24000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f5e12ac3000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f5e1289e000) What else would you like to help figure this out?

1 0

Re: (ITS#8370) SQL test failing
by nwerneck＠gmail.com 10 Feb '16

10 Feb '16

--001a11c2e2980f9e54052b69de0d Content-Type: text/plain; charset=UTF-8 Hi. I understand it is experimental. I just got to a point trying to set it up that I couldn't imagine what I was doing wrong, and decided it could be a bug. Specially considering it's experimental code. I'm actually not even sure I need to use that anymore. But who knows, maybe someone might stumble in the same problem some day... Anyway, I guess we can just close this. Thanks! -- Nicolau Werneck <nwerneck(a)gmail.com> http://n <http://nwerneck.sdf.org>ic.hpavc.net --001a11c2e2980f9e54052b69de0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi. I understand it is experimental. I just got to a = point trying to set it up that I couldn't imagine what I was doing wron= g, and decided it could be a bug. Specially considering it's experiment= al code.</div><div><br></div><div>I'm actually not even sure I need to = use that anymore. But who knows, maybe someone might stumble in the same pr= oblem some day... Anyway, I guess we can just close this. Thanks!</div><div= ><br></div>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div>Nico= lau Werneck <<a href=3D"mailto:nwerneck@gmail.com" target=3D"_blank">nwe= rneck(a)gmail.com</a>><br><a href=3D"http://nwerneck.sdf.org" target=3D"_b= lank">http://n</a><a href=3D"http://ic.hpavc.net" target=3D"_blank">ic.hpav= c.net</a><br></div></div></div> </div> --001a11c2e2980f9e54052b69de0d--

1 0

Re: (ITS#8370) SQL test failing
by quanah＠zimbra.com 09 Feb '16

09 Feb '16

--On Monday, February 08, 2016 3:31 PM +0000 nwerneck(a)gmail.com wrote: > Full_Name: Nicolau Werneck > Version: 2.4.43 > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.217.131.117) > Hello, The ITS system is for reporting bugs, not usage questions. I would also note that back-sql is experimental as documented in the man page. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 09 Feb '16

09 Feb '16

A patch for the failing test022 is uploaded as: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160209.patch

1 0

(ITS#8370) SQL test failing
by nwerneck＠gmail.com 08 Feb '16

08 Feb '16

Full_Name: Nicolau Werneck Version: 2.4.43 OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.217.131.117) Hello. I am trying to run the SQL back-end tests, but it fails and I'm not sure how to debug this. The database looks good to me as far as I can tell. There are actually some error messages when I create the database but I'm assuming theyrere not critical. So, this is what I get from running the test: >>>>> Executing all LDAP tests for sql >>>>> Starting sql-test000-read ... running defines.sh Starting slapd on TCP/IP port 9011... Testing SQL backend read operations... Waiting 5 seconds for slapd to start... Testing correct bind... ldap_bind: Invalid credentials (49) ldapwhoami failed (49)! >>>>> ./scripts/sql-test000-read failed (exit 49) make: *** [sql-yes] Error 49 [root%4ocalalhost tests]# And on the log: 56b8b343 connection_get(11): got connid=1001 56b8b343 connection_read(11): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 49 contents: 56b8b343 op tag 0x60, time 1454945091 ber_get_next 56b8b343 conn=1001 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: 56b8b343 >>> dnPrettyNormal: <cn=Mitya Kovalev,dc=example,dc=com> => ldap_bv2dn(cn=Mitya Kovalev,dc=example,dc=m%m,0) <= ldap_bv2dn(cn=Mitya Kovalev,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Mitya Kovalev,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=mitya kovalev,dc=example,dc=com)=0 56b8b343 <<< dnPrettyNormal: <cn=Mitya Kovalev,dc=example,dc=com>, <cn=mitya kovalev,dc=example,dc=com> 56b8b343 conn=1001 op=0 BIND dn="cn=Mitya Kovalev,dc=example,dc=com" method=128 56b8b343 do_bind: version=3 dn="cn=Mitya Kovalev,dc=example,dc=com" method=128 56b8b343 ==>backsql_bind() 56b8b343 ==>backsql_get_db_conn() 56b8b343 ==>backsql_open_db_handle() 56b8b343 <==backsql_open_db_handle() 56b8b343 <==backsql_get_db_conn() 56b8b343 ==>backsql_attrlist_add(): adding "userPassword" to list 56b8b343 ==>backsqatattrlist_add(): attribute "userPassword" is in list 56b8b343 ==>backsql_attrlist_add(): adding "objectClass" to list 56b8b343 ==>backsql_dn2id("cn=mitya kovalev,dc=example,dc=com") 56b8b343 backsql_dn2id("cn=mitya kovalev,dc=example,dc=com"): id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE upper(dn)=upper(?)" 56b8b343 backsql_dn2id("cn=mitya kovalev,dc=example,dc=com"): id=2 keyval=1 oc_id=1 dn=cn=Mitya Kovalev,dc=example,dc=com 56b8b343 >>> dnPrettyNormal: <cn=Mitya Kovalev,dc=example,dc=com> => ldap_bv2dn(cn=Mitya Kovalev,dc=example,dc=com,0) <= ldap_bv2dn(cn=Mitya Kovalev,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Mitya Kovalev,dc=example,dc=com)=0 => ldap_2b2bv(272) <= ldap_dn2bv(cn=mitya kovalev,dc=example,dc=com)=0 56b8b343 <<< dnPrettyNormal: <cn=Mitya Kovalev,dc=example,dc=com>, <cn=mitya kovalev,dc=example,dc=com> 56b8b343 <==backsql_dn2id("cn=mitya kovalev,dc=example,dc=com"): err=0 56b8b343 ==>backsqattrtrlist_add(): attribute "userPassword" is in list 56b8b343 ==>backsql_attrlist_add(): attribute "objectClass" is in list 56b8b343 ==>backsql_attrlist_add(): adding "ref" to list 56b8b343 ==>backsql_id2entry() 56b8b343 backsql_id2entry(): custom attribute list 56b8b343 backsql_id2entry(): attribute "userPassword" is not defined for objectlass "inetOrgPerson" 56b8b343 ==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="objectClass" keyval=1 56b8b343 backsql_get_attr_vals(): number of values in query: 0 56b8b343 backsql_id2entry(): attribute "ref" is not defined for objectlass "inetOrgPerson" 56b8b343 <==backsql_id2entry() 56b8b343 send_ldap_result: conn=1001 op=0 p=3 56b8b343 send_ldap_result: err=49 matched="" text="" 56b8b343 send_ldap_response: msgid=1 tag=97 err=49 I guess OpenLDAP cannot read the inetOrgPerson attributes configuration correctly. But I'm just using the schema files from the example, and the `ldap_attr_mappings` table is filled... What else could be missing?

1 0

(ITS#8303)
by nivanova＠symas.com 08 Feb '16

08 Feb '16

This is a patch that fixes a problem in the configure.in introduced with the original commit (6cafdfa8d82134f78e68325c4b9c10dd37935d7a). The problem caused compilation error during make depend. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160208.patch

1 0

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by hyc＠symas.com 06 Feb '16

06 Feb '16

nivanova(a)symas.com wrote: > Full_Name: Nadezhda Ivanova > Version: slapd 2.X > OS: > URL: ftp://ftp.openldap.org/incoming/Nadezhda-Ivanova-151105.patch > Submission from: (NULL) (78.83.54.234) > > > This is an asynchronous version of the meta back-end. Something in this patch breaks test022. Reverting the patch (commit 6cafdfa8d82134f78e68325c4b9c10dd37935d7a) fixes the problem. Please investigate. -- -- 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#8367) Unable to authenticate to AD when OpenLDAP 2.4 is set up in SASL mode
by quanah＠zimbra.com 04 Feb '16

04 Feb '16

--On Tuesday, February 02, 2016 9:32 PM +0000 ralthuru(a)yahoo.com wrote: The ITS system is for reporting bugs, not asking how to do stuff. Please use openldap-technical to ask questions on how to use the OpenLDAP software. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8368) Process /usr/sbin/slapd was killed by signal 6 (SIGABRT)
by hyc＠symas.com 04 Feb '16

04 Feb '16

yaroslavr(a)digdes.com wrote: > Full_Name: Yaroslav Rutsky > Version: 2.4.40 > OS: CentOS release 6.6 (Final) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.114.5.9) > > > We used customized OpenLDAP RPM-packets, builded from > openldap-2.4.40-6.el6_7.src.rpm, from CentOS repository with patch to support > Outlook addressbook browsing feature (in conjunction with sssvlv overlay): > What is the root cause of this error ("double free or corruption" at malloc.c)? > What direction we should dig to troubleshoot this error? > Should we monitor memory leaks or try to use tcmalloc instead of malloc? Since it appears that you can reproduce this problem, it ought to be easy to identify the cause using valgrind. Meanwhile, 2.4.40 is 3 releases behind and we're about to release 2.4.44. If you can reproduce the problem in the current RE24 release candidate and track it down in valgrind there may be time to fix it for the 2.4.44 release. Otherwise, you'll have to wait for the next release. -- -- 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

(ITS#8369) Process /usr/sbin/slapd was killed by signal 6 (SIGABRT)
by yaroslavr＠digdes.com 04 Feb '16

04 Feb '16

Full_Name: Yaroslav Rutsky Version: 2.4.40 OS: CentOS release 6.6 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.114.5.9) We used customized OpenLDAP RPM-packets, builded from openldap-2.4.40-6.el6_7.src.rpm, from CentOS repository with patch to support Outlook addressbook browsing feature (in conjunction with sssvlv overlay): -----------------------openldap-2.4.40-outlook-sssvlv.patch----------------------------------- diff -uNr openldap-2.4.40/openldap-2.4.40/servers/slapd/schema_prep.c openldap-2.4.40sok/openldap-2.4.40/servers/slapd/schema_prep.c --- openldap-2.4.40/openldap-2.4.40/servers/slapd/schema_prep.c 2014-09-19 05:48:49.000000000 +0400 +++ openldap-2.4.40mod/openldap-2.4.40/servers/slapd/schema_prep.c 2015-10-16 10:43:36.778308938 +0300 @@ -908,6 +908,7 @@ "DESC 'RFC4519: common supertype of name attributes' " "EQUALITY caseIgnoreMatch " "SUBSTR caseIgnoreSubstringsMatch " + "ORDERING caseIgnoreOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )", NULL, SLAP_AT_ABSTRACT, NULL, NULL, ---------------------------------------------------------------------------------------------- Also, we used LMDB as backend, and some other configurations (chain, syncrepl, referral). This server is slave in our replication structure, serving read requests by themselves and chaining write requests to one of mirror-replicated servers. Modifications, chained from this slave to the mirrored masters, comes back to slave by syncrepl. Recently, we observed occasionally crashed slapd with this error in /var/log/messages: Jan 20 16:51:35 server-02 kernel: slapd[20380] general protection ip:7fe49bf76f85 sp:7fe45d1538d0 error:0 in libc-2.12.so[7fe49bf01000+18a000] Unfortunately, coredump generation configured only after that. Some time later, slapd crashed again: Feb 3 08:05:31 server-02 abrt[24705]: Saved core mpmp of pid 27070 (/usr/sbin/slapd) to /var/spool/abrt/ccpp-2016-02-03-08:05:29-27070 (844488704 bytes) openldap.log (olcLogLevel:256) shows nothing: ==============================================================D%D=== Feb 3 08:05:29 server-02 slapd[27070]: conn=275418 op=617 SEARCH RESULT tag=101 err=0 nentries=0 text= Feb 3 08:05:29 server-02 slapd[27070]: conn=275418 op=618 SRCH base="" scope=2 deref=3 filter="(&(mail=*)(|(?mail=X*)(cn=X*)(sn=X*)(givenName=X*)(displayName=X*))"222 Feb 3 08:05:29 server-02 slapd[27070]: conn=275418 op=618 SRCH attr=cn commonName mail roleOccupant display-name displayname sn surname co organizationName o givenName legacyExchangeDN objectClass uid mailNickname title company physicalDeliveryOfficeName telephoneNumber Feb 3 08:05:29 server-02 slapd[27070]: <= mdb_substring_candidates: (sn) not indexed Feb 3 08:05:29 server-02 slapd[27070]: <= mdb_substring_candidates: (givenName) not indexed Feb 3 08:05:29 server-02 slapd[07070]: <= mdb_substring_candidates: (displayName) not indexed Feb 3 08:24:57 server-02 slapd[26054]: @(#) $OpenLDAP: slapd 2.4.40 (Nov 10 2015 11:22:22) $#012#011root@orw-oldp-01:/root/rpmbuild/BUILD/openldap-2.4.40/openldap-2.4.40/build-servers/servers/slapd Feb 3 08:24:57 server-02 slapd&26055]: slapd starting gdb shows: ================================================================== # gdb /usr/sbin/slapd /var/tmp/coredump/coredump .......... Core was generated by `/usr/sbin/slapd -h ldap:/// ldapi:/// -u ldap'. Proam t terminated with signal 6, Aborted. #0 0x00007f2f4b7bc625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install libtool-ltdl-2.2.6-15.5.el6.x86_64 (gdb) bt #0 0x00007f2f4b7bc625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f2f4b7bde05 in abort () at abort.c:92 #2 0x00007f2f4b7fa537 in __libc_message (do_abort=2, fmt=0x7f2f4b8e2840 "") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 #3 0x00007f2f4b7ffe66 in malloc_printerr (action=3, str=0x7f2f4b8e2b18 "ree or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6336 #4 0x00007f2f48d8f76f in send_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, so=0f2f2ee0106890) at ../../../../servers/slapd/overlays/sssvlv.c:706 #5 0x00007f2f48d90109 in sssvlv_op_response (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../../servers/slapd/overlays/sssvlv.c:792 #6 0x00007f2f4e22f9de in slap_response_play (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/result.c:508 #7 0x00007f2f4e2305c0 in send_ldap_response (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/result.c:583 #8 0x00007f2f4e23158f in slap_send_ldap_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/result.c:861 #9 0x00007f2f4e2ce9dd in mdb_search (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../../servers/slapd/back-mdb/search.c:1164 #10 0x00007f2f4e28e477 in overlay_op_walk (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, which=op_search, oi=0x7f2f4f1f9a60, on=0x0) at ../../../servers/slapd/backover.c:671 #11 0x00007f2f4e28eed4 in over_op_func (op=0x7f2efe4d6fe0, rs=<value optimized out>, which=<value optimized out>) at ../../../servers/slapd/backover.c:723 #12 0x00007f2f4e221e79 in fe_op_search (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/search.c:402 #13 0x00007f2f4e28e477 in overlay_op_walk (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, which=op_search, oi=0x7f2f4f1dd240, on=0x0) at ../../../servers/slapd/backover.c:671 #14 0x00007f2f4e28eed4 in over_op_func (op=0x7f2efe4d6fe0, rs=<value optimized out>, which=<value optimized out>) at ../../../servers/slapd/backover.c:723 #15 0x00007f2f4e2226d7 in do_search (op=0x7f2efe4d6fe0, rs=<value optimized out>) at ../../../servers/slapd/search.c:247 #16 0x00007f2f4e21f349 in connection_operation (ctx=0x7f2eebffeb70, arg_v=0x7f2efe4d6fe0) at ../../../servers/slapd/connection.c:1155 #17 0x00007f2f4e220480 in connection_read_thread (ctx=0x7f2eebffeb70, argv=<value optimized out>) at ../../../servers/slapd/connection.c:1291 #18 0x00007f2f4dd6cb68 in ldap_int_thread_pool_wrapper (xpool=0x7f2f4f184630) at ../../../libraries/libldap_r/tpool.c:688 #19 0x00007f2f4bd309d1 in start_thread (arg=0x7f2eebfff700) at pthread_create.c:301 #20 0x00007f2f4b8728fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) bt full 0,6 #0 0x00007f2f4b7bc625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = 0 pid = <value optimized out> selftid = 30625 #1 0x00007f2f4b7bde05 in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x7f2eebe6c458, sa_sigaction = 0x7f2eebe6c458}, sa_mask = {__val = {139839502992448, 139841150654840, 16, 139841107786729, 1, 139841106467759, 5, 139841107790384, 3, 139839502992446, 2, 139841107786755, 1, 139841107793486, 3, 139839502992452}}, sa_flags = 12, sa_restorer = 0x7f2f4b8e1652} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007f2f4b7fa537 in __libc_message (do_abort=2, fmt=0x7f2f4b8e2840 "") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7f2eebe6cdc0, reg_save_area = 0x7f2eebe6ccd0}} ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7f2eebe6cdc0, reg_save_area = 0x7f2eebe6ccd0}} fd = 2 on_2 = <value optimized out> list = <value optimized out> nlist = <value optimized out> cp = <value optimized out> written = <value optimized out> #3 0x00007f2f4b7ffe66 in malloc_printerr (action=3, str=0x7f2f4b8e2b18 "ree or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6336 buf = "00007f2ee0106890" cp = <value optimized out> #4 0x00007f2f48d8f76f in send_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, so=0x7f2ee0106890) at ../../../../servers/slapd/overlays/sssvlv.c:706 ctrls = {0x7f2ee0004008, 0x7f2ee0005020, 0x0} rc = <value optimized out> i = <value optimized out> #5 0x00007f2f48d90109 in sssvlv_op_response (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../../servers/slapd/overlays/sssvlv.c:792 sc = 0x7f2ee0002a50 so = 0x7f2ee0106890 (More stack frames follow...) (gdb) frame 4 #4 0x00007f2f48d8f76f in send_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, so=0x7f2ee0106890) at ../../../../servers/slapd/overlays/sssvlv.c:706 706 free_sort_op( op->o_conn, so ); (gdb) list 701 slap_add_ctrls( op, rs, ctrls ); 702 send_ldap_result( op, rs ); 703 704 if ( so->so_tree == NULL ) { 705 /* Search finished, so clean up */ 706 free_sort_op( op->o_conn, so ); 707 } 708 } 709 (gdb) frame 3 #3 0x00007f2f4b7ffe66 in malloc_printerr (action=3, str=0x7f2f4b8e2b18 "ree or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6336 6336 __libc_message (action & 2%%D (gdb) list 6331 buf[sizeof (buf) - 1] = '\0'; 6332 char *cp = _itoa_word ((uintptr_t) ptr, &buf[sizeof (buf) - 1], 16, 0); 6333 while (cp > buf) 6334 *--cp = '0'; 6335 6336 ____libc_message (action & 2, 6337 "*** glibc detected *** %s: %s: 0x%s ***\n", 6338 __libc_argv[0] ?: "<unknown>", str, cp); 6339 } 6340 else if (action & 2) ==========================3D%3================================================ What is the root cause of this error ("double free or corruption" at malloc.c)? What direction we should dig to troubleshoot this error? Should we monitor memory leaks or try to use tcmalloc instead of malloc?

1 0

(ITS#8368) Process /usr/sbin/slapd was killed by signal 6 (SIGABRT)
by yaroslavr＠digdes.com 04 Feb '16

04 Feb '16

Full_Name: Yaroslav Rutsky Version: 2.4.40 OS: CentOS release 6.6 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.114.5.9) We used customized OpenLDAP RPM-packets, builded from openldap-2.4.40-6.el6_7.src.rpm, from CentOS repository with patch to support Outlook addressbook browsing feature (in conjunction with sssvlv overlay): -----------------------openldap-2.4.40-outlook-sssvlv.patch----------------------------------- diff -uNr openldap-2.4.40/openldap-2.4.40/servers/slapd/schema_prep.c openldap-2.4.40sok/openldap-2.4.40/servers/slapd/schema_prep.c --- openldap-2.4.40/openldap-2.4.40/servers/slapd/schema_prep.c 2014-09-19 05:48:49.000000000 +0400 +++ openldap-2.4.40mod/openldap-2.4.40/servers/slapd/schema_prep.c 2015-10-16 10:43:36.778308938 +0300 @@ -908,6 +908,7 @@ "DESC 'RFC4519: common supertype of name attributes' " "EQUALITY caseIgnoreMatch " "SUBSTR caseIgnoreSubstringsMatch " + "ORDERING caseIgnoreOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )", NULL, SLAP_AT_ABSTRACT, NULL, NULL, ---------------------------------------------------------------------------------------------- Also, we used LMDB as backend, and some other configurations (chain, syncrepl, referral). This server is slave in our replication structure, serving read requests by themselves and chaining write requests to one of mirror-replicated servers. Modifications, chained from this slave to the mirrored masters, comes back to slave by syncrepl. Recently, we observed occasionally crashed slapd with this error in /var/log/messages: Jan 20 16:51:35 server-02 kernel: slapd[20380] general protection ip:7fe49bf76f85 sp:7fe45d1538d0 error:0 in libc-2.12.so[7fe49bf01000+18a000] Unfortunately, coredump generation configured only after that. Some time later, slapd crashed again: Feb 3 08:05:31 server-02 abrt[24705]: Saved core mpmp of pid 27070 (/usr/sbin/slapd) to /var/spool/abrt/ccpp-2016-02-03-08:05:29-27070 (844488704 bytes) openldap.log (olcLogLevel:256) shows nothing: ==============================================================D%D=== Feb 3 08:05:29 server-02 slapd[27070]: conn=275418 op=617 SEARCH RESULT tag=101 err=0 nentries=0 text= Feb 3 08:05:29 server-02 slapd[27070]: conn=275418 op=618 SRCH base="" scope=2 deref=3 filter="(&(mail=*)(|(?mail=X*)(cn=X*)(sn=X*)(givenName=X*)(displayName=X*))"222 Feb 3 08:05:29 server-02 slapd[27070]: conn=275418 op=618 SRCH attr=cn commonName mail roleOccupant display-name displayname sn surname co organizationName o givenName legacyExchangeDN objectClass uid mailNickname title company physicalDeliveryOfficeName telephoneNumber Feb 3 08:05:29 server-02 slapd[27070]: <= mdb_substring_candidates: (sn) not indexed Feb 3 08:05:29 server-02 slapd[27070]: <= mdb_substring_candidates: (givenName) not indexed Feb 3 08:05:29 server-02 slapd[07070]: <= mdb_substring_candidates: (displayName) not indexed Feb 3 08:24:57 server-02 slapd[26054]: @(#) $OpenLDAP: slapd 2.4.40 (Nov 10 2015 11:22:22) $#012#011root@orw-oldp-01:/root/rpmbuild/BUILD/openldap-2.4.40/openldap-2.4.40/build-servers/servers/slapd Feb 3 08:24:57 server-02 slapd&26055]: slapd starting gdb shows: ================================================================== # gdb /usr/sbin/slapd /var/tmp/coredump/coredump .......... Core was generated by `/usr/sbin/slapd -h ldap:/// ldapi:/// -u ldap'. Proam t terminated with signal 6, Aborted. #0 0x00007f2f4b7bc625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install libtool-ltdl-2.2.6-15.5.el6.x86_64 (gdb) bt #0 0x00007f2f4b7bc625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f2f4b7bde05 in abort () at abort.c:92 #2 0x00007f2f4b7fa537 in __libc_message (do_abort=2, fmt=0x7f2f4b8e2840 "") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 #3 0x00007f2f4b7ffe66 in malloc_printerr (action=3, str=0x7f2f4b8e2b18 "ree or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6336 #4 0x00007f2f48d8f76f in send_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, so=0f2f2ee0106890) at ../../../../servers/slapd/overlays/sssvlv.c:706 #5 0x00007f2f48d90109 in sssvlv_op_response (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../../servers/slapd/overlays/sssvlv.c:792 #6 0x00007f2f4e22f9de in slap_response_play (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/result.c:508 #7 0x00007f2f4e2305c0 in send_ldap_response (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/result.c:583 #8 0x00007f2f4e23158f in slap_send_ldap_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/result.c:861 #9 0x00007f2f4e2ce9dd in mdb_search (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../../servers/slapd/back-mdb/search.c:1164 #10 0x00007f2f4e28e477 in overlay_op_walk (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, which=op_search, oi=0x7f2f4f1f9a60, on=0x0) at ../../../servers/slapd/backover.c:671 #11 0x00007f2f4e28eed4 in over_op_func (op=0x7f2efe4d6fe0, rs=<value optimized out>, which=<value optimized out>) at ../../../servers/slapd/backover.c:723 #12 0x00007f2f4e221e79 in fe_op_search (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../servers/slapd/search.c:402 #13 0x00007f2f4e28e477 in overlay_op_walk (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, which=op_search, oi=0x7f2f4f1dd240, on=0x0) at ../../../servers/slapd/backover.c:671 #14 0x00007f2f4e28eed4 in over_op_func (op=0x7f2efe4d6fe0, rs=<value optimized out>, which=<value optimized out>) at ../../../servers/slapd/backover.c:723 #15 0x00007f2f4e2226d7 in do_search (op=0x7f2efe4d6fe0, rs=<value optimized out>) at ../../../servers/slapd/search.c:247 #16 0x00007f2f4e21f349 in connection_operation (ctx=0x7f2eebffeb70, arg_v=0x7f2efe4d6fe0) at ../../../servers/slapd/connection.c:1155 #17 0x00007f2f4e220480 in connection_read_thread (ctx=0x7f2eebffeb70, argv=<value optimized out>) at ../../../servers/slapd/connection.c:1291 #18 0x00007f2f4dd6cb68 in ldap_int_thread_pool_wrapper (xpool=0x7f2f4f184630) at ../../../libraries/libldap_r/tpool.c:688 #19 0x00007f2f4bd309d1 in start_thread (arg=0x7f2eebfff700) at pthread_create.c:301 #20 0x00007f2f4b8728fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 (gdb) bt full 0,6 #0 0x00007f2f4b7bc625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = 0 pid = <value optimized out> selftid = 30625 #1 0x00007f2f4b7bde05 in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x7f2eebe6c458, sa_sigaction = 0x7f2eebe6c458}, sa_mask = {__val = {139839502992448, 139841150654840, 16, 139841107786729, 1, 139841106467759, 5, 139841107790384, 3, 139839502992446, 2, 139841107786755, 1, 139841107793486, 3, 139839502992452}}, sa_flags = 12, sa_restorer = 0x7f2f4b8e1652} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007f2f4b7fa537 in __libc_message (do_abort=2, fmt=0x7f2f4b8e2840 "") at ../sysdeps/unix/sysv/linux/libc_fatal.c:198 ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7f2eebe6cdc0, reg_save_area = 0x7f2eebe6ccd0}} ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7f2eebe6cdc0, reg_save_area = 0x7f2eebe6ccd0}} fd = 2 on_2 = <value optimized out> list = <value optimized out> nlist = <value optimized out> cp = <value optimized out> written = <value optimized out> #3 0x00007f2f4b7ffe66 in malloc_printerr (action=3, str=0x7f2f4b8e2b18 "ree or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6336 buf = "00007f2ee0106890" cp = <value optimized out> #4 0x00007f2f48d8f76f in send_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, so=0x7f2ee0106890) at ../../../../servers/slapd/overlays/sssvlv.c:706 ctrls = {0x7f2ee0004008, 0x7f2ee0005020, 0x0} rc = <value optimized out> i = <value optimized out> #5 0x00007f2f48d90109 in sssvlv_op_response (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00) at ../../../../servers/slapd/overlays/sssvlv.c:792 sc = 0x7f2ee0002a50 so = 0x7f2ee0106890 (More stack frames follow...) (gdb) frame 4 #4 0x00007f2f48d8f76f in send_result (op=0x7f2efe4d6fe0, rs=0x7f2eebffea00, so=0x7f2ee0106890) at ../../../../servers/slapd/overlays/sssvlv.c:706 706 free_sort_op( op->o_conn, so ); (gdb) list 701 slap_add_ctrls( op, rs, ctrls ); 702 send_ldap_result( op, rs ); 703 704 if ( so->so_tree == NULL ) { 705 /* Search finished, so clean up */ 706 free_sort_op( op->o_conn, so ); 707 } 708 } 709 (gdb) frame 3 #3 0x00007f2f4b7ffe66 in malloc_printerr (action=3, str=0x7f2f4b8e2b18 "ree or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6336 6336 __libc_message (action & 2%%D (gdb) list 6331 buf[sizeof (buf) - 1] = '\0'; 6332 char *cp = _itoa_word ((uintptr_t) ptr, &buf[sizeof (buf) - 1], 16, 0); 6333 while (cp > buf) 6334 *--cp = '0'; 6335 6336 ____libc_message (action & 2, 6337 "*** glibc detected *** %s: %s: 0x%s ***\n", 6338 __libc_argv[0] ?: "<unknown>", str, cp); 6339 } 6340 else if (action & 2) ==========================3D%3================================================ What is the root cause of this error ("double free or corruption" at malloc.c)? What direction we should dig to troubleshoot this error? Should we monitor memory leaks or try to use tcmalloc instead of malloc?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs