[Freeipa-users] Auto membership plugin

[Nathan Kinder]

On 03/30/2011 08:06 AM, Dmitri Pal wrote:
> On 03/30/2011 10:43 AM, Nathan Kinder wrote:
>> 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.
> But can it be an ordinary user controlled by CLI or it is a DM?
I believe this could be done by a normal (admin) user if the ACI allows it.
> Will  newly added rule be respected right away?
Yes, changes to the definition entry would be respected right away.
> You probably want to have an enable/disable flag on the rule to give
> some staging capability to the admin.
Makes sense.
>
>>>>> 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
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
> All the rest seems fine so far.
>