[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Adding openresolv to base
matthew sporleder wrote:
> 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? + ... ?)
All of what you both want is possible with resolvconf :)
resolvconf keeps a copy of each resolv.conf given to it in
/var/run/resolvconf/interfaces stored by interface name. Of course, the
interface name could be any name, just as long as it's unique.
You can also specify resolvconf writing to /var/run/resolv.conf and have
/etc/resolv.conf as a symlink to that allowing for a RO /etc.
resolvconf can be setup to ignore application requested updates. Of
course, you could always chflags schg /etc/resolv.conf.
Both of you seemed to imply that you are happy with the resolvconf
interface though. Is this the case? Any libc updates can always take
place at a later date.
Main Index |
Thread Index |