Martin Kosek wrote:
> On 05/23/2014 07:48 AM, Jan Cholasta wrote:
>> On 22.5.2014 19:27, Simo Sorce wrote:
>>> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote:
>>>> On 05/21/2014 10:11 PM, Dmitri Pal wrote:
>>>>> On 05/21/2014 03:06 PM, Martin Kosek wrote:
>>>>>> On 05/21/2014 08:14 PM, Simo Sorce wrote:
>>>>>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>>       Thanks for all these detailed descriptions.
>>>>>>>>       Just to be sure to be on the same page, here is my understanding 
>>>>>>>> of
>>>>>>>>       the provisioning templates and placeholder definitions. An
>>>>>>>>       administrator can provide a provisioning template. I suppose it
>>>>>>>>       would be a file containing a lines of placeholder definitions.
>>>>>>>>
>>>>>>>>         * Where is located the template file ? Is there a standard
>>>>>>>>           repository where templates are put ? (somewhere under
>>>>>>>> /etc/ipa/* ?)
>>>>>>>
>>>>>>> FreeIPA is a multi-master system, a file stored in a file would be
>>>>>>> extremely cumbersome to use as it would require the admin to manually
>>>>>>> copy it for every new replica and then keep it in sync.
>>>>>>> It would also make it hard to change 'on-line'.
>>>>>>>
>>>>>>> Placeholders should be defined in an object similar to
>>>>>>> cn=ipaConfig,cn=etc,$suffix
>>>>>>>
>>>>>>>>         * Is there an already defined syntax for the provisionning
>>>>>>>>           template. ('$' is separator attr/value, %{<attr>} is 
>>>>>>>> substitute
>>>>>>>>           pattern...). If not, is it possible to user ':<space> ' as
>>>>>>>>           separator ?
>>>>>>>
>>>>>>> Using initial and final ? like in Martin's example doesn't work ?
>>>>>>>
>>>>>>>>         * What is the priority. The user can provide the 
>>>>>>>> 'homeDirectory'
>>>>>>>>           through different methods. Is it ok to use the following 
>>>>>>>> order:
>>>>>>>>             o the CLI option
>>>>>>>>             o the provisionning template
>>>>>>>>             o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX)
>>>>>>>>
>>>>>>>>       For example, if it exists the provisioning template:
>>>>>>>>       /etc/ipa/provisioning/shell-user.template
>>>>>>>>
>>>>>>>>           roomnumber$-2
>>>>>>>>           homeDirectory$/home/net/shell-%{uid}
>>>>>>>>           loginShell$?shell-plugin-autogenerate?
>>>>>>>
>>>>>>> I do not understand this, we are not building a templating engine here,
>>>>>>> you only have 2 options:
>>>>>>> 1) a required (MUST) attribute has an explicit value
>>>>>>> 2) a require (MUST) attribute has a placeholder value
>>>>>>>
>>>>>>> the placeholder value is fixed per type, and what it is substituted with
>>>>>>> uses the same rules as the current code uses to autogenerate values.
>>>>>>>
>>>>>>>>       the command: ipa user-add tuser
>>>>>>>>       --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a
>>>>>>>>       staging entry:
>>>>>>>>
>>>>>>>>       dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
>>>>>>>>       ...
>>>>>>>>       roomNumber: 1234
>>>>>>>>       homeDirectory: /tmp/tuser
>>>>>>>>       loginShell: shell-plugin-autogenerate
>>>>>>>
>>>>>>> loginShell is a MAY attribute, not a MUST attribute, so nothing should
>>>>>>> be stored at all in the staged entry unless explicitly provided for by
>>>>>>> the admin.
>>>>>>>
>>>>>>>>       Then a private DS plugin (catching shell-plugin-autogenerate)
>>>>>>>>       generate the loginShell value when the entry becomes active.
>>>>>>>>
>>>>>>>>
>>>>>>>>       the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage 
>>>>>>>> would
>>>>>>>>       create a staging entry:
>>>>>>>>
>>>>>>>>       dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
>>>>>>>>       ...
>>>>>>>>       roomNumber: -2
>>>>>>>>       homeDirectory: /tmp/tuser
>>>>>>>>       loginShell: shell-plugin-autogenerate
>>>>>>>
>>>>>>> roomNumber is also a MAY, so what would cause it to be set at -2, and
>>>>>>> why ?
>>>>>>>
>>>>>>>>       the command: ipa user-add tuser --to-stage would create a staging
>>>>>>>> entry:
>>>>>>>>
>>>>>>>>       dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
>>>>>>>>       ...
>>>>>>>>       roomNumber: -2
>>>>>>>>       homeDirectory: /home/net/shell-tuser
>>>>>>>>       loginShell: shell-plugin-autogenerate
>>>>>>>
>>>>>>> homeDirectory should be something like: ?placeholder? IMO, we do not
>>>>>>> really want to play templating here.
>>>>>>>
>>>>>>>>       In case the provisioning template does not define 
>>>>>>>> 'homeDirectory',
>>>>>>>>       then the created entry would take the value from the ipa config
>>>>>>>>       definition:
>>>>>>>
>>>>>>> that value should be taken and applied at the time the user is unstaged
>>>>>>> and brought in the actual tree, not at the time a user is staged.
>>>>>>>
>>>>>>> HTH,
>>>>>>> Simo.
>>>>>>>
>>>>>>
>>>>>> Hello Thierry and Simo,
>>>>>>
>>>>>> I think Thierry was confused with this part of the design:
>>>>>>
>>>>>> "
>>>>>> This format of placeholders gives enough space for future enhancements. 
>>>>>> For
>>>>>> example, Administrator could configure a new template
>>>>>> "myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry.
>>>>>> Such value would be replaced by "/home/net/tuser if user uid attribute 
>>>>>> is set
>>>>>> to tuser
>>>>>> "
>>>>>>
>>>>>> My intention when writing this design was to enable future use of
>>>>>> configurable placeholders, i.e. a value "?someplaceholder?" could be turn
>>>>>> into "/custom/path/%{uid}". But I meant that this can be considered as a
>>>>>> future enhancement. For now, I think implementing a placeholder "-1" for
>>>>>> numerical values and "?autogenerate?" for string ones a good start.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> _______________________________________________
>>>>>> Freeipa-devel mailing list
>>>>>> Freeipa-devel@redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>>>
>>>>>
>>>>> Please consider the flow: user added staged -> activated/moved to main 
>>>>> tree ->
>>>>> deleted/moved to deleted tree -> staged back
>>>>> At the first step his IPA user ID and UID should be undefined and
>>>>> autogenerated.
>>>>> On the last step his IPAUserID and UID should be preserved. The main use 
>>>>> case
>>>>> is that this is the user who left the company who comes back again. His 
>>>>> files
>>>>> should be still owned by him unless admin forces a flush of his IDs (new
>>>>> switch???) when he moves user from deleted to staged.
>>>>>
>>>>
>>>> Right, the life-cycle feature should work like that naturally, given that 
>>>> only
>>>> attributes with "-1" or "autogenerate" are generated.
>>>>
>>>> If admin wants to re-generate the IDs, all he would need to do is to 
>>>> change the
>>>> attributes back to "-1" after/before moving the user to staging. Question 
>>>> is
>>>> when it should be done (in deleted tree, in staging tree or after 
>>>> activation)
>>>> and what API/command we choose.
>>>
>>> TBH I question the whole idea of "moving to staging", in what case would
>>> that make sense ?
>>>
>>>> Admin may want to change not only the UID/GID, but maybe also a home 
>>>> directory
>>>> (user may be in a different department) so we should make it general. 
>>>> Maybe we
>>>> should let user-mod support modification in staging area? Like
>>>>
>>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-staged
>>>>
>>>> or
>>>>
>>>> $ ipa user-mod tuser --uid "-1" --gid "-1" --in-deleted
>>>
>>> The reason why we have the 'deleted' area is to be able to preserve the
>>> user intact ... I would almost want to ask to explicitly not allow
>>> modifications to deleted users (admin can always use ldapmodify if they
>>> *really* need to play some game here).
>>
>> +1, it seemed strange to me that modifying deleted user was allowed as well.
> 
> Hm, ok, let us not have an API to modify deleted user then.
> 
> As for active -> staging users flow, I only think of one scenario:
> 
> 1) Operator moves staged user to active users
> 2) Operator realizes that his mouse slipped and he moved a wrong person
> 3) Operator wants to move the person quickly back to staged before anyone
> notices :)

This, I believe, has already been covered, but I'm concerned with the
(over)use of active/inactive in this discussion.

I think use of "inactive" and "active" to describe users might be
confusing since there is already an account enable/disable command. This
on top of unlock, are there now 3 possible boolean states a user can be
in? locked/unlocked, enabled/disabled, active/inactive, plus
deleted/active and staged/active?

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to