- openldap-bugs - openldap.org

(ITS#7315) [PATCH 4/5] MozNSS: do not authenticate to a slot manually
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0004-MozNSS… Submission from: (NULL) (209.132.186.34) We cannot rely on the value of ctx->tc_certificate->slot because it might refer to a wrong slot when the certificate is loaded multiple times. This can happen in multi-threaded applications. Instead of authenticating to a slot implicitly, we can leave the decision on Mozilla NSS library, which will initiate authentication to a proper slot when needed. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7314) [PATCH 3/5] MozNSS: lock whole init and clenaup process
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0003-MozNSS… Submission from: (NULL) (209.132.186.34) This patch changes the mutex locking during Mozilla NSS context initialization and shutdown. When multiple TLS contexts are created in multi-threaded application (like slapd with syncrepl), certificate, private key, or slot lookup errors appeared from time to time when other thread was loading the certificates. This patch makes the process safe as much as possible by protecting the whole context initialization and shutdown. Unfortunatelly, identifying the unsafe operations can be tricky with MozNSS. This patch should not cause any performance drawback, because the initialization is run just once per context. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7313) [PATCH 2/5] MozNSS: store certificate object instead of nickname in ctx
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0002-MozNSS… Submission from: (NULL) (209.132.186.34) PEM certificates should not be referenced by nicknames, because the nicknames are derived from basename of the cerificate file and in general are not easy-predictable. The code of Mozilla NSS backend depends on some aspects of PEM module and tries to guess the nicknames correctly. In some cases the guessing is wrong. This patch changes this approach and the PEM certificates are no longer referenced by nicknames. DER value of the certificate is extracted when the PEM file is loaded into the database and this DER value is then used to retrieve the certificate object. When certificate database is used (not PEM), certificates are retrieved using nickname as before. The retrieved certificate objects (and associated private keys) are now stored directly in the tlsm_ctx structure and the nickname (certname) disappears. The changes are quite broad, but the code was simplified on many places. This approach was recommended by Mozilla NSS developers and was recently implemented for example in CURL. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7312) [PATCH 1/5] MozNSS: context specific token description for certdb
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0001-MozNSS… Submission from: (NULL) (209.132.186.34) Prior to this patch, certificate lookup in Mozilla NSS certificate database by certificate nickname failed, if multiple certdbs were opened. This can happen in certain configurations of replication. Or when an application which links libldap, uses Mozilla NSS library as well. With this patch, all certdbs are opened explicitly with SECMOD_OpenUserDB() call. This allows us to specify a token description, which is later used as a prefix for the certificate nickname. The token description is unique for each TLS context created in OpenLDAP. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7311) Use JDBC-LDAP driver with Sybase Unwired Platform
by quanah＠zimbra.com 21 Jun '12

21 Jun '12

--On Thursday, June 21, 2012 10:31 AM +0000 iavdeev(a)nvg.ru wrote: > Full_Name: Igor G. Avdeev > Version: 2.4.21 > OS: Linux 2.6.32-41-server x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.221.17.130) > > Could you help me create such a properties file for the jdbc-ldap driver? > This ITS system is for filing bug reports. If you have questions, then use the openldap-technical mailing list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7311) Use JDBC-LDAP driver with Sybase Unwired Platform
by iavdeev＠nvg.ru 21 Jun '12

21 Jun '12

Full_Name: Igor G. Avdeev Version: 2.4.21 OS: Linux 2.6.32-41-server x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.221.17.130) Hello, I use the jdbc-ldap driver to connect to the OpenLDAP server with Sybase Unwired Platform. Sybase Unwired Platform to create the data source uses a properties file. Here is an example of such a file: #Instance Properties #Mon Jun 18 12:06:21 MSD 2012 driverClass=com.extendedsystems.jdbc.advantage.ADSDriver ant.project=default-jmsbridge databaseURL=jdbc\:extendedsystems\:advantage\://${serverName}\:${portNumber};catalog \= ${databaseName} Could you help me create such a properties file for the jdbc-ldap driver?

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by jsynacek＠redhat.com 18 Jun '12

18 Jun '12

On 06/07/2012 03:00 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: 2.4.29 >> OS: Fedora 16 >> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> Submission from: (NULL) (209.132.186.34) >> >> >> Constraint overlay doesn't take into account multiple modifications when using >> count. >> >> Example: If count for 'description' attribute is set e.g. to 2, the following >> results in a constraint violation: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> description: d2 >> description: d3-viol >> >> However, this passes: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> - >> add: description >> description: d2 >> - >> add: description >> description: d3 >> >> This patch fixes the behavior in case multiple modifications are used. >> >> Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163 >> >> The patch is uploaded on fedorapeople.org: >> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> >> I wasn't able to use ftp.openldap.org due to 'No space left' error. > > This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) > I've updated the patch: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120619-constraint-coun… Also, I've uploaded the tests I use: http://jsynacek.fedorapeople.org/openldap/constraint-count-tests.tar.bz2 -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by jsynacek＠redhat.com 18 Jun '12

18 Jun '12

On 06/07/2012 03:00 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: 2.4.29 >> OS: Fedora 16 >> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> Submission from: (NULL) (209.132.186.34) >> >> >> Constraint overlay doesn't take into account multiple modifications when using >> count. >> >> Example: If count for 'description' attribute is set e.g. to 2, the following >> results in a constraint violation: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> description: d2 >> description: d3-viol >> >> However, this passes: >> >> dn: cn=usr2, dc=my-domain,dc=com >> add: description >> description: d1 >> - >> add: description >> description: d2 >> - >> add: description >> description: d3 >> >> This patch fixes the behavior in case multiple modifications are used. >> >> Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163 >> >> The patch is uploaded on fedorapeople.org: >> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-coun… >> >> I wasn't able to use ftp.openldap.org due to 'No space left' error. > > This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) I'll fix the patch. I tested only deletes with no additional values. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by hyc＠symas.com 18 Jun '12

18 Jun '12

