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

[Dmitri Pal]

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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.