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

[Martin Basti]

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