Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1220399

Summary: Spacewalk proxy does not deal well with package requests for //XMLRPC/GET-REQ/xxxx/getPackage/yyyy
Product: [Community] Spacewalk Reporter: David Holland <david.w.holland+bz>
Component: Proxy ServerAssignee: Stephen Herr <sherr>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 2.2CC: jdobes
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: spacewalk-proxy-2.4.1-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-08 13:27:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1267654    
Attachments:
Description Flags
patch to fix urlparse problem on 2.2 none

Description David Holland 2015-05-11 13:47:08 UTC 
Created attachment 1024230 [details]
patch to fix urlparse problem on 2.2

Description of problem:

The Spacewalk Ubuntu packages from here: 
https://launchpad.net/~mj-casalogic/+archive/ubuntu/spacewalk-ubuntu

Seem to generate package requests in the form of: 

//XMLRPC/GET-REQ/channelname/getPackage/packagename

Since Spacewalk Proxy (particularly the rhnBroker component) uses urlparse to parse the aforementioned url, it interprets the //XMLRPC/ portion as a network location, and drops it from the request it sends to the real spacewalk server. 


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

I'm using 2.2, however, looking at the 2.3 code base, it appears its susceptible to the problem as well. 


How reproducible:

Always.


Steps to Reproduce:

I've been testing by calling the Ubuntu spacewalk transport directly.

Register client in Spacewalk via proxy server (via rhnreg_ks)

Then: 

root@XXXXXXXX:~# cat /tmp/x
600 URI Acquire
URI: spacewalk://XXXXXXXXXXXX/XMLRPC/GET-REQ/channel_default_ubuntu1204lts_x8664_spacewalk/getPackage/pyjabber-0.5.0-1.4ubuntu3~precise1.all-deb.deb
Filename: /tmp/pyjabber_0.5.0-1.4ubuntu3~precise1_all.deb

root@XXXXXXXX:~# 

<Note the blank line at the end, for a total of 4 lines.   The URI: entry is one long single line.>

root@XXXXXXXX:~# cat /tmp/x | /usr/lib/apt/methods/spacewalk

apt-get -y --force-yes install <package in spacewalk>

Will also fail.


Actual results:

/tmp/pyjabber is not created, and the transport fails with a HTTP 404 error


Expected results:

/tmp/pyjabber is created.


Additional info:

I'm not certain how I missed this w/ my previous Ubuntu testing and bug report, but it doesn't work.

Its arguable the real problem is the client, but I also don't think Proxy should get confused by these sorts of requests.   I also note these style of requests work fine when hitting spacewalk directly.

The minor attached patch fixes the problem for me w/ 2.2.   It should apply to 2.3 with a little fuzz.

There may be other occurrences, I did not audit all usages of urlparse() in the entire spacewalk code base.


Till the next one........
Comment 1 Stephen Herr 2015-05-11 18:03:41 UTC 
Thanks for the excellent bug report and patch David.

I agree with everything you said, especially:
> Its arguable the real problem is the client, but I also don't think Proxy
> should get confused by these sorts of requests.   I also note these style of
> requests work fine when hitting spacewalk directly.

While uris of the form "http://hostname//path" are not a violation of the uri spec they are technically a request for a *different resource* than a uri of the form "http://hostname/path", and so I would say that the real problem is definitely the client. However, I agree that if we're able to handle the (incorrect) request properly then we should, especially if Spacewalk does too.

You patch assumes that it is always impossible for us to actually have a (real) netloc but no scheme at that point in the code, and I wasn't able to convince myself of that. So I added one more 'and' clause to the if statement "and effectiveURI_parts.netloc == 'XMLRPC'" to ensure that we can handle this one specific case properly but don't break anything else.

Committing to Spacewalk master:
693a3bafef25b087cf282495e794302a4499ad1c
Comment 2 Jan Dobes 2015-10-08 13:27:03 UTC 
Spacewalk 2.4 has been released.