On Thu, Jan 31, 2013 at 09:43:09AM -0500, Simo Sorce wrote: > On Thu, 2013-01-31 at 10:49 +0100, Sumit Bose wrote: > > Hi, > > > > I have created a design page for > > https://fedorahosted.org/sssd/ticket/1032 "[RFE] sssd should support DNS > > sites" at > > https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSSites . > > It can be found below as well. > > > > Corrections, comments and enhancements are welcome. > > Good start, comments inline! >
> > struct tevent_req *resolv_getsrv_site_send(TALLOC_CTX *mem_ctx, > > struct tevent_context *ev, > > struct resolv_ctx *ctx, > > struct site_ctx *site_ctx, > > const char *service, > > const char *domain); > > I do not think you should have a site_ctx and a resolv_ctx, one or the > other. > If you added site_ctx with the idea of calling this function recursively > then I would object to that, you should have a higher level internal > public function that does the whole processing and an internal private > one that is called multiple times and conceal internal requirements. no, I didn't plan to use it recursively. The idea was to have both of the functions you suggested in one. If site_ctx is NULL, resolv_getsrv_site_send() will do get_site and then srv_by_site. The found site is returned with the corresponding _recv() call so that in later lookups the get_site step can be skipped. If the provider goes offline the saved site_ctx will be deleted so that the get_site step is done again when the provider goes online again. Instead of using a plain char * for the site I took a struct to safe e.g. the nearest site, if available, to have a better fallback step then just Default-First-Site-Name. > > Also I do not know that we really need to specify the service. I thought it is all about finding a specific service in a site? The current resolv_getsrv_send() call only accepts a single string like _service._prot.domain.name. But since we need to put the site string between the service part and the domain part I wanted to avoid error prone splitting of the string in resolv_getsrv_site_send() and preferred to have to two parts as separate strings. > > The site is independent from the service you want to get. So we should > probably have a call that returns the site and a separate call that gets > the site name as input to get a specific service. > > So I would have something like this: > > struct tevent_req *resolv_get_site_send(TALLOC_CTX *mem_ctx, > struct tevent_context *ev, > struct resolv_ctx *ctx, > const char *domain); > > And separately: > struct tevent_req *resolv_srv_by_site_send(TALLOC_CTX *mem_ctx, > struct tevent_context *ev, > struct resolv_ctx *ctx, > const char *site, > const char *domain); > > > > > ==== Finding a DC for the CLDAP ping ==== > > To find any DC in the domain a Windows client, and samba as well, look > > for a _ldap._tcp service record. The only difference is that samba > > uses a plain _ldap._tcp.domain.name while a Windows client > > _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.name. I > > guess it will fall back to _ldap._tcp.domain.name if the other name > > cannot be resolved. I would suggest to use _ldap._tcp.domain.name for > > the SSSD implementation. > > Why ? Using the Default-First-Site-Name one is technically more correct > when multiple sites are in use. Will this return all DCs or only the ones that are not assigned to a specific site? I just thought _ldap._tcp.domain.name will return a larger number of DCs to choose from? But I'm not against using the Default-First-Site-Name one here. Besides that, you mentioned localized version of Default-First-Site-Name. Would this be an argument against using it? bye, Sumit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
