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:
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()).
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.
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.
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.
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 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?
(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.
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.
I have suddenly noticed that my PC's hostname has been changed to "localhost.localdomain". Is this NetworkManager's fault too?
(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?
(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.
Chris, what are your requirements for /etc/hosts? In your system, what would a "correct" /etc/hosts file look like?
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.
(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.
(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.
(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.
(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.
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?
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?
(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!
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...
Here is another work-around to this problem: https://bugzilla.redhat.com/show_bug.cgi?id=635440#c3
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.
*** Bug 635440 has been marked as a duplicate of this bug. ***
This is also a bug in RHEL 6, should we open a new bug #.
(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.
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
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
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
*** Bug 643443 has been marked as a duplicate of this bug. ***
*** Bug 660128 has been marked as a duplicate of this bug. ***
*** Bug 659471 has been marked as a duplicate of this bug. ***
*** Bug 647311 has been marked as a duplicate of this bug. ***
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).
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).
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.
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).
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
*** Bug 649116 has been marked as a duplicate of this bug. ***
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.