Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 113599 - Traceback during rhn_register: preparing profile page
Traceback during rhn_register: preparing profile page
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: rhn_register (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Adrian Likins
HP requests this be fixed for U4
: 112900 114922 (view as bug list)
Depends On:
Blocks: 116726 up2date-rhel2.1-u5
  Show dependency treegraph
Reported: 2004-01-15 13:03 EST by Glen A. Foster
Modified: 2007-11-30 17:06 EST (History)
6 users (show)

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

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:046 normal SHIPPED_LIVE Updated rhn_register packages fix problem registering on disconnected networks 2004-03-09 00:00:00 EST
Red Hat Product Errata RHBA-2004:368 normal SHIPPED_LIVE Updated up2date packages 2004-08-18 00:00:00 EDT

  None (edit)
Description Glen A. Foster 2004-01-15 13:03:00 EST
Description of problem: I just installed RHEL 2.1 AS update 3 on an HP
Netserver LC2000, edited /etc/sysconfig/rhn/rhn_register and
enabled/setup my HTTP proxy.  On calling rhn_register I get the normal
screens and between step 2 (user/password) and step 3 (profile) the
system looked hung.  It literally took 2 minutes to get to the profile
page (says "Step 3" at the top).

Now I look at the window I spawned rhn_register from and I see:

Traceback (innermost last):
  File "/usr/lib/python1.5/site-packages/libglade.py", line 28 in __call__
    ret = apply(self.func, a)
  File "/usr/share/rhn/register/hardware.py", line 374 in Hardware
    ret = read_network()
  File "/usr/share/rhn/register/hardware.py", line 296 in read_network
    hostname, ipaddr = findHostByRoute()
  File "/usr/share/rhn/register/hardware.py", line 273 in findHostByRoute
    s.connect((server, 80))
socket.error: (110, 'Connection timed out')

Version-Release number of selected component (if applicable):
RHEL 2.1 update 3

How reproducible: 100% (for now) -- is this a network config problem @ RH?

Additional info: Lots of things are listed as ERROR:

Red Hat Linux Version: ERROR              CPU Model: ERROR
             Hostname: ERROR              CPU Speed: ERROR
           IP Address: ERROR                 Memory: ERROR
Comment 1 Glen A. Foster 2004-01-15 13:17:26 EST
... going on to the "Send Profile" stage, the progress hangs at 40%,
and nothing else proceeds, AFAICT.
Comment 2 Malcolm 2004-01-16 02:39:01 EST
have also reproduced this bug exaclty on two RHEL 2.1 ES systems;
current version of rhn_register-2.9.2-1.2.1AS.i386.rpm used. 

rhn_register consistently fails prior to reaching the profile stage. 
Comment 3 Glen A. Foster 2004-01-17 11:57:22 EST
I get the same behavior with an IPF box running rhn_register from the
distro CDs... but a system installed with the _original_ RHAS 2.1 and
upgraded constantly via RHN was OK.

Changing platform to "all".
Comment 4 Glen A. Foster 2004-01-17 12:14:56 EST
The IPF traceback is an entirely different critter.  Looks more like a
timeout in this one, but I've configured this box using the same exact
 settings as other systems we have here that work happily with RHN:

Traceback (innermost last):
  File "/usr/sbin/rhn_register", line 233, in ?
  File "/usr/sbin/rhn_register", line 214, in main
  File "/usr/share/rhn/register/tui.py", line 1042, in main
  File "/usr/share/rhn/register/tui.py", line 986, in run
    win = self.windows[index](self.screen, self)
  File "/usr/share/rhn/register/tui.py", line 567, in __init__
    tui.hardware = hardware.Hardware()
  File "/usr/share/rhn/register/hardware.py", line 374, in Hardware
    ret = read_network()
  File "/usr/share/rhn/register/hardware.py", line 296, in read_network
    hostname, ipaddr = findHostByRoute()
  File "/usr/share/rhn/register/hardware.py", line 273, in findHostByRoute
    s.connect((server, 80))
socket.error: (110, 'Connection timed out')

# grep httpProxy= /etc/sysconfig/rhn/rhn_register
# host web-proxy.fc.hp.com
web-proxy.fc.hp.com has address
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface        *            U     0      0       
0 eth0       *            U     0      0        0 lo
default         lart.lart         UG    0      0       
0 eth0
# ping -c 2 web-proxy.fc.hp.com
PING web-proxy.fc.hp.com ( from : 56(84)
bytes of data.64 bytes from fcwebcache1.fc.hp.com (
icmp_seq=0 ttl=253 time=570
64 bytes from web-proxy.fc.hp.com ( icmp_seq=1 ttl=253
time=482 usec

--- web-proxy.fc.hp.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.482/0.526/0.570/0.044 ms
Comment 5 Glen A. Foster 2004-01-22 15:00:37 EST
I just recieved a call from another HP employee - he was running the
2.4.9-e.24 kernel on an x86 box, which means that this issue is also
present/seen on a system running AS2.1 update 2.

This would seem to indicate it's update-agnostic, which points the
finger of blame directly at RHN itself.

We have customers who cannot register with the subscription service
they have chosen to purchase.  PLEASE fix this ASAP!  Tnx.
Comment 6 Adrian Likins 2004-01-23 16:09:28 EST
It's broken. Fix in cvs and built in 2.9.3. Awaiting release.
Comment 7 Glen A. Foster 2004-01-26 16:20:13 EST
2 questions:

    (1) any idea of availability date (some sort of ETA)?
    (2) what will be the update mechanism since customers cannot get
        the package updates via up2date?
Comment 8 Glen A. Foster 2004-01-28 09:35:39 EST
*** Bug 112900 has been marked as a duplicate of this bug. ***
Comment 9 Suzanne Hillman 2004-02-10 17:02:21 EST
*** Bug 114922 has been marked as a duplicate of this bug. ***
Comment 10 Larry Troan 2004-02-11 11:02:30 EST
Comment 11 Larry Troan 2004-02-11 11:06:47 EST
Adrian, any idea when this will be in a errata? Workaround to get the fix?
Comment 12 Thomas Neemann 2004-02-24 08:01:48 EST
We got the same error, when would it be solved ?
Comment 13 Larry Troan 2004-03-03 11:09:25 EST
ISSUE TRACKER 35445 opened as sev 1
Comment 14 Larry Troan 2004-03-07 13:09:15 EST
HP-IPF asks this be fixed for U4. Nominating for U5 MUSTFIX in case 
it doesn't make U4.
Comment 15 Jay Turner 2004-03-09 14:32:53 EST
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

Comment 16 Olivier de Liocourt 2004-03-19 05:11:08 EST
on RHEL 2.1:
the bug about rhn_register in disconnected mode is still not totally
corrected in errata 2.9.3-1.2.1AS. Sending the profile hangs up.
However the machine is registered on the satellite but without any
profile sent to the satellite.

Acting up2date -p manually updates the profile correctly and makes the
whole stuff working, but it should work during the registration.

It seems that up2date during the registration is searching for
xmlrpc.rhn.redhat.com. Putting it in /etc/hosts pointing to the
Satellite IP gives a SSL error message.

A second problem is the hostname of the machine: unknown is sent as
the name profile when no DNS is setup on the client.
Comment 17 Rick Beldin 2004-03-19 15:29:33 EST
I reproduced this problem on an IA64 zx6000 running RH AW 2.1.   The
problem seemed to occur after some previous update of up2date.   I
ended up with differing versions of up2date and rhn_register and friends. 

A customer with an IA32 installation ended up (somehow) in the same
state.  They had: 


They have a mix of rhn_register 2.9.2 and up2date 2.9.3. What you
should have is: 

(from https://rhn.redhat.com/help/latest-up2date.pxt)
Red Hat Enterprise Linux WS 2.1 i386

* up2date-2.9.3-2.2.1AS.i386.rpm
* up2date-gnome-2.9.3-2.2.1AS.i386.rpm 
* rhn_register-2.9.3-1.2.1AS.i386.rpm 
* rhn_register-gnome-2.9.3-1.2.1AS.i386.rpm
* rhnlib-1.3-11.152.noarch.rpm
* pyOpenSSL-0.5.1-7.152.i386.rpm

It was unclear how both the customer and myself ended up this
situation, but getting the correct version rhn_register to match
up2date fixed the problem.   Both of us are behind firewalls, having
to supply proxies to the up2date config. 

Could it be that when we ran up2date at some previous point, up2date
was updated and not rhn_register?   If so, how do we check? 
Comment 18 Jerome Vacher 2004-04-07 13:10:35 EDT
Jérôme VACHER (Jerome.vacher@gehis.fr)

I found something .. 
 in up2date version 4.2.5 in file hardware.py about line 320
   server = string.split(server_port,':')[0]
 s.connect((server, 80))
Have to be replaced by :
   server, port = string.split(server_port,':')
   port = int(port)
 s.connect((server, port))

This IS better for all who doesn't have its proxy port on 80 (but 
8080 or whatever else)

Thanks for answering if that match the issue
Comment 20 Keiichi Mori 2004-05-17 20:49:29 EDT
This patch for rhn_register-2.9.3-1.2.1AS will be helpful for this issue.

--- hardware.py.orig    Mon May 17 08:19:16 2004
+++ hardware.py Mon May 17 08:20:25 2004
@@ -13,6 +13,7 @@
 import os
 import string
 import config
+import rhnreg
 # Some systems don't have the _locale module installed
@@ -273,7 +274,7 @@
     server = string.split(serverUrl, '/')[2]
     port = 80
     if cfg.readEntry("enableProxy"):
-       server_port = rhnreg.getProxySettings()
+       server_port = rhnreg.getProxySetting()
        (server, port) = string.split(server_port, ':')
         port = int(port)
Comment 21 Nick Strugnell 2004-05-18 03:48:49 EDT
Still a problem on RHEL2.1AS with all latest patches applied:

/usr/sbin/rhnreg_ks --activationkey=XXXXXXXXXXXXXXXXXXXXXXXX --proxy --force

fails with:

Traceback (innermost last):
  File "/usr/sbin/rhnreg_ks", line 326, in ?
  File "/usr/sbin/rhnreg_ks", line 289, in main
    hardwareList = hardware.Hardware()
  File "/usr/share/rhn/register/hardware.py", line 383, in Hardware
    ret = read_network()
  File "/usr/share/rhn/register/hardware.py", line 305, in read_network
    hostname, ipaddr = findHostByRoute()
  File "/usr/share/rhn/register/hardware.py", line 276, in findHostByRoute
    server_port = rhnreg.getProxySettings()
NameError: rhnreg

Using rhn_register-2.9.3-1.2.1AS
Comment 22 Nick Strugnell 2004-05-18 03:56:44 EDT
OK - bit more testing.

This appears to only happen if the client cannot resolve its own name
based on IP address - i.e. there is no entry in /etc/hosts or

The above rhnreg_ks works fine after reboot, but does not work in the
%post section of a kickstart, even though /etc/resolv.conf and
/etc/hosts are written correctly. At what point in the kickstart do
these files get written?
Comment 24 Nick Strugnell 2004-05-18 05:37:43 EDT
no didn't try - however there is an easy workaround.

Simply set the hostname in the kickstart file to something other than

Then the registration goes ahead fine.
Comment 25 Nick Strugnell 2004-05-18 10:28:06 EDT
spoke to soon,

Installed another server using exactly the same kickstart and there is
a hang.

Doing a netstat, it appears that the server is trying to contact
xmlrpc.rhn.redhat.com:443 direct i.e. ignoring the proxy

The only difference is the type of server - this is a Dell PE6650 cf.
a PE2650 in my previous post.
Comment 26 Nick Strugnell 2004-05-18 12:37:05 EDT
Patch at #20 does not seem to work:

 strace -p 19249
Process 19249 attached - interrupt to quit
connect(4, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("")}, 16

i.e. still trying to contact xmlrpc.rhn.redhat.com

ok - I'm going to give up until someone can come up with a reasonable,
working solution to this.

Client is not happy.
Comment 28 Adrian Likins 2004-07-01 18:35:01 EDT
fixed in 2.9.10
Comment 29 John Flanagan 2004-08-18 10:49:52 EDT
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.


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