From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: On a brand new installation of the Limbo beta the rhn_register command throws errors except the first time, when it asked me to supply a HTTP proxy server. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.start X windows (startx) 2.rhn_register 3. Actual Results: Traceback errors produced (see attachment) Expected Results: Should see the RHN registration process. Additional info:
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.