On Fri, Feb 22, 2013 at 04:41:15PM +0100, Jakub Hrozek wrote: > 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?
yes, since it is alse a SRV request. But there might be other environments where this is different, that's why I think it make sense to let the plugin return the list in a appropriate order. 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
