This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 643443 - NetworkManager sets IPv6 in /etc/hosts when disabled
NetworkManager sets IPv6 in /etc/hosts when disabled
Status: CLOSED DUPLICATE of bug 648725
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-10-15 11:56 EDT by Vincent Danen
Modified: 2011-02-25 02:04 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-25 02:04:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
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:	cerberus	# Added by NetworkManager	localhost.localdomain	localhost
::1	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 is ::1, not  Dig shows the right thing:

[root@cerberus ssh]# dig +short
[root@cerberus ssh]# dig -x +short

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 entry and put the hostname on the line like so? cerberus localhost.localdomain localhost
::1 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:

#	cerberus	# Added by NetworkManager cerberus localhost.localdomain	localhost
::1	cerberus	localhost6.localdomain6	localhost6

But the moment I turn it back to:      cerberus        # Added by NetworkManager       localhost.localdomain   localhost
::1      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 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" 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
The authenticity of host ' (::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   foo    # Added by NetworkManager       localhost.localdomain  localhost
::1      foo localhost6.localdomain6  localhost6

In RHEL6 hostname -i outputs

In Fedora 14 it outputs ::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 ''.

If there is no external ipv4 address, NetworkManager will add the host name to the 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())

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.
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 ***

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