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? bye, Sumit > > _______________________________________________ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
