Bug 6989

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