Bug 727908 - Hostname sent to server by rhnreg_ks during kickstart is incorrect
Summary: Hostname sent to server by rhnreg_ks during kickstart is incorrect
Alias: None
Product: Spacewalk
Classification: Community
Component: Clients
Version: 1.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
Depends On: 700067
Blocks: space16
TreeView+ depends on / blocked
Reported: 2011-08-03 15:20 UTC by Milan Zázrivec
Modified: 2011-08-23 09:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 700067
Last Closed: 2011-08-23 09:34:49 UTC

Attachments (Terms of Use)

Description Milan Zázrivec 2011-08-03 15:20:26 UTC
+++ This bug was initially created as a clone of Bug #700067 +++

Created attachment 495179 [details]
patch which fixes the problem

Description of problem:

If you try to kickstart RHEL6 machine using a kickstart file with a custom hostname set through "network --hostname=<somename> ...", rhnreg_ks during registration time sends hostname obtained from dhcp instead of the one defined on network line.

The problem was fixed already for RHEL4 (BZ #134078) and RHEL5 (BZ #457953), but the fix doesn't work for RHEL6, because RHEL6 anaconda benefits of NetworkManager whose behaviour circumvent the code logic used to fix the problem for RHEL4/5.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1. Setup a kickstart with network line simillar to the following one:

network --bootproto=static --hostname=ananas --ip=XXX.XXX.XXX.XXX --netmask= --gateway=XXX.XXX.XXX.XXX --nameserver=XXX.XXX.XXX.XXX

2. Kickstart a machine and then find the system's profile through WebUI and check a value of 'Hostname' field.

Systems -> Systems -> [someprofile] -> Details -> Overview

Actual results:

It contains hostname obtained from dhcp during installation time.

Expected results:

It should contain the hostname set on network line.

Additional info:

The problem is caused by the fact that anaconda uses NetworkManager to setup network before installation begins, which obtains network information from dhcp and sets also hostname so that it is different than in RHEL4/5 where it was set to localhost.localdomain (everytime) and it breaks a code logic which decides how to setup the hostname.

Currently, it sends hostname defined through network line only in case a hostname stored in kernel (line #492) is localhost.localdomain (line #499, gethostname() calls uname syscall internally which returns hostname as nodename, which can be obtained also from /proc/sys/kernel/hostname):

488 def read_network():
489     netdict = {}
490     netdict['class'] = "NETINFO"
492     netdict['hostname'] = gethostname()
493     try:
494         netdict['ipaddr'] = gethostbyname(gethostname())
495     except:
496         netdict['ipaddr'] = ""
499     if netdict['hostname'] == 'localhost.localdomain' or \
500     netdict['ipaddr'] == "":
501         hostname, ipaddr = findHostByRoute()
503         if netdict['hostname'] == 'localhost.localdomain':
504             netdict['hostname'] = hostname
505         if netdict['ipaddr'] == "":
506             netdict['ipaddr'] = ipaddr
508     return netdict

A solution could be either to use similar changes mentioned in attached patch which sends HOSTNAME from /etc/sysconfig/network obtained from findHostByRoute() everytime it differs from the one set in kernel or fix anaconda to set hostname to 'localhost.localdomain' before processing a kickstart file.


The problem disappears as soon as a client/system executes rhn-profile-sync after installation reboots or someone sets hostname to localhost.localdomain in kickstart %post script or sets directly hostname using some kickstart variable and runs the rhn-profiles-sync after that:

network --hostname=$some_kickstart_variable_holding_hostname
hostname $some_kickstart_variable_holding_hostname

Comment 1 Milan Zázrivec 2011-08-03 15:31:04 UTC
spacewalk.git master: bd4cc512b94ee378a891da5f3f2fa295b600ca10
satellite.git CLIENT-RHEL-6: 22996406bf194fa5180fc3869000e1d6727b82d2

Comment 2 Milan Zázrivec 2011-08-23 09:33:47 UTC
Changes made in


were reverted with


since the problem described in this bug is no longer an issue with
RHEL-6.1 and beyond.

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