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?
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.
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.
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?