Bug 68104

Created attachment 64004 [details]
Traceback errors

The machine in question _IS_ behind a firewall machine. The firewall machine is
running RedHat 7.3 ipchains rules, with a Squid proxy.

My related findings:

I get the following (after repeated attempts on running rhn_register and because
the RHN configuration in the "firstboot" stage didn't work either) and then only
an empty window titled "Red Hat Registration" with "Cancel | Back | Forward"
buttons at the bottom right:

# rhn_register

** (rhn_register:1986): WARNING **: could not find handler `onPackagePageBack'

** (rhn_register:1986): WARNING **: could not find handler `onStartPagePrepare'
Adding cert <X509Name object '/C=US/ST=North Carolina/L=Research Triangle
Park/O=Red Hat, Inc./OU=Red Hat Network Services/CN=RHNS Certificate
Authority/Email=rhns'>



I can click "Cancel" and "Forward". Forward gives me another almost empty view
"Step 1: ...". There's no text except the small frame titled "Privacy
Statement". At the same time I get this console output:

Adding cert <X509Name object '/C=US/ST=North Carolina/L=Research Triangle
Park/O=Red Hat, Inc./OU=Red Hat Network Services/CN=RHNS Certificate
Authority/Email=rhns'>
SSL exception (9, 'Bad file descriptor')
Traceback (most recent call last):
  File "/usr/share/rhn/register/gui.py", line 261, in onPrivacyPagePrepare
    text = rhnreg.privacyText()
  File "/usr/share/rhn/register/rhnreg.py", line 447, in privacyText
    return doCall(s.registration.privacy_statement)
  File "/usr/share/rhn/register/rhnreg.py", line 155, in doCall
    ret = apply(method, args)
  File "/usr/lib/python2.2/xmlrpclib.py", line 821, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.2/site-packages/rhn/rpclib.py", line 411, in _request
    verbose=self._verbose
  File "/usr/lib/python2.2/site-packages/rhn/rpclib.py", line 236, in request
    fd = resp.decode(fd)
  File "/usr/lib/python2.2/site-packages/rhn/rpclib.py", line 617, in decode
    self.data = obj.decompress(self.data) + obj.flush()
TypeError: decompress() argument 1 must be string or read-only buffer, not None




I can click "Forward" again to reach "Step 2" to enter my account details. Doing
that and clicking "Forward" once more gives:

Adding cert <X509Name object '/C=US/ST=North Carolina/L=Research Triangle
Park/O=Red Hat, Inc./OU=Red Hat Network Services/CN=RHNS Certificate
Authority/Email=rhns'>
Traceback (most recent call last):
  File "/usr/share/rhn/register/gui.py", line 329, in onInfoPageNext
    parent=elf.mainWin)
NameError: global name 'elf' is not defined




"Step 3" works almost okay and builds the package list:

/usr/share/rhn/register/progress.py:48: DeprecationWarning: 
  self.xml.get_widget("progressBar").update(i)
TypeError: hide() takes no arguments (1 given)





Step "Send Profile Information to Red Hat Network" contains a typo. It reads 

    Click "Next" to send this System Profile to ...

But the button is labeled "Forward".





[At the end, there is no 7.3.92 (Limbo) channel at RHN, but that is okay.]

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