Jan Synacek wrote: > On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: >> jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: git (c73ec15) >>> OS: linux-fedora17 >>> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >>> Submission from: (NULL) (209.132.186.34) >>> >>> >>> I'm using a 2-node mmr setup on my local machine - configuration files and >>> 'uploader' scripts are provided in the archive. >>> >>> 1) I have the two nodes running. >>> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >>> slapd's memory usage. >>> 3) After some time (at about 2k users on my system), slapd consumes a large >>> amount of memory which is still growing >>> >>> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >>> using it e.g. for modifying each user's email, does NOT result in any memory >>> leakage. >>> >>> I have also created a massif output using valgrind's massif tool: >>> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >>> >>> I found a very similar bug (#7292), but I'm not sure if it's related. >> >> Running RE24 with valgrind --leak-check=full I see no leak when running your >> test. That should be the same as git c73ec15. No idea what leak you're seeing. >> > > The memory consumption still grows and slapd eventually gets killed by oom-killer. Perhaps you're seeing fragmentation in the glibc malloc library. Please test RE24, and try with some other malloc (e.g. tcmalloc). I've run your entire test with both valgrind and with tcmalloc's heap checker and neither one shows any leak. -- -- 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#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 17 Jun '12

17 Jun '12

On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: git (c73ec15) >> OS: linux-fedora17 >> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >> Submission from: (NULL) (209.132.186.34) >> >> >> I'm using a 2-node mmr setup on my local machine - configuration files and >> 'uploader' scripts are provided in the archive. >> >> 1) I have the two nodes running. >> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >> slapd's memory usage. >> 3) After some time (at about 2k users on my system), slapd consumes a large >> amount of memory which is still growing >> >> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >> using it e.g. for modifying each user's email, does NOT result in any memory >> leakage. >> >> I have also created a massif output using valgrind's massif tool: >> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >> >> I found a very similar bug (#7292), but I'm not sure if it's related. > > Running RE24 with valgrind --leak-check=full I see no leak when running your > test. That should be the same as git c73ec15. No idea what leak you're seeing. > The memory consumption still grows and slapd eventually gets killed by oom-killer. Also, the second node (the one that the data is being replicated to) constantly calls dnPretty and dnNormalize on every single user that it has synced. At about 2k users, this starts to really show on CPU usage and overall speed as well. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by kurt＠OpenLDAP.org 16 Jun '12

16 Jun '12

Read the spec. OpenLDAP follows it to a T here. -- Kurt

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by michael＠stroeder.com 16 Jun '12

16 Jun '12

kurt(a)OpenLDAP.org wrote: > quanah(a)zimbra.com wrote: >> Kurt(a)OpenLDAP.org wrote: >>> On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: >>>> Handling "!" with objectClasses appears to be broken. For example, >>>> if I perform the following ldap query: >>>> >>>> zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config >>>> -w zimbra -b "" '(!(objectclass=junk))' >>>> >>>> This result appears incorrect to me. I would expect it to return >>>> all entries without that objectClass (which in this case, would be every >>>> entry). >>> >>> which object class (by OID)? If the server doesn't know what junk >>> is (!(objectClass=junk)) is just as undefined (objectclass=junk) is. So basically the question is: What is the negation of undefined in this context. You're saying undefined and this would mean False. But I agree with Quanah: I also expect the server to return all entries if object class 'junk' is not in the server's schema. This seems to be canonical behaviour. Various other LDAP server vendors have implemented it like this (tested on OpenDJ). > if the server doesn't know what objectClass (by OID) the descriptor > refers to, it doesn't know whether the objectClass is in the schema or > not. The server already evaluates this to "undefined" based on what's in the server's schema. So I don't understand your argument. > 'junk', for all the server knows, could refer to the same objectClass > the 'top' descriptor refers to. Why? >> I don't think it should fail to evaluate. > > It evaluates the expression to Undefined, which is exactly the > situation. Junk is not defined. To evaluate (objectClass=junk) to > true or false requires the server to know exactly what object class > 'junk' refers to. It doesn't in this case. I don't think that in case of negation a server has to mean exactly what object class 'junk' refers to. It has to simply know that none of the existing object classes refer to 'junk'. If 'junk' is not in the server's subschema the negation evaluates to True. >> Clearly, if none of the objects match the filter, >> it should return them. > > No, that's not clear. junk could be defined as: > > ( 2.5.6.0 NAME ( 'top' 'junk' ABSTRACT MUST objectClass ) If this object class description is not in the server's schema this argument is not relevant at all. > You are making assumptions regarding how junk is actually defined. The > server should not make any assumptions. Yes, the server should only look in its schema. Still I don't see any true argument why the fact that (objectClass=junk) cannot be true leads to the conclusion that (!(objectClass=junk)) is not true either. > Also, even if junk was defined in the client's schema: > ( 1.1.1.1 NAME ( 'junk' 'crap' ) AUXILIARY MUST objectClass ) > > and the server could easily have in its schema: > ( 1.1.1.1 NAME 'crap' AUXILIARY MUST objectClass ) > in its schema and lots of entries belonging to this class. Such a situation is not relevant for this discussion. And IMO there is no such thing like a client's schema (saying this while being the author of a LDAP client which makes the most versatile use of subschema information with a fall-back schema on the client's side). Ciao, Michael.

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by hyc＠symas.com 15 Jun '12

15 Jun '12

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: git (c73ec15) > OS: linux-fedora17 > URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz > Submission from: (NULL) (209.132.186.34) > > > I'm using a 2-node mmr setup on my local machine - configuration files and > 'uploader' scripts are provided in the archive. > > 1) I have the two nodes running. > 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring > slapd's memory usage. > 3) After some time (at about 2k users on my system), slapd consumes a large > amount of memory which is still growing > > Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but > using it e.g. for modifying each user's email, does NOT result in any memory > leakage. > > I have also created a massif output using valgrind's massif tool: > http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 > > I found a very similar bug (#7292), but I'm not sure if it's related. Running RE24 with valgrind --leak-check=full I see no leak when running your test. That should be the same as git c73ec15. No idea what leak you're seeing. -- -- 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#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 15 Jun '12

15 Jun '12

On 06/15/2012 01:52 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: git (c73ec15) >> OS: linux-fedora17 >> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >> Submission from: (NULL) (209.132.186.34) >> >> >> I'm using a 2-node mmr setup on my local machine - configuration files and >> 'uploader' scripts are provided in the archive. >> >> 1) I have the two nodes running. >> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >> slapd's memory usage. >> 3) After some time (at about 2k users on my system), slapd consumes a large >> amount of memory which is still growing >> >> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >> using it e.g. for modifying each user's email, does NOT result in any memory >> leakage. >> >> I have also created a massif output using valgrind's massif tool: >> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 > > I get no permission to access this URL. > Sorry about that, should be fixed now. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by hyc＠symas.com 15 Jun '12

15 Jun '12

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: git (c73ec15) > OS: linux-fedora17 > URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz > Submission from: (NULL) (209.132.186.34) > > > I'm using a 2-node mmr setup on my local machine - configuration files and > 'uploader' scripts are provided in the archive. > > 1) I have the two nodes running. > 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring > slapd's memory usage. > 3) After some time (at about 2k users on my system), slapd consumes a large > amount of memory which is still growing > > Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but > using it e.g. for modifying each user's email, does NOT result in any memory > leakage. > > I have also created a massif output using valgrind's massif tool: > http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 I get no permission to access this URL. -- -- 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#7310) unable to perform ldapadd for rootdb ""(empty)
by hyc＠symas.com 15 Jun '12

15 Jun '12

The ITS is for bug reports only. Usage questions should be posted to the openldap-technical mailing list. This ITS will be closed. pratima.boddepalli(a)syniverse.com wrote: > Full_Name: Pratima Boddepalli > Version: openldap-2.4.31 > OS: Red Hat Enterprise Linux Server release 5.5 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.111.13.77) > > > Configured in slapd.conf as below: > > suffix "" > rootdn "" > > > sample.ldif file: > dn: o=sample > objectclass: organization > o: sample > > Add Command: > ldapadd -a -D "" -h localhost -p 389 -w secret -x -f sample.ldif > ldap_bind: Invalid credentials (49) > > Please help to resolve this issue where I like to add ldap entries for rootdn "" > (empty/blank) > > This is a requirement in my company's project. Kindly help as soon as possible. > > > > -- -- 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#7310) unable to perform ldapadd for rootdb ""(empty)
by pratima.boddepalli＠syniverse.com 15 Jun '12

15 Jun '12

Full_Name: Pratima Boddepalli Version: openldap-2.4.31 OS: Red Hat Enterprise Linux Server release 5.5 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.111.13.77) Configured in slapd.conf as below: suffix "" rootdn "" sample.ldif file: dn: o=sample objectclass: organization o: sample Add Command: ldapadd -a -D "" -h localhost -p 389 -w secret -x -f sample.ldif ldap_bind: Invalid credentials (49) Please help to resolve this issue where I like to add ldap entries for rootdn "" (empty/blank) This is a requirement in my company's project. Kindly help as soon as possible.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.jp 14 Jun '12

14 Jun '12

At Wed, 13 Jun 2012 09:30:03 +0200, Michael Ströder wrote: > >>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. > >> > >> I hoped that this would not be necessary and the module work include something > >> detected via autoconf before. > > > > Can you try the following Makefile? > > > > https://gist.github.com/2915450 > Could you please submit a patch with your recent Makefile? I've filed a patch to ITS: http://www.openldap.org/its/index.cgi?findid=7309 and another one: http://www.openldap.org/its/index.cgi?findid=7308 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

