I did a default server install without installing any servers. When I
rebooted, it said:
(kiev is the hostname I specified). When I checked /etc/hosts, it only had
127.0.0.1 kiev localhost.localdomain localhost
I don't believe I had this problem on a custom install.
Did you configure networking on the box?
Hmm, apparently you can't. I'm looking into this now.
Umm, could you let me know what kind of install you did (NFS/CDROM/FTP) and if
you for network configuration. If so, are you filling it out?
I am doing a CD/GUI install and it asks for network information and I am filling
This defect is considered MUST-FIX for Winston Release-Candidate #1
Did the nameserver you specified map the IP you supplied for eth0 back to the
hostname 'kiev'? I would
We rely on the nameserver to fill out the /etc/hosts file. After several
different schemes on how to properly handle the /etc/hosts file the current
scheme seems to cause the least problems (all schemes had issues it seems).
Just so we can possibly fine tune how /etc/hosts is written - what would you
have expected to be in the /etc/hosts file after the install?
I would expect:
127.0.0.1 localhost localhost.localdomain
I shouldn't have to rely on the nameserver to determine this because I am
specifying the IP address and name in the install.
*** Bug 13888 has been marked as a duplicate of this bug. ***
While I think this is an actual bug, chaning this code this close to a release
is a Bad Idea (TM). We'll revisit this for Florence.
*** This bug has been marked as a duplicate of 16482 ***
If this is going to be revisited, shouldn't we mark it DEFERRED?
Moving to RESOVLED - DEFERRED from CLOSED - DEFERRED
Reminder. This is something to be considered rather early in the
next release process.
I don't like using the data from DNS lookups myself, if the user gave
IIRC there are issues with kickstart installs in this area, too.
At least for RH 6.2 (didn't check RH7 yet) it's impossible to do a
NFS kickstart install and have a completely divergent network configuration for
the install phase and the future, because the settings of the "network" line in
ks.cfg are used for both the installer _and_ for the final networking
configuriation. This makes %post hacks necessary to adjust hostname, eth0
config, /etc/resolv.conf and /etc/sysconfig/networking (GATEWAY) settings etc.
Please advise wether I should file that problem as a BugID of its own.
An example of a situation where the current way of doing it in the installer is
Imagine a host on a small company network (without own DNS) with a private ip
range. Locally, the host is known as host.foo.org and has the ip 10.0.0.3
(defined in /etc/hosts of the few machines).
But host.foo.com is also known to the outside world, but then returns the ip of
the gateway to this internal network, say 18.104.22.168. This is a perfectly
valid situation - the host may sometimes send it's host name to outside
services, and outside services won't be confused by an unresolvable adress, but
rather send their answers to the gateway, which then forwards it correctly.
Internally, it will work since the machines know each other by /etc/hosts
entries - perfectly viable if it is a
really small network with only a few computers. You shouldn't need a DNS server
of your own for such a small network.
This will break the installer logic - when you enter host.foo.org and 10.0.0.3
in the install, it will query the DNS which is outside the internal network, and
returns 22.214.171.124, the gateway adress. The installer is then confused and
sets up the machine as localhost.localdomain.
The only *real* solution is by trusting that what the user entered is correct.
The behavior now is slightly different from 7.1. We're not likely to be making
large changes in this area any time soon.