Tollef Fog Heen wrote: > I think changing /etc/resolv.conf automatically is broken at all.
What's the malfunction? > 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. With the resolvconf approach the resolver configuration is readable in one file which has the familiar semantics, resolv.conf(5). 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? 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. If it's the case that the mere existence of a file at /etc/resolv.conf causes /run/resolv.conf to be completely ignored then there is not so great a difference between your idea and resolvconf. With resolvconf, the absence of a symlink at /etc/resolv.conf is what causes the dynamic resolv.conf to be ignored. 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. 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. Cheers, - - Thomas -- 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/51d2c629.30...@gmail.com