Bugzilla Bug 164516

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.