[Freeipa-devel] [RFE] Support for automember rebuild membership

[Martin Kosek]

On 09/12/2013 09:46 PM, Dmitri Pal wrote:
> 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?

ipa automember-show --type=hostgroup webservers
ipa automember-add --type=group devel

> 
>>
>> I think I'd drop the -membership part though, automember-rebuild is
>> sufficient. For user/host perhaps user-automember-rebuild.

+1, this is shorter.

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

Hmm, I must say I do not like the reset option very much too. Someone may not
realize what is the real scope or meaning of the option and find out all his
membership is gone.

Nothing prevents Administrator to explicitly remove all user membership before
moving to other role/function. It is a matter of 3 clicks in Web UI.

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

Still not convinced this the way we should go and that life-cycle management
would require rinsing all membership data.

Martin