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

[Martin Babinsky]

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.


-- 
Martin^3 Babinsky