openldap-bugs November 2011

openldap-bugs@openldap.org

22 participants
92 discussions

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

23 Nov '11

--On Wednesday, November 23, 2011 9:48 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: >> Can you provide these two data sets? > > As said in my first posting: This is private address book data. So nope. Can you provide it outside of the ITS system in a private manner to Howard? That is going to be the easiest way to get this resolved. --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

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

23 Nov '11

Quanah Gibson-Mount wrote: > --On Wednesday, November 23, 2011 8:18 PM +0000 michael(a)stroeder.com wrote: > >> 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'm trying to comprehend what you're saying here... So is this correct? > > You have two data sets, data1 and data2. You get can reproduce the issue > using dataset data1, and you have no issues using dataset data2. Yes. And the obvious difference is the order of superior and subordinate entries which get mixed with other superior entries as described in my last posting. > Can you provide these two data sets? As said in my first posting: This is private address book data. So nope. Ciao, Michael.

1 0

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

23 Nov '11

--On Wednesday, November 23, 2011 8:18 PM +0000 michael(a)stroeder.com wrote: > 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'm trying to comprehend what you're saying here... So is this correct? You have two data sets, data1 and data2. You get can reproduce the issue using dataset data1, and you have no issues using dataset data2. Can you provide these two data sets? --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

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 23 Nov '11

23 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 23 Nov '11

23 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

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2011