If an application destroys the lrwxrwxrwx 1 root root 26 Jan 30 10:32 resolv.conf -> resolvconf/run/resolv.conf link, resolvconf does not recover from this. The link has to be manually re-created (ln -s resolvconf/run/resolv.conf) or DNS resolving does not work with any subsequent reboots or even when roaming from a wireless LAN to another. This is apparently due to the following in /etc/resolvconf/update.d/libc: [[ $(readlink /etc/resolv.conf 2>/dev/null) \ != "resolvconf/run/resolv.conf" ]] && exit 0 So it's just an "exit 0" without any possibility to recover. Anyway, my beef, specifically is with Cisco's vpn client (net-misc/cisco-vpnclient-3des). When I activate the VPN, this happens in /etc: etc # ls -l res* -rw-r--r-- 1 root root 34 Oct 12 15:08 reslisarc -rw-r--r-- 1 root users 76 Jan 30 11:29 resolv.conf lrwxrwxrwx 1 root root 26 Jan 30 10:32 resolv.conf.vpnbackup -> resolvconf/run/resolv.conf If the VPN connection is terminated *gracefully* the client restores the original resolv.conf and nothing much happens. If stuff goes wrong, such as the WLAN (or PPP) interface suddendly going down the backup is not restored. I've actually had a kernel panic once when an interface went down. Granted, this kinds of ungraceful exiting is a Cisco-specific problem. Anyway, I'm not sure if this resolv.conf-issue is something that only appears with Cisco-vpn, or is the scope wider (other VPN packages?). If not, the problem may be addressed with the ciscovpn-ebuild (if feasible). However, I'd still like to have some sort of recovery feature for this. Maybe some sort of RC option "FORCE_RESOLVCONF=1" or something that would *always* recreate the link and overwrite whatever is going on in there. However, just overwriting is not always an option. If I have a VPN connection and the files that are active are as above (backup and VPN-client-written resolv.conf), what happens when DHCP (on the underlying logical interface) renews the lease? The DNS information received from the VPN tunnel by the client is overwritten with the underlying iface's (eth0 or something) DNS information... Anyway, Cc's set to people who I think are responsible for Ciscovpn package and resolvconf. Hopefully this gets resolved sometime.
(In reply to comment #0) > If an application destroys the > > lrwxrwxrwx 1 root root 26 Jan 30 10:32 resolv.conf -> > resolvconf/run/resolv.conf > > link, resolvconf does not recover from this. The link has to be manually > re-created (ln -s resolvconf/run/resolv.conf) or DNS resolving does not work > with any subsequent reboots or even when roaming from a wireless LAN to > another. > > This is apparently due to the following in /etc/resolvconf/update.d/libc: > > [[ $(readlink /etc/resolv.conf 2>/dev/null) \ > != "resolvconf/run/resolv.conf" ]] && exit 0 > > So it's just an "exit 0" without any possibility to recover. This is behaviour by design - if resolvconf isn't controlling /etc/resolv.conf then it won't do anything with the libc update script. Instead, each package should use resolvconf when available. Packages converted to use resolvconf baselayout dhcpcd dhclient udhcpc pump openvpn > However, just overwriting is not always an option. If I have a VPN connection > and the files that are active are as above (backup and VPN-client-written > resolv.conf), what happens when DHCP (on the underlying logical interface) > renews the lease? The DNS information received from the VPN tunnel by the > client is overwritten with the underlying iface's (eth0 or something) DNS > information... Exactly. Forcing a recreation of the link in resolvconf is pointless if resolvconf isn't used by everything in the chain. http://www.fmepnet.org/debian_vpnc.html Shows that Debian can use vpnc with resolvconf, so it can be done. Reassigning as vpnc will have to be fixed, not resolvconf.
(In reply to comment #1) > This is behaviour by design - if resolvconf isn't controlling /etc/resolv.conf > then it won't do anything with the libc update script. Instead, each package > should use resolvconf when available. How about still creating the symlink, at least during boot, maybe in bootmisc or net.lo, even if not touching it later? (Namely addressing the crash recovery thing...situations where resolvconf isn't controlling /etc/resolv.conf but so is nothing else, either... - so system should fall back to resolvconf. If at no other time, at least upon reboot it should be safe to assume that nothing else is controlling /etc/resolv.conf.) Hopefully the vpnc-specific stuff gets addressed too.
Umm... vpnc != cisco-vpnclient-3des (which is not open source)... There's absolutely nothing I can do for the cisco-vpnclient-3des package, which is the only thing I maintain. While vpnc can be used to connect to Cisco VPN Concentrators (and PIX, etc), I don't have anything to do with that package.
We can't fix closed source stuff, but we can work with vpnc then. Hanno, Debian support vpnc with resolvconf, so I suggest you grab their patch.
Drat. I could switch to vpnc if it would work for me. However, according to vpnc homepage, it does not support certificates, which makes it kinda useless in any real environment (pre-shared keys are not really used in enterprise deployments - you kinda need to be able to at least authenticate the concentrator.). Oh well, I guess I'm stuck with Cisco - which kinda brings me back to comment #2 - could resolvconf somehow detect or at least assume in certain situations (such as during boot) that while resolvconf does not apparently control /etc/resolv.conf at the time due to bad or missing symlink, neither does anything else (since system is just starting up!). Oh well, I guess I'll just add the symlink creation/overwrite to local.start for the time being.
Ebuild on bug #201853 fixes this.
Do the hook scripts for vpnc not solve your problem? One can call resolvonf -u from there.
(In reply to comment #7) > Do the hook scripts for vpnc not solve your problem? One can call resolvonf -u > from there. Not really since cisco-vpnclient just alters resolv.conf without allowing any hooking. Anyway, fix in bug #228001 works for me.
Closing this one, too.
