https://bugs.openldap.org/show_bug.cgi?id=9805
michael.bobzin@baloise.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|2.4.59 |2.5.11
--- Comment #4 from michael.bobzin@baloise.ch --- (In reply to Quanah Gibson-Mount from comment #3)
(In reply to michael.bobzin from comment #2)
But we will first upgrade to 2.5 and repeat the test.
As Howard noted, dynlist functionality was significantly expanded in OpenLDAP 2.5. That's why the upgrade was suggested. Testing behavior with 2.4 dynlist is not relevant.
Hello Quanah, After upgrading our DEV OpenLDAP server to 2.5.11, we repeated the test. What I also learned is that the autogroup overlay is independent of the dynlist overlay. The autogroup overlay only uses attributes from the dynlist schema and relies on them, that the module dynlist or memberof is loaded, otherwise slapd won't start and will give the following error message: autogroup_db_open: unable to find attribute="memberOf": attribute type undefined (17)
We first repeated the test with the following settings. --------------- slapd.conf ------------------------- ... include /path/to/dyngroup.schema # ... moduleload /path/to/autogroup.so moduleload /path/to/memberof.so # ... database <database> # ... overlay autogroup autogroup-attrset groupOfURLs memberURL member
--------------------------------------------------- The result was the same. The search
ldapsearch .. -s sub -b "ou=groups,dc=basler,dc=ch" "(member=cn=userx,ou=users,dc=basler,dc=ch)" dn
works until you make adjustments to the attributes of the userx.
In a second test we then used only the dynlist overlay
--------------- slapd.conf ------------------------- include /path/to/dyngroup.schema # ... moduleload dynlist # ... database <database> # ... overlay dynlist dynlist-attrset groupOfURLs memberURL
----------------------------------------------------
The search works now with the dynlist overlay but is very slow for our use case (several dynamic groups with 5000+ members).
The solution with member attributes maintained by autogroup would therefore be the better solution for our use case, since the members in this case don't have to be determined dynamically.
Do you see a reason why autogroup deletes the member entries for this user after adjustments to the attributes of userx? If the criterion for autogroup is the search defined in the memberURL, only mutation events for the member attribute of groupA should be relevant and not mutations to the user attributes.
Thank you for your patience and best regards Michael