On 05/31/2010 02:05 AM, Roberto Polli wrote: > Hi all, > > I'll try to summarize: > 1 - we like dynamic group expansion (memberURL is an ldap URI) > 2 - ldapsearch -b GROUPDN "uniqueMember=*" retrieves both static and dynamic > members > 2.1- the forementioned search should retrieve nested group members too > 3 - (wish) memberOf plugin should dynamically set the memberOf attribute in > underlying entries > 3.1 * if memberOf is a virtual attribute, it's impossible to use it in > Searches (eg this won't work #ldapsearch "memberof=GROUPDN" ) > 3.2 * memberOf should be "real" > 3.3 * we need a listener on each Update to > 3.3.1 * rescan all groups > 3.3.2 * update the memberOf attribute > There are likely some things you can do here to optimize for updates. One idea would be to maintain an in-memory cache of dynamic group filters that are present. You would have to scan for these groups at server startup to populate the cache and maintain it whenever a group filter is modified/added/deleted. When an entry is updated, you can use the group filter cache to quickly determine if a change to an entry affects it's group membership instead of searching for all of the groups each time. There may be better ideas than the above, but the cache idea was just a quick thought that may help. > my opinion: > - the dynamic memberOf plugin adds a lot of overhead on Update (that's no > good) > It is true that this adds overhead when an update to grouping is made, but that is much better than taking a hit at search time as you would with a dynamic attribute. The assumption made in a case like this is that a search for group membership happens much more often than an update to group membership. We want to optimize for the more common case. > - its complexity grows with #groups and #users, so should be limited in some > ways > Nested groups also add quite a bit of complexity if you want to support them. The memberOf plug-in already deals with nested groups. We decided to not add any sort of limiting based off of number of users/groups when writing the memberOf plug-in. > - 2 is a priority as that ldapsearch is expected to retrieve all group > members > > another interesting thread is about group naming. > in the sun mailgroup objectclass you can set an email address as a group name > (eg. groups are mailinglist, with static or dynamic members). > > LetMeKnow+Peace, > R. > > > On Tuesday 18 May 2010 19:40:08 Rich Megginson wrote: > >> 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 >> >> > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