The limbo channel exists now.
As for the TypeError: decompress() error, limbo shipped an old version of
rhnlib. This bug is fixed in CVS, and I'll try to figure out a way to push it
out. In the meantime, the workaround is to disable SSL support (i.e. change
https:// with http:// in /etc/sysconfig/rhn/{rhn_register,up2date}).

After making the above described changes rhn_register appears to register the
system, but the program dow not addvance pass the sending profile screen and
gives an error "TypeError: hide() takes no arguments (1 given)"

Can confirm the symptoms described in the previous comment. I could click
"Forward" again and again, but it would never finish sending the profile to RHN. 

However, logging in at https://rhn.redhat.com I discovered it had created
multiple profiles for my machine.

This bug should have been split in two separate ones, one for rhnlib and one for
up2date/rhn_register.

Anyway, can you please test the latest version of rhnlib from rawhide (0.8-2)?
SSL support should work now.

Changed to Modified, although I'm not sure it's the right answer.

Mihai, would you mind providing the new rhnlib package on your ftp space
(ftp://people.redhat.com/misa/ I guess) until the package shows up on the
Rawhide server? Only rhnlib-0.7-4.noarch.rpm is in Rawhide. Usually it takes
quite some time until packages referred to by Red Hat developers in Bugzilla
show up on the Rawhide server (and mirrors).

Good idea.

ftp://people.redhat.com/misa/fixes

With rhnlib updated from misa's directory, I still hang trying to register using
rhn_register (TUI mode).  It stalls at 60% on the "Sending Profile to Red Hat
Network" screen.

Logging in to rhn.redhat.com, though, I see it got added (System ID 1001014514)

And now it finally timed out with the message "Error sending hardware profile"

Only the earlier described SSL problem is gone with rhnlib-0.8-2, and the
privacy statement is back. But at the end I get

  Sending your profile information to Red Hat
  Network. Please wait.

  ---100%---

And then it hangs! Mouse pointer is "clock" symbol. No button in GUI can be
pressed. GUI is not refreshed anymore either. Lockup.

CTRL+C to exit.

As before, a system profile at RHN is created though. Entitled it and ran
"update -u" which worked without any problems (no packages to update though).

I have tried the above mentioned steps.

1.) Using the update rhnlib-0.8-2
2.) Changing the https references in rhs_register,up2date

I am still unable to register. I am also behind a proxy server, and as such have
configured rhn_register to go through the proxy.

Am I missing something?
Below is the python tracebacks I receive.



** (rhn_register:19339): WARNING **: could not find handler `onPackagePageBack'
** (rhn_register:19339): WARNING **: could not find handler
`onStartPagePrepare'Traceback (most recent call last):
  File "/usr/sbin/rhn_register", line 228, in ?
    main()
  File "/usr/sbin/rhn_register", line 197, in main
    gui.main()
  File "/usr/share/rhn/register/gui.py", line 804, in main
    gui = Gui()
  File "/usr/share/rhn/register/gui.py", line 214, in __init__
    text = rhnreg.welcomeText()
  File "/usr/share/rhn/register/rhnreg.py", line 432, in welcomeText
    s = getServer()
  File "/usr/share/rhn/register/rhnreg.py", line 422, in getServer
    password=proxyPassword)
  File "/usr/lib/python2.2/site-packages/rhn/rpclib.py", line 89, in __init__
    self.set_refresh_callback(refreshCallback)
  File "/usr/lib/python2.2/site-packages/rhn/rpclib.py", line 93, in
set_refresh_callback
    self._transport.set_refresh_callback(refreshCallback)
AttributeError: 'str' object has no attribute 'set_refresh_callback'

** (rhn_register:19339): WARNING **: CORBA_ORB_destroy: ORB still has 2 refs.

--
Carl Sychowski (csychowski)
Florist Transworld Delivery, Inc.

Created attachment 65886 [details]
traceback at end of Limbo update

I'm in the same situation as csychowski - the https -> http change and
the updated rhnlib have not fixed the problem.

Fix in CVS now.

To Mihai:

Since this is getting a bit crowded here and this bug report has been about
rhn_register initially, is the attached traceback from 2002-07-18 related or
should we open a separate bug report? If so, against which component shall it
be? rhnlib or up2date?

I'm not sure, let's leave it as an rhn_register for now. I'm tired.

Will we have to wait for the fix to hit rawhide, or will it be uploaded to an
FTP site somewhere?

See further above: ftp://people.redhat.com/misa/fixes

Only the rhn lib fix is in there which doesn't fix the original problem for me.

In other words, rhn_register through proxy still has problems.

[The problem with this report is that it collects several (probably unrelated)
issues with rhn_register and rhnlib, and additionally, up2date uses rhnlib, too.]

