[Freeipa-devel] Status/Question about User life cycle
thierry bordaz
tbordaz at redhat.com
Fri May 23 08:22:54 UTC 2014
On 05/23/2014 10:04 AM, Martin Kosek wrote:
> On 05/23/2014 09:34 AM, thierry bordaz wrote:
>> On 05/23/2014 08:29 AM, Martin Kosek wrote:
>>> On 05/22/2014 05:52 PM, thierry bordaz wrote:
>>>> On 05/22/2014 04:38 PM, Martin Kosek wrote:
>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote:
>>>>>> On 05/21/2014 10:00 PM, Dmitri Pal wrote:
>>>>>>> On 05/19/2014 10:45 AM, thierry bordaz wrote:
>>>>>>>> On 05/19/2014 04:44 PM, Jan Cholasta wrote:
>>>>>>>>> On 19.5.2014 16:34, thierry bordaz wrote:
>>>>>>>>>> On 05/19/2014 04:22 PM, Jan Cholasta wrote:
>>>>>>>>>>> On 19.5.2014 16:03, thierry bordaz wrote:
>>>>>>>>>>>> On 05/19/2014 03:54 PM, Jan Cholasta wrote:
>>>>>>>>>>>>> On 19.5.2014 15:19, Petr Viktorin wrote:
>>>>>>>>>>>>>> Hello list,
>>>>>>>>>>>>>> Here's a conversation that started internally. I'm making it
>>>>>>>>>>>>>> public.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 05/19/2014 01:00 PM, Martin Kosek wrote:
>>>>>>>>>>>>>>> On 05/19/2014 12:46 PM, Petr Viktorin wrote:
>>>>>>>>>>>>>>>> On 05/19/2014 08:25 AM, Martin Kosek wrote:
>>>>>>>>>>>>>>>>> On 05/19/2014 08:24 AM, Martin Kosek wrote:
>>>>>>>>>>>>>>>>>> On 05/16/2014 04:48 PM, thierry bordaz wrote:
>>>>>>>>>>>>>>>>>>> Hello Martin,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I am getting familiar with the freeipa CLI code and
>>>>>>>>>>>>>>>>>>> started
>>>>>>>>>>>>>>>>>>> implemented '--to-stage' and '--from-stage'. This
>>>>>>>>>>>>>>>>>>> really an
>>>>>>>>>>>>>>>>>>> impressive set of code :-)
>>>>>>>>>>>>>>>>>> Great! :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I completed 'to-stage' and testing '--from-stage'.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I have a question regarding the '--from-stage' syntax.
>>>>>>>>>>>>>>>>>>> 'uid'
>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>> mandatory argument to 'user-add' subcommand. In the
>>>>>>>>>>>>>>>>>>> design the
>>>>>>>>>>>>>>>>>>> '--from-stage' option is described with:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ipa user-add --from-stage=tuser
>>>>>>>>>>>>>> Note, the design is here:
>>>>>>>>>>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But as 'uid' is mandatory the command should rather be
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ipa user-add tuser --from-stage=tuser
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In that case the option value for '--from-stage' is not
>>>>>>>>>>>>>>>>>>> required and
>>>>>>>>>>>>>>>>>>> the command should be
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ipa user-add tuser --from-stage
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Is that ok if I implement the command like above or did I
>>>>>>>>>>>>>>>>>>> miss
>>>>>>>>>>>>>>>>>>> something ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>>>> thierry
>>>>>>>>>>>>>>>>>> Hmm, no, I think you are right. We can change --from-stage to
>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>> Bool
>>>>>>>>>>>>>>>>>> parameter. When it is true, it'd mean that get_dn or
>>>>>>>>>>>>>>>>>> pre-callback
>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>> retrieve the record from stage and use all it's attributes (and
>>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>> standard
>>>>>>>>>>>>>>>>>> default attributes values on top of that).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also CC-ing Petr Viktorin for reference.
>>>>>>>>>>>>>>>> This operation can't change the user's attributes, can it?
>>>>>>>>>>>>>>>> I.e., we
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> support something like:
>>>>>>>>>>>>>>>> ipa user-add tuser --from-stage --phone=123456789
>>>>>>>>>>>>>>>> --email=newemail at example.com
>>>>>>>>>>>>>>>> If this is the case, what's the reason for using user-add for
>>>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>>> Wouldn't it
>>>>>>>>>>>>>>>> be better to make this a separate command, say:
>>>>>>>>>>>>>>>> ipa user-activate tuser
>>>>>>>>>>>>>>>> ipa user-activate tuser --from-deleted
>>>>>>>>>>>>>>>> ipa user-activate tuser --from-deleted --to-staged
>>>>>>>>>>>>> +1, I would even go as far as having separate commands for staged
>>>>>>>>>>>>> and
>>>>>>>>>>>>> deleted users, e.g.:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ipa user-unstage tuser
>>>>>>>>>>>>> ipa user-undelete tuser
>>>>>>>>>>>>> ipa user-undelete tuser --to-staged
>>>>>>>>>>>> A deleted entry has already been active so it contains already set
>>>>>>>>>>>> attributes while the pure staged entries are "almost" empty boxes.
>>>>>>>>>>>> But
>>>>>>>>>>>> from an administrator point of view, both staged/deleted entries are
>>>>>>>>>>>> inactive. What would be the advantages of two separated commands ?
>>>>>>>>>>> You just said it yourself: activating/unstaging a user is quite
>>>>>>>>>>> different from undeleting a user. Cramming multiple different
>>>>>>>>>>> operations in a single command is bad design IMHO.
>>>>>>>>>> Ok I understand.
>>>>>>>>>> I believe that deleted entries and staged entries will be in the same
>>>>>>>>>> container (provisioning).
>>>>>>>>> The design page mentions "cn=staged
>>>>>>>>> users,cn=accounts,cn=provisioning,$SUFFIX" and "cn=deleted
>>>>>>>>> users,cn=accounts,cn=provisioning,$SUFFIX", which are two different
>>>>>>>>> containers.
>>>>>>>> Oppsss.. Sorry for the confusion :-[
>>>>>>>>>> So we may have at least those two possibilities:
>>>>>>>>>>
>>>>>>>>>> * ipa user-activate tuser [--from-staging|--from-delete]
>>>>>>>>>> * ipa user-unstage tuser
>>>>>>>>>> ipa user-undelete tuser
>>>>>>> I like the idea of different verbs for different hives.
>>>>>>> Something like:
>>>>>>>
>>>>>>> Adding directly to stage via CLI: ipa user-stage
>>>>>>> Removing from stage: user-unstage (user is gone)
>>>>>>> Stage to Main -> activate; <- deactivate
>>>>>>> Main to delete -> del; <-restore or undelete
>>>>>>> Delete to stage -> I think we can use ipa user-stage command with
>>>>>>> --deleted=user or similar
>>>>>> To be honest, I don't like this idea.
>>>>>> Too many names are confusing, if we can find a consistent option to cut the
>>>>>> number of names down we should do it.
>>>>>> IMO This is the worst part of Git:
>>>>>> http://assets.osteele.com/images/2008/git-transport.png . We can do better.
>>>>>>
>>>>>> Another good thing would be if options did not affect the applicability of
>>>>>> other options (too much). For example in your proposal there'd be something
>>>>>> like:
>>>>>> ipa user-stage tuser --first=abc --last=xyz --phone=123 ......
>>>>>> ipa user-stage --deleted=tuser # <no attribute options allowed>
>>>>>> We should avoid this, if only for the reason that it makes the help text
>>>>>> confusing.
>>>>>>
>>>>>>
>>>>>> My proposal would be that the move commands use the verb for the target
>>>>>> and an
>>>>>> option for the source, and add/mod use an option for the container:
>>>>>>
>>>>>> 1) adding a new user
>>>>>> (to active) ipa user-add tuser ...
>>>>>> (to stage) ipa user-add tuser --staged ...
>>>>>> (to deleted) ipa user-add tuser --deleted ... (*)
>>>>>>
>>>>>> 2) moving to main
>>>>>> (from stage) ipa user-activate tuser (**)
>>>>>> (from del) ipa user-activate tuser --deleted
>>>>>>
>>>>>> 3) moving to deleted
>>>>>> (from active) ipa user-del tuser
>>>>>> (from stage) ipa user-del tuser --staged
>>>>>>
>>>>>> 4) moving to stage
>>>>>> (from active) ipa user-stage tuser
>>>>>> (from del) ipa user-stage tuser --deleted
>>>>>>
>>>>>> 5) modifying
>>>>>> (in active) ipa user-mod tuser ...
>>>>>> (in stage) ipa user-mod tuser --staged ...
>>>>>> (in del) ipa user-mod tuser --deleted ...
>>>>>>
>>>>>> Five commands (two of which are user-specific), plus two fairly consistent
>>>>>> options.
>>>>>>
>>>>>> If the delete container isn't configured, the --deleted option is illegal and
>>>>>> `user-del` deletes permanently.
>>>>>>
>>>>>>
>>>>>> (*) may be useful in some situations?
>>>>> I personally cannot imagine such situation - I would not add this command. If
>>>>> somebody needs that, he can workaround with
>>>>>
>>>>> ipa user-add tuser --staged
>>>>> ipa user-del tuser --staged
>>>>>
>>>>> ... and report us the use case when it's needed. But I general, Petr's
>>>>> proposal
>>>>> makes sense to me, I would go for it. (and update the design as Dmitri
>>>>> correctly proposed).
>>>>>
>>>>> Martin
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-devel mailing list
>>>>> Freeipa-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>> Hello,
>>>>
>>>> I will update the design following Petr proposal. Great one !
>>>> However I was thinking to a sligthly different proposal. For
>>>> example if we have 3 states: staging, active, inactive.
>>> I personally think that inactive state may be confusing. Is inactive deleted
>>> user? Or staged user? Or active disabled user (user-disable command)? Inactive
>>> state would have too many meanings. The previously proposed states active,
>>> staging and deleted sounds clearer to me.
>> Correct. Inactive is confusing and I prefer 'disabled'.
>> For me a 'disabled' used is a user that has been 'active' (should I say
>> 'enabled'). That means he/she has a uidNumber/guidNUmber/ipaUniqueiD set... ,
>> in addition it is in a dedicated container and likely 'nsaccountlock: yes'.
> In terms of FreeIPA vocabulary, disabled user is a user in an active user
> container, but switch to disabled (nsaccountlock is yes). It can be easile
> enabled with "ipa user-enable" command. I.e. "disabled user" term is already
> taken and actively user for other state.
>
>>>> 1) adding a user
>>>>
>>>> (...to active) ipa user-add# ( after the command
>>>> ipaUniqueID=<final value>)
>>>> (... to staging) ipa user-add --stage# (after the command
>>>> ipaUniqueID=generate)
>>>>
>>>> So here we can not add a user directly into inactive state
>>> If by inactive you mean deleted, then yes.
>> Yes I was meaning 'inactive' as 'deleted' in Petr proposal.
>> I do not like very much the word 'deleted' because in term of LDAP it has a
>> different meaning.
>> In term of User life cycle, I have a feeling that 'delete' is a final state, we
>> can not return from 'delete'. This is why I prefered 'inactive' or now 'disabled'.
> Ok, I see your point in the meaning from LDAP POV. However, we cannot use
> 'inactive' as it is confusing and we cannot use 'disabled' as it is already
> used in other scenario. That leaves us with 'delete' state which IMO is
> consistent in FreeIPA vocabulary - user is moved to *deleted users* container
> with user-*del* command.
Ok I understand. 'delete' is the right choice, I vote for it and will
update the design.
>
>>>> 2) activating the user
>>>>
>>>> (staging to active) ipa user-activate# (after the command
>>>> ipaUniqueID=<final value>)
>>>> (inactive to active) ipa user-activate --inactive# (after the
>>>> command ipaUniqueID=<final value>)
>>> --inactive -> --deleted
>>>
>>>> 3) inactivate the user
>>>>
>>>> (active to inactive) ipa user-inactivate# (after the command
>>>> ipaUniqueID=<final value>)
>>>>
>>>> Here there is no possibility to move back an active entry to
>>>> staging, because in staging
>>>> the entries do not have ipaUniqueID set
>>> Why is having ipaUniqueID attribute a problem for a staged user?
>> My understanding is that an account moves from 'staging' to 'active' when we
>> receive a formal approval.
> Right.
Here what is not clear to me is what is this approval.
Would it be a user granted the autorization to run 'ipa user-activate',
or an attribute set in the 'staging' entry (a task could them 'activate'
all the staging entries which receive the approval), or a kind of
'approved group' that contains the DN of approved entries, or...
>
>> Before the approval, the ipaUniqueID is 'generate'
>> and after it is a valid account.
> Right.
>
>> For example, the user attribute should be:
>>
>> Staging Active Disabled
>> ipaUniqueID: generate ipaUniqueID: abc-def-ghi-jkl ipaUniqueID:
>> abc-def-ghi-jkl
>> uidNumber: -1 uidNumber: 1234uidNumber: 1234
>> gidNumber: -1 gidNumber: 1234gidNumber: 1234
>> <no memberof> attribute memberof: * <no
>> memberof>:
>> nsaccountlock: true nsaccountlock: false
>> nsaccountlock: true
> Nice overview, we may even add it to design. Looks correct to me, though I
> still do not undestand practical reasons why a user moved from active to staged
> container cannot have ipaUniqueID already generated.
I think an advantage of having 'active'->'staging' is that the customer
has not to understand some constraint of the state machine. Everything
is allowed staging<-->active<-->delete.
On the opposite I believe
* the entries in staging will not have the same "properties". Some may
have ipaUniqueID/uidNumber set, some others may not.
* What would be the real difference between 'staging' and 'delete'. It
looks like the same state.
>
>>> The command to "inactivate" the user is user-del.
>>>
>>>> 4) modify the user
>>>>
>>>> (from active) ipa user-mod # (after the command
>>>> ipaUniqueID=<final value>)
>>>> (from inactive) ipa user-mod --inactive# (after the
>>>> command ipaUniqueID=<final value>)
>>> --inactive -> --deleted
>>>
>>>> (from staging) ipa user-mod --stage # (after the command
>>>> ipaUniqueID=generate)
>>>>
>>>>
>>>> 5) delete user
>>>>
>>>> (staging to delete) ipa user-del
>>>> (inactive to delete) ipa user-del --inactive
>>>>
>>>> Here the entries are definitely removed
>>> I would stick to original proposal:
>>>
>>> (from active) ipa user-del tuser
>>> (from stage) ipa user-del tuser --staged
>> Is this command to move entry from active/staging into delete container.
>> How to delete definitely an entry ? with a option like '--remove' ?
> The move from active users to deleted users container was planned to be done by
> a plugin so that a simple ldapdelete can be called and the user is saved:
>
> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User
>
> To delete permanently, we could offer
>
> ipa user-del tuser --deleted
>
> command. (Or do not offer the command at all and force admins to use ldapdelete
> to *permanently* delete the account). Missing this API should not be a problem
> as in most small-scale deployments, advanced user life-cycle will not be enabled.
>
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140523/66e85147/attachment.htm>
More information about the Freeipa-devel
mailing list