openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

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

Re: (ITS#3957) Insert ITS# in ITS message download
by Howard Chu 16 Feb '09

16 Feb '09

Fix is now installed, this ITS will be closed.

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2009