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

[Jakub Hrozek]

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.