[Freeipa-devel] User life cycle: question regarding the design
Jan Cholasta
jcholast at redhat.com
Fri May 23 08:55:10 UTC 2014
On 23.5.2014 10:13, Petr Viktorin wrote:
> On 05/23/2014 08:33 AM, 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 at 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.
>
> Here's a scenario:
> - automember is set to add users the appropriate groups when userclass
> is set to "junior admin", or "senior admin"
> - Johnny the Junior Admin leaves the company, is deleted
> - After some time Johnny joins again as Senior Admin
>
> I think in this case we'd want to set the userclass to "senior admin"
> before restoring the user.
I don't agree, IMO this should be done after restoring the user, the
same way as you would "promote" any other active user.
> Other changes (e.g. a name change) can be done after restoring the user,
> but it still seems cleaner for me if they could be done on the deleted
> user (or if the deleted user could be restored to stage first). There
> may be other plugins that run on add and expect current information.
>
>
>> 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 :)
>>
>> Martin
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>
>
--
Jan Cholasta
More information about the Freeipa-devel
mailing list