Original resolv.conf generated by Puppet appended to resolvconf-generated resolv.conf

Looking at your resolv.conf file I see that the first part is generated by resolvconf and the second part by puppet. The latter part includes a line

    domain buildd

which overrides the search line earlier in the file.

Please post the output of the following commands run in a terminal window.

    ls -l /etc/resolvconf/resolv.conf.d
    cat /etc/resolvconf/resolv.conf.d/original

Output of :

    ls -l /etc/resolvconf/resolv.conf.d
    cat /etc/resolvconf/resolv.conf.d/original

Solution: as root do

    rm -f /etc/resolvconf/resolv.conf.d/tail
    ln -s /dev/null /etc/resolvconf/resolv.conf.d/tail
    resolvconf -u

That fixed my problem, though I'm curious as to what caused it...

Thanks!

The cause: when resolvconf was installed the debconf question "Append original file to dynamic file?" was answered in the affirmative. (The default is negative.)

I'm glad the problem is fixed!

The incident is fixed but the problem remains. However, it turns out this problem seems to be related to Business Desktop Remix.

I re-ran a complete fresh re-install from the Business Desktop Remix 12.04 disc (where I first discovered this problem), and the issue occurred again. When I ran a complete fresh install from the standard Ubuntu Desktop 12.04 disc, there was no problem.

In respect to the installation process for Business Desktop Remix: I was never asked a question about appending the original resolv.conf file to the dynamic file; I suspect that this question is answered automatically or implicitly by some configuration or set of packages chosen during installation of Business Desktop Remix, or something like that.

Should I re-open this bug, file a new one here, or file a new one somewhere appropriate for the Business Desktop Remix?

This bug appears to affect the Business Desktop Remix, but not the standard distribution.

@Msquared: Please post the output of the following command run in a terminal.

    debconf-show resolvconf

root@accrec2:~# debconf-show resolvconf
  resolvconf/downup-interfaces:
  resolvconf/linkify-resolvconf: false
  resolvconf/link-tail-to-original: true
  resolvconf/reboot-recommended-after-removal:
root@accrec2:~#

I am having a similar problem with Kubuntu 12.04 (fully updated to today) even after disabling resolvconf. The resolver appears to ignore the search strings in /etc/resolv.conf entirely.

I have uninstalled both dnsmasq and resolvconf from the this machine and am using settings in the KDE Network Manager to create /etc/resolv.conf instead. I told the client to obtain only the machine's IP address with DHCP and to use static items to populate resolv.conf. I get the correct /etc/resolv.conf as a result:

# Generated by NetworkManager
nameserver 192.168.100.100
nameserver xx.xxx.xxx.xx
nameserver 8.8.8.8
search example.com somethingelse.com

However unqualified host names are not searched using the entries in the search directive. If I run "host mail" from the prompt, I get the results for mail.com, not mail.example.com. Other unqualified names are also resolved to "hostname.com".

I tried removing the mdns entries from nsswitch.conf so that I have only "hosts: files dns" entered there. I get the same erroneous lookups. However if I place the unqualified names in /etc/hosts, I get the correct resolutions. Something about the resolver (kernel code?) seems to make it ignore the search list.

Oh, and I checked to make sure it wasn't my in-house DNS server at 192.168.100.100 causing the problem. If I restrict /etc/resolv.conf to just Google's server at 8.8.8.8, I get the same behavior. Unqualified names have ".com" appended to them.

@Peter Lemieux: If you have disabled resolvconf then it is not the same problem. Please file a new bug report.

Msquared wrote:
> resolvconf/link-tail-to-original: true

This confirms that this question was answered in the affirmative and that that was the cause of the originally reported symptoms.

> I was never asked a question about appending the original
> resolv.conf file to the dynamic file; I suspect that this
> question is answered automatically or implicitly by some
> configuration or set of packages chosen during installation
> of Business Desktop Remix, or something like that.

Perhaps the Business Desktop Remix preseeds that debconf question with "true"?

I think you are right. (When I said "answered automatically", that was what I meant, but just didn't know the term you use for it.)

In any case: Is this behaviour in Business Desktop Remix a bug, or desired behaviour?

If it's a bug, how do we fix it?
If it's desired behaviour, how to we document it and/or provide a way to change it during installation?

Here's the perspective of the Debian resolvconf maintainer. Resolvconf is in Debian an optional package and is often installed on a Debian system whose resolver was previously configured by hand. It is almost impossible to write maintainer scripts that perfectly handle all possible previous custom configurations; however a number of things are done in the Debian resolvconf maintainer scripts to increase the chances that the installation goes well and doesn't leave the system without name service. One of the measures is to offer the admin the option of "linking tail to original", i.e., of including the pre-existing static file in the dynamically generated file. Doing this is never the best thing to do, but it can be better than not doing it if the admin doesn't know yet how to configure resolvconf properly.

In Ubuntu resolvconf was never really an optional package (it was broken in Universe for a few years) before it became a standard package. It rarely gets installed on an Ubuntu system that was previously configured by hand. So "link tail to original" is not likely to be helpful on an Ubuntu system. I would be happy to see the feature removed from the Ubuntu package and, now that I think about it, I think it's time to remove it from the Debian package as well. So maybe I'll just axe it in the next release and then it will disappear from the Ubuntu package the next time there's a sync.

I should add that the Remix should be fixed without waiting for changes to trickle down from upstream. E.g., if the Remix is preseeding the debconf question "resolvconf/link-tail-to-original" with "true" then it should stop doing that.