[Bug 668153] Review Request: openresolv - Management framework for resolv.conf

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=668153

--- Comment #9 from Roy Marples <roy at marples.name> 2011-02-07 13:32:26 EST ---
(In reply to comment #3)
> Second, the fact that all resolvconf implementations use the network interface
> names as an ordering and tracking mechanism is completely wrong, since what you
> want to do for priority here has nothing to do with the interface name, and
> everything to do with the network you're connecting to, which is independent of
> the interface name that's connecting to that network.  Plus interface names can
> be anything.  Essentially, using a resolvconf framework does not play well with
> an actual dynamic system.

I think I answered that above.

> Third, resolvconf simply cannot handle bad ordering, if a program crashes or
> otherwise does not remove its configuration.

This is correct, but hardly earth shattering either. The limitation of 3 libc
resolvers is of note, but then a more powerful local resolver such as unbound,
dnsmasq or bind can be configured for a much larger number and probably has
better failover. openresolv can configure these quite easily with minimal user
configuration required.

Of course, I expect quality systems such as RedHat not to be shipping programs
that crash or fail to function correctly which makes this a non issue ;)

> So I'm kind of curious what the motivations for this are, and what problems a
> resolvconf implementation would actually solve?

resolvconf provides a common ground for many things updating resolv.conf(5) and
optionally configuring more powerful local resolvers.
openresolv is such an implementation and requires a POSIX userland and shell,
ie no external 3rd party libraries.

You, on the other hand, maintain NetworkManager, which granted can maintain
resolv.conf(5) in a similar vain so it's natural that you are hostile towards
it. However NetworkManager requires many things which are only found on Linux
based systems and requires GTK+ as well as a few others. And last I checked it
had no provision for local resolvers other than libc.

At this point you may be wondering "why local resolvers?" Well, the answer is
quite simple - openresolv has an extension to mark the interface resolv.conf as
private. So consider this

eth0:
search foo.com
nameserver 1.2.3.4

vpn0: (marked private)
search bar.org
nameserver 1.2.3.5

openresolv would configure the local resolver (where possible) to send query
for bar.org to 1.2.3.5 and any other query to 1.2.3.4
Very handy for work VPN systems.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.