[Freeipa-devel] Status/Question about User life cycle
Martin Kosek
mkosek at redhat.com
Fri May 23 06:29:01 UTC 2014
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.
> 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.
>
> 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?
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
Martin
More information about the Freeipa-devel
mailing list