On 09/12/2013 03:23 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 09/12/2013 01:59 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> The design document for $SUBJECT can be found at: >>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>> >>> Related tickets: >>> https://fedorahosted.org/freeipa/ticket/3752 >>> https://fedorahosted.org/freeipa/ticket/3928 >>> >>> 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: >> >> ipa user-automembership >> and >> ipa host-automembership >> >> If in future we have other objects we would add another command for >> those objects. >> >> so >> 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.
What are they? > > 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. We can have a separate RFE for reset but I think it would make sense for the cases when user moves from one org unit to another or moves from intern to full time. In this case I expect something like 1) Update user "class" attribute 2) Run automember reset > > 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. No it is need for the case when you need to get to the state as if this user was just added without actually deleting and re-addign the user. Use case like I mentioned above are examples. > 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 agree that this would probably be a different task, like delete and rebuild. This I think we should create a separate ticket for reset and file and RFE with DS. It is not urgent but will become handy when we start supporting user lifecycle management and provisioning > > I think I prefer rebuild to update, though update is probably a better > description to what is happening under the hood. I do not have a preference. > > rob -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
