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. -- Best regards, Michał Górny
Attachment:
signature.asc
Description: PGP signature