[Freeipa-users] Auto membership plugin

[Dmitri Pal]

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?
Will  newly added rule be respected right away?

You probably want to have an enable/disable flag on the rule to give
some staging capability to the admin.


>>
>>>>
>>>> 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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/