Bug 113599

... going on to the "Send Profile" stage, the progress hangs at 40%,
and nothing else proceeds, AFAICT.

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. 

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".

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 ?
    main()
  File "/usr/sbin/rhn_register", line 214, in main
    tui.main()
  File "/usr/share/rhn/register/tui.py", line 1042, in main
    tui.run()
  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
httpProxy=web-proxy.fc.hp.com:8088
# host web-proxy.fc.hp.com
web-proxy.fc.hp.com has address 15.15.136.67
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   
Use Iface
10.0.0.0        *               255.0.0.0       U     0      0       
0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         lart.lart       0.0.0.0         UG    0      0       
0 eth0
# ping -c 2 web-proxy.fc.hp.com
PING web-proxy.fc.hp.com (15.15.136.67) from 10.101.0.72 : 56(84)
bytes of data.64 bytes from fcwebcache1.fc.hp.com (15.15.136.67):
icmp_seq=0 ttl=253 time=570
usec
64 bytes from web-proxy.fc.hp.com (15.15.136.67): 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

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.

It's broken. Fix in cvs and built in 2.9.3. Awaiting release.

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?

*** Bug 112900 has been marked as a duplicate of this bug. ***

*** Bug 114922 has been marked as a duplicate of this bug. ***

ISSUE TRACKER 33103 OPENED AS SEV 1 - MAJOR CUSTOMER ISSUE 

Ping....
Adrian, any idea when this will be in a errata? Workaround to get the fix?

We got the same error, when would it be solved ?

ISSUE TRACKER 35445 opened as sev 1

HP-IPF asks this be fixed for U4. Nominating for U5 MUSTFIX in case 
it doesn't make U4.

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.

http://rhn.redhat.com/errata/RHBA-2004-046.html

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.

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: 

rhn_register-2.9.2-1.2.1AS.i386.rpm
rhn_register-gnome-2.9.2-1.2.1AS.i386.rpm
up2date-2.9.3-2.2.1AS.i386.rpm
up2date-gnome-2.9.3-2.2.1AS.i386.rpm

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? 

Jérôme VACHER (Jerome.vacher)

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

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)
                                                                     
          

Still a problem on RHEL2.1AS with all latest patches applied:

/usr/sbin/rhnreg_ks --activationkey=XXXXXXXXXXXXXXXXXXXXXXXX --proxy
http://10.0.0.21:3128 --force

fails with:

Traceback (innermost last):
  File "/usr/sbin/rhnreg_ks", line 326, in ?
    main()
  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

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
/etc/resolv.conf

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?

no didn't try - however there is an easy workaround.

Simply set the hostname in the kickstart file to something other than
'localhost.localdomain'

Then the registration goes ahead fine.

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.

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("209.132.177.100")}, 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.

fixed in 2.9.10

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.

http://rhn.redhat.com/errata/RHBA-2004-368.html