5

A note

New question, since everything else on this matter appears to be outdated and/or conflicting. Hold your close votes, please :)

The problem

On stock installs of Ubuntu 12 and 14 Server, the going advice seems to be that the way you make DNS changes is to edit the interfaces file and add the dns- options there. Only problem is, on servers, where uptime is a concern, it appears the only way to force those changes to be be applied is to bounce the affected network interface with ifdown/ifup.

I've got a large number of servers to make a set of DNS changes on, and I need to update their resolver configurations, en masse, without toggling the network interfaces in this fashion. I also need to make sure the changes stick after a reboot.

The problem is that all of these servers were built with the dns- options in the interfaces file, meaning that if I change resolvconf's head or tail files, I'll end up with a bunch of duplicate lines on reboot.

The process needs to be something like:

  1. Completely eliminate the resolver configuration (it's all over the place right now)
  2. Set the options to new, known-good values
  3. Save those options so they are used by applications immediately, and so they'll be in place after a reboot.

So, a recap:

What won't work

  • Editing the lines in interfaces (requires an outage to recycle the interface)
  • Editing resolv.conf directly (won't take effect, won't be saved)
  • Editing the resolvconf head or tail files (won't take effect, will have duplicate lines on reboot)

The actual question

Is there a way to effect a change like this, without interrupting service? Ideally, I could force resolvconf to go through its update process without toggling the interface.

Improve this question
5
  • "Editing resolv.conf directly (won't take effect" - why won't it take effect, exactly? And what's the problem with having duplicate entries until reboot? Only the last search entry takes effect and multiple nameserver entries shouldn't be a problem.
    – muru
    Mar 4, 2015 at 19:01
  • Mostly because it's going to be a mess for automation going forward. I was under the impression that just messing around in resolv.conf will lead to a not-fully-working resolver, since the resolvconf package handles a notification mechanism of some kind. Is this not the case?
    – Mikey T.K.
    Mar 4, 2015 at 21:16
  • "Messing around" will obviously cause problems. This is what I'd do: Use sed to delete entries in interfaces, add resolvconf.d/base or resolvconf.d/tail, run resolvconf -u and ignore the duplicate entries (which will go away next reboot/network cycle anyway).
    – muru
    Mar 4, 2015 at 21:20
  • Anything that parses resolv.conf will be confused by the dupe lines, not just the resolver itself. (Example: Augeas). Ideally those could be removed - where is resolvconf pulling that info from?
    – Mikey T.K.
    Mar 5, 2015 at 16:23
  • See askubuntu.com/a/225100/158442
    – muru
    Mar 5, 2015 at 16:28

1 Answer 1

Reset to default
2

If you absolutely can't have resolv.conf be in an inconsistent state, here's what I did:

  1. The "state" of the resolver generated from the dns- lines in your /etc/network/interfaces is stored in /var/run/resolvconf/interface/(interfacename).inet - this file was truncated.

  2. The same data (search, nameserver, etc, same stuff that's in a completed resolv.conf) was copied into /etc/resolvconf/resolv.conf.d/tail (the tail file had to be created), with an appropriate comment added so anybody that comes along later can see what happened.

  3. The dns lines in /etc/network/interfaces were commented out

  4. And finally run resolvconf -u to regenerate the /etc/resolv.conf from the tail file

This has the effect of:

  • Decoupling the resolver settings from the network interface (which if you're on a single interface box is needlessly annoying)

  • Placing the resolver settings in a single purpose text file (the tail file)

  • Making the changes take effect immediately

  • ..and having them persist after a reboot

  • And re-generating the system wide /etc/resolv.conf with resolvconf's notification mechanism intact.

  • ...with no downtime :D

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .