Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah@zimbra.com
--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
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael@stroeder.com
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.
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by quanah@zimbra.com
--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
11 years, 10 months
Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael@stroeder.com
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.
11 years, 10 months
Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by h.b.furuseth@usit.uio.no
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
11 years, 10 months
Re: (ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process
by quanah@zimbra.com
--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
11 years, 10 months
ITS#7059 UTF8StringNormalize issue
by hyc@symas.com
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/
11 years, 10 months
Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by michael@stroeder.com
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.
11 years, 10 months