I did a default server install without installing any servers. When I rebooted, it said: localhost login: instead of: kiev login: (kiev is the hostname I specified). When I checked /etc/hosts, it only had one entry: 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 it asks 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 it out.
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 suspect not. 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 192.9.200.3 kiev 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 it already.
ACK. 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 completely wrong: 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 194.47.185.51. 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 194.47.185.51, 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.