[Freeipa-devel] User life cycle: question regarding the design

[Martin Kosek]

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.

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

Martin