Hi all,
I'd like to start a patch on dynamic group expansion, but dunno where to start.
Can you point me?
Should be something like reusing VLV code?
Thx+Peace, R-
Roberto Polli wrote:
Hi all,
I'd like to start a patch on dynamic group expansion, but dunno where to start.
Can you point me?
Should be something like reusing VLV code?
No, probably not VLV. I would start with the member of plugin code. Member of already does something similar to dynamic group expansion, but in the opposite direction. Source (git) information - http://directory.fedoraproject.org/wiki/Developers Git repo - http://git.fedorahosted.org/git/?p=389/ds.git;a=summary member of plugin - http://git.fedorahosted.org/git/?p=389/ds.git;a=tree;f=ldap/servers/plugins/...
Thx+Peace, R-
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
thx+Peace, R.
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.
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.
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? 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.
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
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.
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
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@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
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
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
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@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
On Tuesday 01 June 2010 20:38:48 Nathan Kinder wrote:
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.
added https://bugzilla.redhat.com/show_bug.cgi?id=618988 maybe better move discussion there or in the wiki.
Let me know+Peace, R:
389-users@lists.fedoraproject.org
-
Nathan Kinder -
Rich Megginson -
Roberto Polli