This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 643443

Summary: NetworkManager sets IPv6 in /etc/hosts when disabled
Product: [Fedora] Fedora Reporter: Vincent Danen <vdanen>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: chunnayya, csieh, dcbw, rom, sidney
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-25 02:04:47 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Vincent Danen 2010-10-15 11:56:34 EDT
I don't think this was an issue in F12, but I couldn't figure out why kerberos auth using SSH was no longer working (was always being prompted for a password when I had a valid ticket).

Turns out NetworkManager is writing to /etc/hosts every time it starts.

IPv4 settings are "Automatic (DHCP)" and IPv6 settings are "Ignore", which makes me think it should be disabled, but /etc/hosts looks like:

192.168.250.52	cerberus.annvix.ca	cerberus	# Added by NetworkManager
127.0.0.1	localhost.localdomain	localhost
::1	cerberus.annvix.ca	cerberus	localhost6.localdomain6	localhost6

FQDN is important with kerberos, so if I remove the ::1 entry, then kerberos auth works fine with SSH, but with it there, I think that SSH is probably seeing the IP address of cerberus.annvix.ca is ::1, not 192.168.250.52.  Dig shows the right thing:

[root@cerberus ssh]# dig cerberus.annvix.ca +short
192.168.250.52
[root@cerberus ssh]# dig -x 192.168.250.52 +short
cerberus.annvix.ca.

Shouldn't "Ignore" mean "do nothing"?  It would be ok if ::1 was in there _without_ specifying the system hostname (i.e. just aliasing to localhost6.localdomain6 and localhost6); kerberos auth will work if I remove the host aliases.

Maybe I'm missing something (like a way to completely disable IPv6), but this seriously messes up the ability to use kerberos authentication.
Comment 1 Dan Williams 2010-10-18 13:31:38 EDT
Is there some reason Kerberos is using gethostbyname() or whatever and picking the ::1 address instead of an actual routable address?

Does kerberos also fail if you manually remove the 192.168.250.52 entry and put the hostname on the 127.0.0.1 line like so?

127.0.0.1 cerberus.annvix.ca cerberus localhost.localdomain localhost
::1 cerberus.annvix.ca cerberus localhost6.localdomain6 localhost6

Basically, I'd find it really odd if kerberos is using the localhost instead of a real address.  Given that dig figures this stuff out correctly I"d like to investigate whether kerberos (or glib's resolver) is screwed somehow here before working around stuff in NM itself.
Comment 2 Vincent Danen 2010-10-18 15:32:34 EDT
No, it doesn't fail if I have /etc/hosts look like this:

#192.168.250.52	cerberus.annvix.ca	cerberus	# Added by NetworkManager
127.0.0.1	cerberus.annvix.ca cerberus localhost.localdomain	localhost
::1	cerberus.annvix.ca	cerberus	localhost6.localdomain6	localhost6

But the moment I turn it back to:

192.168.250.52  cerberus.annvix.ca      cerberus        # Added by NetworkManager
127.0.0.1       localhost.localdomain   localhost
::1     cerberus.annvix.ca      cerberus        localhost6.localdomain6 localhost6

I can no longer ssh in with my kerb credentials.

Which has me quite confused, actually.  I hope that maybe makes some sense to you as it makes absolutely none to me.  Could it be that in the first case cerberus.annvix.ca/cerberus both resolve to localhost, but in the second case one does and the other resolves to the 192 address (so kerberos gets confused maybe?).  I don't have IPv6 setup at all, so doing something like "dig -6 cerberus.annvix.ca" fails.
Comment 3 Vincent Danen 2010-11-03 18:39:02 EDT
FWIW, I'm observing the same behaviour in F14.

I'm starting to use this as a work-around, but it's not really nice (noting it in case others run into the same issue).  Add this to /etc/rc.d/rc.local:

# brutal hack for bug #643443 (remove IPv6 address)
perl -pi -e 's/::1.*//g' /etc/hosts


That solves the problem in a rather unelegant way.

Another thing that shows what is going on, when that entry in /etc/hosts for ::1 is there, if I do:

[vdanen@odvfc14]~% ssh odvfc14
The authenticity of host 'odvfc14 (::1)' can't be established.
...
[vdanen@odvfc14]~% ssh odvfc14.annvix.ca
The authenticity of host 'odvfc14.annvix.ca (::1)' can't be established.

So it's preferring IPv6 over IPv4 (the system.. glibc?) anyway, which is why having that default in there, when I don't want IPv6-anything, is so annoying.
Comment 4 Sidney Markowitz 2010-11-18 19:58:44 EST
This is also breaking the configuration script of Sun Grid Engine (gridengine* packages) in Fedora 14 and in RHEL6 (using the gridegine packages in EPEL).

You can see some symptoms of what is happening if you run the command

 hostname -i

with /etc/hosts containing a default setup that you get with NetworkManager and IPv6 disabled, such as

192.168.20.41   foo    # Added by NetworkManager
127.0.0.1       localhost.localdomain  localhost
::1      foo localhost6.localdomain6  localhost6

In RHEL6 hostname -i outputs 192.168.20.41 127.0.0.1

In Fedora 14 it outputs 192.168.20.41 ::1

This breaks Grid Engine when you run its configuration script /usr/share/gridengine/inst-sge because it calls its gethostname utility which returns the same results for ip address as hostname -i does in RHEL6, although it also does it in Fedora 14. Grid Engine is specifically testing that the results of its gethostname utility does not contain a local loopback ip address and so it refuses to continue the configuration.

Note bug #648725 comment #1 in which it is said that Network Manager adds to /etc/hosts the line with the external ip address "to preserve compatibility with programs that gethostbyname(gethostname())". The problem is that it also adds the hostname to the ipv6 line beginning with ::1, even if ipv6 is disabled. That causes the gethostbyname call for the result of gethostname (in this example 'foo') to also return '::1' which some programs will convert to '127.0.0.1'.

If there is no external ipv4 address, NetworkManager will add the host name to the 127.0.0.1 line too (See bug #648725 for an example of this behaviour breaking IPA). I suspect that what is going on is that with ipv6 disabled, NetworkManager is similarly adding the host name to the ipv6 local loopback address, which then breaks programs that check gethostbyname(gethostname()) to ensure thst there is a valid external ip address. It could be argued that such programs should better parse the results to notice the valid external address, but it would be hard to track down and fix all of them.

Also see what happens when you run in python

>>> from socket import gethostbyname
>>> from socket import gethostname
>>> gethostbyname(gethostname())
'127.0.0.1'

The errors do not occur if you comment out that first line added by Network Manager, but that appears to have a purpose. However you can also fix the problem if Network Manager did not add the hostname alias to the ::1 line, and with ipv6 disabled I don't see how that can cause a problem. If ipv6 is enabled, then Network Manager could add the ipv6 external ipv6 address and the host name instead of using the local loopback adddress, so there would still be no breakage.
Comment 5 Sidney Markowitz 2010-11-18 21:08:52 EST
I found what appears to be the relevant bug report upstream in NetworkManager and I added a comment to it.

https://bugzilla.gnome.org/show_bug.cgi?id=629021#c6
Comment 6 Dan Williams 2011-02-25 02:04:47 EST
NM no longer touches /etc/hosts as of latest updates.

*** This bug has been marked as a duplicate of bug 648725 ***