How to reload DHCP client remotely, in order to write new resolv.conf?

Question

I'm trying to configure dnsmasq(8) on a Debian GNU/Linux system in a private DHCP-based network. During a local, manual setup - after installing dnsmasq istelf - one could simply include the line

prepend domain-name-servers 127.0.0.1;

in /etc/dhcp/dhclient.conf and restart networking. This will include the local host in /etc/resolv.conf and one is ready to go. (See also: http://wiki.debian.org/HowTo/dnsmasq#Local_Caching)

But attempts to do the same remotely, especially when working with configuration-managment software, would result in the network connection being lost. Well, since the goal is not the network restart, but updating resolv.conf..:

How can one force dhclient(8) to update resolv.conf whilst keeping the network connections up and running?

[EDIT]

Below please find a script that worked for me:

if grep '^\s*nameserver\>.\+\<127\.0\.0\.1\>' /etc/resolv.conf >/dev/null; then
    : # do nothing
else
    grep -v '^\s*nameserver\>' /etc/resolv.conf > /tmp/resolv.conf.new
    echo "nameserver 127.0.0.1" >> /tmp/resolv.conf.new
    grep '^\s*nameserver\>' /etc/resolv.conf >> /tmp/resolv.conf.new
    mv -f /tmp/resolv.conf.new /etc/resolv.conf
fi

It's kind of awkward - and I'm still searching for a better solution.

Solution

I faced the same issue when setting dnsmasq through ansible. On debian jessie you can update dhclient.conf and do:

/usr/bin/killall dhclient
dhclient INTERFACE

Or if you prefer:

dhclient -x
dhclient INTERFACE

This does not kill your connection unless your lease expires and you get a different IP address.

You mention config management. If you're using ansible, here's the relevant part of my playbook:

tasks:
- name: Ensure a correct resolv.conf
  template: src=templates/resolv.conf.j2 dest=/etc/resolv.conf

- name: Ensure dhclient config wont mess up my resolv.conf
  template: src=dhclient.conf.j2 dest=/etc/dhcp/dhclient.conf
  notify: Kill dhclient

handlers:
- name: Kill dhclient
  command: /usr/bin/killall dhclient
  ignore_errors: yes
  changed_when: false

Notice that I don't restart dhclient after killing it. This works well in my environment but YMMV. You could add another task that copies over a script to handle dhclient stop/start and call that one from the handler (perhaps even using {{ansible_default_ipv4.interface}} to get the name of the interface).

My dhclient.conf template is something like this:

send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers, host-name, interface-mtu, rfc3442-classless-static-routes, ntp-servers, dhcp6.fqdn, dhcp6.sntp-servers;

So, mostly the default debian's dhclient.conf sans the dns-related directives.

Comments

[kostix]

The dhclient(8) manual page tells it supports some funky protocol called "Omapi" which allows remote configuration, and refers to the omshell tool which can be used to set/unset certain parameters in the client and update it, as well as shut it down and restart. Did you explore this route?

[mjhennig]

Yes, but it doesn't provide a way to update resolv.conf. Note that the DHCP client itself is not the issue here, it's the resolv.conf file: It's considered by the resolver(3) C-API and thus used by other software. Usually, the update is performed by either dhclient(8) or resolvconf(8), but the first resets the network connection and the latter fails to preserve the existing configuration --

[TOOGAM]

I expect the answer would depend on your client. With OpenBSD's client which is based on ISC DHCP (which might be what you use), there is an /etc/dhclient.conf that is usually used. "dhclient -c /etc/dhclient.conf" can specify a custom file. The file specifies to do things like figure out the subnet mask, routers (default gateway), and DNS stuff. You could take out what you want. But IP address doesn't seem to be one of the options. There may be no default built-in support to not query. .conf's "supersede" could ignore the info, though. Maybe see also: man dhclient-script

[GnP]

Also, I would argue that this question was appropriate for ServerFault