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.