[Freeipa-devel] Status/Question about User life cycle
Simo Sorce
simo at redhat.com
Thu May 22 17:21:26 UTC 2014
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.
--
Simo Sorce * Red Hat, Inc * New York
More information about the Freeipa-devel
mailing list