Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement

[j@gropefruit.com]

Interesting.  I can't seem to imagine why this behaved the way it did =
(looking over my config again)   I am just happy that moving it fixed =
the issue.




On Feb 14, 2010, at 00:55 , masarati@aero.polimi.it wrote:

>> First of all,  I am paraphrasing.  No one is hiding anything from you =
=3D
>> Pierre. You need only ask.=3D20
>>=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 =3D=

>> provide
>>> bits of information each time, it'll take ages to just discover =
where =3D
>> the
>>> issue is.
>>=20
>>=20
>>> So now the only way to keep this ITS open is to see your ENTIRE =3D
>> 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 =
=3D
>> couple
>>> of postings ago.
>>=20
>> Here, the entire sanitized config. I left out the ACL file (the =
include =3D
>> statement at the very end), but the behavior in question was =
happening =3D
>> to the rootdn user as well, meaning ACLs weren't the culprit.  I also =
=3D
>> removed 14 of 15 of the syncrepl stanzas for brevity, as they were =
all =3D
>> the same aside from hostname/IP.
>>=20
>> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote =
the =3D
>> original (dysfunctional) position vs the current (functional) =
position.
>=20
> 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".
>=20
> p.
>=20