[Date Prev][Date Next]
Re: dynlist overlay feature request
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
> 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 <group-oc> <URL-ad> [<member-ad>] [<result-ad>]
> 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
>> ... 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?
e-mail ::: Leo.Bergolth (at) wu.ac.at
fax ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria