On Wed, 3 Aug 2011 16:26:35 -0300 Lamarque Vieira Souza <lamarque gmail com> wrote: > Em Wednesday 03 August 2011, Michał Górny escreveu: > > On Wed, 3 Aug 2011 14:53:21 -0300 > > > > Lamarque Vieira Souza <lamarque gmail com> wrote: > > > Em Wednesday 03 August 2011, Dan Williams escreveu: > > > > On Wed, 2011-08-03 at 10:29 +0200, Michał Górny wrote: > > > > > Hello, > > > > > > > > > > AFAIK NetworkManager is the most common tool which keeps > > > > > writing to /etc/resolv.conf file during runtime. Such a > > > > > solution makes it hard to support configurations where rootfs > > > > > in read-only most of the time. > > > > > > > > > > That's why I'm considering moving the resolv.conf file > > > > > to /var. I'm not sure about the exact location there but /var > > > > > seems much better for non-static resolver configs. > > > > > > > > > > I think that the best solution would be to patch glibc so it > > > > > will first try to load 'dynamic' resolv.conf from /var, and > > > > > then fallback to static configs in /etc. > > > > > > > > > > I'd really appreciate any kind of feedback on that idea. > > > > > > > > Having resolv.conf in /etc also prevents read-only root, > > > > thus /var is actually a better place for it since it's really a > > > > composite of various information and can change at will. > > > > Lennart wrote a blog post a month or so ago about moving it > > > > somewhere, I forget where, but you might read that post as > > > > well. I'll take a patch that allows you to pass > > > > --with-resolv-conf-file-path=<whatever> which shouldn't be too > > > > hard to do. > > > > > > > > I don't know how far you're likely to get with glibc though, > > > > since /etc/resolv.conf is standardized in various places and > > > > it's a long-standing tradition. The best way to make changes > > > > here is simply to try out patches in your distro and see how it > > > > works, and perhaps eventually they'll see which way the wind is > > > > blowing. > > > > > > This problem is not specific to NM, any dhcp client will > > > have > > > > > > to rewrite /etc/resolv.conf to update name server's IP addresses. > > > When I create read-only filesystems I prefer to create a symbolic > > > link (/etc/resolv.conf in this case) pointing to the real file in > > > the read/write media or ramdisk. Another alternative is use a > > > read-only /etc at first, mounting a ramdisk in /etc and populating > > > the ramdisk with the some contents of the read-only /etc. The > > > latter is a little tricky to make work right because for some > > > instants /etc will be empty. > > > > Not all apps handle symlinks correctly (e.g. I've seen something > > writing temporary file to /etc first and failing then). Not to > > mention that's only a workaround for the real issue of FHS breakage. > > So you can take my second alternative. Since at the start of > the boot process everything is read-only you can use a script inside > a ramdisk to mount /etc in another ramdisk and populate it before > finishing the boot process. I did something like that with OpenSuse > 10.x some years ago. OpenSuse 10.x used to use an initramfs with a > quite complex init script inside, we could do several things there > before passing the boot process control to /sbin/init. ...which is a working problems around as well. > /etc/resolv.conf is not the only file written to during boot > process. localtime, asound.conf, fstab, mtab, modprobe.conf, > cups/printers.conf are other file that may needed to be written to > during user session. Then they're borked as well. Also, you should distinguish files written to commonly and files written to when admin changes system config. The second case requires the admin to remount rootfs r/w, the first one should not. -- Best regards, Michał Górny
Attachment:
signature.asc
Description: PGP signature