[389-users] dynamic group expansion: writing a patch...

[Rich Megginson]

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