This bug was initially created as a copy of Bug #1093037 I am copying this bug because: Such change should get to Fedora first before getting to RHEL. Description of problem: A user is reporting that localhost is in wrong order on /etc/hosts file #man hostname THE FQDN The FQDN (Fully Qualified Domain Name) of the system is the name that the resolver(3) returns for the host name, such as, ursula.example.com. It is usually the hostname followed by the DNS domain name (the part after the first dot). You can check the FQDN using hostname --fqdn or the domain name using dnsdomainname. so with the current status of the /etc/hosts file #hostname -f localhost #hostname localhost.localdomain but it should be the oposite If it could be considered a bug it also affects RHEL 6 Version-Release number of selected component (if applicable): RHEL 7 RHEL 6 How reproducible: $ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 #hostname -f localhost #hostname localhost.localdomain Actual results: cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 #hostname -f localhost #hostname localhost.localdomain Expected results: the fqdn should be first $ cat /etc/hosts 127.0.0.1 localhost.localdomain localhost localhost4 localhost4.localdomain4 ::1 localhost.localdomain localhost localhost6 localhost6.localdomain6 #hostname -f localhost.localdomain #hostname localhost Additional info:
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Same issue here. I tried to find a good documentation but couldn't find one. Where is the exact behavior documented? `man hosts` doesn't seem clear to me, neither does TLDP. Arch's wiki does not have an article on that either.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still an issue in F34, reopening: [root@fedora ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [root@fedora ~]# cat /etc/redhat-release Fedora release 34 (Rawhide)
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
I recently had some discussion about this and came across this BZ. Based on https://lists.debian.org/debian-devel/2005/10/msg00559.html and https://lists.debian.org/debian-devel/2009/12/msg00778.html (found via https://bbs.archlinux.org/viewtopic.php?id=156064) it looks to me the current order for localhost entries in /etc/hosts on Fedora and RHEL is appropriate both from correctness point of view and from cross-distribution consistency point of view. hostname(1) is correct in general of course but localhost seems to be a special case and in fact hosts(5) suggests to use "127.0.0.1 localhost" for IPv4 capable hosts. Perhaps some clarifications for the related manual pages (hostname(1), hostname(7), and hosts(7)) about the special nature of localhost/127.0.0.1 could be considered instead of changing the order in /etc/hosts. Thanks.
(In reply to Marko Myllynen from comment #7) === > Perhaps some clarifications for the related manual pages (hostname(1), > hostname(7), and hosts(7)) about the special nature of localhost/127.0.0.1 > could be considered instead of changing the order in /etc/hosts. === It is probably a good idea to put something in Fedora and RHEL's hosts(5), perhaps right after this part that indirectly states that lines should be formatted "<IP_Address> <FQDN> <ShortName> <OtherAliases>": IP_address canonical_hostname [aliases...] Fields of the entry are separated by any number of blanks and/or tab characters. Text from a "#" character until the end of the line is a comment, and is ignored. Host names may contain only alphanumeric characters, minus signs ("-"), and periods ("."). They must begin with an alphabetic character and end with an alphanumeric character. Optional aliases provide for name changes, alternate spellings, shorter hostnames, or generic host‐ names (for example, localhost). Something to the effect of: For historical reasons, the 127.0.0.1 and ::1 lines are formatted differently to have "localhost" precede "localhost.localdomain" and their other aliases. *However*, I advocate for some comment to go in /etc/hosts, as well. I've seen people go and edit /etc/hosts without reading hosts(5). It is natural to add lines that look like what is already there. Thus, this: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 has caused users to enter something like: 192.168.1.1 testmachine testmachine.example.com ...which causes the wrong output from "hostname -f". So, perhaps a comment being added to /etc/hosts like: # Loopback entries; do not change. # For historical reasons, these lines are different than the format specified in hosts(5). 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 ...should be added.
(In reply to Bernie Hoefer from comment #8) > > It is probably a good idea to put something in Fedora and RHEL's hosts(5), > > *However*, I advocate for some comment to go in /etc/hosts, as well. Your suggestions sound good, would be good to try get the hosts(5) changes upstreamed as well. Thanks.
After evaluating this for some time I decided not to fix the order. Originally there was no localhost.localdomain in /etc/hosts, but localhost only, so let's keep it that way and consider the rest as aliases. If an application fails on localhost entries, then it's buggy and should be fixed. I have checked the customer cases which led to opening this, but they weren't open to fix any application issue but on the notion, this ordering is wrong according to the format described in the hosts(5) manual page. I won't be opening a new downstream BZ to get hosts(5) changes into upstream, because some of the distributions don't contain localhost.localdomain at all, but only localhost. With all that said I understand that the lines could lead to the below: (In reply to Bernie Hoefer from comment #8) > *However*, I advocate for some comment to go in /etc/hosts, as well. I've > seen people go and edit /etc/hosts without reading hosts(5). It is natural > to add lines that look like what is already there. Thus, this: > > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > > has caused users to enter something like: > > 192.168.1.1 testmachine testmachine.example.com So planning to change /etc/hosts to contain the following with the next release: ~~~ $ git diff diff --git a/hosts b/hosts index 849c10d..740a59a 100644 --- a/hosts +++ b/hosts @@ -1,2 +1,7 @@ +# Loopback entries; do not change. +# For historical reasons, localhost precedes localhost.localdomain: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 +# See hosts(5) for proper format and other examples: +# 192.168.1.10 foo.mydomain.org foo +# 192.168.1.13 bar.mydomain.org bar $ ~~~
(In reply to Martin Osvald from comment #11) === > So planning to change /etc/hosts to contain the following with the next release: === Adding your proposed comment will address my concerns. Thank you!
Agreed, the proposed update looks good, thanks!
The fix is in git: https://pagure.io/setup/c/2e8d28e7230558d2f70e443af1c84d5c44f00199?branch=master
FEDORA-2022-13c2b1e6db has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-13c2b1e6db
FEDORA-2022-d37f9b1e8b has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d37f9b1e8b
FEDORA-2022-d37f9b1e8b has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-d37f9b1e8b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d37f9b1e8b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-13c2b1e6db has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-13c2b1e6db` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-13c2b1e6db See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-13c2b1e6db has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-d37f9b1e8b has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Fedora Update System from comment #20) === > FEDORA-2022-d37f9b1e8b has been pushed to the Fedora 35 stable repository. === I installed setup-2.13.10-1.fc35 today. The comments in /etc/hosts look great. Thank you!