[Freeipa-devel] Please review: V4/AD user short names design draft

[Martin Babinsky]

On 03/02/2017 04:11 PM, Jakub Hrozek wrote:
> On Thu, Mar 02, 2017 at 02:47:24PM +0100, Martin Babinsky wrote:
>> On 03/02/2017 10:25 AM, Jakub Hrozek wrote:
>>> On Thu, Mar 02, 2017 at 08:12:04AM +0100, Martin Babinsky wrote:
>>>> On 03/01/2017 05:28 PM, Alexander Bokovoy wrote:
>>>>> On ke, 01 maalis 2017, Simo Sorce wrote:
>>>>>>>> My take is: cut API/UI work, and do the underlying infrastructure work
>>>>>>>> for the widest set of serves/clients possible instead.
>>>>>>>>
>>>>>>>> It is much more important to get the underlying gears done than to add
>>>>>>>> UI candy, that can be delayed.
>>>>>>>>
>>>>>>>> Simo.
>>>>>>>>
>>>>>>>
>>>>>>> I agree, we just have to come to agreement of *which* gears are really
>>>>>>> necessary.
>>>>>>
>>>>>> Indeed, but adding attributes to ipaConfig and the ID Views is not hard,
>>>>>> it is a matter of extending two objectclasses instead of one ... if we
>>>>>> decide that Id Views are a good abstraction point.
>>>>> Adding the same attribute to ID View and to ipaConfig sounds logical to
>>>>> me.
>>>>>
>>>>> Martin, if you want help with this, I can implement ID View-related
>>>>> parts. SSSD does have code to retrieve ipaConfig already, and it also
>>>>> has support for reading ID View associated with the host. The resulting
>>>>> value wouldn't end up in the same place, though, but this is something
>>>>> to handle on SSSD side.
>>>>>
>>>>
>>>> I was thinking about this at night (insomnia FTW) and it is actually pretty
>>>> easy to extend ID view with the same attribute (see my other reply to Simo).
>>>> Given the UI will be pretty dumb, we just can add the new attribute to the
>>>> ID view object and a common code will be responsible for validation of
>>>> changed values.
>>>
>>> (I'm sorry to come late to the discussion, but I spent yesterday
>>> debugging a nasty issue in SSSD and my brain wasn't working anymore)
>>>
>>> To be honest, I haven't heard about users requesting to set the feature
>>> per-host. Most were interested in a global setting and given the short time
>>> before the next release, I thought for users who need a per-client solution,
>>> a local sssd.conf modification could also work, also considering that the
>>> /only/ solution so far was to modify sssd.conf with the default_domain_suffix
>>> hack.
>>>
>>> On the other hand, I see Simo's point about easy migration to this new
>>> setting and easier tinkering with the option if it's possible to set
>>> this per-view. And more importantly, I'm quite sure someone /will/ ask to
>>> set this centrally, but per host(group) eventually.
>>>
>>> So as long as the final design is a) extendable to provide a per-host
>>> setting in the future, even if that part is not implemented in this version
>>> in the UI or not used by the clients immediatelly and b) it's easy for
>>> clients to consume this setting, I'm fine.
>>>
>>> I'm afraid I can't comment on the ipaConfig issues and the replication
>>> concerns as I'm not that proficient with IPA internals..
>>>
>>
>> If we introduce a new objectclass providing the attribute, we may then
>> easily extend IDView object by it (or any other object for that matter) and
>> fix the plugin code so that it can be set by framework, it is easy.
>>
>> If you all agree that this is the way we want to move forward with this
>> project, I can update the design page and start implementing stuff. We need
>> to decide quicky, time is short.
>
> This sounds good to me from purely the client perspective, but I'm
> hardly the best person to decide IPA server-side design questions.
>

That's ok, the thing is that you will be consuming this information so 
we should try our best to make you happy :).

-- 
Martin^3 Babinsky