openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 23 Nov '11

23 Nov '11

I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... But with the old last good backup LDIF (data1) the bug happens again. I noticed that in data1 the entries which were mixed up later in slapcat output were in the order (example data) dn: cn=John Doe,o=Company dn: o=Company whereas later in data2 there was exported: dn: o=Company dn: cn=John Doe,o=Company I will try to provide a test LDIF if necessary but I'm in a hurry now. Please note that I'm talking about LDIF files which were all generated by slapcat and therefore are assumed to be valid input for restoring with slapadd. Also LDAP access to the entries mixed in slapcat output is completely ok. Ciao, Michael.

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by h.b.furuseth＠usit.uio.no 23 Nov '11

23 Nov '11

draft-behera-ldap-password-policy: - Says this should be supported via attribute SubtreeSpecification in the pwdPolicy subentry. I think OpenLDAP does not support this attribute, it accepts it but does not do anything. - Leaves room to make the requested behavior configurable in cn=config, or for that matter make it the default: The draft mostly says ppolicy applies to "user entries". Browsing it quicly, I don't see it define what that means, nor consider the existence of non-user entries. A config attribute could define that. I don't know if anyone will bother to implement this (patches welcome) but I don't see a formal problem with whether it could/should be done. -- Hallvard

1 0

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

23 Nov '11

It seems to work with git master fadb48a723756ac0111731f7650f7da1a23c12a3 So you can close this ITS. If any issue is in the RE24 I will file new ITS. Ciao, Michael.

1 0

Re: (ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by quanah＠zimbra.com 22 Nov '11

22 Nov '11

--On Monday, November 21, 2011 10:35 AM +0000 michael(a)stroeder.com wrote: > 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 > So what do you see in the generated log file? --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

1 0

(ITS#7094) slapd ciphersuite TLS_RSA_3DES_EDE_CBC_SHA1 not usable with GnuTLS
by quanah＠OpenLDAP.org 22 Nov '11

22 Nov '11

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As reported in the debian bug tracker at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648056 If slapd is set to use the TLS_RSA_3DES_EDE_CBC_SHA1 cipher suite, it fails to start up, even though gnuTLS reports it as supported.

1 0

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

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