[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-technical
Subject:    Re: olcLimits and groupOfURLs dynlist
From:       Norman Gray <gray () nxg ! name>
Date:       2024-02-08 10:35:12
Message-ID: B2592036-5295-4196-86A3-116D061FBE2B () nxg ! name
[Download RAW message or body]


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




-- 
Norman Gray  :  https://nxg.me.uk


[prev in list] [next in list] [prev in thread] [next in thread]