This bug is getting too clobbered, and that's partially because of the tight
connection between rhn_register/up2date and rhnlib. How about opening a bug
report  for rhnlib and make it block this bug? (i.e. this bug depends on the
rhnlib bug entry). It would be easier for me and alikins to figure out which
part is still not fixed.

The combined 2.9.17-7.x.9 version of up2date and rhnreg locks up at the page
"Packages Flagged to be Skipped" reproducibly. The GUI is still refreshed, but
doesn't accept any mouse clicks anymore, and the progress dialog "Registration
Progress" (Red Hat Update Agent is building a lis of updated RPM packages
installed on your system. Please wait) stays at 0%.

As a side note, I did expect the "kernel" package to be on the package skiplist,
but it is not in the list. The list is empty. The last thing on the console:

Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 1083, in onChannelsPageNext
    self.pList.run()
  File "/usr/share/rhn/up2date_client/packageList.py", line 72, in run
    availList = rhnPackageInfo.availablePackageList(self.msgCallback,
self.progressCallback)
  File "/usr/share/rhn/up2date_client/rhnPackageInfo.py", line 91, in
availablePackageList
    channels = rhnChannel.getChannels()
  File "/usr/share/rhn/up2date_client/rhnChannel.py", line 36, in getChannels
    selected_channels = up2dateAuth.loginInfo.get('X-RHN-Auth-Channels')
AttributeError: 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 1126, in onSkippedPagePrepare
    maxlength = max(map(lambda x: len(x[0][0]), self.skipPkgList)) * 8
ValueError: min() or max() arg is an empty sequence


I escaped via CTRL+C, and upon running up2date again, it treated my system as
already registered which I double-checked at RHN.

Running "up2date" in virtual console gives a segfault.

mschwendt:

ah, different bug, but a bug nonetheless...

I assume the stuff you are reporting is on a new/clean
box with no system id on it?

It looks to me like in cases where the system is going
though the registration in gui mode, it's never
updating the loginInfo after the system is registered. 

should be fixed in cvs and next version released (2.9.18 or so)

> I assume the stuff you are reporting is on a new/clean
> box with no system id on it?

Of course.

And another one which prevents me from registering at RHN (not using proxy):

$ rpm -q rhnlib        
rhnlib-0.8-9

$ rpm -qa | grep ^up2date
up2date-gnome-2.9.20-7.x.9
up2date-2.9.20-7.x.9

At step "Send Profile Information to Red Hat Network" (We are finished
collecting information for the System Profile.) I get a dialog

  Error

  Problem registering username.

Probably related is this traceback I get upon filling in my RHN userid and
password and clicking "Forward":

Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 420, in onInfoPageNext
    pw1.get_text())
  File "/usr/share/rhn/up2date_client/rhnreg.py", line 458, in reserveUser
    ret = doCall(s.registration.reserve_user, username, password)
  File "/usr/share/rhn/up2date_client/rhnreg.py", line 154, in doCall
    ret = apply(method, args)
  File "/usr/lib/python2.2/xmlrpclib.py", line 821, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.2/site-packages/rhn/rpclib.py", line 122, in _request
    verbose=self._verbose
  File "/usr/lib/python2.2/site-packages/rhn/transports.py", line 117, in request
    headers, fd = req.send_http(host, handler)
  File "/usr/lib/python2.2/site-packages/rhn/transports.py", line 575, in send_http
    return headers, response
NameError: global name 'headers' is not defined

this bug report seems to be quickly spiralling out of control...

mschwendt:
    the last bug reported in this thread should be fixed with new
    rhnlin (0.8-10 I belive). the header object in the new version
    had a different interface from the old one, and should be fixed now.

0.8-11 is the latest one.
Can we close this bug yet? :-)

Ok, consider that latest one fixed.

> Can we close this bug yet? :-)

It is blocked by bug #69337 -- still fatal proxy problems also with the latest
versions.

either way, this bug report is out of control, I have no idea what
proxy errors your talking about for instance, and have attempt
to follow the thread about five times. If things are stil
broke, best to open them under a new bug, since the original
bug was fixed.

closing this one now, open any other issues under new bug reports.