Alexander Sack wrote:
On Sun, Jul 06, 2008 at 02:15:09AM -0400, Daniel Caleb wrote:Jul 6 01:27:38 allone NetworkManager: <info> DHCP returned name servers but system has disabled dynamic modification!Looking at the current debian backend patch at [1], this appears to be the case when resolvconf is installed. uninstalling that package should get you back to "normal". I am not sure about the reasoning for that modification atm. Michael? [1] - http://svn.debian.org/wsvn/pkg-utopia/packages/experimental/networkmanager/debian/patches/05-debian_backend.patch?op=file&rev=0&sc=0
Hi everyone,this patch [1] alone, is obviously incomplete. To better understand what's going on and how a possible fix could look like, I'll try to go into details a bit.
On a standard Debian/Ubuntu installation, which *doesn't* use resolvconf, there are several mechanisms, how /etc/resolv.conf (the libc resolver config file) is managed/updated.
- If you use ifupdown and a static configuration in /etc/network/interfaces, you setup a static /etc/resolv.conf manually.
- If dhcp is used, the script /sbin/dhclient-script updates the dns information in /etc/resolv.conf with the information provided by the dhcp server. You can override/amend the information via the /etc/dhcp3/dhclient.conf configuration file (e.g. supersede domain-name, prepend domain-name-servers). dhcp3-client has it's own hook mechanism via /etc/dhcp3/dhclient-*-hooks.d/ to inform other applications on changes.
- dialup connections: pppd updates /etc/resolv.conf upon successful connections via /etc/ppp/ip-up.d/0000usepeerdns
If resolvconf is installed, it will take over the management of the dns information. In case of dhclient and pppd, instead of writing to /etc/resolv.conf directly, they simply pass the dns information to resolvconf via hooks for ifupdown/dhclient/ppp:
/etc/network/if-down.d/resolvconf /etc/network/if-up.d/000resolvconf /etc/ppp/ip-down.d/000resolvconf /etc/ppp/ip-up.d/000resolvconf /dhcp3/dhclient-enter-hooks.d/resolvconfresolvconf takes this information, merges it with the configuration in /etc/resolvconf/resolv.conf.d/ (where you e.g. can set a global dns server or search domain), then writes resolv.conf. In addition, it has a hook mechanism to inform other applications on changes via /etc/resolvconf/update.d/ (e.g. bind or dnsmasq install hooks).
Now onto NM 0.6:NM 0.6 only handled the dhcp case, it didn't have proper support for static configuration or dialup connections. It also didn't allow to set dns configuration (like dns server, dns search domain).
The interaction between dhclient and NM was via dhcdbd. NM simply called /sbin/dhclient-script.dhcdbd installed a hook /etc/dhcp3/dhclient-exit-hooks.d/dhcdbd, which extracted the dns information from the dhcp server and passed it back to dhcdbd, and NM then got dns information from dhcdbd and wrote /etc/resolv.conf with the information it got from dhcdbd.
If resolvconf was installed, NM didn't write /etc/resolv.conf itself. This was left to /etc/dhcp3/dhclient-enter-hooks.d/resolvconf
NM 0.7:NM 0.7 has a much more sophisticated support for dialup and static configurations. It allows for setting dns configuration on a per connection basis.
For dhcp connections, it no longer calls /sbin/dhclient-script, but has it's own script nm-dhcp-client.action, which directly passes the dns information from dhclient to NM.
So the hook /etc/dhcp3/dhclient-enter-hooks.d/resolvconf is no longer run, thus /etc/resolv.conf is no longer updated.
Sjoerd made a quick fix, which calls /sbin/dhclient-script again [2], for dhcp connections.
I'm not yet totally satisfied with this approach: a.) It only works for dhcp connections. b.) It doesn't use the dns information you set via NM: I think there a two ways to address that:1.) Completely ignore resolvconf and always let NM write and manage /etc/resolv.conf. NM 0.7 almost provides all functionality of resolvconf. What's missing is global dns configuration options (NM only allows per connection) and the /etc/resolvconf/update.d/ hook mechanisms. IIRC, dnsmasq provides a D-Bus interface nowadays, so we could use that instead.
2.) If resolvconf is installed, change NM to not manage /etc/resolv.conf itself, but only pass the dns information to resolvconf (which then will write /etc/resolv.conf). The downside is, that resolvconf might have own dns configuration. So the resulting /etc/resolv.conf might differ from what NM expects it to be.
I'm leaning towards 2.), but I'm open to other suggestions and comments. Cheers, Michael P.S: I admit, that the whole situation is quite messy.[2] http://svn.debian.org/wsvn/pkg-utopia/packages/experimental/networkmanager/debian/patches/10-execute_system_dhclient_script.patch
-- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature