Bug 118414 - up2date/rhn_register doesn't correctly resolve remote host name,IP
up2date/rhn_register doesn't correctly resolve remote host name,IP
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
Depends On:
Blocks: up2date-rhel3-u2
  Show dependency treegraph
Reported: 2004-03-16 10:27 EST by Brian Carp
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-25 17:07:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brian Carp 2004-03-16 10:27:23 EST
Description of problem:
When trying to register (or re-register) my system with Red Hat Network, I am forced 
to decline submitting information about my system (the hostname, kernel info, etc.) 
because the application cannot correctly determine the host IP or name and does not 
allow me to modify these fields (only the Profile name).  If I run up2date during a 
remote session through ssh, then the application uses my remote host and name 
resolution in the registration; however, if I run the application locally from the 
console, it announces my IP address as  And because I am unable to 
modify these fields, the information is not correct and I must choose not to send any 
of the system info through.

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

How reproducible:

Steps to Reproduce:
1. up2date --register
2. in Step 3 (Register a System Profile - Hardware), check the hostname and IP 

Actual Results:  Version: 3ES
Hostname: [reverse DNS lookup - resolves to ISP's registered name]


Version: 3ES
Hostname: [the machine's hostname - CORRECT]
IP Address:

Expected Results:  Version: 3ES
Hostname: [the machine's hostname - i.e. the value returned by "hostname"]
Comment 1 Adrian Likins 2004-03-22 16:18:30 EST
Some of this behaviour should of changed in the first update set
for rhel3. (up2date-4.2.5)

Are you still seeing these problems with 4.2.5?
Comment 2 Brian Carp 2004-03-23 10:02:50 EST
Yes, this behavior was observed in version 4.2.5, as indicated in the Version-Release 
information above ('rpm -q' returns "up2date-4.2.5-1").
Comment 3 Adrian Likins 2004-04-06 15:50:08 EDT
I'm not sure how the current code would be failing to
detect the ip correctly. Heres a run down of what it
does to detect this:

1. Looks up hostname  (socket.gethostname)
2. resolves that name to an up (socket.gethostbyname())

If the above is not and/or "localhost"
it tries:

opens a socket to serverURL (xmlrpc.rhn.redhat.com by default)
or to proxyUrl (if a proxy is configured)

figures out what interface that socket is on, and gets its
ip address. Then it resolves the hostname via a gethostbyaddr
on that address.

The first step can "fail" if the machine belives its hostname
is "localhost" and/or the hostname resolves to 
Check the /etc/hosts file to see if this is whats happening.

That said, the second step should always get a useable IP
address, so I'm not sure whats going on. Anything unusual
about this machines hostname, dns, ip, etc?
Comment 4 Brian Carp 2004-04-06 16:02:17 EDT
It's possible that the behavior is a result of the /etc/hosts file.  The default (i.e., the 
one generated by the RHEL 3 ES install) seemed a little strange to me, and I've since 
fixed it (but I'm haven't re-registered the machine since).  The original /etc/hosts file 
looked something like this:

# Do not remove the following line, or various programs
# that require network functionality will fail.               localhost.localdomain localhost my.example.com my

I subsequently changed it to the following:

# Do not remove the following line, or various programs
# that require network functionality will fail.               localhost.localdomain localhost
XXX.XXX.XXX.XXX         my.example.com my

The interface was listening on the correct IP address, but it was not in the /etc/hosts 
Comment 5 Brian Carp 2004-04-06 16:10:52 EDT
FYI:  I since performed an update on the hardware profile associated with the machine 
(by running up2date --hardware), and it now lists the correct hostname and IP 
address on my Systems profile page on RHN.  I imagine that the alterations to the /
etc/hosts file may be responsible for this, although I can't say for sure.

Perhaps the RedHat team may want to look into how the default /etc/hosts file is 
generated during the install of RHEL 3 ES.

Comment 6 Gavin Edwards 2004-04-28 12:34:17 EDT
I've just done my very first RHEL 3 WS U1 install (so I am using
up2date-4.2.5-1) and have had a similar problem. At the stage where
up2date was detecting my configuration it just sat there for a few
minutes and then listed ERROR in all the fields. I tried running
up2date at least 10 times with the same results.

After reading the above comments I checked my /etc/hosts file,
originally it read:

# Do not remove the following line, or various programs
# that require network functionality will fail.               mymachine localhost.localdomain localhost

so I removed mymachine so the machine would rely on DNS to resolve the
its IP address, i.e. my /etc/hosts file now reads:

# Do not remove the following line, or various programs
# that require network functionality will fail.               localhost.localdomain localhost

and this instantly fixed my up2date problem.

Other information: This was a totally fresh full install, I configured
up2date to work via a proxy, I was using an already existing RHN
account with 3 new and unused entitlements.

Like Brian, the default /etc/hosts file appears strange to me also and
I don't expect a "ping mymachine" command to return an IP address of

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