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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York