openldap-bugs January 2012

openldap-bugs@openldap.org

22 participants
76 discussions

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2012