> 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 = > provide >> bits of information each time, it'll take ages to just discover where = > the >> issue is. > > >> So now the only way to keep this ITS open is to see your ENTIRE = > slapd.conf >> (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 = > couple >> 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". p.
