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.