Hi, On Mon, May 05, 2003 at 07:40:50PM -0400, Theodore Ts'o wrote: > On Mon, May 05, 2003 at 08:27:17PM +0200, Thomas Hood wrote: > > I'm glad you agree that, even if we don't go the /run/ route, > > all variable files in /etc/ should be relocatable. (By 'relocate' > > I mean: replace with a symlink to a new location.) Several > > variable files in /etc/ are not currently relocatable, including > > mtab (See #53829 et al.) and resolv.conf (See #187810). > > Fortunately, ifstate is already relocatable. > > > > This assumes that all programs that touch a particular file (for > example /etc/resolv.conf) are under your control --- that is, they are > part of Debian. If some particular program is part of a third-party > shell script which is distributed by an ISP, or part of some binary > program which (example: AT&T Managed Tunnel Services), then by moving > /etc/resolv.conf to some other directory and leaving a symlink behind, > you may potentially be breaking these programs. > > And, no you may not call it a bug in those programs or shell scripts, > because you don't get to dictate how software outside of Debian (but > which a Debian user might want to use) is written. True. However, the current behaviour of such programs that edit /etc/resolv.conf is undesireable, because they only work if you don't dare to start some other connection that edits /etc/resolv.conf while the first connection is running. And even if that works, stopping the first connection while the second stays open is *guaranteed* to loose information when it "restores" the contents of /etc/resolv.conf. I don't think we should dictate these programs should keep their broken semantics but merely write to resolv.conf in another directory. That's not the issue here at all. If that were the case, the proponents of this change would indeed be guilty of all the "anal purist"-accusations people are making. The thing is that we want to offer those scripts and subsystems that want to provide resolver information an alternative, and solve the case properly for once, so that AT&T et al. won't be *forced* anymore to write inherently buggy scripts. The way I proposed to do that, and that was implemented very well by Thomas, is to allow each script to have its own dynamic file, so no more contention, to merge the dynamic information with static information from the admin, and to push it to the various systems that need it (NSS, as forwarders to a local DNS cache). There's a few ways you can go about it. 1: have the admin edit some /etc/resolv.conf-static and have the update scripts merge that with the dynamic information (wherever it's stored) into /etc/resolv.conf. 2: have the admin edit /etc/resolv.conf, have the update scripts merge that with the dynamic information into a file somewhere else, and make every reader (NSS) use the new file. 3: allow the admin to specify resolvers per interface, which is recorded the same way as dynamic information, have the update scripts merge it into a resolv.conf somewhere else, and allow the admin to make his /etc/resolv.conf a symlink to that file, thereby deciding to having it managed automatically. Thomas opted for 3, and it's an excellent solution IMHO. In such a setup, dialer scripts and ip-up scripts have an alternative to simply editing /etc/resolv.conf and doing their best using various tricks to preserve some information that's there: they have full control over their own resolv.conf, in [/var]/run/resolvconf/interface/<interface> We chose the directory without /var, also for the merged file, because /var can be network mounted, and it would be nice if that could be done from a network that's brought up using the standard tools. However, this is of relatively minor importance. Using /var would be great too. What's important is to resolve the contention around configuration files in /etc, and that can only be achieved if we give scripts, 3rd party or not, an alternative to messing with them. The fact that no other Unix or Linux distribution has resolved this issue yet in a satisfactory way, should not prevent Debian from trying to do so. If Debian is only allowed to follow the design mistakes of others, at all cost, then that'd be a terrible waste of the good contributions we could have made to the whole *nix community. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpmaR1lh3cIF.pgp
Description: PGP signature