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

bugzilla at redhat.com bugzilla at redhat.com
Wed Jan 12 16:00:39 UTC 2011


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 #4 from Jiri Popelka <jpopelka at redhat.com> 2011-01-12 11:00:38 EST ---
(In reply to comment #2)
> Does this work exactly like resolvconf?
I have no idea, truly said, I have never used resolvconf.

>  We've had no end of problems with
> people using resolvconf with NetworkManager, and it's usually fixed by just
> removing resolvconf entirely.
I hadn't been aware of this.

>  Ubuntu doesn't even install resolvconf by default anymore.
I know that debian doesn't have resolvconf or openresolv (in unstable)
installed by default.
And I have no intention pushing openresolv to default install in Fedora.

> How is the final resolv.conf generated and what algorithm defines the priority
> of nameservers in the final file?
I don't know but will try to ask upstream.

(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.
> 
> Third, resolvconf simply cannot handle bad ordering, if a program crashes or
> otherwise does not remove its configuration.
> 
> So I'm kind of curious what the motivations for this are, and what problems a
> resolvconf implementation would actually solve?
Motivations are described in bug Description.
My own is bug #551962.
I don't expect that anybody using NM will use openresolv.
I have been aiming at those not using NM but e.g. DHCPv4+DHCPv6 dhclient.

I have been testing it slightly and it seemed to work pretty well (after
modifying initscripts and switching selinux off :-).
I also build NM with --with-resolvconf=yes and tried with NM.

When I had NM_MANAGED eth0 a NOT NM_MANAGED eth1 (dual stack dhclient),
'resolvconf -l' was showing:

# resolv.conf from dhclient.v4.eth1
nameserver 192.168.1.132

# resolv.conf from dhclient.v6.eth1
nameserver 3ffe:501:ffff:1::131

# resolv.conf from NetworkManager
# Generated by NetworkManager
nameserver 192.168.0.1

and the resulting resolv.conf:
# Generated by resolvconf
nameserver 192.168.0.1
nameserver 192.168.1.132
nameserver 3ffe:501:ffff:1::131

But thanks for sharing your experience,
I'll try to discuss it with upstream first.

-- 
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.



More information about the package-review mailing list