Red Hat Bugzilla – Bug 6989
RedHat 6.1 text install generates bad /etc/hosts file
Last modified: 2008-05-01 11:37:52 EDT
I use the text install, so I don't know whether this also applies to the
graphical install. I also have only tried this with i386 systems, but I am
guessing that it applies to all systems.
When I install RedHat Linux 6.1 and specify a static IP address for my
machine, I end up with a hosts file that looks like this:
127.0.0.1 localhost.localdomain localhost my.full.host.name
where a.b.c.d is my static IP address.
Many applications get confused if the hostname resolves to 127.0.0.1. I've
had two appilcations including samba fail to work properly because of this.
It is also the case that the /etc/resolv.conf does not have anything filled
in for serach so one must fully qualify hostnames. There is also no place
in the installation to specify a secondary or tertiary DNS server.
Gratuitious remark: I think the anaconda-based installation is a great leap
forward for RedHat. Supporting graphical installation and text-based
installation is a good thing. I hope that, in time, the new anaconda-based
installation system will grow to include all the functionality that the old
system had including fixing the problems mentioned above, allowing
selection of which daemons to start at boot time, and showing the about of
disk space required for the current set of selected packages....
I am forwarding this to a developer for further action.
I was not able to replicate the behavior of the /etc/hosts file, getting only
the loopback entry there, but I was able to replicate the behavior of the
resolv.conf file with the missing search directive, and the fact that the
hostname did not get entered into the /etc/hosts file is also a problem.
Just for the record, we're having the same problem here. The box in question is
installed via FTP and it has two ethernet interfaces (it is probably important,
since a dummy /etc/sysconfig/network-scripts/ifcfg-eth1 is created for it too).
It might also be relevant that we're using initscripts package from updates
(4.70-1) automatically (ie. the FTP has updated RPMS directory) because the
older one was so badly broken.
resolv.conf had only an empty "search" string, and /etc/hosts had one line:
127.0.0.1 localhost localhost.localdomain myhost.xxxx.fi
This IMO should be (apart from those people using PPP and no ethernet
127.0.0.1 localhost localhost.localdomain
I dig my ip up from /etc/sysconfig/network-scripts/ifcfg-eth0 in my 'fix redhat
This is obviously related to resolv.conf issues (eg. #6624)
This seems to happen with only one NIC too.
The updated initscripts package is probably the key here.
Here are a few examples of what this bug may affect in the hope that people
observing these problems will find and discover the simple (but potentially
elusive) fix in /etc/hosts. These scenarios mostly affect scenarios in which
one is testing network services using client utilities on the server itself and
a "files first" /etc/nsswitch.conf.
Samba's host-based security makes a distinction between network IPs and
loopback. Consequently, having the FQDN on the 127.0.0.1 line in /etc/hosts
will occasionally provide misleading results from clients like smbclient run on
the server itself.
Like Samba, Apache's host-based security understands the difference between
network IPs and loopback. Consequently, testing Apache using clients on the
server itself may sometimes provide misleading results.
Testing virtual hosts using a client on the server itself may produce results
that differ from what "real" clients see.
Use of the LOCAL keyword does not match localhost because localhost.localdomain
is specified before localhost on the 127.0.0.1 line in /etc/hosts.
Consequently, if one has a line in /etc/hosts.allow such as
in.telnetd: 192.168.1.128/255.255.255.192, LOCAL
plus a line in /etc/hosts.deny such as
then giving the command 'telnet localhost' will fail because the requesting
hostname will appear as localhost.localdomain. (LOCAL essentially means
"hostnames without dots in their names.")
In general, one should use IP addresses when specifying firewalling rules using
ipchains. Nevertheless, one can add rules in which sources (-s) and
destinations (-d) are specified using a host or network names, and ipchains will
attempt to resolve the specification. Consequently, the following
(oversimplified for clarity) rule specifications will not provide the desired
effect if mail.mydomain.com appears on the 127.0.0.1 line of /etc/hosts:
ipchains -A input -p tcp -s 0/0 -d mail.mydomain.com 25 -j ACCEPT
ipchains -P input REJECT
We hope that we are permitting access to our mail server, but denying everything
else. What we actually get, however, is REJECTion of everything except port 25
access from 127.0.0.1
*** This bug has been marked as a duplicate of 8385 ***