[Freeipa-devel] Status/Question about User life cycle

thierry bordaz tbordaz at redhat.com
Mon May 19 14:45:11 UTC 2014


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
>>
>>>
>>>>
>>>>
>>>>>
>>>>>>>
>>>>>>> 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.)
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>




More information about the Freeipa-devel mailing list