NetworkManage does not set domain in /etc/hosts on DHCP connections

[Peter Parzer]

Binary package hint: network-manager

When NetworkManager start a DHCP connection it sets IP and hostname in /etc/hosts, but it does not include the FQHN. Without the FQHN in /etc/hosts Kerberos and AD integration with windbind do not work.

Example: After setting up a DHCP connection NetworkManager adds this line on to of /etc/hosts

161.42.184.214 wkjpvtest # Added by NetworkManager

For Kerberos and winbind to work correctly, the line should be:

161.42.184.214 wkjpvtest.ads.krz.uni-heidelberg.de wkjpvtest # Added by NetworkManager

The following short NetworkManager hook, solves the problem for me now:

#!/bin/sh -e
# Dirty hack to set the FQHN in /etc/hosts for DHCP connections managed
# by NetworkManager, install it in /etc/NetworkManager/dispatcher.d/

HOST=`hostname`
DOMAIN=`grep domain /etc/resolv.conf | cut -d' ' -f2`

# first check if the domainname is already set
if ! grep -q "$HOST.$DOMAIN" /etc/hosts ; then
  # if not, correct /etc/hosts to include the FQHN
  sed -e s/"$HOST.*# Added by NetworkManager.*"/"$HOST.$DOMAIN &"/ /etc/hosts > /tmp/hosts.new
  mv -f /tmp/hosts.new /etc/hosts
fi

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: network-manager 0.8.1+git.20100810t184654.ab580f4-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.34-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
CRDA: Error: [Errno 2] No such file or directory
Date: Wed Oct 13 12:12:00 2010
Gconf:

IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
IpRoute:
 161.42.184.0/24 dev eth0 proto kernel scope link src 161.42.184.214 metric 1
 169.254.0.0/16 dev eth0 scope link metric 1000
 default via 161.42.184.1 dev eth0 proto static
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
Keyfiles: Error: [Errno 2] No such file or directory
ProcEnviron:
 LANG=de_DE.utf8
 SHELL=/bin/bash
RfKill:

SourcePackage: network-manager
ftp_proxy: http://kjp-install:<email address hidden>:8080
http_proxy: http://kjp-install:<email address hidden>:8080

[Tom Helner (duffman)]

I can confirm this issue and at least one problem that it is causing: https://bugs.launchpad.net/duplicity/+bug/662334

Listed below are the differences in 10.10 and 10.04 behavior.
- - - - - - - - - - - - - - - - - - - - - - - - - - -
10.10
$ cat /etc/hosts
xxx.xxx.xxx.xxx ubuntu # Added by NetworkManager
127.0.0.1 localhost.localdomain localhost
::1 kanpai localhost6.localdomain6 localhost6

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
- - - - - - - - - - - - - - - - - - - - - - - - - - -
10.04
$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ubuntu.example.com ubuntu

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
- - - - - - - - - - - - - - - - - - - - - - - - - - -

[Mathieu Trudel-Lapierre (cyphermox)]

I can confirm the issue, but I'm still working on getting things clarified as to how exactly we should handle /etc/hosts. It's starting to be clear that the changes should be "as little as possible" and "only if it's not already set by the admin", but this still causes issues where, like here I assume, NetworkManager is expected to handle *everything* in the network connection, including setting the proper FQDN for the current connection it possibly gets from DHCP.

Note that with this feature complete, you could get into weird issues/weird domain names in /etc/hosts when you log on to public wireless access points, for example.

[Tom Helner (duffman)]

Do you know where NetworkManager is pulling it's FQDN info from if it is not getting it from DHCP?

The behavior I noticed pre 10.04, is whatever domain the machine gets on install (either assigned by DHCP or manually during install) is the one that NetworkManager uses no mater what network you connect to. Although I cannot find anywhere that this is set on the system. This is from memory and I have not specifically tested for it, so I might not be 100% correct here.

For example machines I build at work get work's domain set by DHCP, and when I bring them home their FQDN does not change.

I don't know how NetworkManager is designed to handle this situation. But I do know, in my case if NetworkManager changes the FQDN between home and work this will cause issues w/ Duplicity backup. That said, if NM is expected to change the FQDN to the network it is on, then I can put in place workarounds to get Duplicity backup working again.

[Mathieu Trudel-Lapierre (cyphermox)]

