[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Adding openresolv to base
On Thu, Mar 26, 2009 at 11:54 PM, Luke Mewburn <lukem%netbsd.org@localhost>
> On Wed, Mar 25, 2009 at 12:11:52AM -0400, James K. Lowden wrote:
> | > On Tue, Mar 24, 2009 at 11:29:21PM +0000, David Holland wrote:
> | > > Rather than introducing further hacks to automatically munge what's
> | > > theoretically a sysadmin-edited file, can we have the daemons do this
> | > > in /var/run, and have the resolver go look at the results based on a
> | > > resolv.conf setting?
> | But David makes a useful distinction, don't you think? Let /etc hold
> | adminstrative inputs and /var/run hold system state. Adminstrators don't
> | have to worry about their carefully edited, commented, version-controlled
> | files getting clobbered, and openresolv can manage its file without
> | concern for preserving formatting and comments.
> I like David's suggestion too.
> * /etc can remain effectively read-only, and /etc/resolv.conf remain
> under the sysadmin's version control.
> * /var/run/resolvconf.conf can be updated by the application as it desires.
> * A setting in /etc/resolv.conf makes it easy for the sysadmin to
> control whether or not the resolvconf behaviour is in use.
> I've been bitten in the past by application that "helpfully" updated
> /etc/resolv.conf because I forgot the super secret magic in
> that application's configuration file to disable the auto-munging.
While I've also been bitten by this, I personally think creating
another active resolv.conf would create confusion instead of solving
very much pain.
/var/run/resolv.conf.$DATE as an auto-magic backup of /etc/resolv.conf
whenever resolv.conf was changed would be more useful, in my opnion.
Even an /etc/resolv.local would be less confusing than
/etc/resolv.conf + /var/run/resolv.conf (+
/usr/pkg/var/run/resolv.conf? + ... ?)
Main Index |
Thread Index |