[Date Prev][Date Next]
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
> First of all, I am paraphrasing. No one is hiding anything from you =
> Pierre. You need only ask.=20
>> It is supposed to be a bug. It's also the reason I asked from the
>> beginning to see the real configuration, real data and real operation
>> causing the issue. If you keep hiding essential details, and only =
>> bits of information each time, it'll take ages to just discover where =
>> issue is.
>> So now the only way to keep this ITS open is to see your ENTIRE =
>> (except passwords, of course). An even better alternative would be to
>> receive a sanitized slapd.conf, a LDIF and a search operation based on
>> ldapsearch that clearly illustrates the issue, like what I posted a =
>> of postings ago.
> Here, the entire sanitized config. I left out the ACL file (the include =
> statement at the very end), but the behavior in question was happening =
> to the rootdn user as well, meaning ACLs weren't the culprit. I also =
> removed 14 of 15 of the syncrepl stanzas for brevity, as they were all =
> the same aside from hostname/IP.
> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the =
> original (dysfunctional) position vs the current (functional) position.
I can't see any difference in behavior with the configuration in
<ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and the
ldapsearch command described in my previous posting (the only difference
is that now, after "./run -b hdb test003" you need to manually create
directory "testrun/db.2.a" for the log database, and bind as the rootdn to
perform the search). I tried both HEAD and current re24 code, which
should not differ much from 2.4.21. The only modifications to
configuration are related to: statically built backends/overlays, no ACLs,
no TLS. Also, valgrind does not show anything strange (like dangling
pointers or so) which could be symptoms of doing nasty things with memory
that make my setup work "by chance".