Alexander 'Leo' Bergolth wrote:
On 09/24/2009 08:43 PM, Howard Chu wrote:
Use RFC2307bis. posixGroups with memberUid are deprecated.
Even RFC2307bis says "either ... or", AFAIK it doesn't contain any valuation which one is preferred:
It is suggested that uid and cn are used as the naming attribute for posixAccount and posixGroup entries, respectively. Group members may either be login names (values of memberUid) or dis- tinguished names (values of uniqueMember).E.g. samba recommends to use smbldaptools for managing Users and Group, which cannot handle uniqueMembers.
uniqueMember is also deprecated.
http://www.ietf.org/id/draft-howard-rfc2307bis-02.txt
Section 5.2
Anyway, memberUIDs are still used in many large distributed setups that cannot be easily migrated to uniqueMember style groups without major modifications to all components involved.
So how do you estimate the complexity of adding this extension to dynlist-attrset?
Probably easy. Patches are always welcome.
dynlist-attrset<group-oc> <URL-ad> [<member-ad>] [<result-ad>] i.e.: dynlist-attrset myposixGroup memberURL memberUid uid
E.g. a way to dynamically add a memberUid to each posixAccount that contains the same data as the uid attribute? If that works, a filter like ldap:///ou=users,dc=local,dc=site?memberUid?sub?(&(objectClass=posixAccount)(<searchfilter>))
... could work.
Or maybe another workaround could be to first add the user-account DN to the memberUid attribute using existing dynlist features and then rewrite it's value by extracting the username out of the DN using another overlay? Would this be a realistic approach?
The rewrite overlay only operates on DN-valued attributes. I don't recall if rewriting occurs before or after attribute mapping; if it occurs after then it would not work.