openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs