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@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
>
--
Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
"Il seguente messaggio contiene informazioni riservate. Qualora questo
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto
della legge in materia di protezione dei dati personali."
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
