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

Tue Feb 23 15:37:07 UTC 2016

On 02/19/2016 04:31 PM, 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?
>>
>> 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.
>>
>>
>> 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.
>>
>> 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.
> Maybe have a way in the CLI to override the decisions of the framework
> and set explicit weights ?
>
> Simo.
>

The UI seems OK to me.

Let's say that we would let user define only the order. How would the 
server come up with weights and priorities? Or how would it know that 
some servers are equal (same prio and weight).

Then if server would compute the priorities it would be nice to see if 
some are the same(forms a group).

I would continue with drafting CLI. It may help us with Web UI.

Then focus on LDAP structure. Right now I'm not very fond of usage of 
multiple subtypes. It looks like a workaround of subentries to me.
-- 
Petr Vobornik