[SSSD] Online detection issues going forward

Stephen Gallagher sgallagh at redhat.com
Wed Jun 27 11:23:44 UTC 2012


Right now, SSSD has two mechanisms for detecting a shift in network
state in order to determine if it should attempt to go online
immediately. This is done to ensure that cached entries get updated as
quickly as possible and so that if the provider offers online callbacks
(such as the deferred kinit feature of the krb5 provider) they will fire
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.

2) We set an inotify watch on /etc/resolv.conf to be notified if the DNS
information changes.


In the current default configuration of Fedora, we actually end up
relying more often on 2) than 1) in the case of VPNs. The reason for
this is that when we join a VPN, we are notified that the network has
changed, but in many cases we still cannot connect to the servers until
NetworkManager has also updated /etc/resolv.conf. This is because in the
common VPN case, the DNS entry for the identity and authentication
servers are also located inside the VPN.

So in this situation, our current behavior is to actually try twice to
connect to the servers; the first time when we notice the network change
and the second for when resolv.conf is modified. In situations where DNS
for the identity and auth servers are inside the VPN, it's always this
second attempt that succeeds.

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. This is the current default for NetworkManager
on Fedora and RHEL systems, but this will not be the case soon.

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.

This becomes more urgent because a similar approach is currently planned
to become the default in Fedora 18. This approach will use 'unbound'
instead of 'dnsmasq' in order to facilitate the use of DNSSEC on all
Fedora clients, but the effect will be the same. /etc/resolv.conf will
remain static and configuration changes will occur in 'unbound' instead.

So we need to come up with a new way to deal with the "DNS servers
behind a VPN" use-case that will play nicer with these two solutions (or
better still, work generically).

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.
-------------- 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/437d44f0/attachment.sig>


More information about the sssd-devel mailing list