[Freeipa-devel] User life cycle: question regarding the design
Jan Cholasta
jcholast at redhat.com
Fri May 23 05:48:21 UTC 2014
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.
>
> Simo.
>
--
Jan Cholasta
More information about the Freeipa-devel
mailing list