On 09/24/2009 08:43 PM, Howard Chu wrote:
Alexander 'Leo' Bergolth wrote:
Are there any plans to extend the dynlist overlays dynamic group feature to return not the DNs of the matched entries but an attribute of the entries?
As Andreas already posted, this has been a dynlist feature for a long time.
As explained in my previous mail, this functionality isn't covered yet for posixGroups memberUid style setups.
Could this extension be easily implemented?
Is there currently any workaround?
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.
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?
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?
Cheers, --leo