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

[masarati@aero.polimi.it]

> Actually, maybe I wasn't totally wrong.  There MAY be a bug at work, =
> just not the one I initially thought ....
>
> 1.) Implemented your exact working example on my dev server.  Worked.
> 2.) Implemented same example on my QA server.  Worked.
> 3.) Implemented on a production server. Failed.
>
> I then realized the dynlist-attrset was listed as follows:
>
> syncrepl params
> accesslog params
> dynlist-attrset params
>
> I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl =
> lines (below my indexes for this DB).
>
> Example then worked in production.
>
> Is THAT a bug? That its behavior changes depending on where it is placed =
> inside of a given 'database' section?
>
> Thanks, sorry to keep bugging you with this ....

GUESSING what you meant above is something like this (as you keep writing
things like "accesslog parameters" instead of the real thing)

<slapd.conf excerpt>
database        bdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          secret
#null#bind              on
directory       testrun/db.1.a
index           objectClass     eq
index           cn,sn,uid       pres,eq,sub

overlay dynlist
dynlist-attrset groupOfURLs memberURL memberUid

overlay syncprov

overlay accesslog
logdb cn=log
logops writes reads
logold (objectclass=person)

dynlist-attrset posixGroup memberURL memberUid:uid
</slapd.conf excerpt>

or any permutation of the dynlist-attrset statement, like both before
overlay syncprov, or both at the end, or anywhere between "overlay
syncrepl" and the last "log*" statement, I get the expected result.

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.

p.