November 2011 - openldap-bugs

(ITS#7087) test050-syncrepl-multimaster failed for mdb

by michael＠stroeder.com

Full_Name: Version: RE24 from git OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.253.233) This is also a test which only fails occasionally. testrun/ follows... >>>>> Starting test050-syncrepl-multimaster for mdb... running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Inserting syncprov overlay on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Configuring syncrepl on server 2... Starting server 3 on TCP/IP port 9013... Using ldapsearch to check that server 3 is running... Configuring syncrepl on server 3... Starting server 4 on TCP/IP port 9014... Using ldapsearch to check that server 4 is running... Configuring syncrepl on server 4... Adding schema and databases on server 1... Using ldapadd to populate server 1... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read config from server 1... Using ldapsearch to read config from server 2... Using ldapsearch to read config from server 3... Using ldapsearch to read config from server 4... Comparing retrieved configs from server 1 and server 2... Comparing retrieved configs from server 1 and server 3... Comparing retrieved configs from server 1 and server 4... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Using ldapsearch to read all the entries from server 3... Using ldapsearch to read all the entries from server 4... Comparing retrieved entries from server 1 and server 2... Comparing retrieved entries from server 1 and server 3... test failed - server 1 and server 3 databases differ >>>>> test050-syncrepl-multimaster failed for mdb (exit 1) make[2]: *** [mdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap-git/re24/openldap/tests' make: *** [test] Error 2

11 years, 10 months

1
0
0 / 0

Re: (ITS#7086) typofix for ldapmodify man page

by quanah＠zimbra.com

--On Wednesday, November 09, 2011 8:02 PM +0000 schmiddy(a)gmail.com wrote: > Full_Name: Josh Kupershmidt > Version: git head > OS: OS X > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (165.212.186.27) > > > Here is a typofix for the ldapmodify man page, replacing "where" with > "were" in the description of the "-S" option: Thanks, this is fixed. --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

11 years, 10 months

1
0
0 / 0

(ITS#7086) typofix for ldapmodify man page

by schmiddy＠gmail.com

Full_Name: Josh Kupershmidt Version: git head OS: OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (165.212.186.27) Here is a typofix for the ldapmodify man page, replacing "where" with "were" in the description of the "-S" option: diff --git a/doc/man/man1/ldapmodify.1 b/doc/man/man1/ldapmodify.1 index 0268012..84296e8 100644 --- a/doc/man/man1/ldapmodify.1 +++ b/doc/man/man1/ldapmodify.1 @@ -144,7 +144,7 @@ will continue with modifications. The default is to exit after reporting an error. .TP .BI \-S \ file -Add or change records which where skipped due to an error are written to \fIfile\fP +Add or change records which were skipped due to an error are written to \fIfile\fP and the error message returned by the server is added as a comment. Most useful in conjunction with \fB\-c\fP. .TP

11 years, 10 months

1
0
0 / 0

Re: (ITS#7085) mutex lockup issue

by quanah＠zimbra.com

--On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.edu wrote: > Full_Name: Soichi Hayashi > Version: 2.4.22 OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a current release (2.4.26). This report will not be investigated unless you can reproduce it with a current release of OpenLDAP. You also fail to note what BDB release you are using, and whether or not it has all the relevant patches applied to it. If you have a broken policy of only using vendor provided packages, then you will need to send a bug report to RedHat, as it is their job to maintain their vendor packages. Thanks! --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

11 years, 10 months

1
0
0 / 0

Re: (ITS#7074) back-ldap module compilation issue with gcc 4.6.1

by stephane.paquot＠gmail.com

--90e6ba613518beaf2904b14dee12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard, Compilation is fine and module back-ldap is fully operational with the workaround you have suggested. Many thanks to you. 2011/10/29 <openldap-its(a)openldap.org> > > *** 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#7074. > > 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#7074) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#7074) > > 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=3D7074 > > Please remember to retain your issue tracking number (ITS#7074) > 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. > > --=20 _________________________________ St=E9phane PAQUOT stephane.paquot(a)gmail.com Site web : http://www.sqlpac.com/ --90e6ba613518beaf2904b14dee12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Howard,</div><div><br></div><div>Compilation is fine and module bac= k-ldap is fully operational with the workaround you have suggested.</div><d= iv><br></div><div>Many thanks to you.</div><div><br></div><br><div class=3D= "gmail_quote"> 2011/10/29 <span dir=3D"ltr"><<a href=3D"mailto:openldap-its@openldap.o= rg">openldap-its(a)openldap.org</a>></span><br><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex;"> <br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your<br> report has been assigned the tracking number ITS#7074.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers. =A0They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message. =A0Note that<br> any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#7074)<br> in the subject will automatically be attached to the issue report.<br> <br> =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a>?subject=3D(ITS#7074)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D7074" tar= get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D7074</a><br> <br> Please remember to retain your issue tracking number (ITS#7074)<br> on any further messages you send to us regarding this report. =A0If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla= nk">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>____________= _____________________<br><br>St=E9phane PAQUOT<br><br><a href=3D"mailto:ste= phane.paquot(a)gmail.com">stephane.paquot(a)gmail.com</a><br>Site web : <a href= =3D"http://www.sqlpac.com/">http://www.sqlpac.com/</a><br> <br> --90e6ba613518beaf2904b14dee12--

11 years, 10 months

1
0
0 / 0

(ITS#7085) mutex lockup issue

by hayashis＠indiana.edu

Full_Name: Soichi Hayashi Version: 2.4.22 OS: RHEL 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.137.202.79) When a large number of ldap update requests collides with large number of ldap search queries, mutex on BDB linked to OpenLDAP deadlocks. Following is the gdb output when this deadlocks occurs. (gdb) info threads 13 Thread 0x40a73940 (LWP 18767) 0x00000037aa4d48a8 in epoll_wait () from /lib64/libc.so.6 12 Thread 0x41cbe940 (LWP 18768) 0x00000037aa4cd722 in select () from /lib64/libc.so.6 11 Thread 0x424bf940 (LWP 18769) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x42cc0940 (LWP 19203) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9 Thread 0x41274940 (LWP 19212) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x434c1940 (LWP 19213) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x43cc2940 (LWP 19214) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x444c3940 (LWP 19215) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x44cc4940 (LWP 19216) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x454c5940 (LWP 19217) 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 3 Thread 0x45cc6940 (LWP 19218) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x464c7940 (LWP 19219) 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 * 1 Thread 0x2ad9964071e0 (LWP 18752) 0x00000037aac07b35 in pthread_join () from /lib64/libpthread.so.0 (gdb) thread 2 [Switching to thread 2 (Thread 0x464c7940 (LWP 19219))]#0 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 #1 0x0000003f22c2b963 in __db_pthread_mutex_lock_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #2 0x0000003f22d1e2dc in __memp_fget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #3 0x0000003f22c46a8f in __bam_search_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #4 0x0000003f22c34649 in ?? () from /usr/lib64/libslapd24_db-4.8.so #5 0x0000003f22c3534b in ?? () from /usr/lib64/libslapd24_db-4.8.so #6 0x0000003f22cd4bbf in __dbc_iput_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #7 0x0000003f22cd536f in __dbc_put_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #8 0x0000003f22cdca0f in __dbc_put_pp_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #9 0x00000000004c9d7e in bdb_idl_insert_key () #10 0x00000000004cbcb2 in bdb_key_change () (gdb) thread 4 [Switching to thread 4 (Thread 0x454c5940 (LWP 19217))]#0 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 #1 0x0000003f22c2b754 in __db_pthread_mutex_readlock_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #2 0x0000003f22d1e5fc in __memp_fget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #3 0x0000003f22cd3df9 in __dbc_iget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #4 0x0000003f22cdd43a in __dbc_get_pp_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #5 0x00000000004ca6d0 in bdb_idl_fetch_key () #6 0x00000000004cbd75 in bdb_key_read () In above case, thread 2 and thread 4 are deadlocked. The deadlock occurs within 2 - 8 hours after we start testing LDAP server on our BDII services. Meanwhile, OpenLDAP version 2.3 does not cause this deadlock, but it causes a gradual CPU usage increase until the performance degrades to the point where we need to restart the server. Is there anyway you could fix the deadlock issue on v2.4, or CPU usage issue on v2.3? Thanks, Soichi Hayashi

11 years, 10 months

1
0
0 / 0

(ITS#7084) Password Modify Extended Operation to set pwdReset: TRUE

by michael＠stroeder.com

Full_Name: Version: OS: URL: Submission from: (NULL) (192.166.104.102) Feature Request: The Password Modify Extended Operation should set pwdReset: TRUE if the accompanying password policy specifies pwdMustChange: TRUE. Section 8.2.7 of http://tools.ietf.org/html/draft-behera-ldap-password-policy-09#section-8.2 says: If the value the pwdMustChange is TRUE and the modification is performed by a password administrator, then the pwdReset attribute is set to TRUE. Otherwise, the pwdReset is removed from the user's entry if it exists. So the question is how to determine whether the modification is performed by a password administrator. There could be an attribute in the password policy entry with values like authzTo/authzFrom to specify the set of password admins.

11 years, 10 months

1
0
0 / 0

Re: (ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms

by h.b.furuseth＠usit.uio.no

Thank you. I've committed your fix. verbs_to_mask() adds bits to an existing mask. > (...) I'm not sure why this only > manifests on 64-bit architectures, as my reduced test case (can > provide if necessary) also fails on 32-bit architectures. Probably just a coincidence: There happens to be a 0 on the stack where the compiler puts the m variable on on your 32-bit hosts. -- Hallvard

11 years, 10 months

1
0
0 / 0

(ITS#7083) Broken verb_to_mask() calls

by h.b.furuseth＠usit.uio.no

Full_Name: Hallvard B Furuseth Version: 2.3-2.4.26 OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard slapd/bconfig.c and contrib:smbk5pwd.c use verb_to_mask() as if it returned a bitmask instead of an index. This affects delete operations of restrict, allows, disallows, requires, syslog loglevel, and smbk5pwd modules.

11 years, 10 months

1
0
0 / 0

(ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms

by zanchey＠ucc.gu.uwa.edu.au

Full_Name: David Adam Version: 2.4.23 OS: Debian URL: http://www.openldap.org/lists/openldap-technical/201111/msg00034.html Submission from: (NULL) (2001:44b8:6112:bc00:6ef0:49ff:fe74:26c4) On 64-bit machines using the contributed smbk5pwd overlay, the smbk5pwd module insists on trying to load all the Kerberos configuration regardless, even if smbk5PwdEnable is set to 'samba'. I suspect this has something to do with the call to verbs_to_mask() in smbk5pwd_cf_func (under the case PC_SMB_ENABLE) - my very basic printf() debugging shows that m is set correctly on 32-bit architectures but on 64-bit architectures returns a varying and strangely-numbered value (4511419, -1407332384, 353253328 in subsequent runs). The problem goes away if the m variable is initialised to 0 before the call to verbs_to_mask(). Most of the calls to verbs_to_mask() in the rest of the source initialise the fourth variable to 0 before calling. Either smbk5pwd also needs to do this, or the verbs_to_mask function needs to initialise the variable before use. I'm not sure why this only manifests on 64-bit architectures, as my reduced test case (can provide if necessary) also fails on 32-bit architectures.

11 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2011