[Freeipa-devel] Status/Question about User life cycle
thierry bordaz
tbordaz at redhat.com
Fri May 23 07:34:15 UTC 2014
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'.
>> 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'.
>
>> 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. Before the approval, the ipaUniqueID
is 'generate' and after it is a valid account.
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
>
> 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' ?
>
> Martin
More information about the Freeipa-devel
mailing list