Howard, hello.
On 8 Feb 2024, at 0:34, Howard Chu wrote:
65c3df21.21fc2a30 0x16cacf000 ldap_url_parse_ext(ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs)))
The above URL is not valid for a dynamic group. The attrs portion of the URL must be empty.
Since it's invalid, after it is parsed it gets ignored.
That's true when constructing what slapo-dynlist(5) calls a dynamic group, but that's not what I'm constructing here, but instead a group entry which is dynamically expanded, to a group, by a search.
Hmm: I realise there's a collision of terminology here, and that I used the specific phrase 'dynamic group' in the first message (but managed to avoid it in the second).
slapo-dynlist(5) does indeed consistently use 'dynamic group' to refer to the case where the olcDynListAttrSet has three values, and the generated entry contains the DNs of the matching entries.
Here, however, I'm using the two-argument case, and defining a group as the union of a number of groupOfNames groups. That's a group which is dynamic, but perhaps 'dynamically generated group' would be a less colliding name than 'dynamic group'.
Anyway...
slapd.ldif:
dn: olcOverlay=dynlist,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynlistConfig olcOverlay: dynlist olcDynListAttrSet: groupOfURLs memberURL
and group definition:
dn: cn=ldap-operators,ou=groups,o=example cn: ldap-operators objectClass: groupOfURLs description: Members of all of the LDAP admin and tech groups memberURL: ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs))
When I search for this, I do indeed get a group that looks as I'd hope:
% ldapsearch -x -H ldap://localhost:8389 -b o=example -LLL '(cn=ldap-operators)' dn: cn=ldap-operators,ou=groups,o=example cn: ldap-operators objectClass: groupOfURLs description: Members of all of the LDAP admin and tech groups memberURL: ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs)) member: uid=norman,ou=staff,o=example [...]
That is, the dynlist overlay has synthesised an entry which has a number of 'member' attributes.
That looks good, but this doesn't have the expected effect when I use this group in the olcLimits directive.
olcLimits: group/groupOfURLs/memberURL="cn=ldap-operators,ou=groups,o=example" size=2
(or group/groupOfURLs/member).
Speculation: The objectClass of the above group is groupOfURLs, and not groupOfNames, but the olcLimits documentation mentions groupOfNames only as the default for the /oc element of this spec, and not as a general requirement.
The short version is that if I look at the documentation for olcLimits, it says:
The term group, with the optional objectClass oc and attributeType at fields, followed by pattern, sets the limits for any DN listed in the values of the at attribute (default member) of the oc group objectClass (default groupOfNames) whose DN exactly matches pattern.
Using dynlist, I have synthesised a group with what appear to be the required properties, but olcLimits isn't processing it as I expect. The only difference is that the group is dynamic rather than fixed. What is wrong with my expectation?
Best wishes,
Norman