openldap-bugs November 2011

openldap-bugs@openldap.org

22 participants
92 discussions

(ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by michael＠stroeder.com 21 Nov '11

21 Nov '11

Full_Name: Version: git master 9845c030ab1b569d9943c885cd6db876c535758d OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.253.198) test000 works with bdb and mdb but not hdb $ ./run -b hdb test000 Cleaning up test run directory leftover from previous run. Running ./scripts/test000-rootdse for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: line 66: kill: (5333) - No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by noel＠debian.org 21 Nov '11

21 Nov '11

--=-OBICNroNT6O1Nc+JWJc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Michael, >noel debian.org wrote: >> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to D= N's >> which don't have a userPassword attribute and cannot get one. > Hmm, this is somewhat debatable. I'm not sure. But I also don't see any h= arm > in the current behaviour. It's surely the client configuration which need= s to :( > be fixed. In my case the behaviour is pollution my data with unneeded and unwanted data in ous which I want to prevent. I don't have control over the clients so sadly I cannot fix the source of the problem (the requests). The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there is a userPassword: attribute ( when using pwdAttribute: userPassword). Is there any chance that the behaviour is accepted as a problem? --=20 No=C3=ABl K=C3=B6the <noel debian.org> Debian GNU/Linux, www.debian.org --=-OBICNroNT6O1Nc+JWJc8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk7KFRUACgkQ9/DnDzB9Vu2a8QCfdLgeqXZE6hgK5wy2Tk+bZCAZ vMYAnA9UHtRGoukZcJ/KtvxHDZECFP6d =91QP -----END PGP SIGNATURE----- --=-OBICNroNT6O1Nc+JWJc8--

1 0

Re: (ITS#7092) Please re-open #6548 - Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 19 Nov '11

19 Nov '11

online(a)mark.ziesemer.com wrote: > Full_Name: Mark A. Ziesemer > Version: 2.4.2 2.4.2 would have been an early alpha or beta release. Bug reports filed against such a release at this point are worthless. > OS: Ubuntu Linux 11.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.156.254.191) > Please re-open http://www.openldap.org/its/index.cgi/Incoming?id=6548 . This is > listed as a confirmed issue for Ubuntu at > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/594840 , affecting at > least 12 users - and there is no evidence to show that this is an issue specific > to Ubuntu. > > Please also refer to and at least acknowledge the unaddressed comments left in > response to #6548, which includes a report from a Debian user as well. > To clarify, this appears to be an issue with the libldap client library provided > by OpenLDAP itself (2.4.25), and not the slapd daemon. Some comments simply aren't worth addressing. Inserting sleeps is never the correct solution. A new patch for slapd is in git master, please test. -- -- 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

(ITS#7092) Please re-open #6548 - Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 19 Nov '11

19 Nov '11

Full_Name: Mark A. Ziesemer Version: 2.4.2 OS: Ubuntu Linux 11.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.156.254.191) Please re-open http://www.openldap.org/its/index.cgi/Incoming?id=6548 . This is listed as a confirmed issue for Ubuntu at https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/594840 , affecting at least 12 users - and there is no evidence to show that this is an issue specific to Ubuntu. Please also refer to and at least acknowledge the unaddressed comments left in response to #6548, which includes a report from a Debian user as well. To clarify, this appears to be an issue with the libldap client library provided by OpenLDAP itself (2.4.25), and not the slapd daemon.

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 18 Nov '11

18 Nov '11

hans.moser(a)ofd-z.niedersachsen.de wrote: > Howard, > > Howard Chu schrieb (17.11.2011 23:54 Uhr): >> Marc Patermann wrote: > >>> Howard Chu schrieb (01.11.2011 18:39 Uhr): >>> >>>> Also, this script just performs sync searches, what do you use to >>>> generate the writes? >>> you mean the write which kills the server? >>> It just one simple mod of an object which I made in Apache Directory >>> Studio. >> >> I'm unable to reproduce this crash. I have your slapd.conf and test >> data, I have run 80-some instances of your script as you've described. > I ran 80 instances of each of the three script, where each script > replicates one database, so 240 instances of the script in total. OK. After starting 240 instances and performing the modify, I saw a SEGV due to syncprov. I've patched this in git master, please test. It runs OK for me now. > >> While the initial sync search is running I perform a modify of the base >> entry of the subordinate database. Everything continues to run. I've >> also waited for all of the initial refresh traffic to finish first, and >> then perform the modify, and still no crash. >> >> To be more clear - do you perform your modify while the sync searches >> are still refreshing, or after all of the refreshes have completed? > IIRC it does not make any difference, but I definitly crashed the server > while at least one database still replicated. > >> Do you run the clients on the same host as slapd, or on a remote machine? > I had slapd one one machine and the script on another one. > > > Marc > > > -- -- 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#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 17 Nov '11

