Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1201380 - Proxy client receives Internal Server Error if Proxy's authentication token has expired
Summary: Proxy client receives Internal Server Error if Proxy's authentication token h...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Proxy Server
Version: 2.2
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
: 1025891 (view as bug list)
Depends On:
Blocks: 465198 sat570-triage space23
TreeView+ depends on / blocked
 
Reported: 2015-03-12 15:31 UTC by Stephen Herr
Modified: 2019-07-11 08:46 UTC (History)
7 users (show)

Fixed In Version: spacewalk-proxy-2.3.13-1
Doc Type: Bug Fix
Doc Text:
Clone Of: 1188868
Environment:
Last Closed: 2015-04-14 19:03:49 UTC
Embargoed:


Attachments (Terms of Use)

Description Stephen Herr 2015-03-12 15:31:48 UTC
+++ This bug was initially created as a clone of Bug #1188868 +++

Description of problem:

The first time a client runs rhn_check after the Proxy's authentication token has expired, the client will receive an Internal Server Error.

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

Client:
rhn-check-1.0.0.1-18.el6.noarch
rhn-client-tools-1.0.0.1-18.el6.noarch
yum-rhn-plugin-0.9.1-50.el6.noarch

Proxy:
spacewalk-proxy-broker-2.3.0-5.el6sat.noarch

Satellite:
spacewalk-backend-server-2.3.3-23.el6sat.noarch

How reproducible:

100%

Steps to Reproduce:
1.) On Satellite 5.7, edit /etc/rhn/rhn.conf on the Satellite, set:

proxy_auth_timeout = 300.0

and restart rhn-satellite, to set proxy authentication token lifetime to 5 minutes instead of the 6 hour default.

2.) Activate Proxy 5.7 to the Satellite.

3.) Register RHEL 6.6 system to the Proxy. Wait 5 minutes, then run rhn_check. See error output on first attempt. Subsequent attempts succeed, until the proxy's authentication token expires after another 5 minutes have passed.

# rhn_check
XMLRPC ProtocolError: <ProtocolError for <hostname> /XMLRPC: 400 Bad Request>
# rhn_check
#


Actual results:

Internal Server Error when running rhn_check.

Expected results:

No error on the client; Proxy silently re-authenticates with the Satellite.

Additional info:

--- Additional comment from Stephen Herr on 2015-03-10 18:23:24 EDT ---

The problem appears to be that we hit a 60 second timeout attempting to read the WsgiRequest body. If I strip away the SmartIO changes from apacheRequest.py we can see the real error:

mod_wsgi (pid=3599): Exception occurred processing WSGI script '/usr/share/rhn/wsgi/xmlrpc.py'.
Traceback (most recent call last):
  File "/usr/share/rhn/wsgi/xmlrpc.py", line 22, in application
    return wsgiHandler.handle(environ, start_response, "xmlrpc", "server.xmlrpc")
  File "/usr/share/rhn/wsgi/wsgiHandler.py", line 44, in handle
    ret = appServ(req)
  File "/usr/lib/python2.6/site-packages/spacewalk/server/apacheHandler.py", line 201, in handler
    ret = self._req_processor.process()
  File "/usr/lib/python2.6/site-packages/spacewalk/server/apacheRequest.py", line 475, in process
    _body = self.req.read(self.input.length)
  File "/usr/share/rhn/wsgi/wsgiRequest.py", line 95, in read
    return self.headers_in['wsgi.input'].read(buf)
IOError: request data read error

Why? I have no idea. Will continue investigating tomorrow.

Comment 1 Stephen Herr 2015-03-12 15:32:53 UTC
Cloning for Spacewalk, as this is also a problem for Proxy 2.2 -> Spacewalk 2.2.

Comment 2 Stephen Herr 2015-03-16 21:56:40 UTC
So I have no idea what changed to make this start occurring, it may have been so basic as to be an implementation detail change inside of mod_wsgi. The base problem is that the wsgi.Input object that mod_wsgi hands us that contains the body of the client's request is only guaranteed to be readable once, and in the case of an expired auth token we need to read it twice: once to copy it into the first request we send to Spacewalk (which gets denied because of expired auth token), and a second time when we repeat the request with a valid auth token.

To fix I am replacing the wsgi.Input stream with a SmartIO object (wrapper around StringIO), which can be read as many times as we need.

Committing to Spacewalk master:
e9be1343f4aad6d8f2a880313aa21773816cb7e0

Comment 3 Stephen Herr 2015-03-17 13:19:29 UTC
And a checkstyle fix:
82e50bff83198ee2748f1a077f9a5e0b1522538c

Comment 4 Grant Gainey 2015-03-23 16:59:26 UTC
Moving bugs to ON_QA as we move to release Spacewalk 2.3

Comment 5 Stephen Herr 2015-03-30 18:07:11 UTC
*** Bug 1025891 has been marked as a duplicate of this bug. ***

Comment 6 Grant Gainey 2015-04-14 19:03:49 UTC
Spacewalk 2.3 has been released. See

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes23


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