openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#5956) Unallocatable shm keys lock up slapd
by quanah＠OpenLDAP.org 17 Feb '09

17 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.14 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If I set OpenLDAP to use an shm key, and the kernel is not configured to allow SHM keys of the size requested, slapd goes into an infinite loop trying to connect to the DB, and can only be stopped with a kill -9: Feb 17 15:06:53 tribes slapd[7683]: hdb_db_open: database "": shared memory env open failed, assuming stale env. Feb 17 15:06:53 tribes slapd[7683]: bdb(): shmget: key: 7: unable to create shared system memory region: Invalid argument Feb 17 15:06:53 tribes slapd[7683]: bdb(): PANIC: Invalid argument Feb 17 15:06:53 tribes slapd[7683]: bdb(): unable to join the environment is what it logs endlessly.

1 0

Re: (ITS#5954) deleting one of several syncrepl consumers deletes the wrong one
by hyc＠symas.com 17 Feb '09

17 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: CentOS > URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch > Submission from: (NULL) (213.41.243.192) > > > Hi all, > > It seems that when adding syncrepl consumers to be->be_syncinfo, they are added > in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete > on cn=config from be->be_syncinfo, the nth entry in the list is removed, which > is not the same one. Thanks for the patch, fixed in HEAD. -- -- 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#5953) slapd seg faults with SASL bind DIGEST-MD5
by quanah＠zimbra.com 17 Feb '09

17 Feb '09

--On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: 2.4.14 > OS: SLES 10 > URL: > Submission from: (NULL) (193.197.158.1) > > > If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the > authz-regexp configuration is correct in slapd.conf What makes you think this is a bug with OpenLDAP and not cyrus-sasl? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5955) build failure with gnutls: error: .struct ldapoptions. has no member named .ldo_tls_crlcheck.
by quanah＠zimbra.com 17 Feb '09

17 Feb '09

--On Tuesday, February 17, 2009 12:42 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, February 17, 2009 8:34 PM +0000 > steve.langasek(a)canonical.com wrote: > >> >> --uAKRQypu60I7Lcqm >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> >> Here's the patch. > > Thanks! This fix has been applied to HEAD and RE24 for the 2.4.15 > release. In addition, I saw there were some missing ifdefs around another > OpenSSL specific bit of code that used to be covered in the old tls.c, so > I added that as well: > > <http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls2.c.diff?h > ideattic=1&r1=text&tr1=1.8&r2=text&tr2=1.9&f=h> Sorry, ignore that bit. The comment in the code was wrong, rather than the code being wrong. I've removed the comment. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5955) build failure with gnutls: error: .struct ldapoptions. has no member named .ldo_tls_crlcheck.
by quanah＠zimbra.com 17 Feb '09

17 Feb '09

--On Tuesday, February 17, 2009 8:34 PM +0000 steve.langasek(a)canonical.com wrote: > > --uAKRQypu60I7Lcqm > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Here's the patch. Thanks! This fix has been applied to HEAD and RE24 for the 2.4.15 release. In addition, I saw there were some missing ifdefs around another OpenSSL specific bit of code that used to be covered in the old tls.c, so I added that as well: <http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls2.c.diff?hide…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5955) build failure with gnutls: error: .struct ldapoptions. has no member named .ldo_tls_crlcheck.
by steve.langasek＠canonical.com 17 Feb '09

17 Feb '09

--uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's the patch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=no-crlcheck-for-gnutls Author: Steve Langasek <steve.langasek(a)canonical.com> OpenLDAP 2.4.14 doesn't build with GnuTLS due to a missed guard around a use of an OpenSSL-specific option. ITS #5955 Index: trunk/libraries/libldap/tls2.c =================================================================== --- trunk.orig/libraries/libldap/tls2.c +++ trunk/libraries/libldap/tls2.c @@ -562,6 +562,7 @@ } return ldap_pvt_tls_set_option( ld, option, &i ); } +#ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ i = -1; if ( strcasecmp( arg, "none" ) == 0 ) { @@ -575,6 +576,7 @@ return ldap_pvt_tls_set_option( ld, option, &i ); } return -1; +#endif } return -1; } @@ -638,9 +640,11 @@ case LDAP_OPT_X_TLS_REQUIRE_CERT: *(int *)arg = lo->ldo_tls_require_cert; break; +#ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ *(int *)arg = lo->ldo_tls_crlcheck; break; +#endif case LDAP_OPT_X_TLS_CIPHER_SUITE: *(char **)arg = lo->ldo_tls_ciphersuite ? LDAP_STRDUP( lo->ldo_tls_ciphersuite ) : NULL; @@ -764,6 +768,7 @@ return 0; } return -1; +#ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ if ( !arg ) return -1; switch( *(int *) arg ) { @@ -774,6 +779,7 @@ return 0; } return -1; +#endif case LDAP_OPT_X_TLS_CIPHER_SUITE: if ( lo->ldo_tls_ciphersuite ) LDAP_FREE( lo->ldo_tls_ciphersuite ); lo->ldo_tls_ciphersuite = arg ? LDAP_STRDUP( (char *) arg ) : NULL; --uAKRQypu60I7Lcqm--

1 0

