[SSSD] Design Discussion: SSSD should support DNS sites

Sumit Bose sbose at redhat.com
Thu Jan 31 15:40:41 UTC 2013


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



More information about the sssd-devel mailing list