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(a)lists.fedoraproject.org
>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>>
>>>
>>>
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users