(ITS#5955) build failure with gnutls: error: struct ldapoptions has no member named ldo_tls_crlcheck
by steve.langasek＠canonical.com 17 Feb '09

17 Feb '09

Full_Name: Steve Langasek Version: 2.4.14 OS: n/a URL: Submission from: (NULL) (2001:1938:316:0:219:d2ff:fe76:2acb) Building OpenLDAP 2.4.14 with GnuTLS fails because an OpenSSL-specific option isn't properly #ifdefed in tls2.c: /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c: In function ldap_pvt_tls_get_option: /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c:642: error: struct ldapoptions has no member named ldo_tls_crlcheck /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c: In function ldap_pvt_tls_set_option: /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c:773: error: struct ldapoptions has no member named ldo_tls_crlcheck make[3]: *** [tls2.lo] Error 1 (Trivial) patch to follow.

1 0

RE: (ITS#5954) deleting one of several syncrepl consumers deletes thewrong one
by worganc＠nortel.com 17 Feb '09

17 Feb '09

LOL -----Original Message----- From: openldap-bugs-bounces+worganc=nortel.com(a)openldap.org [mailto:openldap-bugs-bounces+worganc=nortel.com@openldap.org] On Behalf Of jclarke(a)linagora.com Sent: Tuesday, February 17, 2009 3:05 PM To: openldap-its(a)openldap.org Subject: (ITS#5954) deleting one of several syncrepl consumers deletes thewrong one Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch Submission from: (NULL) (213.41.243.192) Hi all, It seems that when adding syncrepl consumers to be->be_syncinfo, they are added in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete on cn=config from be->be_syncinfo, the nth entry in the list is removed, which is not the same one. To reproduce: 1) If we start with this in cn=config: > olcSyncRepl: {0}rid=001 > olcSyncRepl: {1}rid=002 The list order is (schematically): be->be_syncinfo = {rid=002, rid=001} 2) Add add a rid=003, we have in cn=config: olcSyncRepl: {0}rid=001 olcSyncRepl: {1}rid=002 olcSyncRepl: {2}rid=003 and the list is: be->be_syncinfo = {rid=003, rid=002, rid=001} 3) We attempt to delete rid=003: dn: ...,cn=config changeType: modify delete: olcSyncRepl olcSyncRepl: {2}rid=003 The list then contains, value number 2 having been deleted: be->be_syncinfo = {rid=003, rid=002} The above patch changes the order syncrepl info is inserted in the list. This corrects the problem, and I have not seen any other consequences (by running the test suite and browsing the code). Is this OK? My apologies if I have missed something big here.

1 0

(ITS#5954) deleting one of several syncrepl consumers deletes the wrong one
by jclarke＠linagora.com 17 Feb '09

17 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch Submission from: (NULL) (213.41.243.192) Hi all, It seems that when adding syncrepl consumers to be->be_syncinfo, they are added in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete on cn=config from be->be_syncinfo, the nth entry in the list is removed, which is not the same one. To reproduce: 1) If we start with this in cn=config: > olcSyncRepl: {0}rid=001 > olcSyncRepl: {1}rid=002 The list order is (schematically): be->be_syncinfo = {rid=002, rid=001} 2) Add add a rid=003, we have in cn=config: olcSyncRepl: {0}rid=001 olcSyncRepl: {1}rid=002 olcSyncRepl: {2}rid=003 and the list is: be->be_syncinfo = {rid=003, rid=002, rid=001} 3) We attempt to delete rid=003: dn: ...,cn=config changeType: modify delete: olcSyncRepl olcSyncRepl: {2}rid=003 The list then contains, value number 2 having been deleted: be->be_syncinfo = {rid=003, rid=002} The above patch changes the order syncrepl info is inserted in the list. This corrects the problem, and I have not seen any other consequences (by running the test suite and browsing the code). Is this OK? My apologies if I have missed something big here.

1 0

(ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by michael＠stroeder.com 17 Feb '09

17 Feb '09

Full_Name: Michael Ströder Version: 2.4.14 OS: SLES 10 URL: Submission from: (NULL) (193.197.158.1) If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the authz-regexp configuration is correct in slapd.conf See GDB information below. (gdb) info threads 5 process 4888 0xffffe410 in __kernel_vsyscall () 4 process 4889 0xffffe410 in __kernel_vsyscall () 3 process 4890 0xffffe410 in __kernel_vsyscall () 2 process 4891 0xffffe410 in __kernel_vsyscall () * 1 process 4892 0xb7e89c2f in __db_get_flags () from /appserver/bdb-4.6/lib/libdb-4.6.so (gdb) thread apply all bt Thread 5 (process 4888): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d8b5d8 in pthread_join () from /lib/libpthread.so.0 #2 0xb7f356db in ldap_pvt_thread_join (thread=3023272864, thread_return=0x0) at thr_posix.c:197 #3 0x080773fb in ?? () #4 0xb4337ba0 in ?? () #5 0x00000000 in ?? () Thread 4 (process 4889): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7b5957e in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0xb7ae4e63 in _L_mutex_lock_41 () from /lib/libc.so.6 #3 0xb4334314 in ?? () #4 0xb4334314 in ?? () #5 0x00000032 in ?? () #6 0x00000021 in ?? () #7 0xb7f2611c in ?? () from /appserver/openldap-2.4/lib/liblber-2.4.so.2 #8 0x00000001 in ?? () #9 0x0000003c in ?? () #10 0xb4335318 in ?? () #11 0xb7f2173e in lutil_debug (debug=-1271708908, level=-1212492416, fmt=0x8139194 "daemon: activity on %d descriptor%s\n") at debug.c:72 Backtrace stopped: frame did not save the PC Thread 3 (process 4890): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d8e056 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7f357e0 in ldap_pvt_thread_cond_wait (cond=0x81eca6c, mutex=0x81eca54) at thr_posix.c:277 #3 0xb7f3449b in ldap_int_thread_pool_wrapper (xpool=0x81eca50) at tpool.c:654 #4 0xb7d8a2ab in start_thread () from /lib/libpthread.so.0 #5 0xb7b4da4e in clone () from /lib/libc.so.6 Thread 2 (process 4891): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d8e056 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7f357e0 in ldap_pvt_thread_cond_wait (cond=0x81eca6c, mutex=0x81eca54) at thr_posix.c:277 #3 0xb7f3449b in ldap_int_thread_pool_wrapper (xpool=0x81eca50) at tpool.c:654 #4 0xb7d8a2ab in start_thread () from /lib/libpthread.so.0 #5 0xb7b4da4e in clone () from /lib/libc.so.6 Thread 1 (process 4892): #0 0xb7e89c2f in __db_get_flags () from /appserver/bdb-4.6/lib/libdb-4.6.so #1 0xb7a81385 in ?? () from /usr/lib/sasl2/libsasldb.so #2 0x082f9570 in ?? () #3 0x00000000 in ?? ()

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