Bug 13486 - Server install uses loopback IP address
Summary: Server install uses loopback IP address
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Erik Troan
QA Contact:
Whiteboard: Winston rc1
: 13888 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-05 00:13 UTC by Stephen Rasku
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-07 22:43:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Stephen Rasku 2000-07-05 00:13:48 UTC
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:	kiev localhost.localdomain localhost

I don't believe I had this problem on a custom install.

Comment 1 Erik Troan 2000-07-15 16:44:45 UTC
Did you configure networking on the box?

Comment 2 Erik Troan 2000-07-15 16:48:05 UTC
Hmm, apparently you can't. I'm looking into this now.

Comment 3 Erik Troan 2000-07-15 16:54:05 UTC
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?

Comment 4 Stephen Rasku 2000-07-17 16:23:23 UTC
I am doing a CD/GUI install and it asks for network information and I am filling
it out.

Comment 5 Glen Foster 2000-07-30 17:41:38 UTC
This defect is considered MUST-FIX for Winston Release-Candidate #1

Comment 6 Michael Fulbright 2000-08-01 18:46:23 UTC
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?

Comment 7 Stephen Rasku 2000-08-02 19:22:17 UTC
I would expect:		localhost localhost.localdomain	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.

Comment 8 Pekka Savola 2000-08-07 08:04:10 UTC
*** Bug 13888 has been marked as a duplicate of this bug. ***

Comment 9 Erik Troan 2000-08-14 18:50:36 UTC
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.

Comment 10 Michael Fulbright 2000-09-14 21:57:02 UTC

*** This bug has been marked as a duplicate of 16482 ***

Comment 11 Stephen Rasku 2000-09-15 06:46:01 UTC
If this is going to be revisited, shouldn't we mark it DEFERRED?

Comment 12 Michael Fulbright 2000-09-26 16:10:13 UTC

Comment 13 Michael Fulbright 2000-09-26 16:55:55 UTC

Comment 14 Pekka Savola 2000-11-20 22:43:22 UTC
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.

Comment 15 Daniel Roesen 2000-11-22 23:03:51 UTC

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.

Comment 16 Christian Rose 2001-04-09 18:59:21 UTC
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
(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 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
in the install, it will query the DNS which is outside the internal network, and
returns, 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.

Comment 17 Jeremy Katz 2003-03-07 22:43:17 UTC
The behavior now is slightly different from 7.1.  We're not likely to be making
large changes in this area any time soon.

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