[Freeipa-users] Auto membership plugin

[Nathan Kinder]

On 03/30/2011 07:34 AM, Rob Crittenden wrote:
> Nathan Kinder wrote:
>> On 03/30/2011 06:32 AM, Rob Crittenden wrote:
>>> Dmitri Pal wrote:
>>>> Hello,
>>>>
>>>> Please find the design for the auto membership plugin:
>>>> https://fedorahosted.org/freeipa/ticket/753
>>>> Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design
>>>>
>>>> I have some comments and questions:
>>>> 1) Is the AND functionality for inclusion criteria required?
>>>> 2) How the attributes are escaped? Do they need to? Probably there 
>>>> will
>>>> be cases when they should be escaped
>>>> 3) Parsing pairs in the value as a bit of overhead. I wonder if 
>>>> there is
>>>> any way to avoid it?
>>>> 4) I have concerns about the UI and CLI, do you see any good ways to
>>>> mange such entries?
>>>>
>>>
>>> Because the configuration is stored in cn=config we would need to bind
>>> as DM to be able to manage it (unless we want to make an exception and
>>> allow writing here. Could a bad config could prevent 389-ds from
>>> starting).
>> No. Similar to a bad DNA or managed entry setup, an error would be
>> logged and the bad config entry would be skipped.
>
> Ok, great. But we would still need to carve out an exception for allow 
> people to write in cn=config, right?
Yes, someone will need to write the config entry, so that will need to 
be allowed.
>
>>>
>>> I assume a restart would be needed whenever a configuration change is
>>> made?
>> Only enabling the plug-in at the top level, which we could enabled by
>> default. The definition entry changes would be dynamic.
>>>
>>> What happens if the target in automembertargetgroup gets removed?
>> I still need to fill in the "Behavior" section in the design doc, but
>> this plug-in is not a referential integrity plug-in. It simply monitors
>> ADD operations and updates the membership accordingly. Nothing is done
>> for MOD, DEL, or MODRDN operations.
>
> I was thinking more what happens if the targetgroup is deleted and a 
> new user is added? Will this result in a failed modify or would the 
> user get a member pointer to a non-existent entry, or something else?
That's an interesting case.  It would result in a failed modify, as we 
would not be able to update the non-existent group entry.  This plug-in 
does not add a pointer to the user entry (that's done by the memberOf 
plug-in if it is desired).  The usre entry would still be consistent, 
but you would have an error in the errors log about the failed modify.
>
> rob