[SSSD] Online detection issues going forward

Stephen Gallagher sgallagh at redhat.com
Wed Jun 27 12:14:57 UTC 2012


On Wed, 2012-06-27 at 14:01 +0200, Jan Engelhardt wrote:
> On Wednesday 2012-06-27 13:23, Stephen Gallagher wrote:
> 
> >SSSD has two mechanisms for detecting a shift in network
> >state in order to determine if it should attempt to go online
> >immediately. [...]
> >1) We register with libnl (a library providing access to kernel netlink
> >APIs) to be notified whenever a network interface comes up or goes down
> >on the system.
> 
> libnl seems like a huge behemoth; perhaps libmnl is a nicer choice?
> 

Well, in the near future we need to re-evaluate libnl anyway, now that
the version we use is aging. We'll have a look at libmnl.

> >2) We set an inotify watch on /etc/resolv.conf to be notified if the DNS
> >information changes.
> >[...]
> >So in this situation, our current behavior is to actually try twice to
> >connect to the servers; [...]
> >However, this behavior makes one very basic assumption: When a VPN or
> >other connection is established to a new network, /etc/resolv.conf will
> >be updated with new data.
> 
> Does it? If sssd already tries twice, once at events from (1) and once
> at events from (2), it would not only rely on resolv.conf.
> 

Well, read further on. The issue is when the DNS server is inside the
VPN. In those cases, we have a race-condition going on at 1). Basically,
if DHCP/VPN config hasn't updated resolv.conf (or dnsmasq or unbound...)
by the time SSSD performs its lookup for the server IP, then it will
just go offline. We added 2) specifically to solve this by forcing a
second lookup once resolv.conf was updated.

> >Currently, it is possible to set up NetworkManager to use dnsmasq for
> >DNS caching by adding dns=dnsmasq to NetworkManager.conf. The effect of
> >this is that NetworkManager will update dnsmasq configuration instead
> >of /etc/resolv.conf. /etc/resolv.conf will then remain static and always
> >pointed at 127.0.0.1. This means that our inotify backup above becomes
> >useless.
> 
> It already is useless. netconfig(8) on SUSE can edit the bind9 config
> IIRC already since quite some time.
> 

Sure, as I mentioned in my original email, there are ways on Fedora
already with dnsmasq that this doesn't work. Fedora is generally our
first-citizen. Most of the core developers work on that platform, so it
gets the most testing. 

> >As a final note, we are not *completely* broken in these situations. We
> >will still eventually go on once a full minute has passed *and* a
> >request that cannot be answered by the cache occurs. But for those users
> >relying on the deferred kinit feature as part of their workflow will see
> >a definite regression in behavior under this scenario.
> 
> So what would you propose, throwing more watches on etc files?
> Or perhaps NetworkManager and netconfig should broadcast some
> dbus event that sssd can listen to?

I'm not actually proposing anything yet. The purpose of this email was
to solicit suggestions from the community. Ideally I'd like to find a
general solution that works everywhere, but this may not be possible.
I'd rather not rely on new inotify watches, since those need to be
updated every time a new tool (dnsmasq->unbound, for example) comes into
play. Being able to register with NetworkManager for when it has updated
DNS configuration would be very nice, but that's only going to work for
situations where NetworkManager is in play.

So I really want to brainstorm in this thread and see what others can
come up with. All suggestions (no matter how crazy or long-shot they may
seem) are welcome at this point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120627/03eabf76/attachment.sig>


More information about the sssd-devel mailing list