Em Wednesday 03 August 2011, Michał Górny escreveu:
> On Wed, 3 Aug 2011 14:53:21 -0300
> 
> Lamarque Vieira Souza <[email protected]> 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.

        /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.

-- 
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://planetkde.org/pt-br
_______________________________________________
networkmanager-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to