[Freeipa-devel] Status/Question about User life cycle
thierry bordaz
tbordaz at redhat.com
Fri May 23 15:18:18 UTC 2014
On 05/23/2014 05:03 PM, Simo Sorce wrote:
> On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote:
>> On 05/22/2014 07:21 PM, Simo Sorce wrote:
>>> On Thu, 2014-05-22 at 17:52 +0200, 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.
>>>> 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
>>>>
>>>> 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>)
>>>>
>>>> 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
>>> Do we ever want to allow to move a user from active to staging ?
>>>
>>> I can't find a case where my answer is yes.
>>>
>>> From my POV a user once it leaves staging is either active or deleted,
>>> in my mind there is no reason ever to move a user into staging.
>>>
>>> In what case does it make sense ?
>>>
>>> Simo.
>>>
>> Hi Simo,
>>
>> When moving an entry 'staging' -> 'active', some attributes are set (at
>> least uidNumber,gidNumber, ipaUniqueId). In my mind, those attributes
>> are set for ever even if later the entry is moved 'active'->'deleted'.
>> One can imagine that an administrator is not "happy" with the values
>> computed. For example, he would prefer uidNumber to be computed from an
>> other range.
> No, this is not in play. The reason we have been requested the 'deleted'
> area is for regulatory purposes where the administrators are *mandated*
> to keep users intact *especially* for uniquely identifying IDs.
Ok I agree.
Now I was thinking to an other reason an administrator would appreciate
'active' -> 'stage'.
The move 'stage' -> 'active' requires an approval. Then the policy
changes and some active users now needs an additional approval.
It would be a possibility to return the active user to the staging area.
>
>> For that, moving back the entry from 'active' -> 'staging' would be an
>> option (if those attributes are 'reset').
> No, if the admins does not like uid numbers or unique ids, what it
> really means is that the admin just wanted to delete the original user
> and recreate a completely new one with the same name. In that case the
> admin should do just that.
>
> In the rare case when the admin really want to delete-and-preserve, and
> later on change some uniquely identifying attributes he has already 2
> ways:
> 1) 'un'delete the user and *then* change the ids, simple,
> straightforward.
> 2) use ldamodify to change the entry while in the deleted area.
>
>> I do not know if it is a valid use case but IMHO I would prefere he
>> moves the entry 'active'->'delete' then delete the entry and recreate a
>> new one.
> You can do it, see above.
>
> I think the only operations allowed should be the following:
>
> 1. add user in staging area
> 2. un-stage user
> 3. move user to delete area
> 4. un-delete user
> In all cases users in the staging or deleted area cannot be modified via
> ipa commands
>
> I do not think any other operation should be 'aided' by ipa tools unless
> there is overwhelming request motivated by reasonable work-flows to do
> anything else. If there is this request we can add more in the future.
> Admins that need to change stuff can do so when the user is 'live', or
> can use ldapmodify and directly access the entries in LDAP.
>
> Simo.
>
More information about the Freeipa-devel
mailing list