[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: dynlist overlay feature request

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.


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

Probably easy. Patches are always welcome.

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?

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.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/