[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: boot ordering and resolvconf



Steve Langasek wrote:
On Tue, Jul 02, 2013 at 12:38:24PM -0700, Howard Chu wrote:
Don Armstrong wrote:
On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
Automatic processes overwrite explicit admin setups.

If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic processes to override it by writing to
"somewhere else". If it's not a symlink, then it shouldn't be
overridden.

That seems pretty plain, but Ubuntu/Networkmanager routinely ignore this
fact.

I'm not sure why you group Ubuntu and NetworkManager together here.  Ubuntu
has been using dnsmasq and resolvconf on the desktop (and resolvconf alone
on the server) since the 12.04 release specifically to provide a coherent
architecture and get away from NM's past bad behavior of changing files in
/etc out from under the admin.

   http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

*By default*, all Ubuntu systems running a newer release will have
/etc/resolv.conf as a symlink to /run to ensure the system behaves sensibly
(correct DNS server settings with or without dnsmasq running; honoring DNS
server settings configured in /etc/network/interfaces; and so on).  But if
this symlink is really bothering you, you can make /etc/resolv.conf a real
file and resolvconf won't mess with it any further.

That sounds nice, but my old laptop running 12.04 is still getting its /etc/resolv.conf overwritten by networkmanager, I just took a look and the timestamp on it is from a few hours ago.

Anyway, having just now read the launchpad blueprint, I'm sorry I missed this discussion when I was at that UDS. resolvconf is an unnecessary layer here, dnsmasq handles all of the interface-specific knowledge already. Patching dhclient's interface scripts to talk to dnsmasq over DBUS is trivial (see link in my previous email) and anything else that wants to touch it can be fixed easily as well.

virtmanager's use of dnsmasq is a non-issue since it binds its instances to its specific virtual networks already. They all just need to know to forward to the main dnsmasq on 127.0.0.1 when handling their clients' requests.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


Reply to: