openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 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 10:34 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > No way. Then it is unlikely this will get fixed until you can provide a dummy data set that triggers the issue. Personally this is why I keep an NDA with Symas. --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 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? No way. 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 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 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

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