Dmitri Pal wrote:
On 09/12/2013 01:59 PM, Ana Krivokapic wrote:
The design document for $SUBJECT can be found at:
Thoughts, comments, questions welcome.
The names for commands are a bit long.
I am not sure we need all the commands.
$ ipa automember-rebuild-membership --type=group
I do not understand why type is "group".
If you say that all the user group memberships will be rebuilt then the
type is "user".
But then you can really not have the command at all and use just:
If in future we have other objects we would add another command for
ipa user-automembership --update
will update group memberships for all users, or may be it should be
ipa user-automembership --update *
(I do not know what are the rules in the framework, we should follow them)
ipa user-automember --update LOGIN
will update group memberships for a specific user
Now we need to differentiate --update and --reset
--update should update group membership based on the existing filters,
i.e. based on the automember plugin configuration only add missing
memberships (if any)
--reset should clean existing memberships and rebuild them based only
the default groups + automember. It should pretty much mean "make group
memberships as if the user was just added".
Makes sense or I am missing something?
Her design is consistent with the current automember commands.
I think I'd drop the -membership part though, automember-rebuild is
sufficient. For user/host perhaps user-automember-rebuild.
I disagree with your update/reset suggestions.
Unless a user is doing ALL of its group/hostgroup management via
automember rules then the reset command will almost always do the wrong
thing. This could raise all sorts of strange permission issues too, as
we'd have to use the currently bound user to do the group membership
removal. We can separately add delegation to create an automember
rebuild task, and that runs as DM IIRC.
I think I prefer rebuild to update, though update is probably a better
description to what is happening under the hood.
Freeipa-devel mailing list