Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 8.3.2017 10:30, Martin Babinsky wrote: On Tue, Feb 28, 2017 at 01:29:50PM +0100, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. [1] https://www.freeipa.org/page/V4/AD_User_Short_Names [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code I have updated the design page[1] and incorporated most of the comments from all reviewers. The most dramatic change is that I have expanded the discussion by the possibility for overriding global domain resolution order by ID view-specific settings. I have also expanded How-To section accordingly. Please try to review and comment during today as the window for development is quickly closing. LGTM. [1] http://www.freeipa.org/page/V4/AD_User_Short_Names -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Tue, Feb 28, 2017 at 01:29:50PM +0100, Martin Babinsky wrote: >Hello list, > >I have put together a draft of design page describing server-side >implementation of user short name -> fully-qualified name resolution.[1] > >In the end I have taken the liberty to change a few aspects of the design we >have agreed on before and I will be grad if we can discuss them further. > >Me and Honza have discussed the object that should hold the domain resolution >order and given the fact that IPA domain can also be a part of this list, we >have decided that this information is no longer bound to trust configuration >and should be a part of the global config instead. > >Also we have purposefully cut down the API only to a raw manipulation of the >attribute using an option of `ipa config-mod`. The reasons for this are >twofold: > > * the developer resources are quite scarce and it may be good to follow >YAGNI[2] principle to implement the dumbest API now and not to invest into >more high-level interface unless there is a demand for it > > * we can imagine that the manipulation of the domain resolution order is a >rare operation (ideally only once all trusts are established), so I am not >convinced that it is worth investing into designing higher-level API > >I propose we first develop the "dumber" parts first to unblock the SSSD part. >If we have spare cycle afterwards then we can design and implement more >bells-and-whistles afterwards. > >[1] https://www.freeipa.org/page/V4/AD_User_Short_Names >[2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it > >-- >Martin^3 Babinsky > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code I have updated the design page[1] and incorporated most of the comments from all reviewers. The most dramatic change is that I have expanded the discussion by the possibility for overriding global domain resolution order by ID view-specific settings. I have also expanded How-To section accordingly. Please try to review and comment during today as the window for development is quickly closing. [1] http://www.freeipa.org/page/V4/AD_User_Short_Names -- Martin Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Wed, Mar 08, 2017 at 07:37:40AM +0100, Jan Cholasta wrote: >On 7.3.2017 15:14, Simo Sorce wrote: >> On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote: >> > On 03/06/2017 01:48 PM, Simo Sorce wrote: >> > > On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: >> > > > On 03/02/2017 02:54 PM, Simo Sorce wrote: >> > > > > On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: >> > > > > > In this case it would probably be a good idea to think about >> > > > > > "forward >> > > > > > compatibility" and define a new AUX objectclass bringing in >> > > > > > 'ipaDomainResolutionOrder' instead of extending two separate >> > > > > > objectclasses. In this way we may the just extend whathever object >> > > > > > we >> > > > > > desire to carry the override in an easy and clean way. >> > > > > >> > > > > I agree. >> > > > > Simo. >> > > > > >> > > > >> > > > Now the most difficult question remains... How to name this >> > > > objectclass. >> > > > I personally am out of ideas but will try my best to come up with >> > > > something meaningful. >> > > >> > > Try to describe what the option ultimately does with as few words as >> > > possible. >> > > >> > > Simo. >> > > >> > > >> > >> > I was thinking about this and since we are performing name qualification >> > (short-name -> fully-qualified name incl. domain/realm part), I would >> > like to propose the following naming schema: >> > >> > objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used >> > for short name qualification data' SUP top AUXILIARY MAY >> > (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) >> > >> > attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC >> > 'List of domains used to qualify user short name' EQUALITY >> > caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >> > X-ORIGIN 'IPA v4.5' ) >> > >> > Let me know if you are ok with this or am I overengineering the names? >> > >> > I would like to solve this quickly so that I can finish the design and >> > start implementation. >> >> I was thinking that we can use acronyms here to make it less of a >> mouthful and also more easily recognizable: >> My idea is: >> - ipaNameQualificationData -> ipaFQDNPolicies >> - ipaNameQualificationDomainList -> ipaFQDNCheckOrder > >TBH I liked ipaDomainResolutionOrder the best, both >ipaNameQualificationDomainList and ipaFQDNCheckOrder sound overengineered to >me :-) > >If ipaDomainResolutionOrder is not good enough, we could draw some >inspiration from resolv.conf and use e.g. ipaDomainSearchList. > >-- >Jan Cholasta Sigh, naming stuff is always the hardest path. As a compromise let's settle with the following: * objectclass: ipaNameResolutionData * attribute: ipaDomainSearchList I will use these to update the design page. You can the objet during another phase of review process. -- Martin Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 7.3.2017 15:14, Simo Sorce wrote: On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote: On 03/06/2017 01:48 PM, Simo Sorce wrote: On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: On 03/02/2017 02:54 PM, Simo Sorce wrote: On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: In this case it would probably be a good idea to think about "forward compatibility" and define a new AUX objectclass bringing in 'ipaDomainResolutionOrder' instead of extending two separate objectclasses. In this way we may the just extend whathever object we desire to carry the override in an easy and clean way. I agree. Simo. Now the most difficult question remains... How to name this objectclass. I personally am out of ideas but will try my best to come up with something meaningful. Try to describe what the option ultimately does with as few words as possible. Simo. I was thinking about this and since we are performing name qualification (short-name -> fully-qualified name incl. domain/realm part), I would like to propose the following naming schema: objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used for short name qualification data' SUP top AUXILIARY MAY (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC 'List of domains used to qualify user short name' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v4.5' ) Let me know if you are ok with this or am I overengineering the names? I would like to solve this quickly so that I can finish the design and start implementation. I was thinking that we can use acronyms here to make it less of a mouthful and also more easily recognizable: My idea is: - ipaNameQualificationData -> ipaFQDNPolicies - ipaNameQualificationDomainList -> ipaFQDNCheckOrder TBH I liked ipaDomainResolutionOrder the best, both ipaNameQualificationDomainList and ipaFQDNCheckOrder sound overengineered to me :-) If ipaDomainResolutionOrder is not good enough, we could draw some inspiration from resolv.conf and use e.g. ipaDomainSearchList. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 07.03.2017 15:41, Martin Babinsky wrote: > On Tue, Mar 07, 2017 at 04:34:42PM +0200, Alexander Bokovoy wrote: >> On ti, 07 maalis 2017, Simo Sorce wrote: >>> On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote: On 03/06/2017 01:48 PM, Simo Sorce wrote: > On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: >> On 03/02/2017 02:54 PM, Simo Sorce wrote: >>> On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: In this case it would probably be a good idea to think about "forward compatibility" and define a new AUX objectclass bringing in 'ipaDomainResolutionOrder' instead of extending two separate objectclasses. In this way we may the just extend whathever object we desire to carry the override in an easy and clean way. >>> I agree. >>> Simo. >>> >> Now the most difficult question remains... How to name this objectclass. >> I personally am out of ideas but will try my best to come up with >> something meaningful. > Try to describe what the option ultimately does with as few words as > possible. > > Simo. > > I was thinking about this and since we are performing name qualification (short-name -> fully-qualified name incl. domain/realm part), I would like to propose the following naming schema: objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used for short name qualification data' SUP top AUXILIARY MAY (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC 'List of domains used to qualify user short name' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v4.5' ) Let me know if you are ok with this or am I overengineering the names? I would like to solve this quickly so that I can finish the design and start implementation. >>> I was thinking that we can use acronyms here to make it less of a >>> mouthful and also more easily recognizable: >>> My idea is: >>> - ipaNameQualificationData -> ipaFQDNPolicies >>> - ipaNameQualificationDomainList -> ipaFQDNCheckOrder >> Sounds good to me. >> -- >> / Alexander Bokovoy > I am not sure about the relation of this to any policy, but I guess that is > just nitpicking. > > I will wait awhile for others to object and then update design. > I agree to not use "policy" in the name Martin^2 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Tue, Mar 07, 2017 at 04:34:42PM +0200, Alexander Bokovoy wrote: >On ti, 07 maalis 2017, Simo Sorce wrote: >> On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote: >> > On 03/06/2017 01:48 PM, Simo Sorce wrote: >> > > On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: >> > >> On 03/02/2017 02:54 PM, Simo Sorce wrote: >> > >>> On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: >> > In this case it would probably be a good idea to think about "forward >> > compatibility" and define a new AUX objectclass bringing in >> > 'ipaDomainResolutionOrder' instead of extending two separate >> > objectclasses. In this way we may the just extend whathever object we >> > desire to carry the override in an easy and clean way. >> > >>> >> > >>> I agree. >> > >>> Simo. >> > >>> >> > >> >> > >> Now the most difficult question remains... How to name this objectclass. >> > >> I personally am out of ideas but will try my best to come up with >> > >> something meaningful. >> > > >> > > Try to describe what the option ultimately does with as few words as >> > > possible. >> > > >> > > Simo. >> > > >> > > >> > >> > I was thinking about this and since we are performing name qualification >> > (short-name -> fully-qualified name incl. domain/realm part), I would >> > like to propose the following naming schema: >> > >> > objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used >> > for short name qualification data' SUP top AUXILIARY MAY >> > (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) >> > >> > attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC >> > 'List of domains used to qualify user short name' EQUALITY >> > caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >> > X-ORIGIN 'IPA v4.5' ) >> > >> > Let me know if you are ok with this or am I overengineering the names? >> > >> > I would like to solve this quickly so that I can finish the design and >> > start implementation. >> >> I was thinking that we can use acronyms here to make it less of a >> mouthful and also more easily recognizable: >> My idea is: >> - ipaNameQualificationData -> ipaFQDNPolicies >> - ipaNameQualificationDomainList -> ipaFQDNCheckOrder >Sounds good to me. >-- >/ Alexander Bokovoy I am not sure about the relation of this to any policy, but I guess that is just nitpicking. I will wait awhile for others to object and then update design. -- Martin Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On ti, 07 maalis 2017, Simo Sorce wrote: On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote: On 03/06/2017 01:48 PM, Simo Sorce wrote: > On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: >> On 03/02/2017 02:54 PM, Simo Sorce wrote: >>> On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: In this case it would probably be a good idea to think about "forward compatibility" and define a new AUX objectclass bringing in 'ipaDomainResolutionOrder' instead of extending two separate objectclasses. In this way we may the just extend whathever object we desire to carry the override in an easy and clean way. >>> >>> I agree. >>> Simo. >>> >> >> Now the most difficult question remains... How to name this objectclass. >> I personally am out of ideas but will try my best to come up with >> something meaningful. > > Try to describe what the option ultimately does with as few words as > possible. > > Simo. > > I was thinking about this and since we are performing name qualification (short-name -> fully-qualified name incl. domain/realm part), I would like to propose the following naming schema: objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used for short name qualification data' SUP top AUXILIARY MAY (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC 'List of domains used to qualify user short name' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v4.5' ) Let me know if you are ok with this or am I overengineering the names? I would like to solve this quickly so that I can finish the design and start implementation. I was thinking that we can use acronyms here to make it less of a mouthful and also more easily recognizable: My idea is: - ipaNameQualificationData -> ipaFQDNPolicies - ipaNameQualificationDomainList -> ipaFQDNCheckOrder Sounds good to me. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote: > On 03/06/2017 01:48 PM, Simo Sorce wrote: > > On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: > >> On 03/02/2017 02:54 PM, Simo Sorce wrote: > >>> On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: > In this case it would probably be a good idea to think about "forward > compatibility" and define a new AUX objectclass bringing in > 'ipaDomainResolutionOrder' instead of extending two separate > objectclasses. In this way we may the just extend whathever object we > desire to carry the override in an easy and clean way. > >>> > >>> I agree. > >>> Simo. > >>> > >> > >> Now the most difficult question remains... How to name this objectclass. > >> I personally am out of ideas but will try my best to come up with > >> something meaningful. > > > > Try to describe what the option ultimately does with as few words as > > possible. > > > > Simo. > > > > > > I was thinking about this and since we are performing name qualification > (short-name -> fully-qualified name incl. domain/realm part), I would > like to propose the following naming schema: > > objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used > for short name qualification data' SUP top AUXILIARY MAY > (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) > > attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC > 'List of domains used to qualify user short name' EQUALITY > caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 > X-ORIGIN 'IPA v4.5' ) > > Let me know if you are ok with this or am I overengineering the names? > > I would like to solve this quickly so that I can finish the design and > start implementation. I was thinking that we can use acronyms here to make it less of a mouthful and also more easily recognizable: My idea is: - ipaNameQualificationData -> ipaFQDNPolicies - ipaNameQualificationDomainList -> ipaFQDNCheckOrder Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 03/06/2017 01:48 PM, Simo Sorce wrote: On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: On 03/02/2017 02:54 PM, Simo Sorce wrote: On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: In this case it would probably be a good idea to think about "forward compatibility" and define a new AUX objectclass bringing in 'ipaDomainResolutionOrder' instead of extending two separate objectclasses. In this way we may the just extend whathever object we desire to carry the override in an easy and clean way. I agree. Simo. Now the most difficult question remains... How to name this objectclass. I personally am out of ideas but will try my best to come up with something meaningful. Try to describe what the option ultimately does with as few words as possible. Simo. I was thinking about this and since we are performing name qualification (short-name -> fully-qualified name incl. domain/realm part), I would like to propose the following naming schema: objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used for short name qualification data' SUP top AUXILIARY MAY (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' ) attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC 'List of domains used to qualify user short name' EQUALITY caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v4.5' ) Let me know if you are ok with this or am I overengineering the names? I would like to solve this quickly so that I can finish the design and start implementation. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote: > On 03/02/2017 02:54 PM, Simo Sorce wrote: > > On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: > >> In this case it would probably be a good idea to think about "forward > >> compatibility" and define a new AUX objectclass bringing in > >> 'ipaDomainResolutionOrder' instead of extending two separate > >> objectclasses. In this way we may the just extend whathever object we > >> desire to carry the override in an easy and clean way. > > > > I agree. > > Simo. > > > > Now the most difficult question remains... How to name this objectclass. > I personally am out of ideas but will try my best to come up with > something meaningful. Try to describe what the option ultimately does with as few words as possible. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 03/02/2017 02:54 PM, Simo Sorce wrote: On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: In this case it would probably be a good idea to think about "forward compatibility" and define a new AUX objectclass bringing in 'ipaDomainResolutionOrder' instead of extending two separate objectclasses. In this way we may the just extend whathever object we desire to carry the override in an easy and clean way. I agree. Simo. Now the most difficult question remains... How to name this objectclass. I personally am out of ideas but will try my best to come up with something meaningful. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
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. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: > In this case it would probably be a good idea to think about "forward > compatibility" and define a new AUX objectclass bringing in > 'ipaDomainResolutionOrder' instead of extending two separate > objectclasses. In this way we may the just extend whathever object we > desire to carry the override in an easy and clean way. I agree. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
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.. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On to, 02 maalis 2017, Jan Cholasta wrote: "No value is set in configuration => use built-in default / some value is set configuration => use the value" is perfectly user friendly and pretty much common virtually everywhere I believe, much more so than "empty value is set in configuration => ignore the value even if the user deliberately set it empty and use the default value instead". I'm not arguing with "no value is set in configuration -> use built-in default". I do argue on having empty but present attribute because it does not add anything useful for SSSD to decide on. And as it is not adding anything useful, why there should be such difference at all? This is the only question open I see in this design. The list does not have to contain all available domains, therefore it can also be empty. When a domain is not present in the list, a fully qualified name must be used for users in that domain, therefore when the list is empty, fully qualified name must be used for users in all domains. This might be useful to someone, and even if it wasn't, I still don't think it warrants making a (IMO counter-intuitive) special case out of the empty list. I'm confused. I don't want to make this distinction between a missing attribute and an empty one. You appear to be following the same path. What we are arguing about then? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 1.3.2017 14:58, Alexander Bokovoy wrote: On ke, 01 maalis 2017, Jan Cholasta wrote: On 1.3.2017 14:05, Alexander Bokovoy wrote: On ke, 01 maalis 2017, Jan Cholasta wrote: On 1.3.2017 13:39, Martin Babinsky wrote: Alexander, thank you for your comments. Replies inline: On 02/28/2017 01:48 PM, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. The validation is described in a Design section as follows: """ Finally, any modification of the domain resolution order must ensure that each of the specified domain names corresponds either to that of FreeIPA domain or to one of the trusted AD domains stored in LDAP backend. In the case of trusted domains, the domain must not be marked as disabled. """ Is this sufficient or is a more thorough validation required? Shall I split the whole section into sub-sections for easier navigation? - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. I have discussed this with Jan and consulted the same document that you cited, that's why I have arrived to the conclusion to use whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain names or should we consider other options to avoid breakage with more exotic domain names? Actually I would prefer something else than whitespace as a separator. A ':' maybe? or ',' or ';'. Any would work. I have considered a empty attribute value to be a distinct state from the missing attribute and assigned a different semantic meaning to it. The reasoning is as follows: if the attribute is not set, SSSD will not retrieve it and this signals that it should continue operate in usual way. If the attribute is present but is empty, the semantics change slightly as now we consider *no* domains during short name resolution (extension of the missing domain behavior to the case of all domains are missing from list). It doesn't have to be literally empty (LDAP character string syntaxes don't allow it anyway IIRC), there can be a value which denotes an empty list of domain (e.g. the separator alone). I don't see *why* there should be this distinction. The deciding party is SSSD. Whether this attirbute exists and empty or does not exist at all does not change anything. Changing how SSSD interprets own defaults depending on absense or emptiness of certain attribute in IPA config object is not user friendly at all. SSSD default behavior should stay the same whether it finds missing or empty attribute because the attribute will not be known to older SSSD anyway. Missing or empty attribute should, in my opinion, be equal to older SSSD behavior. "No value is set in configuration => use built-in default / some value is set configuration => use the value" is perfectly user friendly and pretty much common virtually everywhere I believe, much more so than "empty value is set in configuration => ignore the value even if the user deliberately set it empty and use the default value instead". I'm not arguing with "no value is set in configuration -> use built-in default". I do argue on having empty but present attribute because it does not add anything useful for SSSD to decide on. And as it is not adding anything useful, why there should be such
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
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. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 03/01/2017 05:51 PM, Simo Sorce wrote: On Wed, 2017-03-01 at 17:29 +0100, Martin Basti wrote: On 01.03.2017 17:04, Simo Sorce wrote: On Wed, 2017-03-01 at 16:47 +0100, Martin Babinsky wrote: On 03/01/2017 04:32 PM, Simo Sorce wrote: On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote: On 03/01/2017 03:42 PM, Simo Sorce wrote: On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. [1] https://www.freeipa.org/page/V4/AD_User_Short_Names [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Thank you Martin, this is a good initial proposal. I have a few issues with this design: - It conflates the idea of ordering with the idea of shortening user names I fail to see where the conflation takes place. The ordered list is stored on the server. The client then uses it to expand short names. I guess I am just missing something. The attribute is called ipaNTDomainResolutionOrder, nothing in that attribute says anything about making names become short names. If it were ipaNTShortNameDomainResolutionOrder then it would be specific, as it is it seem just to refer to the order in which domain are resolved, but that is somethign we want in order to determine which domains SSSD is going to make use short names too, not just the order in which domains are resolved. I hope this makes it clearer. - It allows only for one setting for all the machines, no way to treat different groups of machines differently Yes it was discussed that the setting will be global. I would implement local overrides only when there is a demand for the feature given development time is short. Demand is immediate, and it is obvious IMO. Such demand was not made clear during previous discussions and was not mentioned by SSSD guys either AFAIK. I guess this is why we do reviews :-) The first one is probably just a matter of using a more specific name for the new attribute, or, perhaps not use a new attribute at all but just use ipaConfigString with an agreed syntax like: ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd The side effect of using ipaConfigString is that we can set this on older servers too, so people do not have to upgrade their servers to use this. Old servers will not have any validation, but that is ok, sssd must be prepared to receive a bad list and deal with it appropriately anyway. No more 'ipaConfigString' attribute values, please. Me and everyone else fixing e.g. replication issues can relate to the pain of doing CRUD operations involving them. ipaConfigString was devised explicitly so that configuration options could be added without replication issues because the string can be accepted by any server version. So what replication issues are there ? What has CRUD to do with it ? Well consider client doing a) retrieve ipaDomainResolutionOrder and split it by delimiter, or b) retrieve values of ipaConfigString, iterate until you find one that starts with "Domains Use Short Name list:", strip off the rest of the value and split it by delimiter. I do not see any problem with this. I disagree, ipaConfigString evokes that this is IPA configuration, but AFAIK the SSSD is the consumer of data and it is unrelated to configuration of IPA server. If you plan to extend usage of 'ipaDomainResolutionOrder' to more entries than one, then is better to have separate attribute that allows better LDAP searches (debugging, support). Why SSSD instead of downloading the exact attribute content should do a parsing of messy values that can be inside ipaConfigString? Why we suddenly plan to support older servers with a new feature? In past access to new fe
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Wed, 2017-03-01 at 17:29 +0100, Martin Basti wrote: > > On 01.03.2017 17:04, Simo Sorce wrote: > > On Wed, 2017-03-01 at 16:47 +0100, Martin Babinsky wrote: > >> On 03/01/2017 04:32 PM, Simo Sorce wrote: > >>> On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote: > On 03/01/2017 03:42 PM, Simo Sorce wrote: > > On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: > >> Hello list, > >> > >> I have put together a draft of design page describing server-side > >> implementation of user short name -> fully-qualified name > >> resolution.[1] > >> > >> In the end I have taken the liberty to change a few aspects of the > >> design we have agreed on before and I will be grad if we can discuss > >> them further. > >> > >> Me and Honza have discussed the object that should hold the domain > >> resolution order and given the fact that IPA domain can also be a part > >> of this list, we have decided that this information is no longer bound > >> to trust configuration and should be a part of the global config > >> instead. > >> > >> Also we have purposefully cut down the API only to a raw manipulation > >> of > >> the attribute using an option of `ipa config-mod`. The reasons for this > >> are twofold: > >> > >> * the developer resources are quite scarce and it may be good to > >> follow YAGNI[2] principle to implement the dumbest API now and not to > >> invest into more high-level interface unless there is a demand for it > >> > >> * we can imagine that the manipulation of the domain resolution > >> order > >> is a rare operation (ideally only once all trusts are established), so > >> I > >> am not convinced that it is worth investing into designing > >> higher-level API > >> > >> I propose we first develop the "dumber" parts first to unblock the SSSD > >> part. If we have spare cycle afterwards then we can design and > >> implement > >> more bells-and-whistles afterwards. > >> > >> [1] https://www.freeipa.org/page/V4/AD_User_Short_Names > >> [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it > > Thank you Martin, > > this is a good initial proposal. > > > > I have a few issues with this design: > > - It conflates the idea of ordering with the idea of shortening user > > names > I fail to see where the conflation takes place. The ordered list is > stored on the server. The client then uses it to expand short names. I > guess I am just missing something. > >>> The attribute is called ipaNTDomainResolutionOrder, nothing in that > >>> attribute says anything about making names become short names. > >>> If it were ipaNTShortNameDomainResolutionOrder then it would be > >>> specific, as it is it seem just to refer to the order in which domain > >>> are resolved, but that is somethign we want in order to determine which > >>> domains SSSD is going to make use short names too, not just the order in > >>> which domains are resolved. > >>> I hope this makes it clearer. > >>> > > - It allows only for one setting for all the machines, no way to treat > > different groups of machines differently > > > Yes it was discussed that the setting will be global. I would implement > local overrides only when there is a demand for the feature given > development time is short. > >>> Demand is immediate, and it is obvious IMO. > >>> > >> Such demand was not made clear during previous discussions and was not > >> mentioned by SSSD guys either AFAIK. > > I guess this is why we do reviews :-) > > > > The first one is probably just a matter of using a more specific name > > for the new attribute, or, perhaps not use a new attribute at all but > > just use ipaConfigString with an agreed syntax like: > > ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd > > > > The side effect of using ipaConfigString is that we can set this on > > older servers too, so people do not have to upgrade their servers to use > > this. Old servers will not have any validation, but that is ok, sssd > > must be prepared to receive a bad list and deal with it appropriately > > anyway. > > > No more 'ipaConfigString' attribute values, please. Me and everyone else > fixing e.g. replication issues can relate to the pain of doing CRUD > operations involving them. > >>> ipaConfigString was devised explicitly so that configuration options > >>> could be added without replication issues because the string can be > >>> accepted by any server version. > >>> So what replication issues are there ? > >>> What has CRUD to do with it ? > >>> > >> Well consider client doing a) retrieve ipaDomainResolutionOrder and > >> split it by delimiter, or b) retrieve values of ipaConfigString, iterate > >> until you find one that starts with "Domains Use Short Name l
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 01.03.2017 17:04, Simo Sorce wrote: On Wed, 2017-03-01 at 16:47 +0100, Martin Babinsky wrote: On 03/01/2017 04:32 PM, Simo Sorce wrote: On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote: On 03/01/2017 03:42 PM, Simo Sorce wrote: On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. [1] https://www.freeipa.org/page/V4/AD_User_Short_Names [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Thank you Martin, this is a good initial proposal. I have a few issues with this design: - It conflates the idea of ordering with the idea of shortening user names I fail to see where the conflation takes place. The ordered list is stored on the server. The client then uses it to expand short names. I guess I am just missing something. The attribute is called ipaNTDomainResolutionOrder, nothing in that attribute says anything about making names become short names. If it were ipaNTShortNameDomainResolutionOrder then it would be specific, as it is it seem just to refer to the order in which domain are resolved, but that is somethign we want in order to determine which domains SSSD is going to make use short names too, not just the order in which domains are resolved. I hope this makes it clearer. - It allows only for one setting for all the machines, no way to treat different groups of machines differently Yes it was discussed that the setting will be global. I would implement local overrides only when there is a demand for the feature given development time is short. Demand is immediate, and it is obvious IMO. Such demand was not made clear during previous discussions and was not mentioned by SSSD guys either AFAIK. I guess this is why we do reviews :-) The first one is probably just a matter of using a more specific name for the new attribute, or, perhaps not use a new attribute at all but just use ipaConfigString with an agreed syntax like: ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd The side effect of using ipaConfigString is that we can set this on older servers too, so people do not have to upgrade their servers to use this. Old servers will not have any validation, but that is ok, sssd must be prepared to receive a bad list and deal with it appropriately anyway. No more 'ipaConfigString' attribute values, please. Me and everyone else fixing e.g. replication issues can relate to the pain of doing CRUD operations involving them. ipaConfigString was devised explicitly so that configuration options could be added without replication issues because the string can be accepted by any server version. So what replication issues are there ? What has CRUD to do with it ? Well consider client doing a) retrieve ipaDomainResolutionOrder and split it by delimiter, or b) retrieve values of ipaConfigString, iterate until you find one that starts with "Domains Use Short Name list:", strip off the rest of the value and split it by delimiter. I do not see any problem with this. I disagree, ipaConfigString evokes that this is IPA configuration, but AFAIK the SSSD is the consumer of data and it is unrelated to configuration of IPA server. If you plan to extend usage of 'ipaDomainResolutionOrder' to more entries than one, then is better to have separate attribute that allows better LDAP searches (debugging, support). Why SSSD instead of downloading the exact attribute content should do a parsing of messy values that can be inside ipaConfigString? Why we suddenly plan to support older servers with a new feature? In past access to new features required to upgrade freeipa, why we should increase complexity of code and ldap sea
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
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. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Wed, 2017-03-01 at 16:47 +0100, Martin Babinsky wrote: > On 03/01/2017 04:32 PM, Simo Sorce wrote: > > On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote: > >> On 03/01/2017 03:42 PM, Simo Sorce wrote: > >>> On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: > Hello list, > > I have put together a draft of design page describing server-side > implementation of user short name -> fully-qualified name resolution.[1] > > In the end I have taken the liberty to change a few aspects of the > design we have agreed on before and I will be grad if we can discuss > them further. > > Me and Honza have discussed the object that should hold the domain > resolution order and given the fact that IPA domain can also be a part > of this list, we have decided that this information is no longer bound > to trust configuration and should be a part of the global config instead. > > Also we have purposefully cut down the API only to a raw manipulation of > the attribute using an option of `ipa config-mod`. The reasons for this > are twofold: > > * the developer resources are quite scarce and it may be good to > follow YAGNI[2] principle to implement the dumbest API now and not to > invest into more high-level interface unless there is a demand for it > > * we can imagine that the manipulation of the domain resolution order > is a rare operation (ideally only once all trusts are established), so I > am not convinced that it is worth investing into designing higher-level > API > > I propose we first develop the "dumber" parts first to unblock the SSSD > part. If we have spare cycle afterwards then we can design and implement > more bells-and-whistles afterwards. > > [1] https://www.freeipa.org/page/V4/AD_User_Short_Names > [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it > >>> > >>> Thank you Martin, > >>> this is a good initial proposal. > >>> > >>> I have a few issues with this design: > >>> - It conflates the idea of ordering with the idea of shortening user > >>> names > >> > >> I fail to see where the conflation takes place. The ordered list is > >> stored on the server. The client then uses it to expand short names. I > >> guess I am just missing something. > > > > The attribute is called ipaNTDomainResolutionOrder, nothing in that > > attribute says anything about making names become short names. > > If it were ipaNTShortNameDomainResolutionOrder then it would be > > specific, as it is it seem just to refer to the order in which domain > > are resolved, but that is somethign we want in order to determine which > > domains SSSD is going to make use short names too, not just the order in > > which domains are resolved. > > I hope this makes it clearer. > > > >>> - It allows only for one setting for all the machines, no way to treat > >>> different groups of machines differently > >>> > >> > >> Yes it was discussed that the setting will be global. I would implement > >> local overrides only when there is a demand for the feature given > >> development time is short. > > > > Demand is immediate, and it is obvious IMO. > > > > Such demand was not made clear during previous discussions and was not > mentioned by SSSD guys either AFAIK. I guess this is why we do reviews :-) > >>> The first one is probably just a matter of using a more specific name > >>> for the new attribute, or, perhaps not use a new attribute at all but > >>> just use ipaConfigString with an agreed syntax like: > >>> ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd > >>> > >>> The side effect of using ipaConfigString is that we can set this on > >>> older servers too, so people do not have to upgrade their servers to use > >>> this. Old servers will not have any validation, but that is ok, sssd > >>> must be prepared to receive a bad list and deal with it appropriately > >>> anyway. > >>> > >> > >> No more 'ipaConfigString' attribute values, please. Me and everyone else > >> fixing e.g. replication issues can relate to the pain of doing CRUD > >> operations involving them. > > > > ipaConfigString was devised explicitly so that configuration options > > could be added without replication issues because the string can be > > accepted by any server version. > > So what replication issues are there ? > > What has CRUD to do with it ? > > > > Well consider client doing a) retrieve ipaDomainResolutionOrder and > split it by delimiter, or b) retrieve values of ipaConfigString, iterate > until you find one that starts with "Domains Use Short Name list:", > strip off the rest of the value and split it by delimiter. I do not see any problem with this. > I just feel anything involving 'ipaConfigString' leads to design smell, > sorry. Yes it is my personal opinion but I think there are more people > sharing it. If not, I am happy to hear counterargumen
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 03/01/2017 04:32 PM, Simo Sorce wrote: On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote: On 03/01/2017 03:42 PM, Simo Sorce wrote: On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. [1] https://www.freeipa.org/page/V4/AD_User_Short_Names [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Thank you Martin, this is a good initial proposal. I have a few issues with this design: - It conflates the idea of ordering with the idea of shortening user names I fail to see where the conflation takes place. The ordered list is stored on the server. The client then uses it to expand short names. I guess I am just missing something. The attribute is called ipaNTDomainResolutionOrder, nothing in that attribute says anything about making names become short names. If it were ipaNTShortNameDomainResolutionOrder then it would be specific, as it is it seem just to refer to the order in which domain are resolved, but that is somethign we want in order to determine which domains SSSD is going to make use short names too, not just the order in which domains are resolved. I hope this makes it clearer. - It allows only for one setting for all the machines, no way to treat different groups of machines differently Yes it was discussed that the setting will be global. I would implement local overrides only when there is a demand for the feature given development time is short. Demand is immediate, and it is obvious IMO. Such demand was not made clear during previous discussions and was not mentioned by SSSD guys either AFAIK. The first one is probably just a matter of using a more specific name for the new attribute, or, perhaps not use a new attribute at all but just use ipaConfigString with an agreed syntax like: ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd The side effect of using ipaConfigString is that we can set this on older servers too, so people do not have to upgrade their servers to use this. Old servers will not have any validation, but that is ok, sssd must be prepared to receive a bad list and deal with it appropriately anyway. No more 'ipaConfigString' attribute values, please. Me and everyone else fixing e.g. replication issues can relate to the pain of doing CRUD operations involving them. ipaConfigString was devised explicitly so that configuration options could be added without replication issues because the string can be accepted by any server version. So what replication issues are there ? What has CRUD to do with it ? Well consider client doing a) retrieve ipaDomainResolutionOrder and split it by delimiter, or b) retrieve values of ipaConfigString, iterate until you find one that starts with "Domains Use Short Name list:", strip off the rest of the value and split it by delimiter. I just feel anything involving 'ipaConfigString' leads to design smell, sorry. Yes it is my personal opinion but I think there are more people sharing it. If not, I am happy to hear counterarguments. If the admin wishes old servers to server new clients this information, They do not "wish", this is pretty much what happens all the time ... all he has to do is upgrade a single replica, set the attribute value there and let replication take care of the rest. Come on, really ? If you have RHEL6 it is not a matter of "simply" upgrading a single replica, it means upgrade of the whole infrastructure ... There is plenty of features not available to deplyments with RHEL6 masters, I simply fail to see why this one should be special. Yes, the management CLI will not be available on the old masters but that is
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote: > On 03/01/2017 03:42 PM, Simo Sorce wrote: > > On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: > >> Hello list, > >> > >> I have put together a draft of design page describing server-side > >> implementation of user short name -> fully-qualified name resolution.[1] > >> > >> In the end I have taken the liberty to change a few aspects of the > >> design we have agreed on before and I will be grad if we can discuss > >> them further. > >> > >> Me and Honza have discussed the object that should hold the domain > >> resolution order and given the fact that IPA domain can also be a part > >> of this list, we have decided that this information is no longer bound > >> to trust configuration and should be a part of the global config instead. > >> > >> Also we have purposefully cut down the API only to a raw manipulation of > >> the attribute using an option of `ipa config-mod`. The reasons for this > >> are twofold: > >> > >>* the developer resources are quite scarce and it may be good to > >> follow YAGNI[2] principle to implement the dumbest API now and not to > >> invest into more high-level interface unless there is a demand for it > >> > >>* we can imagine that the manipulation of the domain resolution order > >> is a rare operation (ideally only once all trusts are established), so I > >> am not convinced that it is worth investing into designing higher-level API > >> > >> I propose we first develop the "dumber" parts first to unblock the SSSD > >> part. If we have spare cycle afterwards then we can design and implement > >> more bells-and-whistles afterwards. > >> > >> [1] https://www.freeipa.org/page/V4/AD_User_Short_Names > >> [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it > > > > Thank you Martin, > > this is a good initial proposal. > > > > I have a few issues with this design: > > - It conflates the idea of ordering with the idea of shortening user > > names > > I fail to see where the conflation takes place. The ordered list is > stored on the server. The client then uses it to expand short names. I > guess I am just missing something. The attribute is called ipaNTDomainResolutionOrder, nothing in that attribute says anything about making names become short names. If it were ipaNTShortNameDomainResolutionOrder then it would be specific, as it is it seem just to refer to the order in which domain are resolved, but that is somethign we want in order to determine which domains SSSD is going to make use short names too, not just the order in which domains are resolved. I hope this makes it clearer. > > - It allows only for one setting for all the machines, no way to treat > > different groups of machines differently > > > > Yes it was discussed that the setting will be global. I would implement > local overrides only when there is a demand for the feature given > development time is short. Demand is immediate, and it is obvious IMO. > > The first one is probably just a matter of using a more specific name > > for the new attribute, or, perhaps not use a new attribute at all but > > just use ipaConfigString with an agreed syntax like: > > ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd > > > > The side effect of using ipaConfigString is that we can set this on > > older servers too, so people do not have to upgrade their servers to use > > this. Old servers will not have any validation, but that is ok, sssd > > must be prepared to receive a bad list and deal with it appropriately > > anyway. > > > > No more 'ipaConfigString' attribute values, please. Me and everyone else > fixing e.g. replication issues can relate to the pain of doing CRUD > operations involving them. ipaConfigString was devised explicitly so that configuration options could be added without replication issues because the string can be accepted by any server version. So what replication issues are there ? What has CRUD to do with it ? > If the admin wishes old servers to server new clients this information, They do not "wish", this is pretty much what happens all the time ... > all he has to do is upgrade a single replica, set the attribute value > there and let replication take care of the rest. Come on, really ? If you have RHEL6 it is not a matter of "simply" upgrading a single replica, it means upgrade of the whole infrastructure ... > Yes, the management CLI > will not be available on the old masters but that is the case of new > features anyway. I do not think we need any management UI in the short term to be honest, just a way to set a string. That will cut most development time that can be spent instead on dealing with allowing smaller groups of machines to be affected instead. > > The second one is something we *may* address later, and use the setting > > in cn=ipaConfig as a default, but there are two reasons why I think a > > setting applicable to just a host group makes sense: > > - it allows to test
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 03/01/2017 03:42 PM, Simo Sorce wrote: On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. [1] https://www.freeipa.org/page/V4/AD_User_Short_Names [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Thank you Martin, this is a good initial proposal. I have a few issues with this design: - It conflates the idea of ordering with the idea of shortening user names I fail to see where the conflation takes place. The ordered list is stored on the server. The client then uses it to expand short names. I guess I am just missing something. - It allows only for one setting for all the machines, no way to treat different groups of machines differently Yes it was discussed that the setting will be global. I would implement local overrides only when there is a demand for the feature given development time is short. The first one is probably just a matter of using a more specific name for the new attribute, or, perhaps not use a new attribute at all but just use ipaConfigString with an agreed syntax like: ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd The side effect of using ipaConfigString is that we can set this on older servers too, so people do not have to upgrade their servers to use this. Old servers will not have any validation, but that is ok, sssd must be prepared to receive a bad list and deal with it appropriately anyway. No more 'ipaConfigString' attribute values, please. Me and everyone else fixing e.g. replication issues can relate to the pain of doing CRUD operations involving them. If the admin wishes old servers to server new clients this information, all he has to do is upgrade a single replica, set the attribute value there and let replication take care of the rest. Yes, the management CLI will not be available on the old masters but that is the case of new features anyway. The second one is something we *may* address later, and use the setting in cn=ipaConfig as a default, but there are two reasons why I think a setting applicable to just a host group makes sense: - it allows to test the setting on a small set of machines to see if everything works right, this is going to be especially important on existing setups, where people do not want to risk all machines misbehaving at once if something goes wrong. - it allows to migrate machines slowly, in some cases people may need to change local files/application settings on machines if the usernames change, so they may need a controlled roll out before changing a setting globally. This may achieved by adding this setting to an ID View for example, then only hosts in that IDView would get this. Or a new object could be created that has members, the former has the advantage of being already in place and SSSD already downloads that data, the latter allows to target an even smaller set of hosts unrelated to previous ID views settings. Simo. That is an interesting proposal but I am afraid we may not get to implement that during 4.5 development. I can certainly mention the possibility in the design so that we can return to it when a need arises. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Tue, 2017-02-28 at 13:29 +0100, Martin Babinsky wrote: > Hello list, > > I have put together a draft of design page describing server-side > implementation of user short name -> fully-qualified name resolution.[1] > > In the end I have taken the liberty to change a few aspects of the > design we have agreed on before and I will be grad if we can discuss > them further. > > Me and Honza have discussed the object that should hold the domain > resolution order and given the fact that IPA domain can also be a part > of this list, we have decided that this information is no longer bound > to trust configuration and should be a part of the global config instead. > > Also we have purposefully cut down the API only to a raw manipulation of > the attribute using an option of `ipa config-mod`. The reasons for this > are twofold: > >* the developer resources are quite scarce and it may be good to > follow YAGNI[2] principle to implement the dumbest API now and not to > invest into more high-level interface unless there is a demand for it > >* we can imagine that the manipulation of the domain resolution order > is a rare operation (ideally only once all trusts are established), so I > am not convinced that it is worth investing into designing higher-level API > > I propose we first develop the "dumber" parts first to unblock the SSSD > part. If we have spare cycle afterwards then we can design and implement > more bells-and-whistles afterwards. > > [1] https://www.freeipa.org/page/V4/AD_User_Short_Names > [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Thank you Martin, this is a good initial proposal. I have a few issues with this design: - It conflates the idea of ordering with the idea of shortening user names - It allows only for one setting for all the machines, no way to treat different groups of machines differently The first one is probably just a matter of using a more specific name for the new attribute, or, perhaps not use a new attribute at all but just use ipaConfigString with an agreed syntax like: ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd The side effect of using ipaConfigString is that we can set this on older servers too, so people do not have to upgrade their servers to use this. Old servers will not have any validation, but that is ok, sssd must be prepared to receive a bad list and deal with it appropriately anyway. The second one is something we *may* address later, and use the setting in cn=ipaConfig as a default, but there are two reasons why I think a setting applicable to just a host group makes sense: - it allows to test the setting on a small set of machines to see if everything works right, this is going to be especially important on existing setups, where people do not want to risk all machines misbehaving at once if something goes wrong. - it allows to migrate machines slowly, in some cases people may need to change local files/application settings on machines if the usernames change, so they may need a controlled roll out before changing a setting globally. This may achieved by adding this setting to an ID View for example, then only hosts in that IDView would get this. Or a new object could be created that has members, the former has the advantage of being already in place and SSSD already downloads that data, the latter allows to target an even smaller set of hosts unrelated to previous ID views settings. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On ke, 01 maalis 2017, Jan Cholasta wrote: On 1.3.2017 14:05, Alexander Bokovoy wrote: On ke, 01 maalis 2017, Jan Cholasta wrote: On 1.3.2017 13:39, Martin Babinsky wrote: Alexander, thank you for your comments. Replies inline: On 02/28/2017 01:48 PM, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. The validation is described in a Design section as follows: """ Finally, any modification of the domain resolution order must ensure that each of the specified domain names corresponds either to that of FreeIPA domain or to one of the trusted AD domains stored in LDAP backend. In the case of trusted domains, the domain must not be marked as disabled. """ Is this sufficient or is a more thorough validation required? Shall I split the whole section into sub-sections for easier navigation? - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. I have discussed this with Jan and consulted the same document that you cited, that's why I have arrived to the conclusion to use whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain names or should we consider other options to avoid breakage with more exotic domain names? Actually I would prefer something else than whitespace as a separator. A ':' maybe? or ',' or ';'. Any would work. I have considered a empty attribute value to be a distinct state from the missing attribute and assigned a different semantic meaning to it. The reasoning is as follows: if the attribute is not set, SSSD will not retrieve it and this signals that it should continue operate in usual way. If the attribute is present but is empty, the semantics change slightly as now we consider *no* domains during short name resolution (extension of the missing domain behavior to the case of all domains are missing from list). It doesn't have to be literally empty (LDAP character string syntaxes don't allow it anyway IIRC), there can be a value which denotes an empty list of domain (e.g. the separator alone). I don't see *why* there should be this distinction. The deciding party is SSSD. Whether this attirbute exists and empty or does not exist at all does not change anything. Changing how SSSD interprets own defaults depending on absense or emptiness of certain attribute in IPA config object is not user friendly at all. SSSD default behavior should stay the same whether it finds missing or empty attribute because the attribute will not be known to older SSSD anyway. Missing or empty attribute should, in my opinion, be equal to older SSSD behavior. "No value is set in configuration => use built-in default / some value is set configuration => use the value" is perfectly user friendly and pretty much common virtually everywhere I believe, much more so than "empty value is set in configuration => ignore the value even if the user deliberately set it empty and use the default value instead". I'm not arguing with "no value is set in configuration -> use built-in default". I do argue on having empty but present attribute because it does not add anything useful for SSSD to decide on. And as it is not adding anything useful, why there should be such difference at all? This is the only que
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 1.3.2017 14:05, Alexander Bokovoy wrote: On ke, 01 maalis 2017, Jan Cholasta wrote: On 1.3.2017 13:39, Martin Babinsky wrote: Alexander, thank you for your comments. Replies inline: On 02/28/2017 01:48 PM, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. The validation is described in a Design section as follows: """ Finally, any modification of the domain resolution order must ensure that each of the specified domain names corresponds either to that of FreeIPA domain or to one of the trusted AD domains stored in LDAP backend. In the case of trusted domains, the domain must not be marked as disabled. """ Is this sufficient or is a more thorough validation required? Shall I split the whole section into sub-sections for easier navigation? - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. I have discussed this with Jan and consulted the same document that you cited, that's why I have arrived to the conclusion to use whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain names or should we consider other options to avoid breakage with more exotic domain names? Actually I would prefer something else than whitespace as a separator. A ':' maybe? or ',' or ';'. Any would work. I have considered a empty attribute value to be a distinct state from the missing attribute and assigned a different semantic meaning to it. The reasoning is as follows: if the attribute is not set, SSSD will not retrieve it and this signals that it should continue operate in usual way. If the attribute is present but is empty, the semantics change slightly as now we consider *no* domains during short name resolution (extension of the missing domain behavior to the case of all domains are missing from list). It doesn't have to be literally empty (LDAP character string syntaxes don't allow it anyway IIRC), there can be a value which denotes an empty list of domain (e.g. the separator alone). I don't see *why* there should be this distinction. The deciding party is SSSD. Whether this attirbute exists and empty or does not exist at all does not change anything. Changing how SSSD interprets own defaults depending on absense or emptiness of certain attribute in IPA config object is not user friendly at all. SSSD default behavior should stay the same whether it finds missing or empty attribute because the attribute will not be known to older SSSD anyway. Missing or empty attribute should, in my opinion, be equal to older SSSD behavior. "No value is set in configuration => use built-in default / some value is set configuration => use the value" is perfectly user friendly and pretty much common virtually everywhere I believe, much more so than "empty value is set in configuration => ignore the value even if the user deliberately set it empty and use the default value instead". -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On ke, 01 maalis 2017, Jan Cholasta wrote: On 1.3.2017 13:39, Martin Babinsky wrote: Alexander, thank you for your comments. Replies inline: On 02/28/2017 01:48 PM, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. The validation is described in a Design section as follows: """ Finally, any modification of the domain resolution order must ensure that each of the specified domain names corresponds either to that of FreeIPA domain or to one of the trusted AD domains stored in LDAP backend. In the case of trusted domains, the domain must not be marked as disabled. """ Is this sufficient or is a more thorough validation required? Shall I split the whole section into sub-sections for easier navigation? - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. I have discussed this with Jan and consulted the same document that you cited, that's why I have arrived to the conclusion to use whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain names or should we consider other options to avoid breakage with more exotic domain names? Actually I would prefer something else than whitespace as a separator. A ':' maybe? or ',' or ';'. Any would work. I have considered a empty attribute value to be a distinct state from the missing attribute and assigned a different semantic meaning to it. The reasoning is as follows: if the attribute is not set, SSSD will not retrieve it and this signals that it should continue operate in usual way. If the attribute is present but is empty, the semantics change slightly as now we consider *no* domains during short name resolution (extension of the missing domain behavior to the case of all domains are missing from list). It doesn't have to be literally empty (LDAP character string syntaxes don't allow it anyway IIRC), there can be a value which denotes an empty list of domain (e.g. the separator alone). I don't see *why* there should be this distinction. The deciding party is SSSD. Whether this attirbute exists and empty or does not exist at all does not change anything. Changing how SSSD interprets own defaults depending on absense or emptiness of certain attribute in IPA config object is not user friendly at all. SSSD default behavior should stay the same whether it finds missing or empty attribute because the attribute will not be known to older SSSD anyway. Missing or empty attribute should, in my opinion, be equal to older SSSD behavior. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On ke, 01 maalis 2017, Martin Babinsky wrote: Alexander, thank you for your comments. Replies inline: On 02/28/2017 01:48 PM, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. The validation is described in a Design section as follows: """ Finally, any modification of the domain resolution order must ensure that each of the specified domain names corresponds either to that of FreeIPA domain or to one of the trusted AD domains stored in LDAP backend. In the case of trusted domains, the domain must not be marked as disabled. """ Is this sufficient or is a more thorough validation required? Shall I split the whole section into sub-sections for easier navigation? I think it would be good to increase visibility by making subsections. However, I'd like to spell it out that trusted forest root domain is also verified on the list. We have trusts structured hierarchically, this means both levels have to be checked. - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. I have discussed this with Jan and consulted the same document that you cited, that's why I have arrived to the conclusion to use whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain names or should we consider other options to avoid breakage with more exotic domain names? - "If ipaDomainResolutionOrder is empty then *all* users must use fully qualified names." This is not correct with regards to the current behavior. I think we should change this to "if ipaDomainResolutionOrder is empty, then standard SSSD configuration logic applies on each client." This would make current behavior compatible with either empty or ipaDomainResolutionOrder value of a single IPA domain name. I have considered a empty attribute value to be a distinct state from the missing attribute and assigned a different semantic meaning to it. The reasoning is as follows: if the attribute is not set, SSSD will not retrieve it and this signals that it should continue operate in usual way. If the attribute is present but is empty, the semantics change slightly as now we consider *no* domains during short name resolution (extension of the missing domain behavior to the case of all domains are missing from list). I'd rather avoid making this distinction. You always can override things on SSSD side and default on SSSD side is to *not* use fully qualified domain names for a domain. I don't think we have any use case of having all domains with fully qualified names. Even in case of NFS and sss_rpcidmapd, SSSD will happily handle both non-fully qualified names and fully qualified ones. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 1.3.2017 13:39, Martin Babinsky wrote: Alexander, thank you for your comments. Replies inline: On 02/28/2017 01:48 PM, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. The validation is described in a Design section as follows: """ Finally, any modification of the domain resolution order must ensure that each of the specified domain names corresponds either to that of FreeIPA domain or to one of the trusted AD domains stored in LDAP backend. In the case of trusted domains, the domain must not be marked as disabled. """ Is this sufficient or is a more thorough validation required? Shall I split the whole section into sub-sections for easier navigation? - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. I have discussed this with Jan and consulted the same document that you cited, that's why I have arrived to the conclusion to use whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain names or should we consider other options to avoid breakage with more exotic domain names? Actually I would prefer something else than whitespace as a separator. A ':' maybe? - "If ipaDomainResolutionOrder is empty then *all* users must use fully qualified names." This is not correct with regards to the current behavior. I think we should change this to "if ipaDomainResolutionOrder is empty, then standard SSSD configuration logic applies on each client." This would make current behavior compatible with either empty or ipaDomainResolutionOrder value of a single IPA domain name. I have considered a empty attribute value to be a distinct state from the missing attribute and assigned a different semantic meaning to it. The reasoning is as follows: if the attribute is not set, SSSD will not retrieve it and this signals that it should continue operate in usual way. If the attribute is present but is empty, the semantics change slightly as now we consider *no* domains during short name resolution (extension of the missing domain behavior to the case of all domains are missing from list). It doesn't have to be literally empty (LDAP character string syntaxes don't allow it anyway IIRC), there can be a value which denotes an empty list of domain (e.g. the separator alone). That is however open to discussion and I think we can even get away from this by letting SSSD guys to decide how to handle this case. - There are typos in the page. I know there was not much proofreading involved in this iteration. I have already tried to fix them. [1] https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers,-domains,-sites,-and-ous -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
Alexander, thank you for your comments. Replies inline: On 02/28/2017 01:48 PM, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. The validation is described in a Design section as follows: """ Finally, any modification of the domain resolution order must ensure that each of the specified domain names corresponds either to that of FreeIPA domain or to one of the trusted AD domains stored in LDAP backend. In the case of trusted domains, the domain must not be marked as disabled. """ Is this sufficient or is a more thorough validation required? Shall I split the whole section into sub-sections for easier navigation? - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. I have discussed this with Jan and consulted the same document that you cited, that's why I have arrived to the conclusion to use whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain names or should we consider other options to avoid breakage with more exotic domain names? - "If ipaDomainResolutionOrder is empty then *all* users must use fully qualified names." This is not correct with regards to the current behavior. I think we should change this to "if ipaDomainResolutionOrder is empty, then standard SSSD configuration logic applies on each client." This would make current behavior compatible with either empty or ipaDomainResolutionOrder value of a single IPA domain name. I have considered a empty attribute value to be a distinct state from the missing attribute and assigned a different semantic meaning to it. The reasoning is as follows: if the attribute is not set, SSSD will not retrieve it and this signals that it should continue operate in usual way. If the attribute is present but is empty, the semantics change slightly as now we consider *no* domains during short name resolution (extension of the missing domain behavior to the case of all domains are missing from list). That is however open to discussion and I think we can even get away from this by letting SSSD guys to decide how to handle this case. - There are typos in the page. I know there was not much proofreading involved in this iteration. I have already tried to fix them. [1] https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers,-domains,-sites,-and-ous -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On ke, 01 maalis 2017, David Kupka wrote: On Tue, Feb 28, 2017 at 02:48:02PM +0200, Alexander Bokovoy wrote: On ti, 28 helmi 2017, Martin Babinsky wrote: > Hello list, > > I have put together a draft of design page describing server-side > implementation of user short name -> fully-qualified name resolution.[1] > > In the end I have taken the liberty to change a few aspects of the > design we have agreed on before and I will be grad if we can discuss > them further. > > Me and Honza have discussed the object that should hold the domain > resolution order and given the fact that IPA domain can also be a part > of this list, we have decided that this information is no longer bound > to trust configuration and should be a part of the global config > instead. > > Also we have purposefully cut down the API only to a raw manipulation of > the attribute using an option of `ipa config-mod`. The reasons for this > are twofold: > > * the developer resources are quite scarce and it may be good to follow > YAGNI[2] principle to implement the dumbest API now and not to invest > into more high-level interface unless there is a demand for it > > * we can imagine that the manipulation of the domain resolution order > is a rare operation (ideally only once all trusts are established), so I > am not convinced that it is worth investing into designing higher-level > API > > I propose we first develop the "dumber" parts first to unblock the SSSD > part. If we have spare cycle afterwards then we can design and implement > more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. - "If ipaDomainResolutionOrder is empty then *all* users must use fully qualified names." This is not correct with regards to the current behavior. I think we should change this to "if ipaDomainResolutionOrder is empty, then standard SSSD configuration logic applies on each client." This would make current behavior compatible with either empty or ipaDomainResolutionOrder value of a single IPA domain name. Would it make sense to add ipaDomainResolutionOrder attribute during upgrade with the FreeIPA domain and have the behavior as proposed? That would ensure that users will be resolved the same way as before unless someone changes the attribute. I'm not sure it changes anything. Newer SSSD still needs to handle cases when talking to servers which has no ipaDomainResolutionOrder attribute so they would treat missing attribute the same way which means we don't need to handle upgrade here. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On Tue, Feb 28, 2017 at 02:48:02PM +0200, Alexander Bokovoy wrote: > On ti, 28 helmi 2017, Martin Babinsky wrote: > > Hello list, > > > > I have put together a draft of design page describing server-side > > implementation of user short name -> fully-qualified name resolution.[1] > > > > In the end I have taken the liberty to change a few aspects of the > > design we have agreed on before and I will be grad if we can discuss > > them further. > > > > Me and Honza have discussed the object that should hold the domain > > resolution order and given the fact that IPA domain can also be a part > > of this list, we have decided that this information is no longer bound > > to trust configuration and should be a part of the global config > > instead. > > > > Also we have purposefully cut down the API only to a raw manipulation of > > the attribute using an option of `ipa config-mod`. The reasons for this > > are twofold: > > > > * the developer resources are quite scarce and it may be good to follow > > YAGNI[2] principle to implement the dumbest API now and not to invest > > into more high-level interface unless there is a demand for it > > > > * we can imagine that the manipulation of the domain resolution order > > is a rare operation (ideally only once all trusts are established), so I > > am not convinced that it is worth investing into designing higher-level > > API > > > > I propose we first develop the "dumber" parts first to unblock the SSSD > > part. If we have spare cycle afterwards then we can design and implement > > more bells-and-whistles afterwards. > Looks mostly OK, but there are few comments I have: > > - I do not see you mention how validation of the > ipaDomainResolutionOrder is done. This is important to avoid hard to > debug issues because SSSD will ignore domains it doesn't know about. > > - Space separator initially caused me to look up DNS RFCs as strictly > speaking domain names can contain any 8-bit octet (while host names > should follow LDH rule). But then [1] does explicitly say space is not > allowed in AD domain names. > > - "If ipaDomainResolutionOrder is empty then *all* users must use fully > qualified names." This is not correct with regards to the current > behavior. I think we should change this to "if > ipaDomainResolutionOrder is empty, then standard SSSD configuration > logic applies on each client." This would make current behavior > compatible with either empty or ipaDomainResolutionOrder value of > a single IPA domain name. Would it make sense to add ipaDomainResolutionOrder attribute during upgrade with the FreeIPA domain and have the behavior as proposed? That would ensure that users will be resolved the same way as before unless someone changes the attribute. > > - There are typos in the page. > > [1] > https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers,-domains,-sites,-and-ous > > > -- > / Alexander Bokovoy > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- David Kupka signature.asc Description: PGP signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On ti, 28 helmi 2017, Martin Babinsky wrote: Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. Looks mostly OK, but there are few comments I have: - I do not see you mention how validation of the ipaDomainResolutionOrder is done. This is important to avoid hard to debug issues because SSSD will ignore domains it doesn't know about. - Space separator initially caused me to look up DNS RFCs as strictly speaking domain names can contain any 8-bit octet (while host names should follow LDH rule). But then [1] does explicitly say space is not allowed in AD domain names. - "If ipaDomainResolutionOrder is empty then *all* users must use fully qualified names." This is not correct with regards to the current behavior. I think we should change this to "if ipaDomainResolutionOrder is empty, then standard SSSD configuration logic applies on each client." This would make current behavior compatible with either empty or ipaDomainResolutionOrder value of a single IPA domain name. - There are typos in the page. [1] https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers,-domains,-sites,-and-ous -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Please review: V4/AD user short names design draft
Hello list, I have put together a draft of design page describing server-side implementation of user short name -> fully-qualified name resolution.[1] In the end I have taken the liberty to change a few aspects of the design we have agreed on before and I will be grad if we can discuss them further. Me and Honza have discussed the object that should hold the domain resolution order and given the fact that IPA domain can also be a part of this list, we have decided that this information is no longer bound to trust configuration and should be a part of the global config instead. Also we have purposefully cut down the API only to a raw manipulation of the attribute using an option of `ipa config-mod`. The reasons for this are twofold: * the developer resources are quite scarce and it may be good to follow YAGNI[2] principle to implement the dumbest API now and not to invest into more high-level interface unless there is a demand for it * we can imagine that the manipulation of the domain resolution order is a rare operation (ideally only once all trusts are established), so I am not convinced that it is worth investing into designing higher-level API I propose we first develop the "dumber" parts first to unblock the SSSD part. If we have spare cycle afterwards then we can design and implement more bells-and-whistles afterwards. [1] https://www.freeipa.org/page/V4/AD_User_Short_Names [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code