Nathan Kinder wrote: > On 05/18/2010 09:50 AM, Rich Megginson wrote: > >> Nathan Kinder wrote: >> >> >>> On 05/18/2010 08:48 AM, Rich Megginson wrote: >>> >>> >>> >>>> Roberto Polli wrote: >>>> >>>> >>>> >>>> >>>>> On Tuesday 18 May 2010 16:28:48 Rich Megginson wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> ...I would start with the member of plugin code. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I'll take a look. >>>>> >>>>> do you think it will be better to extend memberof plugin or play directly into >>>>> the group entry >>>>> >>>>> >>>>> >>>>> >>>>> >>>> not sure what you mean by "play directly into the group entry" >>>> >>>> You might be able to do this by extending the member of plugin. With >>>> dynamic groups, you will probably still want to have the member of >>>> functionality, and it should work with member of when using static >>>> groups too. >>>> >>>> >>>> >>>> >>> The difficult part is going to be making the memberOf plug-in work with >>> dynamic groups. >>> >>> Is the idea to have the "member" attributes be virtual attributes that >>> are generated on the fly when a client performs a search for the group? >>> >>> >>> >> That might work, as long as you don't have to support searches in >> dynamic group entries like (member=someUserDN) >> >> >>> I'm not quite sure how this approach can be made to work with the >>> memberOf plug-in since it is triggered by write operations that affect >>> group membership. >>> >>> >>> >> However it works, it should work with memberof and generate memberof >> attributes in user entries, whether the group is static or dynamic. >> >> I suppose it would work a little like persistent search - on every >> update operation (not just group updates, but all updates), it would >> have to scan every dynamic group entry, looking at the pre-update entry >> and the post-update entry. If the pre-update entry does not match the >> dynamic group definition, but the post-update entry does match the >> dynamic group definition, then you add the DN of that entry to the >> member attribute in the group entry. If the pre-update matches but not >> the post-update, you have to remove the member. >> >> > I think this approach is best, assuming you are saying that the member > of value is actually added to the group entry (not a virtual > attribute). Yes, a real attribute, not virtual. The member attribute in the dynamic group entry would be a real attribute. > This could be implemented as a new post-op plug-in. If > plug-in ordering is used to have this new plug-in invoked before the > memberOf plug-in, then the memberOf feature should work fine. > Ok. >>>> static group: >>>> cn=groupA,.... >>>> objectclass: groupOfNames >>>> member: uid=foo,...<- static member - must add/delete manually >>>> member: uid=bar,...<- static member - must add/delete manually >>>> >>>> dynamic group: >>>> cn=groupB,... >>>> objectclass: groupOfDynNames<- need new objectclass that has both url >>>> specifier attribute and member attribute >>>> memberURL: ldap:///ou=people?sub?(ou=myorg)<- specifies which entries >>>> are members >>>> member: uid=foo,...<- dynamic member - plugin adds this >>>> member: uid=bar,...<- dynamic member - plugin adds this >>>> >>>> uid=foo,ou=people,... >>>> ou: myorg >>>> memberof: cn=groupA,....<- plugin adds this >>>> memberof: cn=groupB,....<- plugin adds this >>>> >>>> >>>> >>>> >>>>> thx+Peace, >>>>> R. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> 389 users mailing list >>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>> >>>> >>>> >>>> >>> -- >>> 389 users mailing list >>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >>> >>> >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
