Design doc reviewed. Some minor specifications discussed with Petr and Martin, added to the doc. UQE_ACK. Thanks, - alich -
----- Original Message ----- > From: "Martin Basti" <mba...@redhat.com> > To: "Simo Sorce" <s...@redhat.com>, "Petr Spacek" <pspa...@redhat.com> > Cc: freeipa-devel@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 > -- 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