On Fri, 2011-01-07 at 22:37 +0100, Michael Biebl wrote: > Am 07.01.2011 17:13, schrieb Uwe Geuder: > > > > On Ubuntu Lucid I solved the dnsmasq - nm integration as follows: > > > > - dnsmasq is configured to read upstream DNS servers from /etc/resolv.conf1 > > > > - nm is patched to write to /etc/resolv.conf1 instead of /etc/resolv.conf > > (I'm willing to share the patch if anybody is interested. I haven't > > done so, because it's not 100% perfect, see below) > > > > - /etc/resolve.conf is manually edited to contain 127.0.0.1. It will never > > be changed (*) > > Or you can simply install resolvconf + dnsmasq without any patching. > > Should basically work the same way: /etc/resolv.conf contains 127.0.0.1 > and remains static. NM pushes DNS updates to resolvconf, which in turn > pushes those updates to dnsmasq.
Sure... but the problem with resolvconf is it only works if ALL the facilities that manipulate /etc/resolv.conf are modified to use resolvconf instead. Sadly, this is not the case; not even all the NetworkManager components grok resolvconf (for example, openconnect doesn't work properly with resolvconf). And beyond that there's a whole suite of proprietary VPN solutions which certainly don't know to do anything except "overwrite /etc/resolv.conf". Plus, resolvconf is only available in Debian and derived distros like Ubuntu; there's no support in Red Hat/Fedora/etc. that I can find, which means that it will never (IMO) be a complete solution. In short, there's no really robust (in the face of all the different network utilities and their idiosyncracies) way to handle this today. What I attempted to do was write a script (Perl) that used inotify to watch /etc/resolv.conf and whenever it was changed my script would swoop in, figure out what changes were made, and rework my dnsmasq-based local proxy DNS server configuration to represent those changes, then write a new simplified /etc/resolv.conf. This works, actually... until it doesn't. It turns out that too many utilities are just too badly behaved to allow this to work automatically in a robust way. And yes, this includes NetworkManager (see my bug where, when an interface goes down, NetworkManager recreates the resolv.conf file completely from scratch based only on the interfaces it knows about... destroying any resolv.conf elements like search domains that were added by other tools such as proprietary VPN tools). I do think that resolvconf has absolutely the right CONCEPT, where it segregates individual resolv.conf-style files for each interface. The idea that each interface has its own search paths, nameservers, etc. is spot-on; I wish NetworkManager kept that kind of distinction internally. But the requirement that /etc/resolv.conf be a symlink is simply not workable in the face of proprietary tools that feel entitled to stomp resolv.conf as they like. We can say that we don't care about that kind of software... except that people wanting to switch to Linux almost never have any kind of say into the VPN solutions that their companies choose. If you want to REALLY know what I think, I think that the best solution is to rewrite libresolv so that instead of reading /etc/resolv.conf, it reads a list of files in /etc/resolv.d (for example), one for each interface, each of which was a resolv.conf-style formatted file. It could also read /etc/resolv.conf for backward-compatibility. Each of these would be maintained separately internally to the resolver, not combined into one big list, so that hostnames associated with a given search domain would be resolved only by the nameservers associated with the /etc/resolv.d file containing that domain, etc. There are still issues, of course, such as ordering of nameservers used for reverse lookups and what happens if search domains overlap, but these are solvable. This would remove the need for resolvconf, it would remove the need to run a local dnsmasq proxy server, etc. Even then, though, we'll need a method for handling legacy applications. But I think it could be done and if Linux could just get to one true, complete solution for this problem rather than a lot of different "kind of" solutions it would be a lot easier to get the proprietary vendors to help out. _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
