[Freeipa-devel] Status/Question about User life cycle
Dmitri Pal
dpal at redhat.com
Wed May 21 20:00:01 UTC 2014
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
This is just an example. Pick the commands the way you see fit better
but IMO CLI should provide the whole cycle of moving entries around and
it should be very unambiguous what each means.
Please do not forget to update the design based on the results of this
discussion.
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> user-add command does a lot of additional processing besides just
>>>>>>>> taking the
>>>>>>>> values and writing them to LDAP. It fills the UID and GID, sets
>>>>>>>> the
>>>>>>>> non-filled
>>>>>>>> default attributes like Kerberos attributes, adds user as a
>>>>>>>> member of
>>>>>>>> ipausers
>>>>>>>> groups - all that stuff. The same procedures should be also
>>>>>>>> done with
>>>>>>>> the user
>>>>>>>> from stage. This is why I proposed to augment user-add.
>>>>>>>>
>>>>>>>> If there is a better way, I am open to it.
>>>>>>>
>>>>>>> That's not a very good reason to bring in all the CLI/API options,
>>>>>>> most
>>>>>>> importantly from the user's perspective. Also you'd have to write
>>>>>>> extra
>>>>>>> code to e.g. check the user didn't use the other options, and that
>>>>>>> tends
>>>>>>> to get messy quite fast.
>>>>>>>
>>>>>>> The common processing should be split out into functions* that both
>>>>>>> commands would call.
>>>>>>> (Or methods of the `user` object, which may turn out to be more
>>>>>>> practical.)
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
More information about the Freeipa-devel
mailing list