[Freeipa-devel] Locations design v2: LDAP schema & user interface

[Aleš Mareček]

Design doc reviewed. Some minor specifications discussed with Petr and Martin, added to the doc. UQE_ACK.
Thanks,
 - alich -

----- Original Message -----
> From: "Martin Basti" <mbasti at redhat.com>
> To: "Simo Sorce" <simo at redhat.com>, "Petr Spacek" <pspacek at redhat.com>
> Cc: freeipa-devel at redhat.com
> Sent: Thursday, April 21, 2016 7:39:02 PM
> Subject: Re: [Freeipa-devel] Locations design v2: LDAP schema & user	interface
> 
> 
> 
> On 21.04.2016 18:58, Simo Sorce wrote:
> > On Thu, 2016-04-21 at 17:39 +0200, Petr Spacek wrote:
> >> On 19.4.2016 19:17, Simo Sorce wrote:
> >>> On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote:
> >>>> On 18.4.2016 21:33, Simo Sorce wrote:
> >>>>> On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote:
> >>>>>> * Find, filter and copy hand-made records from main tree into the
> >>>>>> <tt>_locations</tt> sub-trees. This means that every hand-made record
> >>>>>> needs to be copied and synchronized N-times where N = number of IPA
> >>>>>> locations.
> >>>>> This ^^ seem the one that provides the best semantics for admins and
> >>>>> the
> >>>>> least unexpected results.
> >>>>>
> >>>>>> My favorite option for the first version is 'document that enabling
> >>>>>> DNS location will hide hand-made records in IPA domain.'
> >>>>> I do not think this is acceptable, sorry.
> >>>>>
> >>>>>> The feature is disabled by default and needs additional configuration
> >>>>>> anyway so simply upgrading should not break anything.
> >>>>> It is also useless this way.
> >>>>>
> >>>>>> I'm eager to hear opinions and answers to questions above.
> >>>>> HTH,
> >>>> Well it does not help because you did not answer the questions listed in
> >>>> the
> >>>> design page.
> >>>>
> >>>> Anyway, here is third version of the design. It avoids copying user-made
> >>>> records (basically 2 DNAMEs were replaced with bunch of CNAMEs):
> >>>>
> >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29
> >>>>
> >>>> It seems like a good middle ground:
> >>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals
> >>> It does seem like a decent middle ground.
> >>> And I guess an admin would be able to add custom templates if he wants
> >>> to have specific services forwarded to the location specific subtree ?
> >> Yes, the bind-dyndb-ldap's RecordGenerator and PerServerConfigInLDAP are
> >> generic enough. At the moment we do not plan to expose these mechanisms in
> >> user interface, we might do that later on.
> >>
> >>
> >>>> This required changes in RecordGenerator design, too:
> >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator
> >>> I do not see where you specify the specific record names you forward to
> >>> the location trees here?
> >> I do not understand the question. Let's have a look at the example:
> >>
> >> # DN specifies DNS node name which will hold the generated record:
> >> dn: idnsName=_udp,idnsname=example.com.,cn=dns,dc=example,dc=com
> >> # this is equivalent to _udp.example.com.
> >>
> >> objectClass: idnsTemplateObject
> >> objectClass: top
> >> objectClass: idnsRecord
> >> idnsName: _udp
> >>
> >> # sub-type determines type of the generated record = DNAME
> >> idnsTemplateAttribute;dnamerecord:
> >> _udp.\{substitutionvariable_ipalocation\}._locations
> >> # generated value will be _udp.your-location._locations
> >> # it is a relative name so zone name (example.com) will be automatically
> >> appended
> >>
> >> The template is just string, so you can specify an absolute name if you
> >> want:
> >> idnsTemplateAttribute;dnamerecord:
> >> _udp.\{substitutionvariable_ipalocation\}._locations.another.zone.example.
> >>
> >> Of course 'ipalocation' is just a variable name so user can define his own
> >> in
> >> PerServerConfigInLDAP.
> >>
> >> Is it clearer now?
> > Sorry I thought you said in option 3 that you would only create records
> > for specific services using CNAMEs
> > I was looking for how you configure which services you are going to pick
> > in that case and couldn't see it.
> > This example is a DNAME one and looks to me it is about option 2 ?
> >
> I put there image for version 3 there, and put/fix some implementation
> details there. I will add more implementation details tomorrow.
> 
> Basically, IPA knows what services are on which server (except NTP, will
> be fixed), so based on this we are able to generate proper SRV records
> in all locations, and mark the original one by attribute
> 'idnsTemplateAttribute;cnamerecord'  Please see example here, I will
> refer on it later
> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CNAME_data_generation
> 
> 
> In case that server is not configured to provide Location specific data,
> or the server is old, the original SRV record (marked with
> 'idnsTemplateAttribute') will be used. In case that server is configured
> to provide location specific data, bind-dyndb-ldap will replace the
> original SRV record by CNAME according to location.
> 
> Other SRV records (those not marked by 'idnsTemplateAttribute') are
> untouched.
> 
> Martin
> 
> --
> 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
>