Bug 29688 - hostname never set during or after clean install
Summary: hostname never set during or after clean install
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Erik Troan
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-27 01:46 UTC by Tim Clymo
Modified: 2007-04-18 16:31 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-19 21:50:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
requested values (731 bytes, text/plain)
2001-03-07 20:47 UTC, R P Herrold
no flags Details

Description Tim Clymo 2001-02-27 01:46:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-0.1.10 i686)


Wolverine seems to behave differently to previous RH distributions in the
following scenario:
1) During clean install, set it up as a DHCP client
2) The DHCP server isn't a "proper" fully featured implementation - it's
actually the DHCP spoof from an Ascend Pipeline 75 which simply returns an
IP address, default gateway and DNS servers. No hostname is returned, and
it certainly doesn't interact with DDNS or anything clever.

Previous distributions have done a gethostbyaddr some time during the init
sequence to determine the hostname (the default resolver will try
/etc/hosts first, and then DNS if there's no match - I'm not using NIS).
However, wolverine doesn't do anything like this, and the hostname ends up
being set as localhost.localdomain

I've done a sys-unconfig which seems to have fixed it. Specifically, I
think it put a HOSTNAME=xxxx line in
/etc/sysconfig/network-scripts/ifcfg-eth0 which it appears to have derived
from a gethostbyaddr call against the address it got from the DHCP "server"
(I've put an entry in /etc/hosts for the address which I know will be
returned by the DHCP, but it is also resolvable to the same name forwards
and reverse by DNS if necessary).

I liked the "old" behaviour where it wasn't necessary to set anything up -
it just went off and sorted itself out without assistance (either from
hosts if the correct entry was there, or DNS if not)

Reproducible: Always
Steps to Reproduce:
1. See description
2.
3.

Comment 1 Glen Foster 2001-03-02 18:05:30 UTC
Our installer team-lead thinks we should really fix this before next release.

Comment 2 R P Herrold 2001-03-07 00:45:51 UTC
This still present in 7.1RC1

-- Russ Herrold

Comment 3 Erik Troan 2001-03-07 18:57:53 UTC
What is in /etc/sysconfig/network, what does pump --status say, and what
does ifconfig say?

Also, does 'host <yourip>' return anything usefull?

I've tested this here and pump does a reverse DNS lookup properly.

Comment 4 R P Herrold 2001-03-07 20:44:56 UTC
(7.1RC__-3/4/01 version)
I removed the HOSTNAME="<snip>" line after doing my most recent install, and it
worked fine --

---  Perhaps all that is needed is a explanation to '(Leave blank for automatic
DNS-based hostname assignment)', and removing the entry from
/etc/sysconfig/netwrok

-------------------------

A problem with this is that if networking does not get set up (as was the case
with this build -- it had an ISA SMC-Ultra at 10/300, sshd will generate keys
with bad hostnames when first started ...

--------------------------

I will attach the requested output in a second.

-- Russ Herrold


Comment 5 R P Herrold 2001-03-07 20:47:35 UTC
Created attachment 12022 [details]
requested values

Comment 6 Erik Troan 2001-03-07 20:49:24 UTC
Did you enter a host name manually during installation?

Comment 7 R P Herrold 2001-03-07 21:25:19 UTC
Yes -- a dummy which I could egrep for to see where it landed.

that is why I manuially removed the line from /etc/sysconfig/network

-- Russ

Comment 8 Tim Clymo 2001-03-08 17:50:25 UTC
For me, I told it to used DHCP for eth0 configuration so it didn't give any
opportunity to enter anything at install time:

1) /etc/sysconfig/network contains a line "HOSTNAME=localhost.localdomain"
2) pump --status returns viable numeric entries for every field (pump
--lookup-hostname returns nothing at all, I have no idea whether this is
expected...)
3) ifconfig shows correct addresses and subnetmasks bound to eth0 and lo
4) host <IP addr of eth0> returns a proper answer (FQDN)


Comment 9 Erik Troan 2001-03-13 15:42:50 UTC
What does 'hostname' say when you log into the system?

Comment 10 R P Herrold 2001-03-14 03:43:02 UTC
QA 0309 upgrade frpm 7.1RC2 --

[herrold@dhcp164 herrold]$ hostname
dhcp164.basement.net
[herrold@dhcp164 herrold]$              

... that is, the FQDN ...

=================================================

Comment 11 Erik Troan 2001-03-14 14:27:03 UTC
So what's the bug? Isn't that what the hostname *should* say?

Comment 12 R P Herrold 2001-03-14 15:54:42 UTC
I consider the item closed and resolved -- dunno about Tim C -- the initial
submitter ..

Russ Herrold

Comment 13 Erik Troan 2001-03-14 15:57:18 UTC
You're the boss ;-)

Comment 14 Tim Clymo 2001-03-19 17:53:43 UTC
Can you re-open this, my hostname says localhost.localdomain

I have discovered a "better" workaround (to get sshd keys generated properly).

1) Perform install
2) After install is finished and system reboots - don't let it come up on its 
own, boot into single user mode
3) Edit /etc/sysconfig/network, change "HOSTNAME=localhost.localdomain" to 
proper hostname (optionally place appropriate entry in /etc/hosts to get it to 
use this instead of DNS, or change /etc/resolv.conf to use an appropriate 
search path or domain)
4) Reboot and let it start normally for the "first" time

Comment 15 Erik Troan 2001-03-20 16:15:57 UTC
Tim, I can't reproduce this problem. On every system I've tried pump sets the
hostname properly at startup.


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