On 22.5.2014 19:27, Simo Sorce wrote:
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).

+1, it seemed strange to me that modifying deleted user was allowed as well.


Simo.



--
Jan Cholasta

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to