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 a.b.c.d localhost.localdomain 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 interfaces): 127.0.0.1 localhost localhost.localdomain myip myhost.xxxx.fi I dig my ip up from /etc/sysconfig/network-scripts/ifcfg-eth0 in my 'fix redhat glitches' patch. 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-client, samba: 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. Apache: 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. tcp_wrappers: 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 in.telnetd: ALL 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.") ipchains: 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 ***