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@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/ _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users