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

Tue Feb 23 10:00:39 UTC 2016

Hi,

On 19.2.2016 16:31, Simo Sorce wrote:
> On Fri, 2016-02-19 at 08:58 +0100, Petr Spacek wrote:
>> On 4.2.2016 18:21, Petr Spacek wrote:
>>> On 3.2.2016 18:41, Petr Spacek wrote:
>>>> Hello,
>>>>
>>>> I've updated the design page
>>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism
>>>>
>>>> Namely it now contains 'Version 2'.
>>>
>>> Okay, here is the idea how we can make it flexible:
>>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Implementation
>>
>> Hello,
>>
>> I'm thinking about LDAP schema for DNS locations.
>>
>> Purpose
>> =======
>> * Allow admins to define any number of locations.
>> * 1 DNS server advertises at most 1 location.
>> * 1 location generally contains set of services with different priorities and
>> weights (in DNS SRV terms).
>> * Express server & service priority for each defined location in a way which
>> is granular and flexible and ad the same time easy to manage.
>>
>>
>> Proposal
>> ========
>> a) Container for locations
>> --------------------------
>> cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>
>>
>> b) 1 location
>> -------------
>> Attributes:
>> 2.16.840.1.113730.3.8.5.32     idnsLocationMember
>> Server/service assigned to a DNS Location. Usually used to define 'main'
>> servers for that location. Should it point to service DNs to be sure we have
>> smooth upgrade to containers?

Services always live on a host (call it server or not), so IMO it makes 
sense to point to servers.

>>
>> 2.16.840.1.113730.3.8.5.33     idnsBackupLocation
>> Pointer to another location. Sucks in all servers from that location as one
>> group with the same priority. Easy to use with _default location where all
>> 'other' servers are used as backup.
>>
>> These two attributes use sub-type priority<number> and relativeweight<number>.
>> This is the only way I could express all the information without need for
>> separate objects.

I don't see the benefit here. What is wrong with separate objects? Why 
is it necessary to reinvent the wheel and abuse attribute sub-types for 
this, losing schema integrity checks provided by DS and making the 
implementation more complex along the way?

>>
>>
>> Object classes:
>> 2.16.840.1.113730.3.8.6.7      idnsLocation
>> MAY ( idnsLocationMember $ idnsBackupLocation )
>>
>>
>> 1st example:
>> Location CZ:
>> - servers czserver1, czserver2
>> - priority=1
>> - relative weight = 50 % each
>> - if both CZ servers fail, use servers in location UK as backup (priority 2)
>> - if all CZ and UK servers fail, use servers in location US as backup
>> (priority 3) - servers on the other continent are used only as option of last
>> resort
>> DN: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>> objectClass: idnsLocation
>> idnsLocationMember;priority1;relativeweight50:
>> cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> idnsLocationMember;priority1;relativeweight50:
>> cn=czserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>> idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>
>> Location UK:
>> - servers ukserver1, ukserver2
>> - priority=1
>> - server ukserver1 is a new beefy machine so it can handle 3 times more load
>> than ukserver2, thus relative weights 75 % and 25 %
>> - if both UK servers fail, use servers in location CZ as backup (priority 2)
>> - if all CZ and UK servers fail, use servers in location US as backup
>> (priority 3) - servers on the other continent are used only as option of last
>> resort
>> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>> objectClass: idnsLocation
>> idnsLocationMember;priority1;relativeweight3:
>> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> idnsLocationMember;priority1;relativeweight1:
>> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>> idnsBackupLocation;priority3: cn=us,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>
>> Location US:
>> - servers usserver1, usserver2
>> - priority=1
>> - relative weight = 50 % each
>> - if both US servers fail, use servers in location CZ and UK as backup
>> (priority 2) - it is over ocean anyway, so US clients will not make any
>> difference between CZ and UK locations
>> DN: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>> objectClass: idnsLocation
>> idnsLocationMember;priority1;relativeweight50:
>> cn=ukserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> idnsLocationMember;priority1;relativeweight50:
>> cn=ukserver2,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> idnsBackupLocation;priority2: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>> idnsBackupLocation;priority2: cn=uk,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>
>>
>> Resulting DNS SRV records (generated by FreeIPA framework). Please note that
>> only numbers in SRV records matter only relatively. Priorities work as group,
>> weights are relative only inside the group. Absolute values above are used
>> only in algorithm which generates SRV records:
>> Location CZ:
>> _kerberos._udp SRV 1 50 czserver1
>> _kerberos._udp SRV 1 50 czserver2
>> _kerberos._udp SRV 2 75 ukserver1
>> _kerberos._udp SRV 2 25 ukserver1
>> _kerberos._udp SRV 3 50 usserver1
>> _kerberos._udp SRV 3 50 usserver2
>>
>> Location UK:
>> _kerberos._udp SRV 1 75 ukserver1
>> _kerberos._udp SRV 1 25 ukserver1
>> _kerberos._udp SRV 2 50 czserver1
>> _kerberos._udp SRV 2 50 czserver2
>> _kerberos._udp SRV 3 50 usserver1
>> _kerberos._udp SRV 3 50 usserver2
>>
>> Location US:
>> _kerberos._udp SRV 1 50 usserver1
>> _kerberos._udp SRV 1 50 usserver2
>> _kerberos._udp SRV 2 250 czserver1
>> _kerberos._udp SRV 2 250 czserver2
>> _kerberos._udp SRV 2 375 ukserver1
>> _kerberos._udp SRV 2 125 ukserver1
>>
>>
>> 2nd example:
>> - 10 locations with 4 servers each
>> - we want to have use only 1 server from each location as backup so clients
>> will not spend a lot of time while attempting to contact cut-off branch (e.g.
>> when remote WAN link is down)
>> -> use only idnsLocationMember attribute instead of idnsBackupLocation attribute
>>
>>
>> Fancier combinations are possible with this schema. I assume that fancy things
>> will be necessary later on if/when IPA supports large topologies.
>>
>>
>>
>> c) Assigning DNS servers to locations:
>> Each DNS server can advertise at most 1 location as 'default' to its clients.
>>
>> Attributes:
>> 2.16.840.1.113730.3.8.5.34 idnsAdvertisedLocation
>> Pointer to a idnsLocation object. On DNS service object / external server.
>> Single-valued.

IMO this should be attribute of server rather than service, given that 
idnsLocationMember points to servers rather than services.

Or, if there is an actual use case for different DNS services (internal 
or external) on the same server to reside in different locations, change 
idnsLocationMember to point to services rather than servers.

>>
>> Example:
>> DN: cn=DNS,cn=czserver1,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> idnsAdvertisedLocation: cn=cz,cn=locations,cn=ipa,cn=etc,dc=example,dc=com
>>
>> When we start integrating with external DNS we will need a special object to
>> represent external DNS servers. We can deal with that later on.
>>
>>
>> d) User interface
>> This is the hardest thing.
>>
>> First rough idea can be seen on
>> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#UI
>>
>> I would think about CLI when we agree on WebUI, IMHO it will be easier.
>>
>>
>> What do you think? I'm waiting for your comments ;-)
>
> I am thinking about it, on the surface it all looks quite reasonable.
> I think the UI is alittle messy, I wonder if we want to expose lower
> level concepts as priority and groups, or if we just want to allow users
> to set an order in the UI and then let the framework come up with weight
> an priority numbers to assign.

+1, it seems to me that locations are a rather standalone concept, so 
why tie them to DNS like this?

> Maybe have a way in the CLI to override the decisions of the framework
> and set explicit weights ?

-- 
Jan Cholasta