On Fri, Feb 22, 2013 at 04:32:44PM +0100, Sumit Bose wrote: > On Fri, Feb 22, 2013 at 02:57:08PM +0100, Pavel Březina wrote: > > On 02/22/2013 09:33 AM, Sumit Bose wrote: > > >On Thu, Feb 21, 2013 at 07:02:47PM +0100, Jakub Hrozek wrote: > > >>On Thu, Feb 21, 2013 at 05:16:07PM +0100, Sumit Bose wrote: > > >>>After a discussion with Simo I updated the page again. > > >>> > > >>>bye, > > >>>Sumit > > >>> > > >> > > >>Hi, > > >> > > >>I think this plugin architecture matches what we discussed over the > > >>phone. I only have two questions, one of which is inline. The other is > > >>-- since the AD specific plugin would link with a Samba library, should > > >>I ressurect the patch that splits responders into multiple packages? > > > > > >yes, I think this would help to avoid pull in unwanted dependencies. > > >E.g. AD, IPA provider and PAC responder can be put into a new package > > >which has a dependency on samba(4)-libs. Then the other stuff only > > >depends on libldap and libkrb5. > > > > > >> > > >>>== Use Active Directory's DNS sites == > > >>>Related ticket(s): > > >>>* [https://fedorahosted.org/sssd/ticket/1032 RFE sssd should support DNS > > >>>sites] > > >>> > > >>>=== Problem Statement === > > >>>In larger Active Directory environments there is typically more than one > > >>>domain controller. Some of them are used for redundancy, others to build > > >>>different administrative domains. But in environments with multiple > > >>>physical locations each location often has at least one local domain > > >>>controller to reduce latency and network load between the locations. > > >>> > > >>>Now clients have to find the local or nearest domain controller. For > > >>>this the concept of sites was introduce where each physical location can > > >>>be seen as an individual site with a unique name. The naming scheme for > > >>>DNS service records was extended (see e.g. > > >>>http://technet.microsoft.com/en-us/library/cc759550(v=ws.10).aspx) so > > >>>that clients can first try to find the needed service in the local site > > >>>and can fall back to look in the whole domain if there is no local > > >>>service available. > > >>> > > >>>Additionally clients have to find out about which site they belong to. > > >>>This must be done dynamically because clients might move from one > > >>>location to a different one on regular basis (roaming users). For this a > > >>>special LDAP request, the (C)LDAP ping > > >>>(http://msdn.microsoft.com/en-us/library/cc223811.aspx), was introduced. > > >>> > > >>>=== Overview view of the solution === > > >>>==== General considerations ==== > > >>>The solution in SSSD should take into account that other types of > > >>>domains, e.g. a FreeIPA domain, want to implement their own scheme to > > >>>discover the nearest service of a certain type. A plugin interface where > > >>>the configured ID provider can implement methods to determine the > > >>>location of the client looks like the most flexible solution here. > > >>> > > >>>Since the currently available (AD sites) or discussed schemes > > >>>(http://www.freeipa.org/page/V3/DNS_Location_Mechanism) use DNS SRV > > >>>lookups the plugin will be called in this code path. Since network > > >>>lookups will be needed the plugin interface must allow asynchronous > > >>>operations. SSSD prefers the tevent_req style for asynchronous > > >>>operations where the plugin has to provide a *_send and a *_recv method. > > >>>Besides a list of server names which will be handled as primary servers, > > >>>like the servers currently returned by DNS SRV lookups, the *_recv > > >>>method can additionally return a list of fallback servers to make full > > >>>use of the current fallback infrastructure on SSSD. > > >>> > > >>>==== Sites specific details ==== > > >>> > > >>>The plugin of the AD provider will do the following steps: > > >>>1. do a DNS lookup to find any DC > > >>>1. send a CLDAP ping to the first DC returned to get the client's site > > >>>1. after a timeout send a CLDAP ping to the next DC on the list > > >>>1. if after an overall timeout no response is received the CLDAP lookups > > >>>will be terminated and the client's site is unknown > > >>>1. if the clients site is known a DNS SRV > > >>>_service._protocol.site-name._sites.domain.name for primary server and > > >>>_service._protocol.domain.name for backup server is send, otherwise only > > >>>one with _service._protocol.domain.name is done > > >>>1. if primary and backup server lists are available all primary servers > > >>>are removed from the backup list > > >> > > >>^^^ I don't really understand when can this happen. Is this for the case > > >>when the backup list is configured but the primary list is discovered > > >>from DNS? Then it would be a generic problem, not one specific to site > > >>discovery. > > > > > >No, _service._protocol.domain.name will return all servers in the domain > > >and _service._protocol.site-name._sites.domain.name return the nearest. > > >The nearest are the primary servers. Since the nearest servers will be > > >in the list of all servers, to avoid checking a non working server twice > > >they should be removed there and the remaining servers can be used as > > >backup servers. > > > > > >HTH > > > > > >bye, > > >Sumit > > > > Hi, > > since we are creating a plugin interface, we should use custom data > > type in _recv instead of struct ares_srv_reply. > > makes sense. Then I would suggest that a list ordered according to RFC > 2782 of hostname, port pairs is returned, where the elements then can be > fed directly to create_fo_server(). Do you agree?
For SRV records the RFC 2782 makes sense for sure, but is it also applicable to the AD site discovery? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
