Bug 643443

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.

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.

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.

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.

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

NM no longer touches /etc/hosts as of latest updates.

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