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

Tue, 23 Feb 2016 01:59:40 -0800 

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

--
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

Reply via email to