From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040803

Description of problem:
When you register a machine against RHN it sends a h/w profile which
includes the 'hostname'. This hostname is used by default as the
profile name, and can also be used in provisioning macros.

Unfortunately, if you use rhn_register during a kickstart it does not
really send the hostname as returned by gethostname(2), it just sends
the FQDN of the IP address associated with eth0. (see
findHostByRoute() in hardware.py)

This is frequently not the hostname that we want - particularly in macros.

Many customers are doing provisioning etc. over a service network and
the hostname associated with this service network address is _not_
what they want. They want {@ rhn.system.hostname @} to resolve to the
same as 'hostname' on the command line. 

The information is there - it will have been set by anaconda in
/etc/sysconfig/network

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

How reproducible:
Always

Steps to Reproduce:
1. Configure multihomed machine
2. Register to RHN in kickstart
3. Check hostname on RHN
    

Actual Results:  hostname on RHN is different to result of 'hostname'
on commandline, depending on NIC ordering.

Expected Results:  should be same.

Additional info:

I accept that using the FQDN of the first NIC on the system is a valid
fallback if hostname has not been set. However, the checking order
should be:

gethostname()
HOSTNAME in /etc/sysconfig/network
FQDN of eth0

This is a problem for British Airways