tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Adding openresolv to base



> If you didn't want something to "munge" or clobber /etc/resolv.conf
> then would wouldn't be running DHCP, PPP, VPN, etc - or those
> components would already be disabled for applying DNS to the system.

Nice theory.  Doesn't quite work out that way, though.  I've already
lost one resolv.conf to running DHCP on a system that normally doesn't
run it, forgetting that by default it destroys resolv.conf.  (Yes, this
could reasonably be viewed as human error.  A design that doesn't take
human error into account when humans are involved is a bad design.
This includes things like thinking about the failure modes in the face
of likely human errors.)

> By adding another file you have increased complexity.

Your proposed changes increase complexity too - just in different ways.
(Not saying either is better or worse; just pointing out that this
particular argument is specious.)

> If both files are present, which should be used?

Whatever the sysadmin has resolv.conf configured for, of course.  The
point is that the master file driving this process is the
human-configured one.

> If both, in what order?  What if I want my static config to appear
> somewhere in the middle?

These are questions for the design of the "go look at this other file"
mechanism for resolv.conf.

> You're also ignoring the extra benefits of openresolv dealing with a
> local resolver such as named or dnsmsq.  Some of these benefits
> include [...]

I don't see how this is so.  The admin can always configure resolv.conf
as just "that other file is where everything lives", in which case
we're basically at what you started out suggesting, with the crucial
difference that a sysadmin who is unaware of this stuff, or who is
doing something unusual and doesn't happen to think of this lurking
gotcha, isn't going to have manually created configuration destroyed.

This does introduce the failure mode of "I ran DHCP (or whatever), why
isn't it using the new data?".  I wouldn't mind a warning from dhclient
if resolv.conf isn't configured to look at the generated config, but I
even absent that I would much prefer this failure mode over the
configuration-destroying one.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index