On 05/23/2014 07:48 AM, Jan Cholasta wrote:
> 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.
Hm, ok, let us not have an API to modify deleted user then.
As for active -> staging users flow, I only think of one scenario:
1) Operator moves staged user to active users
2) Operator realizes that his mouse slipped and he moved a wrong person
3) Operator wants to move the person quickly back to staged before anyone
notices :)
Martin
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
