Date: Wed, 31 Aug 2011 07:08:31 -0700 From: perryh@pluto.rain.com To: peterjeremy@acm.org Cc: freebsd-arch@freebsd.org Subject: Re: Regularly updated files in /etc Message-ID: <4e5e405f.59yZRGyROtIPwuBg%perryh@pluto.rain.com> In-Reply-To: <20110831060713.GB37259@server.vk2pj.dyndns.org> References: <20110831060713.GB37259@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peterjeremy@acm.org> wrote: > - Moving dumpdates out of root just means a different FS would > need te be writable during dumps. Said other FS would also need to be _mounted_ during all dumps that either are incremental or specify -u; and it would ordinarily _not_ be mounted if one were following the classical advice to have the system in single-user mode (with root remounted read/write to enable writing to dumpdates) while running dump(8). Granted that's no longer supposed to be necessary if using -L, but not everyone trusts UFS snapshots. Since anyone who wants to move dumpdates elsewhere can easily enough add -D to their dump(8) scripts, and/or put a symlink to the new location in /etc, I don't know that there's a lot of upside to changing its default location. > resolv.conf is more problematic: > - Potentially, it could be needed to NFS mount /var, though this > seems unlikely in practice. > - Since there are no standard APIs for updating resolv.conf, there > are likely to be lots of home-grown scripts that know where it is. I would be concerned about the first item (chicken-egg problem). There would at least need to be an entry in UPDATING. The last is easy enough to fix by dropping a symlink to the new location into /etc, but as with dumpdates there is nothing stopping someone who wants a read-only root FS -- and who doesn't need an NFS-mounted /var -- from doing it on their own.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4e5e405f.59yZRGyROtIPwuBg%perryh>