resolvconf

baselayout-1.12 forces all dhcp clients to store its resolv.conf in their own locations so they didn’t overwrite each others. It even merged them all together. This works very well. :D

So along comes openvpn with its ability to use an unspecified tun/tap interface (if tun0 is in use it will use tun1, etc) and that wanting to setup it’s own resolv.conf too (not that current portage one does this, but next one will ;) ). The nice thing about openvpn as it is right now is that it doesn’t rely too much on baselayout, and I would like to keep it like this so that when other packages come along that want to say “here, use this dns information now” we have an easy way for them not to stamp on each others toes.

So I got thinking. Gentoo can’t be the only distro that has this problem, so I looked around some. I found Debians resolvconf which does pretty much what baselayout did with resolv.conf but provided a generic framework for managing it. This is what I’ve been looking for as it also provided a framework for subscribers to be notified of a resolv.conf change, something that my solution did not. This means that no-one should have to do a /etc/init.d/nscd restart in their conf.d/net postup anymore :)

So I’m writing a resolvconf for Gentoo at the moment, taking the best bits of baselayout-1.12 (better merging and interface selection based on metrics) and Debians resolvconf (command line compatibility and subscriber framework). Once I get that into portage, I’ll be patching baselayout, our dhcp clients and things like openvpn to use it.

I’m also thinking that instead of patching dhclient for dbus support for up and coming NetworkManager support it’s probably a better idea just to write a !NetworkManager subscriber for resolvconf which means !NetworkManager could in theory work with any dhcp client :)