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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
