[SSSD] Design Discussion: SSSD should support DNS sites

Jakub Hrozek jhrozek at redhat.com
Thu Jan 31 16:44:57 UTC 2013


On Thu, Jan 31, 2013 at 11:32:21AM -0500, Simo Sorce wrote:
> > 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().
> 

Yes this would work, resolv_ctx is permanent, only the c-ares
"channel" (=context in their terminology) changes when resolv.conf is
updated.

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

I think that historically the initialization in the IPA dyndns code was
different because with regular resolving you can talk to both /etc/hosts
and real DNS but with with IPA dyndns you need to make sure to only talk
to DNS server. But the current code doesn't reflect that, so yeah, a bug.

No idea about sudo.



More information about the sssd-devel mailing list