Bug 6989 - RedHat 6.1 text install generates bad /etc/hosts file
Summary: RedHat 6.1 text install generates bad /etc/hosts file
Status: CLOSED DUPLICATE of bug 8385
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: installer
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-13 19:46 UTC by Jay Berkenbilt
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-22 16:16:50 UTC

Attachments (Terms of Use)

Description Jay Berkenbilt 1999-11-13 19:46:24 UTC
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:	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  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....

Comment 1 Jay Turner 1999-11-29 19:51:59 UTC
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.

Comment 2 Pekka Savola 1999-12-13 14:21:59 UTC
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: localhost localhost.localdomain myhost.xxxx.fi

This IMO should be (apart from those people using PPP and no ethernet
interfaces): 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)

Comment 3 Pekka Savola 1999-12-20 20:41:59 UTC
This seems to happen with only one NIC too.

The updated initscripts package is probably the key here.

Comment 4 Randy Russell 1999-12-23 17:14:59 UTC
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 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 line in /etc/hosts.
Consequently, if one has a line in /etc/hosts.allow such as

in.telnetd:, 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.")

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 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

Comment 5 Jay Turner 2000-02-22 16:16:59 UTC
*** This bug has been marked as a duplicate of 8385 ***

Note You need to log in before you can comment on or make changes to this bug.