[SSSD] Design Discussion: SSSD should support DNS sites

Simo Sorce simo at redhat.com
Thu Jan 31 16:32:21 UTC 2013


On Thu, 2013-01-31 at 16:40 +0100, Sumit Bose wrote:
> 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.

I see your point but my concern is with site_ctx being 'magic' in that
you can pass NULL at any time to cause a new site discovery and you are
supposed to keep it around, but then offline operation may delete it.
I see a clear risk that at some point you will have a dangling pointer
to a since deleted site_ctx.

I am thinking we should probably have a more permanent context that has
setters to invalidate their internal state when offline happens.

This way the pointer is always valid and can be passed around safely and
store on some long term upper context.

Btw while looking at this is seem that the resolv_ctx could be this long
term context already (so no need for explicit site_ctx, just add a sub
struct in resolv_ctx), and is initialized in data_provider_fo.c in
be_init_failover() which is called from be_process_init().

Unfortunately for some reason resolv_init() is also called by
sdap_sudo_hostname_send() and ipa_dydndns_init(), I can't understand
why, bug ?

> > 
> > 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?

This statement was meant in the context of splitting your function in 2,
one to find the site (where service need not be specified) and then one
function to find the actual service.

But if we conceal site discovery into resolv_ctx, we can simply avoid a
new separate interface altogether.

We simply add site support to the resolver library through a module and
let all current calls be 'magically' made site aware.
We might need to change calls that specify SRV searches so that we
separate Service and Domain, but I think that would be a better
architecture as we can abstract away how we do resolve stuff into a
module of the resolver.

This way when we later add an IPA location discovery mechanism we do not
have to change anything in the common code, we just plug in a different
resolver plugin for 'location' discovery for the ipa domain case.

and we can actually mix both as long as we make the 'site/location'
plugin domain bound (hence why we need to split service and domain
arguments in requests so each request can be bound to the correct site
discovery code.

>  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.

Yes,m we need to change resolv_getsrv_send() to accept a service part
and a domain part, and put site specific code in a resolver plugin
dereferenced opaquely by resolv_ctx.

Of course we will need a setter to 'install' the proper site discovery
mechanism based on the domain on the resolv_ctx.

> > 
> > 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);
> > 
> > 

So scrap this too :-)

> > 
> > > ==== 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?

Good question, but if the site exists it is the 'default' one we
should  ..well ... default to.

> I just thought _ldap._tcp.domain.name will return a
> larger number of DCs to choose from?

This is actually a problem, you may end up trying to access a DC in
Antractica over a Geosynchronous satellite link. I do not think you want
to ever do that unless you live in Antractica :) 

> But I'm not against using the Default-First-Site-Name one here.

I think it should be the default fallback if nothing can be obtained by
a CLDAP ping. 
> Besides that, you mentioned localized version of
> Default-First-Site-Name. Would this be an argument against using it?

No, it is an argument about not assuming the name, but picking the right
one from the CLDAP ping. If the CLDAP ping times out it is ok to 'try'
it, worst case we get back an error and further fallback to searching
SRV records w/o any site component in the name at all.
However I think it is also 'possibly' an argument for having an option
to set what is the site sssd should be bound to. A way to force it.
Just for those cases where sites can be resolved via DNS but CLDAP is
filtered (think VPN access or something).
If an option with a specific site is present, that specific site should
be immediately tried before everything else. If it fails then the usual
discovery mechanism should be used.


Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list