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@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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel