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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
All the rest seems fine so far.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
