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
my opinion: - the dynamic memberOf plugin adds a lot of overhead on Update (that's no good) - its complexity grows with #groups and #users, so should be limited in some ways - 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users