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@xxxxxxxxxx> 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review