]] Thomas Hood > Tollef Fog Heen wrote: > > I think changing /etc/resolv.conf automatically is broken at all. > > What's the malfunction?
Automatic processes overwrite explicit admin setups. > > We should have a generated /run/resolv.conf that's overridden by the > > settings in /etc/resolv.conf (if it exists). This allows you to have a > > consistent set of domains searched for matching hosts even when roaming > > to other networks. It also allows me to express the preference «I want > > to use localhost as a nameserver, always» without resorting to chattr to > > prevent dhclient, NetworkManager and other tools from auto-updating the > > resolv.conf file. > > Those features are available in resolvconf. > > Let's consider your idea. I like the aspect that /etc/resolv.conf > remains a static file and doesn't have to be symlinked to a generated > resolv.conf. > > However, your idea requires that the glibc resolver be enhanced. > And once it is enhanced the logic is cast in binary stone: > /etc/resolv.conf always overrides /run/resolv.conf, period. With > resolvconf the logic is under the control of the administrator. > If the admin puts a static file at /etc/resolv.conf then resolv.conf > is static. If the admin puts a symlink at /etc/resolv.conf then the > target of that symlink is used. It seems resolvconf wants to get its name servers from /etc/network/interfaces? If so, that won't work particularly well with NetworkManager, unless I'm mistaken. Also, I don't think updating files in /etc at runtime is a sensible idea, it should be possible to run with / read-only if you want to. > With the resolvconf approach the resolver configuration is readable > in one file which has the familiar semantics, resolv.conf(5). I find resolvconf's behaviour confusing enough that I generally purge it from all my machines. It is, to me, an abstraction layer that seems to randomly overwrite my settings. Having it write to /run and having apps fall back to settings there if there's no setting in /etc/resolv.conf would ease that confusion, I think. > If there are two files then questions arise about how the one > overrides the other. If /run/resolv.conf contains nameserver options > and so does /etc/resolv.conf, then are both addresses tried, or just > the latter, or what? I specified that: settings are overridden, the file in /run is not masked. Whether you want to append the nameserver list or override the one from /run should probably be specified. I'd say override, since appending can easily lead to security breaches. > Also, you will need a third file, also static, to provide defaults > which get overridden by /run/resolv.conf. This will need to be > documented. You don't need a third file the defaults are «an empty file», just like today. [...] > What is missing from your idea so far is functionality to handle > multiple sources of nameserver information. What if the machine > runs both dhclient and a VPN client, or both ifup and pppd? In the > past each of these sorts of programs updated /etc/resolv.conf > and (sometimes) restored the file to the preceding state on exit > which left the file in an incorrect state if programs were stopped > in other than LIFO order. In that case, feel free to provide a framework for packages to coordinate updates to /run/resolv.conf and have stacking and whatnot. (They could write to /run/resolv.conf.d/$num_$basename and resolvconf or a similar tool could build a /run/resolv.conf from that.) > Some packages make use of resolvconf hook scripts, a mechanism > whereby they get notified when the resolver configuration changes. > You could think about whether or not you want to implement that > too, and how. I think any packages needing such hooks should just be fixed, since they're buggy. Adding a lot of infrastructure to work around bugginess is, IMO, not a good idea. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwq59i3f....@xoog.err.no
