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
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.
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):


It seems like a good middle ground:
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:
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
# generated value will be _udp.your-location._locations
# it is a relative name so zone name (example.com) will be automatically 

The template is just string, so you can specify an absolute name if you want:

Of course 'ipalocation' is just a variable name so user can define his own in

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.


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to