On Wed, 03 Aug 2011 12:33:24 -0500 Dan Williams <dcbw redhat com> wrote: > 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. Read-only rootfs is the main thing I'm interested in, to be honest. > 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. Well, that's mostly why I'd like to still support fallback to /etc/resolv.conf and just give /var location for power users or so. Not sure if I am likely to get such change applied in my distro. It's more probable to get into Fedora or one of those. We don't really like to hack things incompatibly with upstream as that results in random applications starting to rely on non-standard features in a short time. And that doesn't necessarily mean those features will be in glibc because of that. Just look how many apps ship strlcpy() & strlcat()... -- Best regards, Michał Górny
Attachment:
signature.asc
Description: PGP signature