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.