marg@rz.tu-clausthal.de wrote:
I found a behaviour issue with the dynlist overlay configuration:
I tried the following configuration:
overlay dynlist dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL owner
The reason of that check is that the same attribute "memberURL" could otherwise be used by both group classes to expand.
but slaptest complains about it - and the slapd doesn't start with it:
@(#) $OpenLDAP: slapd 2.3.34[...] /usr/local/etc/openldap/slapd.conf: line 91: "dynlist-attrset <oc> <URL-ad> [<member-ad>]": URL attributeDescription "memberURL" already mapped. slapd stopped.
When I use multiple "overlay dynlist"-entries like:
overlay dynlist dynlist-attrset posixGroup memberURL overlay dynlist dynlist-attrset groupOfURLs memberURL owner
it works as expected, but there is a warning:
overlay_config(): warning, overlay "dynlist" already in list
PS: Although the new Version 2.3.35 isn't available via FreeBSD Ports yet, I don't think that it would change anything, because the source file of the dynlist-overlay doesn't seem to have changed in any part that matters to this issue.
I think the documentation describes the intended behavior, but configuration parsing is not (no longer?) in agreement with the documentation. I think the real issue is that the behavior is no longer consistent for compares and searches: - for searches, only the first group that matches the entry's objectClass will be expanded - for compares, all groups that match will be expanded until a match is found
I'm reworking the configuration test to be consistent with the documentation, and the code to be self-consistent: now all groups matching the entry are expanded. So now a configuration like
dynlist-attrset groupOfURLs memberURL dynlist-attrset groupOfURLs memberURL member
will simultaneously merge all attributes listed in a "memberURL", and add the expanded entries' DN as "member".
However, I believe something like
dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL
should still be forbiden, otherwise the same "memberURL" would expand twice. This, strictly speaking, is not an issue, as duplicates would simply be discarded, but it would cause unnecessary overhead. Right now, I have decided to turn this check into a config-time warning.
Please test and report.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------