- openldap-bugs - openldap.org

(ITS#7126) MDB_cursor.mc_top is used uninitialized
by h.b.furuseth＠usit.uio.no 13 Jan '12

13 Jan '12

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard test027-emptydn uses MDB_cursor.mc_top uninitialized. To force a crash, initialize it to 0xdead in mdb_cursor_init() or mdb_cursor_open(). Crash at line 4669: mdb_xcursor_init1(): mx->mx_db.md_pad = mc->mc_pg[mc->mc_top]->mp_pad; where mc_top is still 0xdead. Does not happen in 2.4.28.

1 0

(ITS#7125) Misplaced connection_done() calls
by h.b.furuseth＠usit.uio.no 13 Jan '12

13 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.26 - 2.4.28 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard Connection.c_mutex gets unlocked twice since since commit 9e00b6cc6ce2857490b33218bdaf1339319c5f60 (Add strictrefresh syncrepl option): connection_done() is called inside connection_<first/next>() loops, but connection_next() does the same inlined. The functions should be used as: for (c=connection_first(...); c; c=connection_next(c,...)) {...} connection_done(c); though connection_done(c) is currently unnecessary when c==NULL. Fixing.

1 0

RE: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by qzhu＠tibco-support.com 12 Jan '12

12 Jan '12

Dear team, Could you please provide me the roadmap of OpenLDAP directory server for 2012? We are interested in finding out ¡€ Any new releases planning in 2012. If any, what are the new features? ¡€ Any plan to support Windows7, RHEL6.x and AIX 7.1? Thanks& Best regards, Henry -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 2012Äê1ÔÂ12ÈÕ 20:22 To: Qingyun Zhu Subject: Re: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#7124. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#7124) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#7124) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=7124 Please remember to retain your issue tracking number (ITS#7124) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by qzhu＠tibco-support.com 12 Jan '12

12 Jan '12

Full_Name: Henry Zhu Version: 2.4.26 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.138.101.62) Could you please provide me the roadmap of OpenLDAP directory server for 2012? We are interested in finding out ¡€ Any new releases planning in 2012. If any, what are the new features? ¡€ Any plan to support Windows7, RHEL6.x and AIX 7.1?

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by hyc＠symas.com 12 Jan '12

12 Jan '12

Howard Chu wrote: > ondrej.kuznik(a)acision.com wrote: >> On 07/07/2011 03:26 PM, ondrej.kuznik(a)acision.com wrote: >>> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c >>> has an example of such overlay. To try it, initialize the overlay and >>> add these entries: >>> >>> dn: olcTestAttrOne=zero,$OVERLAY_DN >>> objectclass: olcTestOne >>> >>> dn: olcTestAttrTwo=one,$OVERLAY_DN >>> objectclass: olcTestTwo >>> >>> dn: olcTestAttrOne=two,$OVERLAY_DN >>> objectclass: olcTestOne >>> >>> dn: olcTestAttrTwo=three,$OVERLAY_DN >>> objectclass: olcTestTwo >>> >>> After a restart compare the output of slapcat -n0 with the output of >>> ldapsearch -b cn=config, you should see at least one different entry. >>> You might also try to modify the entries before and after the restart. >>> For those that do not match you get "no such object" as the dn is no >>> longer in the ldif database. >> >> The issue is in bconfig.c:4726, the code treats all siblings as part of >> one ordering (contrary to what >> http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html >> implies since cn=config seems to treat everything as X-ORDERED >> 'SIBLINGS'), while back-ldif orders them accordingly. >> Also its caller (config_ldif_resp) does not expect any reordering to be >> necessary, after all it should be (and is) reading a valid cn=config db, >> so the entry renaming then never gets propagated to back-ldif causing >> this desync. >> > This ITS still appears to me to be invalid. bconfig treats all siblings *of > the same type* as a single ordering. Your demonstration code is claiming your > entries are all of the same type, even though they aren't. I.e., all entries > in cn=config of a given type have only one distinguished naming attribute. You > have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config > doesn't distinguish them in its sort order. Additionally, you have hijacked the Cft_Overlay type for your custom entries, even though that type is reserved for actual overlay config entries. You should be using Cft_Misc for your custom entries. All of the other Cft_* types are reserved for all of the built in cn=config objectclasses. -- -- 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#6987) cn=config renumbers indexes on startup without modrdn-ing them
by hyc＠symas.com 12 Jan '12

12 Jan '12

ondrej.kuznik(a)acision.com wrote: > On 07/07/2011 03:26 PM, ondrej.kuznik(a)acision.com wrote: >> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c >> has an example of such overlay. To try it, initialize the overlay and >> add these entries: >> >> dn: olcTestAttrOne=zero,$OVERLAY_DN >> objectclass: olcTestOne >> >> dn: olcTestAttrTwo=one,$OVERLAY_DN >> objectclass: olcTestTwo >> >> dn: olcTestAttrOne=two,$OVERLAY_DN >> objectclass: olcTestOne >> >> dn: olcTestAttrTwo=three,$OVERLAY_DN >> objectclass: olcTestTwo >> >> After a restart compare the output of slapcat -n0 with the output of >> ldapsearch -b cn=config, you should see at least one different entry. >> You might also try to modify the entries before and after the restart. >> For those that do not match you get "no such object" as the dn is no >> longer in the ldif database. > > The issue is in bconfig.c:4726, the code treats all siblings as part of > one ordering (contrary to what > http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html > implies since cn=config seems to treat everything as X-ORDERED > 'SIBLINGS'), while back-ldif orders them accordingly. > Also its caller (config_ldif_resp) does not expect any reordering to be > necessary, after all it should be (and is) reading a valid cn=config db, > so the entry renaming then never gets propagated to back-ldif causing > this desync. > This ITS still appears to me to be invalid. bconfig treats all siblings *of the same type* as a single ordering. Your demonstration code is claiming your entries are all of the same type, even though they aren't. I.e., all entries in cn=config of a given type have only one distinguished naming attribute. You have used olcTestAttrOne and olcTestAttrTwo for the same type, so cn=config doesn't distinguish them in its sort order. -- -- 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#7118) [PATCH] Improve SASL plugin handling
by thomas＠koeller.dyndns.org 10 Jan '12

10 Jan '12

On Tuesday 10 January 2012 09:56:02 Pierangelo Masarati wrote: > > Now, if ldapdb is incompatible with slapd at a fundamental level, and > > causes problems when loaded, I think not to load it is the right thing > > to do, and this is what my patch does. > > An alternative solution consists in creating a specific folder > containing plugins one wants to load, and start slapd with SASL_PATH set > to point to that folder. This allows fine tuning of what to load > without modifying a single line of code. That is certainly true, however, it misses the point I am trying to make. I want to provide a fix for the problem I encountered. >From a user's perspective, it is certainly preferable for the whole thing to 'just work', instead of being provided with instructions about how to configure one's system to avoid problems that arise when using the standard configuration. This places the burden on the user, for no other gain than being able to load a module that cannot be used anyway. With the change I proposed, slapd can work with every standard cyrus-sasl installation right away, no special configuration required, and the problem is solved once and forever. Thomas

1 0

Re: (ITS#7118) [PATCH] Improve SASL plugin handling
by masarati＠aero.polimi.it 10 Jan '12

10 Jan '12

On 01/10/2012 12:32 AM, thomas(a)koeller.dyndns.org wrote: > On Monday 02 January 2012 19:22:28 masarati(a)aero.polimi.it wrote: > >> I note that Cyrus SASL already provides built-in ways to select what >> plugins must be loaded (e.g. auxprop_plugin, although I'm not an expert of >> Cyrus SASL configuration, so I suggest you carefully read the >> documentation). >> >> p. > > You are probably referring to this paragraph (quotation from > 'cyrus-sasl-2.1.25/doc/options.html'), regarding the > use of the ldapdb plugin: > >> This plugin is not for use with slapd itself. When OpenLDAP is built with >> SASL support, slapd uses its own internal auxprop and canonuser module. By >> default, without configuring anything else, slapd will fail to load the >> ldapdb module when it's present. This is as it should be. If you don't like >> the "auxpropfunc: error -7" message that is sent to syslog by slapd, you can >> stop it by creating /usr/lib/sasl2/slapd.conf with: >> >> auxprop_plugin: slapd >> >> which will force the SASL library to ignore all other auxprop modules. > > When I was debugging the problem I described, I found that the measure > described above did not stop ldapdb from being loaded. It only seems to > avoid _use_ of the ldapdb plugin, which is still loaded along with all > other plugins present, and that was what caused the problem. > > Now, if ldapdb is incompatible with slapd at a fundamental level, and > causes problems when loaded, I think not to load it is the right thing > to do, and this is what my patch does. An alternative solution consists in creating a specific folder containing plugins one wants to load, and start slapd with SASL_PATH set to point to that folder. This allows fine tuning of what to *load* without modifying a single line of code. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7118) [PATCH] Improve SASL plugin handling
by thomas＠koeller.dyndns.org 09 Jan '12

09 Jan '12

On Monday 02 January 2012 19:22:28 masarati(a)aero.polimi.it wrote: > I note that Cyrus SASL already provides built-in ways to select what > plugins must be loaded (e.g. auxprop_plugin, although I'm not an expert of > Cyrus SASL configuration, so I suggest you carefully read the > documentation). > > p. You are probably referring to this paragraph (quotation from 'cyrus-sasl-2.1.25/doc/options.html'), regarding the use of the ldapdb plugin: > This plugin is not for use with slapd itself. When OpenLDAP is built with > SASL support, slapd uses its own internal auxprop and canonuser module. By > default, without configuring anything else, slapd will fail to load the > ldapdb module when it's present. This is as it should be. If you don't like > the "auxpropfunc: error -7" message that is sent to syslog by slapd, you can > stop it by creating /usr/lib/sasl2/slapd.conf with: > > auxprop_plugin: slapd > > which will force the SASL library to ignore all other auxprop modules. When I was debugging the problem I described, I found that the measure described above did not stop ldapdb from being loaded. It only seems to avoid _use_ of the ldapdb plugin, which is still loaded along with all other plugins present, and that was what caused the problem. Now, if ldapdb is incompatible with slapd at a fundamental level, and causes problems when loaded, I think not to load it is the right thing to do, and this is what my patch does. Thomas

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by ghenry＠OpenLDAP.org 06 Jan '12

06 Jan '12

Thanks, will do! ----- Original Message ----- > It was getting on my nerves and I had to spend a lot of time > to clear up the situation. Being a beginner in both areas > Debian Distribution and OpenLDAP-Server I entered the docs > via Quick Start and immediately stuck headover in the mud > of outdated and inconsistent docs / references.. > > Please add at least a note about the new configuration > method and a link to the explaining wiki page > http://www.openldap.org/doc/admin24/slapdconf2.html > > in Quick-Start: > http://www.openldap.org/doc/admin24/quickstart.html > > As you link to http://www.openldap.org/doc/admin24/slapdconfig.html > from there in section 8 about Configuration you should > also add a note and link there or even better add an own section > about the dynamic configuration method in Quick-Start. > > Thanks in advance and cheers > > Gabriele > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#6446) Quickstart guide only uses slapd.conf
by contact＠dipohl.com 06 Jan '12

06 Jan '12

It was getting on my nerves and I had to spend a lot of time to clear up the situation. Being a beginner in both areas Debian Distribution and OpenLDAP-Server I entered the docs via Quick Start and immediately stuck headover in the mud of outdated and inconsistent docs / references.. Please add at least a note about the new configuration method and a link to the explaining wiki page http://www.openldap.org/doc/admin24/slapdconf2.html in Quick-Start: http://www.openldap.org/doc/admin24/quickstart.html As you link to http://www.openldap.org/doc/admin24/slapdconfig.html from there in section 8 about Configuration you should also add a note and link there or even better add an own section about the dynamic configuration method in Quick-Start. Thanks in advance and cheers Gabriele

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by contact＠dipohl.com 06 Jan '12

06 Jan '12

It was getting on my nerves and I had to spend a lot of time to clear up the situation. Being a beginner in both areas Debian Distribution and OpenLDAP-Server I entered the docs via Quick Start and immediately stuck headover in the mud of outdated and inconsistent docs / references.. Please add at least a note about the new configuration method and a link to the explaining wiki page http://www.openldap.org/doc/admin24/slapdconf2.html in Quick-Start: http://www.openldap.org/doc/admin24/quickstart.html As you link to http://www.openldap.org/doc/admin24/slapdconfig.html from there in section 8 about Configuration you should also add a note and link there or even better add an own section about the dynamic configuration method in Quick-Start. Thanks in advance and cheers Gabriele

1 0

Re: (ITS#7122) MozNSS linked libldap makes startTLS extremely slow
by quanah＠zimbra.com 05 Jan '12

05 Jan '12

--On Thursday, January 05, 2012 1:27 PM -0700 Rich Megginson <rmeggins(a)redhat.com> wrote: > Cannot reproduce > steps: Have you tried using the RHEL6 packages, since that is what the issue was reported against? --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#7122) MozNSS linked libldap makes startTLS extremely slow
by rmeggins＠redhat.com 05 Jan '12

05 Jan '12

Cannot reproduce steps: 1) grabbed latest openldap 2.4 branch source code from git (OPENLDAP_REL_ENG_2_4) - HEAD commit is commit 14171f88ac1a5162c0d801e071163cc1b6de8aeb Author: Quanah Gibson-Mount<quanah(a)openldap.org> Date: Tue Jan 3 12:20:15 2012 -0800 ITS#7117 2) built (on RHEL6.2 x86_64) from source into local install directories - one version built with moznss, one built with openssl 3) setup and configured server for TLS/SSL 4) on each server, did the following: LDAPTLS_CACERT=~/save/CA/cacert.pem time bin/ldapsearch -xLLL -ZZ -H ldap://localhost.localdomain:1389/ -s base -b "" the one built with moznss yields results similar to the following: 0.00user 0.00system 0:00.02elapsed 57%CPU (0avgtext+0avgdata 15344maxresident)k 0inputs+0outputs (0major+1051minor)pagefaults 0swaps the one built with openssl yields results similar to the following: 0.02user 0.00system 0:00.04elapsed 64%CPU (0avgtext+0avgdata 17184maxresident)k 0inputs+0outputs (0major+1163minor)pagefaults 0swaps i.e. the difference is negligible Please provide more information so that I can reproduce the issue you are seeing.

1 0

Re: (ITS#7120) crash when checkpointing DB
by quanah＠zimbra.com 05 Jan '12

05 Jan '12

--On Tuesday, January 03, 2012 9:24 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.26 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) Another bt. I note in thread #1 there's a null value for curelm, which doesn't look valid. Thread 10 (Thread 955): #0 0x00007f1f7a183343 in unshare () from /lib64/libc.so.6 No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. Thread 9 (Thread 953): #0 0x00007f1f7b28fe75 in pthread_tryjoin_np () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f72997d28 in ?? () No symbol table info available. #2 0x000000000081fb30 in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. Thread 8 (Thread 13542): #0 0x00007f1f7b2934fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f7bc2affb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007f1f7bc29a5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x85c098 ctx = {ltu_id = 139772993017600, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xca1f00, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0xdc56340, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0x5186120, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x7f1f77481060, ltk_data = 0xddbe000, ltk_free = 0x7f1f77481040 <search_stack_free>}, {ltk_key = 0x4551a4, ltk_data = 0xbb46400, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x947e000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 1021 hash = 35764221 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 7 (Thread 29245): #0 0x00007f1f7b2934fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f7bc2affb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007f1f7bc29a5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7f1f7be73090 ctx = {ltu_id = 139773009803008, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0x946d600, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0x9613200, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0x30c9d40, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x7f1f77481060, ltk_data = 0x975e000, ltk_free = 0x7f1f77481040 <search_stack_free>}, {ltk_key = 0x4551a4, ltk_data = 0xb7ad800, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0xdc75600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 94 hash = 2709149790 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 6 (Thread 960): #0 0x00007f1f7b2934fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f7bc2affb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007f1f7bc29a5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7f1f7be73090 ctx = {ltu_id = 139773018195712, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xcf1400, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0xc7c340, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0xd039e0, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x4551a4, ltk_data = 0xbb10c00, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0x7f1f77481060, ltk_data = 0x519e000, ltk_free = 0x7f1f77481040 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0xfdf6000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 559 hash = 2613558831 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 5 (Thread 19359): #0 0x00007f1f7b2934fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f7bc2affb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007f1f7bc29a5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7f1f7be73090 ctx = {ltu_id = 139772984624896, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xcb8400, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0xdc57b80, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0xb782000, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x4551a4, ltk_data = 0xbb47400, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0x7f1f77481060, ltk_data = 0xff3e000, ltk_free = 0x7f1f77481040 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x953f600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 109 hash = 1561476205 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 13102): #0 0x00007f1f7b2934fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f7bc2affb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007f1f7bc29a5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7f1f7be73090 ctx = {ltu_id = 139773001410304, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xca1400, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0x9597800, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0x5186c60, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x4551a4, ltk_data = 0xbac9800, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0x7f1f77481060, ltk_data = 0xbc48000, ltk_free = 0x7f1f77481040 <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x30bb600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 206 hash = 4234861774 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 959): #0 0x00007f1f7b2934fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f7bc2affb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007f1f7bc29a5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7f1f7be73090 ctx = {ltu_id = 139773026588416, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xcd3d00, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0xc8e5c0, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0x4551a4, ltk_data = 0xe80000, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0xca9440, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x7f1f77481060, ltk_data = 0x30ce000, ltk_free = 0x7f1f77481040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x9266000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 447 hash = 1087846847 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 21041): #0 0x00007f1f7b2934fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f1f7bc2affb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007f1f7bc29a5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7f1f7be73090 ctx = {ltu_id = 139772976232192, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0x946c900, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0xbaca080, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0x4551a4, ltk_data = 0xbb46800, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0xb7826c0, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x7f1f77481060, ltk_data = 0x120d2000, ltk_free = 0x7f1f77481040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x953f600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 891 hash = 1293901691 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 956): #0 0x00007f1f7bc2aa48 in ldap_pvt_runqueue_stoptask (rq=0x792f40, entry=0x82ac80) at rq.c:131 curelm = 0x0 #1 0x00007f1f77471279 in hdb_checkpoint (ctx=0x7f1f72195b80, arg=0x82ac80) at config.c:195 rtask = 0x82ac80 bdb = 0xe68700 #2 0x00007f1f7bc29afd in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:685 pool = 0x85c000 task = 0xb848cc0 work_list = 0x85c098 ctx = {ltu_id = 139773034981120, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xd24a00, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0xc8e480, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0x4551a4, ltk_data = 0xb931c00, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0x8bbe60, ltk_free = 0x7f1f77494917 <bdb_reader_free>}, {ltk_key = 0x7f1f77481060, ltk_data = 0x71a6000, ltk_free = 0x7f1f77481040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x11f5e400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 656 hash = 991977104 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f1f7b28f696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f1f7a182cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. -- 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#7122) MozNSS linked libldap makes startTLS extremely slow
by quanah＠OpenLDAP.org 05 Jan '12

05 Jan '12

Full_Name: Quanah Gibson-Mount Version: 2.4.23 (RHEL build) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As part of http://rhn.redhat.com/errata/RHBA-2011-0673.html, RedHat updated its OpenLDAP packages to use MozNSS instead of OpenSSL. However, this has an immediate negative effect on people who use StartTLS: | Problem: | | Redhat rebased their openldap server packages to use Mozilla NSS | instead of the OpenSSL libraries | (http://rhn.redhat.com/errata/RHBA-2011-0673.html). | | Attempting to authenticate a Zimbra session against this upgraded | external openLDAP server using starttls results in a 30s delay | between the beginning of the request and the validation of the | credentials. I've tested this scenario by rolling back to the | previous version of openLDAP (2.4.19-15), which restores the | authentication to an acceptable speed. | | This bug only impacts starttls sessions, utilizing ldaps is an | acceptable work around for the time being, although we would like to | return to starttls in the future as ldaps is deprecated in openLDAP. | | Action: | | rolled openLDAP server back to a previous version and the | authentication returns to normal.

1 0

(ITS#7121) back-mdb segfaults when splitting pages
by quanah＠OpenLDAP.org 04 Jan '12

04 Jan '12

Full_Name: Quanah Gibson-Mount Version: 2.4.28 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Back-mdb can segfault when doing page splits.

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by chris＠blueoxsolutions.com 04 Jan '12

04 Jan '12

Is there any progress on this? Speaking as a user who wanted to setup an ldap server so that I can combine a thunderbird and alpine address book in to one and perhaps export to my external memory unit (a semi-intelligent phone) I found the documentation on this sight (and others) to be very confusing. Is there gong to be any effort to fix the doccumentation in the near future? Is there a better guide by somone else that I can use to set up a simple address book with openldap? -- ======================================================================== Chris Oxenreider | chris(a)blueoxsolutions.com | ======================================================================== Personal

1 0

(ITS#7120) crash when checkpointing DB
by quanah＠OpenLDAP.org 03 Jan '12

03 Jan '12

Full_Name: Quanah Gibson-Mount Version: 2.4.26 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Thread 10 (Thread 8881): #0 0x00007fdf6b3544fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fdf6bcebffb in ldap_pvt_thread_cond_wait (cond=0x85c060, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007fdf6bceae6c in handle_pause (tpool=0x792fe0, do_pause=1) at tpool.c:757 pool = 0x85c000 #3 0x00007fdf6bceaed0 in ldap_pvt_thread_pool_pause (tpool=0x792fe0) at tpool.c:780 No locals. #4 0x00000000004265e7 in config_back_modify (op=0x302bc00, rs=0x7fdf5fa51a30) at bconfig.c:5793 cfb = 0x750ec0 ce = 0x88af40 last = 0x0 ml = 0x0 ca = {argc = 0, argv = 0x0, argv_size = 0, line = 0x0, tline = 0x0, fname = 0x0, lineno = 0, log = '\000' <repeats 4123 times>, reply = {err = 0, msg = '\000' <repeats 255 times>}, depth = 0, valx = 0, values = {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}, v_ad = 0x0}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 0, ca_op = 0x0, be = 0x0, bi = 0x0, ca_entry = 0x0, ca_private = 0x0, cleanup = 0, table = Cft_Abstract} rdn = {bv_len = 0, bv_val = 0x0} ptr = 0x894372 "=config" rad = 0x0 do_pause = 1 #5 0x000000000045a6de in fe_op_modify (op=0x302bc00, rs=0x7fdf5fa51a30) at modify.c:303 update = 0 repl_user = 0 op_be = 0x85e1a0 bd = 0x752a60 textbuf = "\001\000\000\000\000\000\000\000@^\230\021", '\000' <repeats 12 times>, "\001\000\000\000\000\000\000\000p\a\245_\337\177\000\000Q\006F", '\000' <repeats 17 times>, "\002\000\000\000 \304\324\021\000\000\000\000\200\245\210\000\000\000\000\000`\a\245_\000\000\000\000\000\000\000\000\337\177\000\000\001\000\000\000\000\000\000\000@^\230\021\000\000\000\000\300b%\t\000\000\000\000\340 H\t\000\000\000\000\220\a\245_\337\177\000\000p\275\002\003\000\000\000\000\020\b\245_\337\177\000\000\243\256E\000\000\000\000\000H\274\002\003\000\000\000\000\001", '\000' <repeats 16 times>, "\001\000\000\000\000\000\000\220\030\245_\337\177\000\000P\032\245_\337\177", '\000' <repeats 11 times>"\274, \002\003\000\000\000\000H\274\002\003\000\000\000\000\001", '\000' <repeats 16 times>, "\001\000\000\000\000\000" textlen = 50510848 #6 0x000000000045a031 in do_modify (op=0x302bc00, rs=0x7fdf5fa51a30) at modify.c:177 dn = {bv_len = 9, bv_val = 0x11c38577 "cn=config"} textbuf = "\020\\\245b\337\177\000\000\000 \245_\337\177\000\000\000'\245_\337\177\000\000C\313\033j\337\177\000\000(\000\000\000\060\000\000\000\220\031\245_\337\177\000\000\320\030\245_\337\177\000\000\220z\316\021\000\000\000\000\360\030\245_\337\177\000\000\002", '\000' <repeats 15 times>, "H\031\245_\337\177\000\000j\237J\000\000\000\000\000\200\033\245_\337\177\000\000\200\033\245_\337\177\000\000\200n\365k\001\000\000\000\300\031\245_\337\177\000\000\345\237J\000\000\000\000\000\300b%\t\000\000\000\000\b\000\000\000\001\000\000\000\200\033\245_\337\177\000\000\200d\266\021\001\000\000\000\000\000\020\000\000\000\000\000\300b%\t\000\000\000\000\300b%\t\000\000\000\000Q\374\254k\000\000\000\000\a\000\000\000\000\000\000\000\377\377\377\377\377\377\377\377\377\377\377\377\000\000\000\000\200\033\245_\337\177\000\000\200\033\245_\337\177\000\000\200n\365k\001\000\000" textlen = 153445056 tmp = 0x100000008 #7 0x000000000043aa95 in connection_operation (ctx=0x7fdf5fa51b80, arg_v=0x302bc00) at connection.c:1138 rc = 80 cancel = 0 op = 0x302bc00 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, 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 = 102 opidx = SLAP_OP_MODIFY conn = 0xee5380 memctx = 0x92562c0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #8 0x000000000043b021 in connection_read_thread (ctx=0x7fdf5fa51b80, argv=0x2a) at connection.c:1274 rc = 0 cri = {op = 0x302bc00, func = 0, arg = 0x0, ctx = 0x7fdf5fa51b80, nullop = 0} s = 42 #9 0x00007fdf6bceaafd in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:685 pool = 0x85c000 task = 0x91f49e0 work_list = 0x85c098 ctx = {ltu_id = 140597359093504, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0x83d900, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0x92562c0, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0xd02120, ltk_free = 0x7fdf67555917 <bdb_reader_free>}, {ltk_key = 0x4551a4, ltk_data = 0x0, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0x7fdf67542060, ltk_data = 0x9584000, ltk_free = 0x7fdf67542040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x3013600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 0 keyslot = 0 hash = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #10 0x00007fdf6b350696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #11 0x00007fdf6a243cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #12 0x0000000000000000 in ?? () No symbol table info available. Thread 9 (Thread 4167): #0 0x00007fdf6b3544fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fdf6bcebffb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007fdf6bceaa5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7fdf6bf34090 ctx = {ltu_id = 140597401057024, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xbf0d00, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0x8b21c0, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0x4551a4, ltk_data = 0x302a400, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0xca85a0, ltk_free = 0x7fdf67555917 <bdb_reader_free>}, {ltk_key = 0x7fdf67542060, ltk_data = 0x3196000, ltk_free = 0x7fdf67542040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x862400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 284 hash = 2414680348 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fdf6b350696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fdf6a243cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 8 (Thread 4176): #0 0x00007fdf6a250dee in __unregister_atfork () from /lib64/libc.so.6 No symbol table info available. #1 0x00000000118ae000 in ?? () No symbol table info available. #2 0x00000000118ae000 in ?? () No symbol table info available. #3 0x00000000118ae000 in ?? () No symbol table info available. #4 0x00000000118ae000 in ?? () No symbol table info available. #5 0x00000000118ae046 in ?? () No symbol table info available. #6 0x00000000118b0000 in ?? () No symbol table info available. #7 0x0000000000000000 in ?? () No symbol table info available. Thread 7 (Thread 4175): #0 0x00007fdf6b3544fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fdf6bcebffb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007fdf6bceaa5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7fdf6bf34090 ctx = {ltu_id = 140597392664320, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xbf1000, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0xc7fb80, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0x4551a4, ltk_data = 0x826800, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0xca8d80, ltk_free = 0x7fdf67555917 <bdb_reader_free>}, {ltk_key = 0x7fdf67542060, ltk_data = 0x519e000, ltk_free = 0x7fdf67542040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x11a35200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 203 hash = 2515150027 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fdf6b350696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fdf6a243cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 6 (Thread 8879): #0 0x00007fdf6b3544fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fdf6bcebffb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007fdf6bceaa5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7fdf6bf34090 ctx = {ltu_id = 140597375878912, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xd24a00, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0x9256000, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0x4551a4, ltk_data = 0x302a000, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0x2ff17a0, ltk_free = 0x7fdf67555917 <bdb_reader_free>}, {ltk_key = 0x7fdf67542060, ltk_data = 0xb5b6000, ltk_free = 0x7fdf67542040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x11c98400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 874 hash = 4136452970 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fdf6b350696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fdf6a243cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 5 (Thread 4166): #0 0x00007fdf6a244343 in unshare () from /lib64/libc.so.6 No symbol table info available. #1 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 4150): #0 0x00007fdf6b350e75 in pthread_tryjoin_np () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fdf62a58d28 in ?? () No symbol table info available. #2 0x000000000081fad0 in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 8953): #0 0x00007fdf6b3544fc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fdf6bcebffb in ldap_pvt_thread_cond_wait (cond=0x85c030, mutex=0x85c008) at thr_posix.c:277 No locals. #2 0x00007fdf6bceaa5f in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:672 pool = 0x85c000 task = 0x0 work_list = 0x7fdf6bf34090 ctx = {ltu_id = 140597350700800, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0x302cc00, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0x9256b00, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0x3023e60, ltk_free = 0x7fdf67555917 <bdb_reader_free>}, {ltk_key = 0x7fdf67542060, ltk_data = 0xf6c6000, ltk_free = 0x7fdf67542040 <search_stack_free>}, {ltk_key = 0x4551a4, ltk_data = 0x0, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x11caa800, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 1017 hash = 2993379321 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fdf6b350696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fdf6a243cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 5427): #0 0x00007fdf6a244ce1 in __opensock () from /lib64/libc.so.6 No symbol table info available. #1 0x00007fdf5ea4f948 in ?? () No symbol table info available. #2 0x00000000004a9f6a in slap_sl_mem_destroy (key=Cannot access memory at address 0x6effffffc3 ) at sl_malloc.c:78 sh = Cannot access memory at address 0x6effffffd3 Thread 1 (Thread 8880): #0 0x00007fdf6bceba48 in ldap_pvt_runqueue_stoptask (rq=0x792f40, entry=0x82ac80) at rq.c:131 curelm = 0x0 #1 0x00007fdf67532279 in hdb_checkpoint (ctx=0x7fdf60252b80, arg=0x82ac80) at config.c:195 rtask = 0x82ac80 bdb = 0xe68700 #2 0x00007fdf6bceaafd in ldap_int_thread_pool_wrapper (xpool=0x85c000) at tpool.c:685 pool = 0x85c000 task = 0x91f49c0 work_list = 0x85c098 ctx = {ltu_id = 140597367486208, ltu_key = {{ltk_key = 0x43a5ee, ltk_data = 0xd25600, ltk_free = 0x43a43e <conn_counter_destroy>}, {ltk_key = 0x4a9f6a, ltk_data = 0x9256040, ltk_free = 0x4a9d64 <slap_sl_mem_destroy>}, {ltk_key = 0x4551a4, ltk_data = 0xe80c00, ltk_free = 0x455100 <slap_op_q_destroy>}, {ltk_key = 0xdb8300, ltk_data = 0x3023d40, ltk_free = 0x7fdf67555917 <bdb_reader_free>}, {ltk_key = 0x7fdf67542060, ltk_data = 0xd5be000, ltk_free = 0x7fdf67542040 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x9200400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 986 hash = 1367197658 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fdf6b350696 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fdf6a243cbd in eventfd_read () from /lib64/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available.

1 0

Re: (ITS#7118) [PATCH] Improve SASL plugin handling
by masarati＠aero.polimi.it 02 Jan '12

02 Jan '12

I note that Cyrus SASL already provides built-in ways to select what plugins must be loaded (e.g. auxprop_plugin, although I'm not an expert of Cyrus SASL configuration, so I suggest you carefully read the documentation). p.

1 0

Re: (ITS#7119) smbldap-populate error
by michael＠stroeder.com 01 Jan '12

01 Jan '12

adri58(a)gmail.com wrote: > > I'mtrying to install a Samba + LDAP PDC but when I try to create the database > with smbldap-populate I get this error: > [..] > failed to add entry: invalid DN at /usr/sbin/smbldap-populate line 498,<GEN1> > line 242. The ITS is for reporting bugs but this seems like a configuration error for which you can get help on the openldap-technical mailing list. (Most like you did not load the Samba3 schema.) Ciao, Michael.

1 0

(ITS#7118)
by thomas＠koeller.dyndns.org 01 Jan '12

01 Jan '12

I found that the patch I proposed actually threw out the baby with the bathwater; rejecting all plugins is inappropriate. So here is a revised version that only excludes the ldapdb plugin specifically: diff -brpu openldap-2.4.28-orig/servers/slapd/sasl.c openldap-2.4.28/servers/slapd/sasl.c --- openldap-2.4.28-orig/servers/slapd/sasl.c 2011-11-25 19:52:29.000000000 +0100 +++ openldap-2.4.28/servers/slapd/sasl.c 2012-01-02 01:48:58.000000000 +0100 @@ -67,6 +67,24 @@ char *slap_sasl_auxprops; #ifdef HAVE_CYRUS_SASL +/* Do not load the ldapdb plugin */ +static int +slap_sasl_verifyfile( + void *context, + const char *file, + sasl_verify_type_t type) +{ + int res = SASL_OK; + + if (type == SASL_VRFY_PLUGIN) { + static const char name[] = "libldapdb.so"; + const char * const p = strstr(file, name); + if (p && !strchr(p, '/')) + res = SASL_CONTINUE; + } + return res; +} + /* Just use our internal auxprop by default */ static int slap_sasl_getopt( @@ -1111,6 +1129,7 @@ int slap_sasl_init( void ) static sasl_callback_t server_callbacks[] = { { SASL_CB_LOG, &slap_sasl_log, NULL }, { SASL_CB_GETOPT, &slap_sasl_getopt, NULL }, + { SASL_CB_VERIFYFILE, &slap_sasl_verifyfile, NULL }, { SASL_CB_LIST_END, NULL, NULL } }; #endif

1 0

(ITS#7119) smbldap-populate error
by adri58＠gmail.com 01 Jan '12

01 Jan '12

Full_Name: Adrián Version: 2.4.23-7.2 OS: Debian Testing "Wheezy" URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.213.191.231) Hello everybody. I'mtrying to install a Samba + LDAP PDC but when I try to create the database with smbldap-populate I get this error: -------------------------------------------------------------------------------- Populating LDAP directory for domain empresa (S-1-5-21-802753395-3202467916-1484007712) (using builtin directory structure) entry dc=empresa,dc=com already exist. entry ou=Users,dc=empresa,dc=com already exist. entry ou=Groups,dc=empresa,dc=com already exist. entry ou=Computers,dc=empresa,dc=com already exist. entry ou=Idmap,dc=empresa,dc=com already exist. adding new entry: uid=root,ou=Users,dc=empresa,dc=com failed to add entry: objectClass: value #4 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 58. adding new entry: uid=nobody,ou=Users,dc=empresa,dc=com failed to add entry: objectClass: value #4 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 89. adding new entry: cn=Domain Admins,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 101. adding new entry: cn=Domain Users,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 112. adding new entry: cn=Domain Guests,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 123. adding new entry: cn=Domain Computers,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 134. adding new entry: cn=Administrators,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 179. adding new entry: cn=Account Operators,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 201. adding new entry: cn=Print Operators,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 212. adding new entry: cn=Backup Operators,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 223. adding new entry: cn=Replicators,ou=Groups,dc=empresa,dc=com failed to add entry: objectClass: value #2 invalid per syntax at /usr/sbin/smbldap-populate line 498, <GEN1> line 234. adding new entry: sambaDomainName=empresa,dc=empresa,dc=com failed to add entry: invalid DN at /usr/sbin/smbldap-populate line 498, <GEN1> line 242. Please provide a password for the domain root: /usr/sbin/smbldap-passwd: user root doesn't exist ---------------------------------------------------------------------------------- In the log file I get this other error: slapd[1369]: conn=1005 op=28 do_search: invalid dn: "sambaDomainName=empresa,dc=empresa,dc=com" slapd[1369]: conn=1005 op=29 do_add: invalid dn (sambaDomainName=empresa,dc=empresa,dc=com) Any ideas? I've been looking for any solution for 4 days and nobody seems to know anything

1 0

Re: (ITS#7117) Documentation typo
by hyc＠symas.com 27 Dec '11

27 Dec '11

hydrapolic(a)gmail.com wrote: > Full_Name: hydra > Version: 2.4 > OS: Any > URL: http://www.openldap.org/doc/admin24/slapdconf2.html > Submission from: (NULL) (195.91.56.62) > > > Table 5.1: Debugging Levels > trace function callss Thanks, fixed now in git master. -- -- 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#7116) pwdAccountLockedTime not honoured by PAM
by hyc＠symas.com 27 Dec '11

27 Dec '11

rajnesh.siwal(a)gmail.com wrote: > Full_Name: Rajnesh Siwal > Version: 2.4.21-0ubuntu5.6 > OS: Ubuntu 10.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.180.141.110) > > > The user account has been locked by the parameter "pwdAccountLockedTime" and > still we are able to login into the linux servers (LDAP clients) using the LDAP > credentials. > Please suggest what the reason could be. The ITS is for actual bug reports, not help requests. Please post your question to the openldap-technical mailing list. This ITS will be closed. -- -- 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#7118) [PATCH] Improve SASL plugin handling
by thomas＠koeller.dyndns.org 26 Dec '11

26 Dec '11

Full_Name: Thomas Koeller Version: 2.4.28 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.171.14.55) I had a problem with slapd always segfaulting. A little debugging revealed that slapd allocated the thread-safe version of 'struct ldapoptions', since it is linked with libldap_r.so. However, the destructor function ldap_int_destroy_global_options() invoked during cleanup seemed to be the non-threadsafe version which assumes a different layout of 'struct ldapoptions' (the ldo_mutex field is missing). I noticed that that SASL loaded all its plugins, including the 'ldapdb' module which is present in my SASL installation, and that ldapdb.so was linked against the non-threadsafe libldap.so. I still do not quite understand the exact reason why this confusion arose, because AFAIK theoretically both libraries should be able to co-exist. However, I did not investigate that problem any further, because I think that loading all sasl plugins is just wrong, because slapd only uses its own internal auxprop module and does not need any of them. I tried the proposed method of excluding ldapdb by having a slapd.conf file containing 'pwcheck_method: auxprop' and 'auxprop_plugin: slapd',but that did not improve anything. I therefore changed slapd to no longer load any sasl plugins whatsoever. With this change, everything works fine. Btw., my SASL installation is cyrus-sasl-2.1.25. Here is the patch I created, along with the required legalese: The inlined patch below is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Thomas Koeller <thomas(a)koeller.dyndns.org>. I have not assigned rights and/or interest in this work to any party. I, Thomas Koeller, 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. diff -brpu openldap-2.4.28-orig/servers/slapd/sasl.c openldap-2.4.28/servers/slapd/sasl.c --- openldap-2.4.28-orig/servers/slapd/sasl.c 2011-11-25 19:52:29.000000000 +0100 +++ openldap-2.4.28/servers/slapd/sasl.c 2011-12-26 15:40:14.000000000 +0100 @@ -67,6 +67,16 @@ char *slap_sasl_auxprops; #ifdef HAVE_CYRUS_SASL +/* Do not load any plugin modules, only use internal auxprop */ +static int +slap_sasl_verifyfile( + void *context, + const char *file, + sasl_verify_type_t type) +{ + return type == SASL_VRFY_PLUGIN ? SASL_CONTINUE : SASL_OK; +} + /* Just use our internal auxprop by default */ static int slap_sasl_getopt( @@ -1111,6 +1121,7 @@ int slap_sasl_init( void ) static sasl_callback_t server_callbacks[] = { { SASL_CB_LOG, &slap_sasl_log, NULL }, { SASL_CB_GETOPT, &slap_sasl_getopt, NULL }, + { SASL_CB_VERIFYFILE, &slap_sasl_verifyfile, NULL }, { SASL_CB_LIST_END, NULL, NULL } }; #endif

1 0

(ITS#7117) Documentation typo
by hydrapolic＠gmail.com 26 Dec '11

26 Dec '11

Full_Name: hydra Version: 2.4 OS: Any URL: http://www.openldap.org/doc/admin24/slapdconf2.html Submission from: (NULL) (195.91.56.62) Table 5.1: Debugging Levels trace function callss

1 0

(ITS#7116) pwdAccountLockedTime not honoured by PAM
by rajnesh.siwal＠gmail.com 26 Dec '11

26 Dec '11

Full_Name: Rajnesh Siwal Version: 2.4.21-0ubuntu5.6 OS: Ubuntu 10.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.180.141.110) The user account has been locked by the parameter "pwdAccountLockedTime" and still we are able to login into the linux servers (LDAP clients) using the LDAP credentials. Please suggest what the reason could be.

1 0

Re: (ITS#7045) "ldapsearch -Z" should continue using TLS one cert mis-match
by bgmilne＠staff.telkomsa.net 21 Dec '11

21 Dec '11

On Monday, 19 September 2011 02:41:30 Jason_Haar(a)trimble.com wrote: > > (I'm using ldapsearch to dump Active Directory LDAP data via the DNS > round-robin entry for the domain name: as such the LDAP host *never* > matches the hostname DNS round-robin gives back - and I don't care - I > just don't want the network group sniffing my password ;-) Then your 'Active Directory' servers should have subjectAltName extensions for the DNS round-robin hostname ...

1 0

Re: (ITS#7114) Password synchronization is not working
by quanah＠zimbra.com 20 Dec '11

20 Dec '11

--On Tuesday, December 20, 2011 4:02 PM +0000 venkata.udumula(a)yahoo.co.in wrote: > Full_Name: venkata reddy > Version: 2.4.26 > OS: Windows server 2008 R2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.252.70.4) The ITS System is for bug reports, not help with how to use openldap. The proper forum for your question is to 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#7114) Password synchronization is not working
by venkata.udumula＠yahoo.co.in 20 Dec '11

20 Dec '11

Full_Name: venkata reddy Version: 2.4.26 OS: Windows server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.252.70.4) Hi, I am setting up a Forefront Identity Manager (FIM) infrastructure. I installed the FIM software. Our Active Directory is already exists. And I have to use another LDAP system for testing the my FIM setup. I chose OpenLDAP for Windows, as i am comfortable with only windows applications. I am assuming that your Tech support team would have some idea of what FIM does. I have setup the management agents on the FIM synchronize server to FIM, AD and OpenLDAP. For FIM and AD management agents are available by default in the FIM synchronization server. But for OpenLDAP i used OpenLDAP XMA management agent provided by sourceforge. With the management agents I am able to move the user and group objects between all the systems successfully. When a new user is created the password is moved to the OpenLDAP system successfully. But when I change the password in the FIM portal, it should automatically update it in all the systems. It is updating in the FIM and AD. But not in OpenLDAP. I am not aware of any configuration settings I have to change to make it work in OpenLDAP. Could you please help me resolving this issue? At the time of installation instead of using the default port numbers I used 50000 for LDAP and 50001 for LDAPS. Is it a problem? Thanks,

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hume-ol＠bofh.ca 19 Dec '11

19 Dec '11

On 12/15/11 11:14 PM, Howard Chu wrote: > > A fix for this is in git master, please test. > Built and deployed, I've allowed to run for 72h and problem has yet to show. I believe this particular bug has been squashed.

1 0

(ITS#7113) broken read-only replica results in assertion failure and crash on master slapd process
by kacarstensen＠csupomona.edu 19 Dec '11

19 Dec '11

Full_Name: Kevan Carstensen Version: 2.4.28 OS: gentoo linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.71.248.23) During a heavy update load, replication from our master to one of our read-only ldap replicas started failing due to locking errors on the replica. Dec 14 04:01:08 pip-dev slapd[12645]: bdb(dc=csupomona,dc=edu): Lock table is out of available lock entries Dec 14 04:01:08 pip-dev slapd[12645]: => bdb_idl_delete_key: c_get failed: Cannot allocate memory (12) Dec 14 04:01:08 pip-dev slapd[12645]: conn=-1 op=0: attribute "memberUid" index delete failure Dec 14 04:01:08 pip-dev slapd[12645]: null_callback : error code 0x50 Dec 14 04:01:08 pip-dev slapd[12645]: syncrepl_entry: rid=001 be_modify failed (80) Dec 14 04:01:08 pip-dev slapd[12645]: do_syncrepl: rid=001 rc 80 retrying (these are due to an incorrect DB_CONFIG on the replica and are not related to this issue; I include them in case their impact on how/when the replica connects to the master are important) After about ten minutes of the replica trying and failing to start its syncrepl again, the master slapd crashed. Nothing in the master slapd logs specifically references the crash or indicates why it happened. Shortly after the replica broke, some unusual messages started showing up in the logs on the master: Dec 14 03:50:11 fosse slapd[22596]: connection_read(65): no connection! Dec 14 03:50:22 fosse slapd[22596]: send_search_entry: conn 7535053 ber write failed. Dec 14 03:50:32 fosse slapd[22596]: send_search_entry: conn 7535061 ber write failed. Dec 14 03:50:42 fosse slapd[22596]: send_search_entry: conn 7535065 ber write failed. Dec 14 03:50:56 fosse slapd[22596]: send_search_entry: conn 7535068 ber write failed. Dec 14 03:51:06 fosse slapd[22596]: connection_read(65): no connection! Dec 14 03:51:06 fosse slapd[22596]: connection_read(65): no connection! These continued until the crash, persisted after the master slapd was successfully restarted, and went away when I turned the broken replica off. I found similar behavior in a development setup similar to our production setup. There is one master, and there are two read-only replicas configured to replicate from the master with the following syncrepl stanza: syncrepl rid=1 provider=ldaps://master-2.ldap.csupomona.edu/ type=refreshAndPersist retry="10 10 60 +" searchbase="dc=csupomona,dc=edu" bindmethod=simple binddn=cn=slapd-syncrepl,ou=user,ou=service,dc=csupomona,dc=edu credentials=__PASSWORD__ (there are two replicas because I couldn't reliably produce a crash with one replica) The replicas have a DB_CONFIG that causes their replication attempts to fail with the same error as we saw in our production setup. The master database is initialized so that the replicas have a lot of changes to catch up on, as was the case when our production setup failed. Even with loglevel -1, there's nothing specifically referencing the crash in the master slapd's logs. There's an assertion failure in the backtrace: slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffea863700 (LWP 27623)] 0x00007ffff6a95175 in raise () from /lib64/libc.so.6 (gdb) bt full #0 0x00007ffff6a95175 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007ffff6a96590 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007ffff6a8e201 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #3 0x000000000042ec9b in slapd_clr_write (s=<value optimized out>, wake=0) at daemon.c:942 id = 0 __PRETTY_FUNCTION__ = "slapd_clr_write" #4 0x000000000043419b in connection_write (s=17) at connection.c:1896 c = <value optimized out> op = <value optimized out> __PRETTY_FUNCTION__ = "connection_write" #5 0x000000000043006a in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2782 rc = 1 fd = 17 w = 6 ns = 1 at = 0 revents = <value optimized out> tvp = <value optimized out> cat = {tv_sec = 1324320980, tv_usec = 0} i = 0 now = <value optimized out> tv = {tv_sec = 1135, tv_usec = 0} rtask = <value optimized out> l = <value optimized out> last_idle_check = 1324317380 ebadf = 0 tid = <value optimized out> #6 0x00007ffff71ed914 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #7 0x00007ffff6b347dd in clone () from /lib64/libc.so.6 No symbol table info available. The master and replicas in my development setup all run 2.4.28. The production master runs 2.4.26. I successfully reproduced the issue on both 2.4.26 and 2.4.28, but only have a backtrace for 2.4.28. If you want a backtrace for 2.4.26, I can get one. Thanks.

1 0

Re: (ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations
by mkrz＠free.fr 16 Dec '11

16 Dec '11

----- Mail Original ----- De: "Howard Chu" <hyc(a)symas.com> À: mkrz(a)free.fr Cc: openldap-its(a)openldap.org Envoyé: Jeudi 8 Décembre 2011 22h37:21 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: (ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations >> I noticed an issue with "refreshOnly" syncrepl when a large number of records is >> added, updated and deleted. At the end of synchronization the contextCSN is >> equal on all servers, but the data is out of synchronization for some deleted >> records that remains undeleted on consumer/slave servers. >> >> Restarting the consumer or forcing a synchronization with "slapd ... -c >> 'rid=1,csn=0' " does not help. > >This appears to caused by the sessionlog overflowing due to incoming modifies >that occur after the refresh operation has begun. I would call this a >misconfigured server, since the sessionlog can only ever be useful if you size >it large enough to accomodate all of your update traffic. > >I don't have any plans to fix this issue; fix the server configuration. Thank you for your answer. I withdrew the "syncprov-sessionlog" parameter and this fixed the data loss issue.

1 0

Re: (ITS#7112) Slapd Daemon leaking file descriptor
by quanah＠zimbra.com 15 Dec '11

15 Dec '11

--On Friday, December 16, 2011 5:45 AM +0000 aditya1606(a)gmail.com wrote: > Full_Name: Aditya Bajaj > Version: 2.2.30 > OS: RHEL 5.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.100.112.203) 2.2 is not a supported release series. 2.3 is not a supported release series. Upgrade to a supported release series. This ticket 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#7112) Slapd Daemon leaking file descriptor
by aditya1606＠gmail.com 15 Dec '11

15 Dec '11

Full_Name: Aditya Bajaj Version: 2.2.30 OS: RHEL 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.100.112.203) Hello, losf of slapd is showing like this slapd 10127 root 585u sock 0,5 3532897126 can't identify protocol we have read openldap previous queries , were it as being mentioned that its already fixed in 2.3.32 or after. My question is what was the ticket number that fixed this issue. we would like to now more about that ticket. Regards Aditya

1 0

(ITS#7111) Forward bug-fix commits to ITS
by hyc＠OpenLDAP.org 15 Dec '11

15 Dec '11

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc Testing...

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hyc＠symas.com 15 Dec '11

15 Dec '11

hume-ol(a)bofh.ca wrote: > I have reproduced the problem on 2.4.27. The mentioned ldapsearch query > seems to have a high probability of success if run immediately after > server start, which also seems true on 2.4.28. > > I threw in an extra Debug() line and op->op_protocol == 2 at the check. > > I'm rebuilding with as many debugging symbols enabled as possible to try > to figure out what's going on. A fix for this is in git master, please test. -- -- 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#7110) cn=config mixes values
by raphael.ouazana＠linagora.com 15 Dec '11

15 Dec '11

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, I try to modify valuse of eg. olcAccess with a certain order, I get different values if numbered values are in the correct order or not. Case 1 (normal): dn: olcDatabase={3}bdb,cn=config changetype: modify replace: olcAccess olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write Result: olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write Case 2 (inversed values): dn: olcDatabase={3}bdb,cn=config changetype: modify replace: olcAccess olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write Result: olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write The two last values are incorrectly mixed. Regards, Raphaël Ouazana.

1 0

Re: (ITS#7109) Slapd Freezing
by h.b.furuseth＠usit.uio.no 14 Dec '11

14 Dec '11

I wrote: >> And what information should we provide to solve this problem? (strace, gdb >> log, db_stat or something else?) > > Server log from slapd, and gdb 'thread apply all backtrace'. Eh, I forgot the obvious one: slapd's configuration, minus any passwords. -- Hallvard

1 0

Re: (ITS#7109) Slapd Freezing
by quanah＠zimbra.com 12 Dec '11

12 Dec '11

--On Saturday, December 10, 2011 7:07 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Unfortunately OpenLDAP installation strips debugging symbols by default, > which makes backtraces nearly useless. You can prevent that by > configuring with > ./configure --enable-memberof ac_cv_prog_STRIP=: You can also do it at install time by simply typing: make install STRIP="" --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#7050) meta stop at the first unreachable candidate
by hyc＠symas.com 12 Dec '11

12 Dec '11

llg(a)portaildulibre.fr wrote: > Does anybody knows if and when this patch will be included in future > versions ? No, the patch is wrong. A new fix is in git master now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7109) Slapd Freezing
by h.b.furuseth＠usit.uio.no 10 Dec '11

10 Dec '11

nikolay.bogdanov(a)flant.ru writes: > Version: 2.4.23 > (...) What can you advice for us? Upgrade, building from the source at www.openldap.org. There are several possibly-related bugfixes since 2.4.23. Then report back whether nor not that fixed the problem. If it is: > And what information should we provide to solve this problem? (strace, gdb > log, db_stat or something else?) Server log from slapd, and gdb 'thread apply all backtrace'. Unfortunately OpenLDAP installation strips debugging symbols by default, which makes backtraces nearly useless. You can prevent that by configuring with ./configure --enable-memberof ac_cv_prog_STRIP=: -- Hallvard

1 0

(ITS#7109) Slapd Freezing
by nikolay.bogdanov＠flant.ru 10 Dec '11

10 Dec '11

Full_Name: Nikolay Bogdanov Version: 2.4.23 OS: Debian/Ubuntu URL: ftp://ftp.openldap.org/incoming/sysinfo.txt Submission from: (NULL) (95.221.182.198) Dear ñolleagues, We used open ldap for three years. But some weeks ago we disided to restructurate our LDAP server. We did it, but there are a lot of users in the company. So we enabled the "rwm" overlay and added "oldDn" field in a schema. Futhermore, we use "memberof" overlay. As a result users can bind with their old dn. But after that slapd stops with deadlock everyday. What can you advice for us? And what information should we provide to solve this problem? (strace, gdb log, db_stat or something else?) With best regards, Nikolay Bogdanov. CJSC Flant.

1 0

Re: (ITS#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hume-ol＠bofh.ca 09 Dec '11

09 Dec '11

I have reproduced the problem on 2.4.27. The mentioned ldapsearch query seems to have a high probability of success if run immediately after server start, which also seems true on 2.4.28. I threw in an extra Debug() line and op->op_protocol == 2 at the check. I'm rebuilding with as many debugging symbols enabled as possible to try to figure out what's going on.

1 0

Re: (ITS#7050) meta stop at the first unreachable candidate
by llg＠portaildulibre.fr 09 Dec '11

09 Dec '11

Does anybody knows if and when this patch will be included in future versions ? Thanks llg

1 0

Re: (ITS#7104) refreshOnly syncrepl out of sync during bulk update/delete operations
by hyc＠symas.com 08 Dec '11

08 Dec '11

mkrz(a)free.fr wrote: > Full_Name: Martin Krzaczek > Version: 2.4.28 > OS: CentOS 5.7 > URL: > Submission from: (NULL) (83.202.204.201) > > > Hello, > > I noticed an issue with "refreshOnly" syncrepl when a large number of records is > added, updated and deleted. At the end of synchronization the contextCSN is > equal on all servers, but the data is out of synchronization for some deleted > records that remains undeleted on consumer/slave servers. > > Restarting the consumer or forcing a synchronization with "slapd ... -c > 'rid=1,csn=0' " does not help. This appears to caused by the sessionlog overflowing due to incoming modifies that occur after the refresh operation has begun. I would call this a misconfigured server, since the sessionlog can only ever be useful if you size it large enough to accomodate all of your update traffic. I don't have any plans to fix this issue; fix the server configuration. > > A similar issue was submitted few weeks ago (ITS#7052), but I'm not sure the > problem is the same. > > My configuration : > - CentOS 5.7 + OpenLDAP 2.4.28 + BDB 5.1.29 > (the same issue occurs with CentOS 5.7 + OpenLDAP 2.4.26 + BDB 5.1.25) > - one main provider where all modification operations are performed > - one 'first level' consumer synchronizing data on the main provider > and providing data for 'second level' consumers > - one 'second level' consumer synchronizing data on the 'first level' > consumer/provider > > I tried several combinations of configurations (refreshOnly/refreshAndPersist, > syncprov-sessionlog) and noticed that when refreshOnly mode is used, some > records may be not deleted on consumer/slave servers. The number of undeleted > records varies depending on the configuration. > So with a higher value of "syncprov-sessionlog" (for example 5000 instead of > 500) the number of lost records is reduced. > > I have an application that sequentially (i.e. in a single thread) adds about > 12000 records, modifies about 25000 records and deletes about 1000 records. > Add/update/delete operations are mixed i.e. it is possible a have sequences such > as add/add/delete/update/update/update/delete/add/... > > With a small amount of records to add/update/delete the synchronization properly > works without any data loss. > So it seams that if all modifications may be cached and transmitted to consumers > then deleted records are not lost. > There is no data loss for added and updated records whatever is the number of > operations. > > > Regards, > Martin > > > -- -- 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#7108) syncrepl loses updates when replica is down
by hyc＠symas.com 08 Dec '11

08 Dec '11

ml+openldap(a)esmtp.org wrote: > Full_Name: Claus Assmann > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.3 > URL: ftp://ftp.openldap.org/incoming/claus-assmann-111208.patch > Submission from: (NULL) (63.211.143.38) > > > This is a followup to ITS 7037 which has been fixed in 2.4.28. > It is the same setup and test -- I've uploaded a "patch" that > includes the test program (sorry if it doesn't follow all > the OpenLDAP conventions, I hope it is sufficient to reproduce > the problem). > > It looks like some changes to the OpenLDAP master are not transferred to the > replica (the test prg demonstrates that). > > Note: in my test runs it doesn't always fail, but almost all the time. > > Please let me know whether my test is broken or whether there is a problem in > slapd. I would consider this test invalid. You're deleting the replica database while the consumer is still running. The slapd consumer code assumes that it is the only thing that can make changes to a consumer database. -- -- 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#7107) cn=config syncrepl fails with "controls require LDAPv3" on bound v3 connection
by hyc＠symas.com 08 Dec '11

08 Dec '11

hume-ol(a)bofh.ca wrote: > Full_Name: Brandon Hume > Version: 2.4.28 > OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64 > URL: http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt > Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e) > > > OpenLDAP 2.4.28 compiled with BerkeleyDB 5.2.36, attempting to configure for > multi-master replication. Problems occurred with the second server complaining > about operations errors while attempting to replicate the cn=config tree; I've > been able to reproduce the problem from the command line using ldapsearch from > the same compile. > > The host is RHEL 6.1 running inside VMWare. Version of OpenLDAP is 2.4.28, > compiled with BerkeleyDB 5.2.36 (no patches available from Oracle at the time I > downloaded). Configuration options used are visible in > http://den.bofh.ca/~hume/config_ol_sh.txt > > The problem does *not* seem to be consistent, as *sometimes* it will work but > most of the time not. I've run the example query once, had it fail, run it > again immediately and had it succeed, and then again fail a dozen times in a > row. Wireshark traces showed the connection was established using LDAPv3; > putting the server in debug "Any" mode also confirms the same. The syslogs > generated are viewable at http://den.bofh.ca/~hume/ol_v3_fail_syslog.txt > > I've compiled 2.4.27 with the same options and it *seemed* to behave, though I > may have merely gotten lucky. Only two source files are changed between 2.4.27 and 2.4.28, and neither of the changes affect cn=config, syncrepl, or Bind operations. If you're seeing a difference in behavior here then I can only conclude that your build environment is corrupted. > Example ldapsearch invocation: > > $ /appl/ldap/bin/ldapsearch -x -D 'cn=config' -h kil-ds-3.its.dal.ca -b > cn=config -w bindpass -s sub -E sync=rp -e manageDSAit 'objectclass=*' > # extended LDIF > # > # LDAPv3 > # base<cn=config> with scope subtree > # filter: objectclass=* > # requesting: ALL > # with manageDSAit control > # > > # search result > search: 2 > result: 2 Protocol error > text: controls require LDAPv3 > > # numResponses: 1 > ldap_result: Can't contact LDAP server (-1) > > > These servers are not yet in production and I have ~two weeks to play and tweak > to generate more debugging information if you'd find it useful. > > -- -- 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#7108) syncrepl loses updates when replica is down
by ml+openldap＠esmtp.org 08 Dec '11

08 Dec '11

Full_Name: Claus Assmann Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.3 URL: ftp://ftp.openldap.org/incoming/claus-assmann-111208.patch Submission from: (NULL) (63.211.143.38) This is a followup to ITS 7037 which has been fixed in 2.4.28. It is the same setup and test -- I've uploaded a "patch" that includes the test program (sorry if it doesn't follow all the OpenLDAP conventions, I hope it is sufficient to reproduce the problem). It looks like some changes to the OpenLDAP master are not transferred to the replica (the test prg demonstrates that). Note: in my test runs it doesn't always fail, but almost all the time. Please let me know whether my test is broken or whether there is a problem in slapd. this is the failure output from running ./run syncrepl-ldap in the tests/ directory: test failed - master and slave databases differ 79,83d78 < dn: dc=com < dc: com < objectClass: top < objectClass: domain < 101,115d95 < dn: dc=example,dc=com < dc: example < objectClass: organization < objectClass: domainRelatedObject < objectClass: dcObject < l: Anytown, Michigan < st: Michigan < o: Example, Inc. < o: EX < o: Ex. < description: The Example, Inc. at Anytown < postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US < telephoneNumber: +1 313 555 1817 < associatedDomain: example.com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs