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). 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. >>> 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 at lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >>> >>> >> -- >> 389 users mailing list >> 389-users at lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> > -- > 389 users mailing list > 389-users at lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users >