(ITS#7309) [PATCH] contrib/slapd-modules: Unify the structure and usage of Makefile
by fumiyas＠osstech.co.jp 14 Jun '12

14 Jun '12

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: https://gist.github.com/2931594 Submission from: (NULL) (114.48.132.80) In contrib/slapd-modules, there are many Makefiles for each contrib modules, but there is no common style and usage of Makefile. E.g, some Makefile use $LDAP_SRC to specify a location of OpenLDAP source tree but others use $LDAPSRC or $OPENLDAP_SRC. I've created a patch to unify the structure and usage of Makefiles in contrib/slapd-modules.

1 0

(ITS#7308) [PATCH] contrib/slapd-modules: Add missing missing Makefiles
by fumiyas＠osstech.co.jp 14 Jun '12

14 Jun '12

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: https://gist.github.com/2931574 Submission from: (NULL) (114.48.132.80) In contrib/slapd-modules, some modules have no Makefile to build and install itself. I've created a patch to add Makefile and update README for that.

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by kurt＠OpenLDAP.org 14 Jun '12

14 Jun '12

--Apple-Mail=_9109C66A-11FD-46D5-B12C-CDB17F336920 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 14, 2012, at 3:31 PM, quanah(a)zimbra.com wrote: > --On Thursday, June 14, 2012 3:09 PM -0700 Kurt Zeilenga=20 > <Kurt(a)OpenLDAP.org> wrote: >=20 >>=20 >> On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: >>=20 >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.31 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.108.184.39) >>>=20 >>>=20 >>> Handling "!" with objectClasses appears to be broken. For example, = if I >>> perform the following ldap query: >>>=20 >>> zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=3Dconfig = -w >>> zimbra -b "" '(!(objectclass=3Djunk))' >>> zimbra@zre-ldap002:~$ >>>=20 >>> This result appears incorrect to me. I would expect it to return = all >>> entries without that objectClass (which in this case, would be every >>> entry). >>=20 >> which object class (by OID)? If the server doesn't know what junk = is, >> (!(objectClass=3Djunk)) is just as undefined (objectclass=3Djunk) is. >>=20 >>>=20 >>> Doing the same sort of search on a different attribute, the behavior = is >>> as expected: >>=20 >> Bad expectation, as junk here is a string not a descriptor. >=20 > Just because the objectClass doesn't exist in the schema, if the server doesn't know what objectClass (by OID) the descriptor = refers to, it doesn't know whether the objectClass is in the schema or = not. 'junk', for all the server knows, could refer to the same objectClass = the 'top' descriptor refers to. > I don't think it should fail to evaluate. It evaluates the expression to Undefined, which is exactly the = situation. Junk is not defined. To evaluate (objectClass=3Djunk) to = true or false requires the server to know exactly what object class = 'junk' refers to. It doesn't in this case. > Clearly, if none of the objects match the filter,=20 No, that's not clear. junk could be defined as: ( 2.5.6.0 NAME ( 'top' 'junk' ABSTRACT MUST objectClass ) > it should return them. You are making assumptions regarding how junk is actually defined. The = server should not make any assumptions. Also, even if junk was defined in the client's schema: ( 1.1.1.1 NAME ( 'junk' 'crap' ) AUXILIARY MUST objectClass ) and the server could easily have in its schema: ( 1.1.1.1 NAME 'crap' AUXILIARY MUST objectClass ) in its schema and lots of entries belonging to this class. The server cannot possibly return any of these entries when the filter = is (objectClass=3Djunk) and shouldn't return any entries when the filter = is (!(objectClass=3Djunk)), because doing so is, per the specs, wrong. The specs say that such filters should evaluate to Undefined. That's = what slapd(8) does. >=20 > --Quanah >=20 >=20 > -- >=20 > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >=20 >=20 --Apple-Mail=_9109C66A-11FD-46D5-B12C-CDB17F336920 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br><div><div>On Jun 14, 2012, at 3:31 PM, <a = href=3D"mailto:quanah@zimbra.com">quanah(a)zimbra.com</a> wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>--On = Thursday, June 14, 2012 3:09 PM -0700 Kurt Zeilenga <br><<a = href=3D"mailto:Kurt@OpenLDAP.org">Kurt(a)OpenLDAP.org</a>> = wrote:<br><br><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite">On Jun 14, 2012, at 2:10 PM, <a = href=3D"mailto:quanah@openldap.org">quanah(a)openldap.org</a> = wrote:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">Full_Name: Quanah = Gibson-Mount<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Version: = 2.4.31<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">OS: Linux 2.6<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">Submission from: (NULL) = (75.108.184.39)<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Handling "!" with objectClasses = appears to be broken.  For example, if = I<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">perform the following ldap = query:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">zimbra@zre-ldap002:~$ ldapsearch = -LLL -x -H <a href=3D"ldapi:///">ldapi:///</a> -D cn=3Dconfig = -w<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">zimbra -b "" = '(!(objectclass=3Djunk))'<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">zimbra@zre-ldap002:~$<br></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">This result appears incorrect to = me.  I would expect it to return = all<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">entries without that objectClass (which in this case, = would be every<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">entry).<br></blockquote></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">which object = class (by OID)?  If the server doesn't know what junk = is,<br></blockquote><blockquote type=3D"cite">(!(objectClass=3Djunk)) is = just as undefined (objectclass=3Djunk) is.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Doing the same sort of search on = a different attribute, the behavior = is<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">as expected:<br></blockquote></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Bad = expectation, as junk here is a string not a = descriptor.<br></blockquote><br></div></blockquote></div><div><br><blockqu= ote type=3D"cite"><div>Just because the objectClass doesn't exist in the = schema,</div></blockquote><div><br></div><div>if the server doesn't know = what objectClass (by OID) the descriptor refers to, it doesn't know = whether the objectClass is in the schema or = not.</div><div><br></div><div>'junk', for all the server knows, could = refer to the same objectClass the 'top' descriptor refers = to.</div><div><br></div></div><div><blockquote type=3D"cite"><div>I = don't think it  should fail to evaluate. = </div></blockquote><div><br></div>It evaluates the expression to = Undefined, which is exactly the situation.  Junk is not defined. =  To evaluate (objectClass=3Djunk) to true or false requires the = server to know exactly what object class 'junk' refers to.  It = doesn't in this case.<br><div><br></div><blockquote = type=3D"cite"><div>Clearly, if none of the objects match the filter, = <br></div></blockquote><div><br></div>No, that's not clear.  junk = could be defined as:</div><div><br></div><div><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; ">( 2.5.6.0 NAME ( 'top' 'junk' ABSTRACT MUST = objectClass )</span></div><div><div><br></div><blockquote = type=3D"cite"><div>it should return = them.<br></div></blockquote><div><br></div><div>You are making = assumptions regarding how junk is actually defined.  The server = should not make any assumptions.</div><div><br></div><div>Also, even if = junk was defined  in the client's schema:</div><div><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; "> ( 1.1.1.1 NAME ( 'junk' 'crap' ) AUXILIARY = MUST objectClass )</span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = "><br></span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = ">and the server could easily have in its schema:</span></div><div><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; "> ( 1.1.1.1 NAME 'crap' AUXILIARY MUST = objectClass )</span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = "><br></span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; ">in = its schema and lots of entries belonging to this = class.</span></div><div><span class=3D"Apple-style-span" = style=3D"font-family: monospace; font-size: 16px; white-space: pre; = "><br></span></div><div><font class=3D"Apple-style-span" = face=3D"monospace"><span class=3D"Apple-style-span" style=3D"font-size: = 16px; white-space: pre;">The server cannot possibly return any of these = entries when the filter is (objectClass=3Djunk) and shouldn't return any = entries when the filter is (!(objectClass=3Djunk)), because doing so is, = per the specs, wrong.</span></font></div><div><font = class=3D"Apple-style-span" face=3D"monospace"><span = class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: = pre;"><br></span></font></div><div><font class=3D"Apple-style-span" = face=3D"monospace"><span class=3D"Apple-style-span" style=3D"font-size: = 16px; white-space: pre;">The specs say that such filters should evaluate = to Undefined. That's what slapd(8) does.</span></font></div><div><span = class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 16px; white-space: pre; = "><br></span></div><div><br></div></div><div><blockquote = type=3D"cite"><div><br>--Quanah<br><br><br>--<br><br>Quanah = Gibson-Mount<br>Sr. Member of Technical Staff<br>Zimbra, Inc<br>A = Division of VMware, Inc.<br>--------------------<br>Zimbra ::  the = leader in open source messaging and = collaboration<br><br><br></div></blockquote></div><br></body></html>= --Apple-Mail=_9109C66A-11FD-46D5-B12C-CDB17F336920--

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by quanah＠zimbra.com 14 Jun '12

14 Jun '12

--On Thursday, June 14, 2012 3:09 PM -0700 Kurt Zeilenga <Kurt(a)OpenLDAP.org> wrote: > > On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.31 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> Handling "!" with objectClasses appears to be broken. For example, if I >> perform the following ldap query: >> >> zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w >> zimbra -b "" '(!(objectclass=junk))' >> zimbra@zre-ldap002:~$ >> >> This result appears incorrect to me. I would expect it to return all >> entries without that objectClass (which in this case, would be every >> entry). > > which object class (by OID)? If the server doesn't know what junk is, > (!(objectClass=junk)) is just as undefined (objectclass=junk) is. > >> >> Doing the same sort of search on a different attribute, the behavior is >> as expected: > > Bad expectation, as junk here is a string not a descriptor. Well, I would note that AD at least behaves the way in which I expect. Just because the objectClass doesn't exist in the schema, I don't think it should fail to evaluate. Clearly, if none of the objects match the filter, it should return them. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7307) Inconsistent "!" evaluation
by Kurt＠OpenLDAP.org 14 Jun '12

14 Jun '12

On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > Handling "!" with objectClasses appears to be broken. For example, if I perform > the following ldap query: > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b > "" '(!(objectclass=junk))' > zimbra@zre-ldap002:~$ > > This result appears incorrect to me. I would expect it to return all entries > without that objectClass (which in this case, would be every entry). which object class (by OID)? If the server doesn't know what junk is, (!(objectClass=junk)) is just as undefined (objectclass=junk) is. > > Doing the same sort of search on a different attribute, the behavior is as > expected: Bad expectation, as junk here is a string not a descriptor. > > ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" '(!(mail=junk))' > > [snip] > > # search result > search: 2 > result: 0 Success > > # numResponses: 82 > # numEntries: 81 > >

1 0

(ITS#7307) Inconsistent "!" evaluation
by quanah＠OpenLDAP.org 14 Jun '12

14 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Handling "!" with objectClasses appears to be broken. For example, if I perform the following ldap query: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" '(!(objectclass=junk))' zimbra@zre-ldap002:~$ This result appears incorrect to me. I would expect it to return all entries without that objectClass (which in this case, would be every entry). Doing the same sort of search on a different attribute, the behavior is as expected: ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" '(!(mail=junk))' [snip] # search result search: 2 result: 0 Success # numResponses: 82 # numEntries: 81

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by michael＠stroeder.com 13 Jun '12

13 Jun '12

quanah(a)zimbra.com wrote: > --On Tuesday, June 12, 2012 11:25 AM -0700 Howard Chu <hyc(a)symas.com> wrote: >> Tough luck. Currently ldap:/// means localhost. Changing the library >> behavior here would be a pretty drastic incompatible change and would >> break pretty much all existing software. This has been discussed and shot >> down before, and rejecting this request is the only correct outcome for >> this ITS. > > What about an ldap_set_option() parameter for enabling it? Given the fact that there's no standard with appropriate security considerations clearly saying e.g. what should be done in case of StartTLS and hostname check I would also leave it up to the application to do the DNS lookup itself. I think people asking for including that feature into libldap should first try to implement it themselves taking into account all security implications when relying on DNS. Several existing approaches are IMO flawed. Ciao, Michael.

1 0

Re: (ITS#7288) Doc update for MemberOf Overlay: add cn=config info
by stomptemp＠larl.org 13 Jun '12

13 Jun '12

I would be happy to change the formatting to get this patch in more acceptable shape. If there are some specific formatting rules that I didn't follow, or a specific man page I should try to emulate please let me know and I'll work on it. Thanks Josh Stompro

1 0

(ITS#7305) New function to slapi library
by jani.salonen＠eficode.com 13 Jun '12

13 Jun '12

Full_Name: Jani Salonen Version: 2.4.31 OS: Linux/Debian URL: http://uranus.eficode.fi/jsalonen/jani-salonen-120613.patch Submission from: (NULL) (192.89.165.194) Added slapi_get_client_ip call.

1 0

(ITS#7304) ldapc++ fails to build with gcc-4.7
by xarthisius.kk＠gmail.com 13 Jun '12

13 Jun '12

Full_Name: Kacper Kowalik Version: 2.4.31 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (158.75.7.230) Currently ldap fails to build with gcc-4.7 with following error: SaslInteractionHandler.cpp:56:27: error: 'STDIN_FILENO' was not declared in this scope SaslInteractionHandler.cpp:67:27: error: 'STDIN_FILENO' was not declared in this scope SaslInteractionHandler.cpp:85:23: error: 'STDIN_FILENO' was not declared in this scope make[2]: *** [SaslInteractionHandler.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -mtune=native -O2 -pipe -D_GNU_SOURCE -c LdifWriter.cpp -o LdifWriter.o >/dev/null 2>&1 x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -mtune=native -O2 -pipe -D_GNU_SOURCE -c StringList.cpp -o StringList.o >/dev/null 2>&1 x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../include -I/usr/include/db4.8 -DLDAP_CONNECTIONLESS -I../../../include -mtune=native -O2 -pipe -D_GNU_SOURCE -c TlsOptions.cpp -o TlsOptions.o >/dev/null 2>&1 make[2]: Leaving directory `/var/tmp/paludis/net-nds-openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/paludis/net-nds-openldap-2.4.31-r1/work/openldap-2.4.31/contrib/ldapc++/src' It's sufficient to include <unistd.h> in SaslInteractionHandler.cpp to fix this. I've tried to upload the patch but got: local: 0001-Fix-building-with-gcc-4.7.patch remote: Kacper-Kowalik-120613.patch 227 Entering Passive Mode (204,152,186,57,209,187) 553 Kacper-Kowalik-120613.patch: No space left on device. Downstream bug: https://bugs.gentoo.org/show_bug.cgi?id=420959

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 13 Jun '12

13 Jun '12

Michael Ströder wrote: > fumiyas(a)osstech.jp wrote: >> At Mon, 11 Jun 2012 21:30:18 +0200, >> Michael Ströder wrote: >>>>> Do I have to tweak the Makefile? >>>> >>>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. >>> >>> I hoped that this would not be necessary and the module work include something >>> detected via autoconf before. >> >> Can you try the following Makefile? >> >> https://gist.github.com/2915450 > > This works much better. > > And now the bind after Password Modify ext. op. also works! > ??? And now client-hashed password generated by web2ldap also works. Strange it did not before. Ciao, Michael.

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 13 Jun '12

13 Jun '12

This is a cryptographically signed message in MIME format. --------------ms060502000406060901070508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable fumiyas(a)osstech.jp wrote: > At Mon, 11 Jun 2012 21:30:18 +0200, > Michael Str=F6der wrote: >>>> Do I have to tweak the Makefile? >>> >>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. >> >> I hoped that this would not be necessary and the module work include s= omething >> detected via autoconf before. >=20 > Can you try the following Makefile? >=20 > https://gist.github.com/2915450 This works much better. And now the bind after Password Modify ext. op. also works! ??? Could you please submit a patch with your recent Makefile? Ciao, Michael. --------------ms060502000406060901070508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjEzMDczMDAzWjAjBgkq hkiG9w0BCQQxFgQUrungi4tWis9D11T/hGg7NPK0+MQwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEALHbs0wAx3r3but/uiE5O3lKc+27I4VhWvGrTxD8CHDtE8Xk4xA7CNiHjMMtoYWRWrSKw VWMXXhEXwNN6ePT4CIu4UgBpvh5DsVnaOeRHspjv0+V1Dy0H0QmptzyEf1pjxhguIv181eRm aZmKatgTBXTxj7aWrm1+N2ozuYXPVUSJCWXa2OcENnYc4Fm7XuAy0LDg0dqnaAxRgSlTQyu0 tEXBz5M7a0YJuCwjVMyf74f3hP/Z90CGIirnk96SKC9UutbYocWlck3F4KQkKhTR8A+Tx/Hv M9EqRvWw7PxRGoRpSSjX7SdkRw0cUw5ZJtZX3UmYohz8Ks0v+8krldsgMgAAAAAAAA== --------------ms060502000406060901070508--

1 0

(ITS#7303) bdb/hdb search checks aliases unnecessarily
by hyc＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.193) Submitted by: hyc If a search request has derefSearching set in the alias deref option, the search_aliases() function walks thru a (potentially) large number of entries checking to see if they are aliases, even if the objectclass index shows there are no alias entries in the database. It should exit early instead. The bug is also present to a lesser degree in back-mdb; the back-mdb version of search_aliases() would only do a single unneeded entry lookup.

1 0

(ITS#7302) mdb segfault when renaming entry
by quanah＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Got the following segfault in mdb when renaming entry X to the same name as a previously deleted entry Y. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f076d5c6700 (LWP 15510)] 0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at ./../../../libraries/libmdb/mdb.c:4516 4516 ./../../../libraries/libmdb/mdb.c: No such file or directory. in ./../../../libraries/libmdb/mdb.c (gdb) thr apply all bt full Thread 5 (Thread 0x7f076ddc7700 (LWP 15509)): #0 0x00007f1b7261c2d3 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #1 0x00000000004395d9 in slapd_daemon_task (ptr=0x2715d00) at daemon.c:2540 ns = 1 at = 0 nfds = 8 revents = 0x287e000 tvp = 0x7f076ddc4da0 cat = {tv_sec = 1339538180, tv_usec = 0} i = 1 nwriters = 0 now = 1339537971 tv = {tv_sec = 209, tv_usec = 0} tdelta = 1 rtask = 0x2d81950 l = 3 last_idle_check = 1339537880 ebadf = 0 tid = 0 #2 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 0x7f076d5c6700 (LWP 15510)): #0 0x00007f1b6ea5190b in mdb_cursor_del (mc=0x2e09a08, flags=0) at ./../../../libraries/libmdb/mdb.c:4516 leaf = 0x130000004c rc = 0 #1 0x00007f1b6ea519b4 in mdb_cursor_del (mc=0x2e09880, flags=0) at ./../../../libraries/libmdb/mdb.c:4523 leaf = 0x50baacc rc = 0 #2 0x00007f1b6ea42088 in mdb_dn2id_delete (op=0x2c0fc00, mc=0x2e09880, id=75) at dn2id.c:235 key = {mv_size = 8, mv_data = 0x7f076d5c5468} rc = 0 #3 0x00007f1b6ea31abc in mdb_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:336 mdb = 0x2e56000 pdn = {bv_len = 16, bv_val = 0x48e82c2 "dc=zimbra,dc=com"} e = 0x48e8e90 p = 0x48e83f0 manageDSAit = 0 children = 0x2722ec0 entry = 0x2722f00 txn = 0x458c000 mc = 0x2e09880 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x2e56000}, moi_txn = 0x458c000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f076d5c5530 preread_ctrl = 0x0 ctrls = {0x0, 0x151f55373c8e5d00, 0x0, 0x48e8308, 0x7f076d5c5570, 0x27fb280} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #4 0x00000000004d4b08 in overlay_op_walk (op=0x2c0fc00, rs=0x7f076d5c5a10, which=op_delete, oi=0x2c62d20, on=0x0) at backover.c:671 func = 0x7f1b6ec60cf8 rc = 32768 #5 0x00000000004d4d46 in over_op_func (op=0x2c0fc00, rs=0x7f076d5c5a10, which=op_delete) at backover.c:723 oi = 0x2c62d20 on = 0x2c62780 be = 0x27589c0 db = {bd_info = 0x7f1b6ec60ca0, bd_self = 0x27589c0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x2be7900, be_nsuffix = 0x2be78c0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2d5eda0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2d5ed80 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x2c6f6c0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x456f610, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7f1b6ec60aa0, be_private = 0x2e56000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x48e82e0, sc_response = 0x4d3840 <over_back_response>, sc_cleanup = 0, sc_private = 0x2c62d20} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004d4f2f in over_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at backover.c:780 No locals. #7 0x000000000046149c in fe_op_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:174 org_req_dn = {bv_len = 0, bv_val = 0x0} org_ndn = {bv_len = 0, bv_val = 0x0} org_managedsait = 41923200 org_req_ndn = {bv_len = 0, bv_val = 0x0} org_dn = {bv_len = 0, bv_val = 0x0} repl_user = 0 pdn = {bv_len = 0, bv_val = 0x0} op_be = 0x27589c0 bd = 0x75fdc0 #8 0x000000000046110f in do_delete (op=0x2c0fc00, rs=0x7f076d5c5a10) at delete.c:95 dn = {bv_len = 26, bv_val = 0x4577da5 "ou=people,dc=zimbra,dc=com"} #9 0x000000000043d8c9 in connection_operation (ctx=0x7f076d5c5b50, arg_v=0x2c0fc00) at connection.c:1150 rc = 80 cancel = 0 op = 0x2c0fc00 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 74 opidx = SLAP_OP_DELETE conn = 0x2f6b440 memctx = 0x27fb280 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043de67 in connection_read_thread (ctx=0x7f076d5c5b50, argv=0x13) at connection.c:1286 rc = 0 cri = {op = 0x2c0fc00, func = 0, arg = 0x0, ctx = 0x7f076d5c5b50, nullop = 0} s = 19 #11 0x00007f1b73db5cc9 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:688 pool = 0x273c1c0 task = 0x4576680 work_list = 0x273c258 ctx = {ltu_id = 139669876270848, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c78200, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x27fb280, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x0, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x45e6000, ltk_data = 0x457e000, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x49e8000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x4daa000, ltk_data = 0x4581400, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x65f2000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x4579200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 854 hash = 2665057110 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #13 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #14 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 0x7ef36cdc3700 (LWP 15671)): #0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0, mutex=0x273c1c8) at thr_posix.c:277 No locals. #2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:675 pool = 0x273c1c0 task = 0x0 work_list = 0x273c258 ctx = {ltu_id = 139583968524032, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c04400, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x2bc1200, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x2c0e000, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x4daa000, ltk_data = 0x4582e00, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x51ee000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x45e6000, ltk_data = 0x4586200, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x55ee000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x457a400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 464 hash = 81037776 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 0x7ef36c5c2700 (LWP 15672)): #0 0x00007f1b728c385c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db72be in ldap_pvt_thread_cond_wait (cond=0x273c1f0, mutex=0x273c1c8) at thr_posix.c:277 No locals. #2 0x00007f1b73db5c22 in ldap_int_thread_pool_wrapper (xpool=0x273c1c0) at tpool.c:675 pool = 0x273c1c0 task = 0x0 work_list = 0x273c258 ctx = {ltu_id = 139583960131328, ltu_key = {{ltk_key = 0x43d429, ltk_data = 0x2c04500, ltk_free = 0x43d26d <conn_counter_destroy>}, {ltk_key = 0x4b388f, ltk_data = 0x2bc1300, ltk_free = 0x4b36b4 <slap_sl_mem_destroy>}, {ltk_key = 0x4591ad, ltk_data = 0x2c0e800, ltk_free = 0x459100 <slap_op_q_destroy>}, {ltk_key = 0x45e6000, ltk_data = 0x458e000, ltk_free = 0x7f1b6ea4492b <mdb_reader_free>}, {ltk_key = 0x7f1b6ea384d9, ltk_data = 0x75f6000, ltk_free = 0x7f1b6ea38491 <scope_chunk_free>}, {ltk_key = 0x7f1b6ea3aaf4, ltk_data = 0x78f6000, ltk_free = 0x7f1b6ea3aad1 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x457b600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 576 hash = 1606749760 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1b728be9ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007f1b7261bcdd in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 0x7f1b744e4720 (LWP 15508)): #0 0x00007f1b728c003d in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007f1b73db71ff in ldap_pvt_thread_join (thread=139669884663552, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x000000000043a7ff in slapd_daemon () at daemon.c:2930 i = 0 rc = 0 #3 0x0000000000416d7f in main (argc=9, argv=0x7fffc49fe378) at main.c:1012 i = 9 no_detach = 0 rc = 0 urls = 0x271a000 "ldap://zre-ldap003.eng.vmware.com:389 ldapi:///" username = 0x2714020 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {10, 11} g_argc = 9 g_argv = 0x7fffc49fe378 configfile = 0x0 configdir = 0x2712040 "/opt/zimbra/data/ldap/config" serverName = 0x7fffc49ffd92 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9928 "" l = 139755887037800 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main"

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 11:25 AM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.31 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.108.184.39) >> >> >> LDAP URI handling via SRV records is not in the library. In >> particular, an OpenLDAP library client that specifies a >> (correctly formed or otherwise) LDAP URI of the form: >> >> ldap:///dc=example,dc=com/ >> >> will not be connected to the LDAP servers found in the SRV records >> for _ldap._tcp.example.com. That code is only in the ldapsearch(1) >> and related tools. >> >> The existence of the low-level support functions in the library is >> of no help to users who want to specify URIs that resolve to the >> underlying LDAP servers via SRV records. > > Tough luck. Currently ldap:/// means localhost. Changing the library > behavior here would be a pretty drastic incompatible change and would > break pretty much all existing software. This has been discussed and shot > down before, and rejecting this request is the only correct outcome for > this ITS. What about an ldap_set_option() parameter for enabling it? >> Also, the SRV -> host:port list lookup code that is in the library >> (but not tied to the libraries connection establishment code) is >> broken, it ignores the weight and priority which is not a good >> idea, the published SRV priorities and weights must not be ignored. > > priorities/weights are already the subject of ITS#7027. Ok, so will 7027 be committed, since there is a patch already provided? ;) The discussion around this started at <http://archives.neohapsis.com/archives/postfix/2012-06/0183.html> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7301) Improve DNS SRV support in OpenLDAP
by hyc＠symas.com 12 Jun '12

12 Jun '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > LDAP URI handling via SRV records is not in the library. In > particular, an OpenLDAP library client that specifies a > (correctly formed or otherwise) LDAP URI of the form: > > ldap:///dc=example,dc=com/ > > will not be connected to the LDAP servers found in the SRV records > for _ldap._tcp.example.com. That code is only in the ldapsearch(1) > and related tools. > > The existence of the low-level support functions in the library is > of no help to users who want to specify URIs that resolve to the > underlying LDAP servers via SRV records. Tough luck. Currently ldap:/// means localhost. Changing the library behavior here would be a pretty drastic incompatible change and would break pretty much all existing software. This has been discussed and shot down before, and rejecting this request is the only correct outcome for this ITS. > Also, the SRV -> host:port list lookup code that is in the library > (but not tied to the libraries connection establishment code) is > broken, it ignores the weight and priority which is not a good > idea, the published SRV priorities and weights must not be ignored. priorities/weights are already the subject of ITS#7027. -- -- 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#7301) Improve DNS SRV support in OpenLDAP
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 6:09 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) Note: Filed on behalf of the Postfix authors. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7301) Improve DNS SRV support in OpenLDAP
by quanah＠OpenLDAP.org 12 Jun '12

12 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) LDAP URI handling via SRV records is not in the library. In particular, an OpenLDAP library client that specifies a (correctly formed or otherwise) LDAP URI of the form: ldap:///dc=example,dc=com/ will not be connected to the LDAP servers found in the SRV records for _ldap._tcp.example.com. That code is only in the ldapsearch(1) and related tools. The existence of the low-level support functions in the library is of no help to users who want to specify URIs that resolve to the underlying LDAP servers via SRV records. Also, the SRV -> host:port list lookup code that is in the library (but not tied to the libraries connection establishment code) is broken, it ignores the weight and priority which is not a good idea, the published SRV priorities and weights must not be ignored.

1 0

Re: (ITS#7300) ACLs
by quanah＠zimbra.com 12 Jun '12

12 Jun '12

--On Tuesday, June 12, 2012 5:57 PM +0000 andre.cardinal(a)bell.ca wrote: > Full_Name: Andre Cardinal > Version: 2.4.30 > OS: Red Hat 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.47.249.246) This is not a bug report. This ITS will be closed. If you have usage questions, please use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7300) ACLs
by andre.cardinal＠bell.ca 12 Jun '12

12 Jun '12

Full_Name: Andre Cardinal Version: 2.4.30 OS: Red Hat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.47.249.246) I have the following ACL set up in slapd.conf access to dn.base="" by * read access to attrs=GCSRAAllow,GCSRAGroup,GCSRASubjectdn,userpassword by dn="cn=ProvAdmin,ou=GCSRAAdmin,o=gc,c=ca" write by dn="cn=gateAdmin1,ou=GCSRAAdmin,o=gc,c=ca" read by dn="cn=gateAdmin2,ou=GCSRAAdmin,o=gc,c=ca" read slapacl -f /usr/local/etc/openldap/slapd.conf -D cn=provadmin,ou=gcsraadmin,o=gc,c=ca -b ou=gcsrausers,o=gc,c=ca gcsraallow authcDN: "cn=provadmin,ou=gcsraadmin,o=gc,c=ca" GCSRAAllow: write(=wrscxd) However any modify I try returns: modifying entry "GCSRASubjectDN=my636-test,ou=GCSRAUsers,o=gc,c=ca" ldap_modify: Insufficient access (50)

1 0

(ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 12 Jun '12

12 Jun '12

Full_Name: Jan Synacek Version: git (c73ec15) OS: linux-fedora17 URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz Submission from: (NULL) (209.132.186.34) I'm using a 2-node mmr setup on my local machine - configuration files and 'uploader' scripts are provided in the archive. 1) I have the two nodes running. 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring slapd's memory usage. 3) After some time (at about 2k users on my system), slapd consumes a large amount of memory which is still growing Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but using it e.g. for modifying each user's email, does NOT result in any memory leakage. I have also created a massif output using valgrind's massif tool: http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 I found a very similar bug (#7292), but I'm not sure if it's related.

1 0

(ITS#7298) permissive modify control misparsed
by ondrej.kuznik＠acision.com 12 Jun '12

12 Jun '12

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: Submission from: (NULL) (62.168.56.1) It appears that an oversight in commit f810e6ed417939ed69b388ad7fb0c696e185f593 has caused the permissive modify control[1] to be parsed as needing a value. Negating the condition in file servers/slapd/controls.c at line 1627 fixes that. [1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366984(v=vs.85).a…

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by fumiyas＠osstech.jp 11 Jun '12

11 Jun '12

At Mon, 11 Jun 2012 21:30:18 +0200, Michael Ströder wrote: > >> Do I have to tweak the Makefile? > > > > Add -fPIC to $CCFLAGS in Makefile if you are using GCC. > > I hoped that this would not be necessary and the module work include something > detected via autoconf before. Can you try the following Makefile? https://gist.github.com/2915450 > Anyway it does not work for me. If I set password-hash {SSHA512} such a > userPassword value is added to the entry but the bind does not work. > > Also if I generate a salted SHA-2 userPassword with my web2ldap it does not > work. (I did interop-tests web2ldap<->OpenDJ before with salted SHA-2 hashes.) > > SHA-2 hashes without salt seem to work. I've confirmed that slapd-sha2 works on Debian GNU/Linux unstable (x86-64), Solaris 10 (SPARC) and AIX 6.1 (POWER). Can you try the following command line with the latest master source or http://www.openldap.org/its/index.cgi?findid=7284 patch? $ slappasswd -o module-load=slapd-sha2 -h '{SSHA512}' -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes
by michael＠stroeder.com 11 Jun '12

11 Jun '12

This is a cryptographically signed message in MIME format. --------------ms030301040508090109040302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable SATOH Fumiyasu wrote: > Michael Str=F6der wrote: >> Do I have to tweak the Makefile? >=20 > Add -fPIC to $CCFLAGS in Makefile if you are using GCC. I hoped that this would not be necessary and the module work include some= thing detected via autoconf before. Anyway it does not work for me. If I set password-hash {SSHA512} such a userPassword value is added to the entry but the bind does not work. Also if I generate a salted SHA-2 userPassword with my web2ldap it does n= ot work. (I did interop-tests web2ldap<->OpenDJ before with salted SHA-2 has= hes.) SHA-2 hashes without salt seem to work. Ciao, Michael. --------------ms030301040508090109040302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjExMTkzMDE4WjAjBgkq hkiG9w0BCQQxFgQUMUtgv30CwgTbWOkzpQDwzN00lcMwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAw0JtCBlKGlfrvqpogZVQuE1yAJWrELkDIlOEkqPIy/apGKJLDE+BIcxLZTAluWAWT3zR E7oTFnqee1rTZ3Uip5EMmW0GV81y46mLLD+kRvGpIcEJA0jl6ksAIHBLNGhzxcQsnmyI6qRc L+2WO7KpTNNqj83tfvPxRNnorcCj+76Mt+VNTrPu9f5TzBbG4IkOLdeJyjNv4Kh4ZRoI4dsy 0h4FIbAam6H+ZLLg+L+yeXdQrmUpUJq+T4iQ0Wl7vcerfDx65nt/NyVMWq1hqcO/wIg5PC9k aZXcLzWxhH6ovmjEB41sGDEuREiooGw+X2FIKG1D3EAr7ts7SqDpbIjLZgAAAAAAAA== --------------ms030301040508090109040302--

1 0

Re: (ITS#7297) slapd crashes when ldap->mysql-backend query contains '\00' symbols
by quanah＠zimbra.com 11 Jun '12

11 Jun '12

--On Monday, June 11, 2012 12:10 PM +0000 mobisid(a)gmail.com wrote: > Full_Name: Alex Rusinov > Version: slapd 2.3.43 (Feb 22 2012 15:59:04) This is not a supported release series. Please use a supported version of OpenLDAP prior to filing ITSes. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7297) slapd crashes when ldap->mysql-backend query contains '\00' symbols
by masarati＠aero.polimi.it 11 Jun '12

11 Jun '12

On 06/11/2012 02:10 PM, mobisid(a)gmail.com wrote: > Full_Name: Alex Rusinov > Version: slapd 2.3.43 (Feb 22 2012 15:59:04) > OS: CentOS release 5.6 (Final), Linux isg 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:578:1:101:daa:ef09:905b:5510) > > > Im experiencing ldap crashes when query contains \00 symbols, example (dc was > hidden): > # ldapsearch -LLL -x -s sub -b "dc=aaanet,dc=net" > "(&(objectClass=account)(uid=aaa\00bbb))" > ldap_result: Can't contact LDAP server (-1)<- here it crashed > -- > I'm using ldap with mysql-backend, versions: > http://pastebin.com/AMBZKvjH installed > ======= > logs: > http://pastebin.com/Jmz61mQb > > Right before the crash the following string appears in logs: > slapd: ../../../../servers/slapd/back-sql/util.c:144: backsql_strfcat_x: > Assertion `dest->bb_val.bv_val == ((void *)0) || dest->bb_val.bv_len == strlen( > dest->bb_val.bv_val )' failed. At a first glance, the test "dest->bb_val.bv_len == strlen( dest->bb_val.bv_val )" looks malformed, as it expects bervals to be valid C strings, so it looks like a bug. Disclaimer: please don't take this message as a commitment to fixing the bug, as I don't know when I'll have time to look at it in detail. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7297) slapd crashes when ldap->mysql-backend query contains '\00' symbols
by mobisid＠gmail.com 11 Jun '12

11 Jun '12

Full_Name: Alex Rusinov Version: slapd 2.3.43 (Feb 22 2012 15:59:04) OS: CentOS release 5.6 (Final), Linux isg 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:578:1:101:daa:ef09:905b:5510) Im experiencing ldap crashes when query contains \00 symbols, example (dc was hidden): # ldapsearch -LLL -x -s sub -b "dc=aaanet,dc=net" "(&(objectClass=account)(uid=aaa\00bbb))" ldap_result: Can't contact LDAP server (-1) <- here it crashed -- I'm using ldap with mysql-backend, versions: http://pastebin.com/AMBZKvjH installed ======= logs: http://pastebin.com/Jmz61mQb Right before the crash the following string appears in logs: slapd: ../../../../servers/slapd/back-sql/util.c:144: backsql_strfcat_x: Assertion `dest->bb_val.bv_val == ((void *)0) || dest->bb_val.bv_len == strlen( dest->bb_val.bv_val )' failed. Any ideas? Alex

1 0

Re: (ITS#7292) Memory leak with MMR + delta syncrepl
by hyc＠symas.com 08 Jun '12

08 Jun '12

brandon.hume(a)dal.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.31 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/ol-2.4.31_memleak.tar.gz > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > OpenLDAP 2.4.31 compiled in 64-bit with BerkeleyDB 5.3.15 appears to exhibit a > memory leak while replicating the full database from another node in MMR. > > A two-node MMR configuration has been set up. Node 1 is full populated with > data, approximately 338k DNs, which occupies around 1G on-disk (including bdb > __db.* and log.* files). Node 1 is brought up and on a 64-bit system occupies > around 5.5G VM and 4.7G RSS. > > Node 2 is initialized with a copy of cn=config (slapcat/slapadd method) and > brought up with an empty database to begin replication. Over the course of the > replication, node 2's slapd will grow continuously. On the one occasion it > managed to "finish" the replication (with the test database), node 2's slapd > occupied 14G VM and approximately 6G RSS. > > I've included a link to the test kit I put together. This includes a fairly > large, anonimized database, as well as a simplified copy of the configuration. > I've left in the sendmail and misc schemas but removed irrelevant local schemas. > Also included are the DB_CONFIGs used for the main database and accesslog, and > the configuration scripts used for compiling both bdb and OpenLDAP. > > Steps to reproduce: > - Compile and install bdb and OpenLDAP with options the same as in the > config-db.sh and config-ldap.sh scripts. > - Initialize configuration on node 1 and 2 using "slapadd -F etc/slapd.d -b > cn=config -l slapd-conf.ldif". > - Initialize main DB on node 1 using "slapadd -l test_dit.ldif" > - Start node 1. The slapd process should stabilize at around 5G VM in use. > - Start node 2 and allow it to begin replication. > > I've tested with node 2 on both RHEL6 and on Solaris 10. In both cases, node > 2's slapd became extremely bloated over the course of several hours. Only the > Solaris SPARC box was able to complete the replication, stabilizing at 14G VM > used. The Redhat x86 box continued to grow far beyond the 16G swap limit and > was killed by the OS. > > I've attempted to use the Solaris libumem tools to trace the memory leak, using > gcore on the running process and "::findleaks -dv" within mdb running on the > core. I've included the report generated in case it provides any useful > information as "mdb_findleaks_analysis.txt". Disregard if you wish. > > (I apologize for the large test LDIF. I wanted something to definitively show > the problem so didn't want to trim it too much...) Thanks for the detailed report, your test revealed several bugs. The leaks are now fixed in git master. There's still another issue where node 2 starts sending the received changes back to node 1, even though they came from node 1 originally. This is triggered because most of your entries were created with sid=0, and syncprov doesn't know that they actually originated from node 1 (sid=1). That wastes a lot of CPU/network while it sends over a bunch of data that isn't needed, but that's all a separate issue from the memory leaks. -- -- 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#7296) slapd stuck (in async mode) after client disconnection
by gerard.gobillard＠alcatel-lucent.com 08 Jun '12

08 Jun '12

Full_Name: gerard gobillard Version: 2.4.30 OS: RHEL 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.139.226.97) Hello all, Summary : on an Intel basic box (dual core) we create search base traffic with slamd in asynchronous mode (30 threads). When, after 1 or 2 seconds, Ctrl-C is sent to slamd (SIGINT), slapd gets stuck with main thread in epoll_wait() and all other threads in pthread_cond_wait() (in send_ldap_ber()). It may be necessary to repeat a few times before slapd gets stuck Notes : no change to slapd.conf except RootDN. We build OpenLDAP as follows : CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include -g" export CPPFLAGS LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib -R/usr/local/BerkeleyDB.4.7/lib" export LDFLAGS LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.7/lib ./configure --prefix=/usr/slapd.2.4.23.Dbg --enable-spasswd=yes --enable-crypt=yes --disable-syslog --enable-debug --enable-ppolicy make depend make make install gstack: [root@lalxsdmcomp db-5.2.36]# gstack 19444 Thread 18 (Thread 1099237696 (LWP 19445)): #0 0x0000003cf08d21d8 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042bf11 in slapd_daemon_task () #2 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 17 (Thread 1112529216 (LWP 19463)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 16 (Thread 1120921920 (LWP 19464)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 15 (Thread 1129314624 (LWP 19465)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 14 (Thread 1137707328 (LWP 19466)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 13 (Thread 1146100032 (LWP 19467)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 12 (Thread 1154492736 (LWP 19468)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 11 (Thread 1162885440 (LWP 19469)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004446a0 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 10 (Thread 1171278144 (LWP 19470)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 9 (Thread 1087490368 (LWP 19471)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 8 (Thread 1179670848 (LWP 19472)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 7 (Thread 1188063552 (LWP 19473)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 6 (Thread 1196456256 (LWP 19474)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004446a0 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 5 (Thread 1204848960 (LWP 19475)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 4 (Thread 1213241664 (LWP 19476)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 3 (Thread 1221634368 (LWP 19477)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x0000000000444428 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 2 (Thread 1230027072 (LWP 19478)): #0 0x0000003cf140a4b6 in pthread_cond_wait@@GLIBC_2.3.2 () #1 0x00000000004446a0 in send_ldap_ber () #2 0x00000000004477da in slap_send_search_entry () #3 0x00000000004cdbe6 in bdb_search () #4 0x00000000004334e4 in fe_op_search () #5 0x0000000000432d9b in do_search () #6 0x000000000042fec7 in connection_operation () #7 0x000000000056562c in ldap_int_thread_pool_wrapper () #8 0x0000003cf1406307 in start_thread () from /lib64/libpthread.so.0 #9 0x0000003cf08d1ded in clone () from /lib64/libc.so.6 Thread 1 (Thread 47813429243440 (LWP 19444)): #0 0x0000003cf14075c5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042cf32 in slapd_daemon () #2 0x000000000040d2a0 in main () #0 0x0000003cf14075c5 in pthread_join () from /lib64/libpthread.so.0 netstat: [root@lalxsdmcomp db-5.2.36]# netstat -pan | grep :389 tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 19444/slapd tcp 28071 0 172.25.198.71:389 172.25.195.198:38743 CLOSE_WAIT 19444/slapd tcp 14026 0 172.25.198.71:389 172.25.195.198:38749 CLOSE_WAIT 19444/slapd tcp 57221 0 172.25.198.71:389 172.25.195.198:38751 CLOSE_WAIT 19444/slapd tcp 31304 0 172.25.198.71:389 172.25.195.198:38750 CLOSE_WAIT 19444/slapd tcp 38300 0 172.25.198.71:389 172.25.195.198:38745 CLOSE_WAIT 19444/slapd tcp 83048 0 172.25.198.71:389 172.25.195.198:38744 ESTABLISHED 19444/slapd tcp 3433 0 172.25.198.71:389 172.25.195.198:38747 CLOSE_WAIT 19444/slapd tcp 11058 0 172.25.198.71:389 172.25.195.198:38746 CLOSE_WAIT 19444/slapd tcp 47204 0 172.25.198.71:389 172.25.195.198:38757 CLOSE_WAIT 19444/slapd tcp 36392 0 172.25.198.71:389 172.25.195.198:38756 CLOSE_WAIT 19444/slapd tcp 2341 0 172.25.198.71:389 172.25.195.198:38759 CLOSE_WAIT 19444/slapd tcp 73183 0 172.25.198.71:389 172.25.195.198:38758 ESTABLISHED 19444/slapd tcp 71796 0 172.25.198.71:389 172.25.195.198:38753 CLOSE_WAIT 19444/slapd tcp 78209 0 172.25.198.71:389 172.25.195.198:38752 CLOSE_WAIT 19444/slapd tcp 35915 0 172.25.198.71:389 172.25.195.198:38755 CLOSE_WAIT 19444/slapd tcp 12701 0 172.25.198.71:389 172.25.195.198:38754 CLOSE_WAIT 19444/slapd tcp 20333 0 172.25.198.71:389 172.25.195.198:38765 CLOSE_WAIT 19444/slapd tcp 74817 0 172.25.198.71:389 172.25.195.198:38764 CLOSE_WAIT 19444/slapd tcp 73757 0 172.25.198.71:389 172.25.195.198:38767 CLOSE_WAIT 19444/slapd tcp 2705 0 172.25.198.71:389 172.25.195.198:38766 CLOSE_WAIT 19444/slapd tcp 36180 0 172.25.198.71:389 172.25.195.198:38761 CLOSE_WAIT 19444/slapd tcp 75029 0 172.25.198.71:389 172.25.195.198:38760 CLOSE_WAIT 19444/slapd tcp 49112 0 172.25.198.71:389 172.25.195.198:38763 CLOSE_WAIT 19444/slapd tcp 8726 0 172.25.198.71:389 172.25.195.198:38762 CLOSE_WAIT 19444/slapd tcp 44 0 172.25.198.71:389 172.25.195.198:38772 ESTABLISHED - tcp 4005 0 172.25.198.71:389 172.25.195.198:38769 CLOSE_WAIT 19444/slapd tcp 17789 0 172.25.198.71:389 172.25.195.198:38768 CLOSE_WAIT 19444/slapd tcp 9945 0 172.25.198.71:389 172.25.195.198:38770 CLOSE_WAIT 19444/slapd tcp 0 0 :::389 :::* LISTEN 19444/slapd Provides attachments at https://online-storage.yuuwaa.com/s/HkSdr/94bc6ba666 slapd_stuck.log - openldap logs populBlits.ldif - ldif file to get a blitz population (that's what we used but it works with any other data) testWriteTO.pl - a Perl script to loop thru client disconnection

1 0

(ITS#7295) Problem with TLS: threads and OpenSSL
by quanah＠OpenLDAP.org 07 Jun '12

07 Jun '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Resurrecting ITS#1823. This issue with SSL mutexes still exists today, and is causing https://sourceforge.net/tracker/?func=detail&atid=1147701&aid=3531477&group… with OpenDKIM

1 0

(ITS#7294) Reference RFC 4526 instead of draft-zeilenga-ldap-t-f
by michael＠stroeder.com 07 Jun '12

07 Jun '12

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/man-pages-patch-rfc4526.diff Submission from: (NULL) (79.227.167.46) draft-zeilenga-ldap-t-f was issued as RFC 4526. See patch attached for slapd-ldap(5) and slapd-meta(5).

1 0

(ITS#7293) [PATCH] Add missing function declarations and make some functions static
by fumiyas＠osstech.co.jp 07 Jun '12

07 Jun '12

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-function-declarations.patch Submission from: (NULL) (220.100.28.128) This patch adds missing function declarations to *.h, and make some functions and a global variable static.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs