[SSSD] Online detection issues going forward

Jan Engelhardt jengelh at inai.de
Wed Jun 27 12:01:24 UTC 2012


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?



More information about the sssd-devel mailing list