openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

ITS#7059 UTF8StringNormalize issue
by hyc＠symas.com 22 Nov '11

22 Nov '11

As Ralf Haferkamp noted, the real bug was introduced with postalAddressNormalize which was released in 2.4.10, so nothing earlier than that is affected. Also, this bug had no effect on most Linux installs because glibc malloc always allocates at least 16 bytes. The bug was only detected because I was running valgrind to check for leaks; there was no known crash related to this bug. -- -- 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#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by michael＠stroeder.com 21 Nov '11

21 Nov '11

Noël Köthe wrote: >> noel debian.org wrote: >>> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute >>> to DN'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 >> harm in the current behaviour. It's surely the client configuration >> which needs 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? Maybe you got me wrong: I don't have a really strong opinion on that (nor am I the one who decides on this). The question is: What should the pwdFailureTime exactly mean? I understand what's your personal opinion on that and I somewhat support it. But there might be corner-cases where the current behaviour makes sense. Ciao, Michael.

1 0

(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

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