[Freeipa-devel] User life cycle: question regarding the design
thierry bordaz
tbordaz at redhat.com
Fri May 23 15:47:17 UTC 2014
On 05/23/2014 10:13 AM, 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.
> 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.
About membership. I think it could be risky to keep membership in
'delete' or 'stage'. Those entries are not valid user and should not
belong to any active group. Should we keep membership attributes in
those state or let the plugin recompute the valid values when the entry
is back to active ?
>
>
>> 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
>>
>
>
More information about the Freeipa-devel
mailing list