Re: [389-users] dynamic group expansion: writing a patch...
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
Re: [389-users] dynamic group expansion: writing a patch...
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 > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] dynamic group expansion: writing a patch...
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 > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] dynamic group expansion: writing a patch...
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 > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] dynamic group expansion: writing a patch...
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. > > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] dynamic group expansion: writing a patch...
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/memberof > Thx+Peace, > R- > > > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
