[Freeipa-devel] User life cycle: question regarding the design
Simo Sorce
simo at redhat.com
Thu May 22 17:27:54 UTC 2014
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).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
More information about the Freeipa-devel
mailing list