17 Nov '11

Howard, Howard Chu schrieb (17.11.2011 23:54 Uhr): > Marc Patermann wrote: >> Howard Chu schrieb (01.11.2011 18:39 Uhr): >> >>> Also, this script just performs sync searches, what do you use to >>> generate the writes? >> you mean the write which kills the server? >> It just one simple mod of an object which I made in Apache Directory >> Studio. > > I'm unable to reproduce this crash. I have your slapd.conf and test > data, I have run 80-some instances of your script as you've described. I ran 80 instances of each of the three script, where each script replicates one database, so 240 instances of the script in total. > While the initial sync search is running I perform a modify of the base > entry of the subordinate database. Everything continues to run. I've > also waited for all of the initial refresh traffic to finish first, and > then perform the modify, and still no crash. > > To be more clear - do you perform your modify while the sync searches > are still refreshing, or after all of the refreshes have completed? IIRC it does not make any difference, but I definitly crashed the server while at least one database still replicated. > Do you run the clients on the same host as slapd, or on a remote machine? I had slapd one one machine and the script on another one. Marc

1 0

Re: (ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by hyc＠symas.com 17 Nov '11

17 Nov '11

hyc(a)symas.com wrote: > >>> > The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, > back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for > assertion failure, if op->o_do_not_cache flag is set and there is no valid > binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI > for the remote AD Windows box is such a case. > <<< > > So it sounds like this assert only triggers because you have an invalid > configuration. I don't believe your patch is the correct solution if that's > the only error case. I've committed an alternate fix, turning the assert into an error return. Please test. -- -- 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#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by hyc＠symas.com 17 Nov '11

17 Nov '11

tedcheng(a)symas.com wrote: > The following patch fixed the issue: > > Index: servers/slapd/back-ldap/bind.c > =================================================================== > RCS file: /var/CVSROOT/ldap24/servers/slapd/back-ldap/bind.c,v > retrieving revision 1.12 > retrieving revision 1.13 > diff -u -u -r1.12 -r1.13 > --- servers/slapd/back-ldap/bind.c 28 Jul 2011 09:31:34 -0000 1.12 > +++ servers/slapd/back-ldap/bind.c 17 Nov 2011 21:35:46 -0000 1.13 > @@ -2056,7 +2056,7 @@ > struct berval ndn; > int dobind = 0; > > - if ( op->o_conn == NULL || op->o_do_not_cache ) { > + if ( op->o_conn == NULL ) { > goto done; > } > In your original post you state: >>> The ldap_back_dobind() function calls ldap_back_dobind_int() for bind, back-ldap/bind.c. The following ldap_back_dobind_int() code is destined for assertion failure, if op->o_do_not_cache flag is set and there is no valid binddn and bindcred returned by ldap_back_getconn(). Setting an invalid LDAP URI for the remote AD Windows box is such a case. <<< So it sounds like this assert only triggers because you have an invalid configuration. I don't believe your patch is the correct solution if that's the only error case. -- -- 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#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by tedcheng＠symas.com 17 Nov '11

17 Nov '11

The following patch fixed the issue: Index: servers/slapd/back-ldap/bind.c =================================================================== RCS file: /var/CVSROOT/ldap24/servers/slapd/back-ldap/bind.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -u -r1.12 -r1.13 --- servers/slapd/back-ldap/bind.c 28 Jul 2011 09:31:34 -0000 1.12 +++ servers/slapd/back-ldap/bind.c 17 Nov 2011 21:35:46 -0000 1.13 @@ -2056,7 +2056,7 @@ struct berval ndn; int dobind = 0; - if ( op->o_conn == NULL || op->o_do_not_cache ) { + if ( op->o_conn == NULL ) { goto done; } Ted C. Cheng Symas Corporation

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 17 Nov '11

17 Nov '11

hyc(a)symas.com wrote: > Marc Patermann wrote: >> Howard, >> >> Howard Chu schrieb (01.11.2011 18:39 Uhr): >> >>> Also, this script just performs sync searches, what do you use to >>> generate the writes? >> you mean the write which kills the server? >> It just one simple mod of an object which I made in Apache Directory Studio. > > I'm unable to reproduce this crash. I have your slapd.conf and test data, I > have run 80-some instances of your script as you've described. While the > initial sync search is running I perform a modify of the base entry of the > subordinate database. Everything continues to run. I've also waited for all of > the initial refresh traffic to finish first, and then perform the modify, and > still no crash. > > To be more clear - do you perform your modify while the sync searches are > still refreshing, or after all of the refreshes have completed? > > Do you run the clients on the same host as slapd, or on a remote machine? By the way... Your backtrace shows a crash down a code path that only gets executed when an operation is abandoned. None of the steps you've outlined ever cause an abandon or connection close to occur, so again, we can't duplicate the problem. -- -- 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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2011