Bug 648725 - NetworkManager adds hostname to /etc/hosts pointing to localhost
NetworkManager adds hostname to /etc/hosts pointing to localhost
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
14
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 635440 643443 647311 649116 659471 660128 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-01 19:10 EDT by David O'Brien
Modified: 2011-04-12 17:27 EDT (History)
18 users (show)

See Also:
Fixed In Version: NetworkManager-0.8.3.996-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-01 20:50:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David O'Brien 2010-11-01 19:10:57 EDT
Description of problem:
IPA does not completely support IPv6, and if using NetworkManager the FQDN is added to /etc/hosts for both IPv4 & 6, pointing to localhost.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. service NetworkManager start
2.
3.
  
Actual results:
In /etc/hosts
127.0.0.1  f13client.example.com  f13client  localhost.localdomain  localhost
::1  f13client.example.com  f13client  localhost6.localdomain  localhost6

Expected results:
127.0.0.1  localhost.localdomain  localhost
::1  localhost6.localdomain  localhost6

Additional info:
Comment 1 Dan Williams 2010-11-01 23:15:11 EDT
The hostname of the machine *must* be mapped to the either localhost or to the machine's public IP address.  Not doing that breaks various things that try to take the result of gethostname(2) and look that up to determine the machine's IP address.  It also breaks cases where the hostname cannot be resolved because it's a locally-specified hostname.  Unfortunately, this isn't something we can change.  It's something that simply has to be done in /etc/hosts.

What's the specific problem that IPA has here?  What is IPA trying to do that breaks?

Note that if the machine has a non-local IP address, NM will do:

192.168.0.192	dcbw.foobar.com	dcbw	# Added by NetworkManager
127.0.0.1	localhost.localdomain	localhost
::1	dcbw.foobar.com	dcbw	localhost6.localdomain6	localhost6

to preserve compatibility with programs that gethostbyname(gethostname()).
Comment 2 David O'Brien 2010-11-02 01:01:32 EDT
When working with IPA one needs to map the hostname to the public IP address. I'm not clever/educated enough to give you the specifics of _why_ (so I've CC'd Rob Crittenden who is). From our email:

"IPv6 support is a bit spotty right now. The underlying products we use should be ok, its a matter of our installer and framework supporting it. I discovered some problems in the way we configure DNS that need to be addressed in particular.

Otherwise it is a bit of an unknown right now, I think. I think that IPv6 network availabilty is a bit of an issue for us so testing is going to be interesting."

I'm sorry I can't give you more specific details; my sysadmin skills are at the Technical Writer level.
Comment 3 Rob Crittenden 2010-11-02 09:14:29 EDT
IPA is by definition a networked service so we don't allow one to configure it using any localhost address.

What do you mean by "if the machine has a non-local IP address"? Where would this address come from? e.g. /etc/sysconfig/network-scripts/ifcfg-*?

I think we can address this via documentation, I just want to be sure we tell the user the right thing.
Comment 4 Sidney Markowitz 2010-11-18 20:06:07 EST
See my comment in Bug #643443 Comment #4 for more details. This breaks other things besides IPA. I think the problem is not that it adds the host name to the 127.0.0.1 line, because it only does that when you don't have an external IP address and in that case you can't install a networked service anyway. The problem is that even with ipv6 disabled NetworkManager adds the host name to the ipv6 local loopback line in /etc/hosts, which gethostbyname then sees as configuring an ip address of "::1" for the host name, which some non-ipv6 savvy programs end up seeing as an ip address of 127.0.0.1.
Comment 5 Chuck Lever 2010-11-29 15:38:38 EST
Adding the host name to "::1" also appears to be a problem for Kerberos and NFS.

A host key is required to serve files with Kerberos authentication over NFS.  I set up a keytab with a key for nfs/myhost.example.com@EXAMPLE.COM on my test server.

My test server's network interfaces are configured with Network Manager.  When the host comes up, NM adds myhost.example.com to the "::1" entry in /etc/hosts (as described in the above in Comment 1).  That prevents rpc.svcgssd from finding the host key I added to the keytab.  rpc.svcgssd, from what I can tell, uses standard Kerberos library functions to find this key.

If I then remove myhost.example.com from the "::1" entry, I can start rpc.svcgssd without any problem.

Some of what I've read here and in other NetworkManager-related bugs suggests that having the hostname on that entry is required for certain other applications, and is present in some non-NetworkManager configurations as well.  Does that mean that my issue is due specifically to this NetworkManager workaround behavior, or is it a Kerberos library bug?
Comment 6 Chris Rankin 2010-12-05 19:29:46 EST
(In reply to comment #1)
> The hostname of the machine *must* be mapped to the either localhost or to the
> machine's public IP address.  Not doing that breaks various things that try to
> take the result of gethostname(2) and look that up to determine the machine's
> IP address.  It also breaks cases where the hostname cannot be resolved because
> it's a locally-specified hostname.  Unfortunately, this isn't something we can
> change.  It's something that simply has to be done in /etc/hosts.

What about when you have a small local network, where the public IP address is on a router instead? I really, REALLY don't want all my hostnames mapped to 127.0.0.1 because I'm expecting the correct domainname to be matched with the correct network device. "chattr +i" is my friend, but I'd prefer it if NetworkManager didn't constantly presume to interfere with things that are none of its business. If I wanted an OS that did that then I'd run Windows.
Comment 7 Dmitri Pal 2010-12-10 15:43:36 EST
My /etc/hosts looks like this and works perfectly for the machine "lenovo.home" for my needs.  

192.168.2.107   lenovo.home     lenovo
127.0.0.1       localhost.localdomain   localhost
::1     localhost6.localdomain6 localhost6

After Network Manager restart I get

127.0.0.1       lenovo.home     lenovo  localhost.localdomain   localhost
::1     lenovo.home     lenovo  localhost6.localdomain6 localhost6
192.168.2.107   lenovo.home     lenovo

And this does not work.

The Network Manager should be smarter and see that the name is defined on a different line and not add host name to the local host line if it is already defined in the file.
Comment 8 Chris Rankin 2010-12-11 16:23:48 EST
I have suddenly noticed that my PC's hostname has been changed to "localhost.localdomain". Is this NetworkManager's fault too?
Comment 9 Chris Rankin 2010-12-11 16:50:40 EST
(In reply to comment #8)
> I have suddenly noticed that my PC's hostname has been changed to
> "localhost.localdomain". Is this NetworkManager's fault too?

OMFG, it is NetworkManager's fault!!

Dec 11 21:45:45 volcano NetworkManager[5010]: <info> Setting system hostname to 'volcano.underworld' (from system configuration)
Dec 11 21:45:45 volcano NetworkManager[5010]: <info> Updating /etc/hosts with new system hostname
Dec 11 21:45:45 volcano NetworkManager[5010]: <warn> couldn't update /etc/hosts: (22) Failed to rename file '/etc/hosts.FYNSNV' to '/etc/hosts': g_rename() failed: Operation not permitted
Dec 11 21:45:45 volcano NetworkManager[5010]: <info> Setting system hostname to 'localhost.localdomain' (error updating /etc/hosts)

The **** thing is spiting me for not letting it mangle my /etc/hosts file! I can't continue fighting with NM like this over every single thing. Is there a simple way to fix this, or am I just going to have to uninstall it?
Comment 10 Dan Williams 2010-12-13 12:19:59 EST
(In reply to comment #9)
> (In reply to comment #8)
> > I have suddenly noticed that my PC's hostname has been changed to
> > "localhost.localdomain". Is this NetworkManager's fault too?
> 
> OMFG, it is NetworkManager's fault!!
> 
> Dec 11 21:45:45 volcano NetworkManager[5010]: <info> Setting system hostname to
> 'volcano.underworld' (from system configuration)
> Dec 11 21:45:45 volcano NetworkManager[5010]: <info> Updating /etc/hosts with
> new system hostname
> Dec 11 21:45:45 volcano NetworkManager[5010]: <warn> couldn't update
> /etc/hosts: (22) Failed to rename file '/etc/hosts.FYNSNV' to '/etc/hosts':
> g_rename() failed: Operation not permitted
> Dec 11 21:45:45 volcano NetworkManager[5010]: <info> Setting system hostname to
> 'localhost.localdomain' (error updating /etc/hosts)
> 
> The **** thing is spiting me for not letting it mangle my /etc/hosts file! I
> can't continue fighting with NM like this over every single thing. Is there a
> simple way to fix this, or am I just going to have to uninstall it?

If locked down /etc/hosts or if SELinux is denying NM the ability to change /etc/hosts, then yes, your hostname will revert, because your current hostname cannot be updated in /etc/hosts, so there must be a fallback of some kind.

Again, your current hostname *must* map to something in /etc/hosts, or various things will break.  Like X, or Firefox.  Anything that tries to use your hostname for anything will break if the hostname cannot be resolved to an IP address matching the local machine.  That can be 127.0.0.1, ::1, or something else.

Next, we're looking at removing the "hostname maps to current public IP" behavior because it's really only a workaround for stupid programs that do gethostbyname(gethostname()) to find your IP address.  That's completely broken and will certainly not work in various circumstances (especially if/when your IP address changes); why does IPA require that?  Why does Kerberos require that?

But removing the "hostname->public IP" mapping leaves us back at mapping the current hostname to 127.0.0.1, unless the sysadmin has mapped the current hostname to something else.

The bottom line: your current hostname *must* map to something in /etc/hosts that is resolvable to the local machine.  That's all NM is trying to do.  The reason the mappings for your public IP address were added was due to programs that used the gethostbyname(gethostname()) pattern, which is quite busted.
Comment 11 Dan Williams 2010-12-13 12:27:53 EST
Chris, what are your requirements for /etc/hosts?  In your system, what would a "correct" /etc/hosts file look like?
Comment 12 Chris Rankin 2010-12-13 12:35:40 EST
Before NM "had its way" with it, my /etc/hosts file looked like:

127.0.0.0 localhost.localdomain localhost localhost4
::1       localhost6.localdomain6 localdomain6

192.168.1.1  myhostname.mydomainname myhostname

where 192.168.1.1 is the IP address on eth0. I am even running a local nameserver which can resolve myhostname.mydomainname to 192.168.1.1, and vice verse.

Whichever way you look at it, my /etc/hosts file is already mapping my PC's local hostname to something in /etc/hosts.
Comment 13 Chuck Lever 2010-12-13 12:36:22 EST
(In reply to comment #10)
> Next, we're looking at removing the "hostname maps to current public IP"
> behavior because it's really only a workaround for stupid programs that do
> gethostbyname(gethostname()) to find your IP address.  That's completely broken
> and will certainly not work in various circumstances (especially if/when your
> IP address changes); why does IPA require that?  Why does Kerberos require
> that?

Kerberos needs to know the name of the local host so it can look up keys in the local keytab.  The key in question here is "nfs/matisse.1015granger.net" for the rpc.svcgssd daemon.  Other services might want "host/matisse.1015granger.net" instead.

The library appears to have some difficulty divining the local hostname: matisse.1015granger.net.  I'm told that Kerberos does not have this problem on other platforms.
Comment 14 Dan Williams 2010-12-13 12:48:13 EST
(In reply to comment #12)
> Before NM "had its way" with it, my /etc/hosts file looked like:
> 
> 127.0.0.0 localhost.localdomain localhost localhost4
> ::1       localhost6.localdomain6 localdomain6
> 
> 192.168.1.1  myhostname.mydomainname myhostname
> 
> where 192.168.1.1 is the IP address on eth0. I am even running a local
> nameserver which can resolve myhostname.mydomainname to 192.168.1.1, and vice
> verse.
> 
> Whichever way you look at it, my /etc/hosts file is already mapping my PC's
> local hostname to something in /etc/hosts.

That appears to be a bug and should not happen; if the hostname of the machine is already mapped to a public IP address of one of the interfaces NM controls, then NM should ignore /etc/hosts as it is already valid.

In the meantime, we're discussing ways to fix this issue once and for all and try to make everyone happy, given the constraints we have.
Comment 16 Sidney Markowitz 2010-12-13 15:08:04 EST
(in reply to comment #15)

> Again, your current hostname *must* map to something in /etc/hosts,
> or various things will break.

Why? On my older (pre-NM) systems the hostname and public ip address do not appear in /etc/hosts, and gethostbyname finds the ip address from the DNS server. That seems to be what everything expects and works fine for dynamic ip addresses.

Why not leave the hostname out of /etc/hosts when DNS is supplying the ip address?

Also, could you say more about what requires the hostname to appear on the ::1 line? It is that specifically which is breaking things I'm trying to run, as I'm seeing programs that do not expect a properly configured system to map the hostname to a local address.
Comment 17 Chris Rankin 2010-12-13 15:38:16 EST
(In reply to comment #10)
> The bottom line: your current hostname *must* map to something in /etc/hosts
> that is resolvable to the local machine.  That's all NM is trying to do.  The
> reason the mappings for your public IP address were added was due to programs
> that used the gethostbyname(gethostname()) pattern, which is quite busted.

I have just tested this on my PC:

    char hostname[128];
    if (gethostname(hostname, sizeof(hostname)) == 0) {
        const struct hostent *host = gethostbyname(hostname);
        if (host != NULL) {
            printf("Hostname: %s\n", host->h_name);
        }
    }

And the output is as expected. I even get the correct result when I *remove* the lines for /etc/hosts, thanks to my local nameserver. So I can't see any reason at all for NM to modify /etc/hosts here.
Comment 18 Colin Simpson 2011-01-04 12:10:55 EST
I opened a very similar bug to this when F14 first appeared. 

https://bugzilla.redhat.com/show_bug.cgi?id=635440

This is also a problem on RHEL 6! Should this be duplicate for RHEL6, as much more likely to be an issue in a commercial RHEL environment where Kerberos is more common.

I don't mind NM adding these lines to NM but is it configurable?

I just get :

10.50.54.226 fedoratest # Added by NetworkManager

So I need FQDN so Kerberos/GSSAPI works but my DHCP server doesn't put out the domain name.

Can I get ?

10.50.54.226 fedoratest.mydomainname fedoratest

Is there a configuration option to specify an appended domain or/and to turn off this adding to /etc/hosts?
Comment 19 Orion Poplawski 2011-01-04 15:52:02 EST
Is there anyway to work around this for now?  It does appear that NM strips off any domain name and only puts the short name in /etc/hosts, and sets the hostname to the short name (which is probably okay).

Also, even having the FQDN in the ::1 line breaks GSSAPI with ssh.

Perhaps a config setting for NM to disable mucking with /etc/hosts for those of us with more complicated network environments?
Comment 20 Orion Poplawski 2011-01-05 18:31:16 EST
(In reply to comment #14)
> In the meantime, we're discussing ways to fix this issue once and for all and
> try to make everyone happy, given the constraints we have.

Where is this discussion taking place?  Thanks!
Comment 21 Steve Dickson 2011-01-06 07:27:15 EST
A side note. Adding 'rdns = false' to the libdefaults section in /etc/krb5.conf
will tell the Kerberos library not to do the reverse DNS lookups which
causes this problem... 

Its not clear what type of security ramifications this has, but it is a
work-around that works...
Comment 22 Steve Dickson 2011-01-06 07:29:51 EST
Here is another work-around to this problem: 
    https://bugzilla.redhat.com/show_bug.cgi?id=635440#c3
Comment 23 Dan Williams 2011-01-10 17:59:42 EST
Modification of /etc/hosts has been removed upstream and will hit in future Fedora update.  To ensure that the current hostname is mapped to a locally accessible IP address, as some tools require, you should install nss-myhostname.  Otherwise, you're free to not install that, and to manage /etc/hosts as you see fit after that update hits.
Comment 24 Dan Williams 2011-01-10 18:00:48 EST
*** Bug 635440 has been marked as a duplicate of this bug. ***
Comment 25 Colin Simpson 2011-01-11 04:55:55 EST
This is also a bug in RHEL 6, should we open a new bug #.
Comment 26 Dan Williams 2011-01-11 13:03:58 EST
(In reply to comment #25)
> This is also a bug in RHEL 6, should we open a new bug #.

Yes.  There's little time to get that fixed for 6.1, so the sooner the better.
Comment 27 Fedora Update System 2011-02-24 01:05:40 EST
NetworkManager-0.8.3.995-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.995-1.fc14
Comment 28 Fedora Update System 2011-02-24 01:09:08 EST
NetworkManager-0.8.3.995-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.995-1.fc13
Comment 29 Fedora Update System 2011-02-24 15:56:54 EST
NetworkManager-0.8.3.995-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.995-1.fc14
Comment 30 Dan Williams 2011-02-25 02:04:47 EST
*** Bug 643443 has been marked as a duplicate of this bug. ***
Comment 31 Dan Williams 2011-02-25 14:08:25 EST
*** Bug 660128 has been marked as a duplicate of this bug. ***
Comment 32 Dan Williams 2011-02-25 14:09:02 EST
*** Bug 659471 has been marked as a duplicate of this bug. ***
Comment 33 Dan Williams 2011-02-25 18:24:55 EST
*** Bug 647311 has been marked as a duplicate of this bug. ***
Comment 34 Fedora Update System 2011-02-25 18:42:31 EST
Package NetworkManager-0.8.3.996-1.fc14:
* should fix your issue,
* was pushed to the Fedora 14 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.3.996-1.fc14'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.996-1.fc14
then log in and leave karma (feedback).
Comment 35 Fedora Update System 2011-02-25 18:45:32 EST
Package NetworkManager-0.8.3.996-1.fc13:
* should fix your issue,
* was pushed to the Fedora 13 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.3.996-1.fc13'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.996-1.fc13
then log in and leave karma (feedback).
Comment 36 Fedora Update System 2011-03-01 20:48:49 EST
NetworkManager-0.8.3.996-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 37 Fedora Update System 2011-03-03 04:46:55 EST
Package NetworkManager-0.8.3.997-1.fc13:
* should fix your issue,
* was pushed to the Fedora 13 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.3.997-1.fc13'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.997-1.fc13
then log in and leave karma (feedback).
Comment 38 Fedora Update System 2011-03-24 23:29:47 EDT
NetworkManager-0.8.3.998-2.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/NetworkManager-0.8.3.998-2.fc13
Comment 39 Gabriel Somlo 2011-03-26 15:34:40 EDT
*** Bug 649116 has been marked as a duplicate of this bug. ***
Comment 40 Fedora Update System 2011-04-12 17:27:40 EDT
NetworkManager-0.8.3.998-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.