Right now, as I understand it, NetworkManager doesn't do anything with domain name (not did it in the past). The domain name from DHCP isn't used because different servers appear to send different conflicting information, which makes it hard to figure out what to use as domain name (usually they really send a search domain, which is very different). In previous versions NM simply didn't touch /etc/hosts, the domain there was left from the initial installation.

As a workaround, you could add a script to the /etc/NetworkManager/dispatcher.d directory that will handle the hostname changes.

[Daniel Richard G. (skunk)]

Is this still an issue in Natty?

[Peter Parzer (peter-parzer)]

In Natty, the /etc/hosts still needs manual corrections after install, but I am not sure if this is NetworkManager's fault. After installation with DHCP networking the hosts-file looks like this:

127.0.0.1 localhost
127.0.1.1 myhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

and /etc/resolv.conf is correctly set by NetworkManager:

# Generated by NetworkManager
domain my.domain
search my.domain
nameserver xxx.xxx.xxx.xxx

With this configuration 'hostname -f' does not return the FQDN as it should. Deleting the second line of /etc/hosts or changing it to:

127.0.1.1 myhost.my.domain myhost

solves the problem. Is NetworkManager supposed to add the domain in /etc/hosts or is this a Problem of the Installer? When I install the old 10.04 server edition with DHCP, than the domain name is correctly set in /etc/hosts.

[Mathieu Trudel-Lapierre (cyphermox)]

Closing as won't fix, here's why:

We can' t change /etc/hosts, it's very dangerous, prone to errors, and just tends to cause major headaches for everybody. It's been tried on Maverick IIRC, and it's been completely reverted and ripped out of NM since, the decision being made by upstream in collaboration with a few Ubuntu developers and Debian developers.

As mentioned above, what you're getting from DHCP is not an actual domain name you're on (or actually, not *necessarily*, which makes it often wrong to set it in /etc/hosts unless you know what you're doing. /etc/hosts is normally set at install time with the correct hostname and domain name if necessary, by the admin; entries other than 127.0.0.1, 127.0.1.1 and the ipv6 ones, as stated above, should be all that appears in /etc/hosts.

If you're in a system that requires the domain name like this, it's probably not likely to change location or IP frequently, and the above settings take care of that. If you're on a mobile system, then the domain name always changes anyway (and you're most likely usually not going to have your system available from the net anyway, which would be the usual use case for having the domain name set).

Additionally and as a workaround if you're not yet convinced, if you're using this on a laptop with Apache or whatever: even if it's not a full FQDN things should still work. Systems will usually be available through MDNS anyway, so reachable via their hostname on the .local domain as well (which is something that can be made us of in Apache and other apps). There has been various discussions on the subject already, on bugs and mailing lists.

And finally, an excerpt from the dnsdomainname man page, section THE FQDN:

       Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.

       Therefore it depends on the configuration (usually in /etc/host.conf) how you can change it. Usually (if the hosts file is parsed before DNS or NIS) you can change it in /etc/hosts.

       If a machine has multiple network interfaces/addresses or is used in a mobile environment, then it may either have multiple FQDNs/domain names or none at all. Therefore avoid using hostname --fqdn, hostname --domain and dnsdomainname. hostname --ip-address is subject to the same limitations so it should be avoided as well.

... and there's a reasonable workaround provided in comment #5.

Ooof. Sorry if this seems a bit rash, it's not the intent. I'm just explaining why we won't be fixing this in NetworkManager, and so the response can be kept as a reference :)

[Daniel Richard G. (skunk)]

Mathieu, thank you for the detailed explanation. Automatic editing of /etc/hosts always struck me as a dicey proposition, and I'm glad to hear it got axed.

For those users/admins who do want /etc/hosts to be updated with DHCP info, it may be worthwhile to provide an example of such a dispatcher.d/ script for them to use as a starting point. It's a lot easier to modify a well-documented (if technically unsupported) script to one's needs than to figure out how to write such a script from scratch, and I think bundling one in would soften the blow of the WONTFIX for those who had hoped for an alternate outcome.

[Thomas Hood (jdthood)]

> Without the FQHN in /etc/hosts Kerberos and AD integration with windbind do not work.

I agree with Mathieu and just want to underline that if any application fails with a static /etc/hosts containing

    127.0.0.1 localhost
    127.0.1.1 <UNIX hostname>

then it's the application that needs to be fixed.