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

[Martin Kosek]

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