[Spacewalk-list] Proxy Server /cobbler_api Requests Timing Out

[Jon Miller]

Jon Miller writes:

> I am having a problem with cobbler requests via my proxy server. Machines
> that use the proxy server can successfully proxy requests through for
> channel / package information just fine. The problem seems isolated to only
> /cobbler_api URL requests.
>
> I've been testing via a simple "koan -D" command and then trying to trace
> the multiple steps is must take through the proxy, down to my main
> spacewalk server and back again.
>
> I can see the request making its way to the cobblerd process on my main
> spacewalk server. I performed an strace on it and see it receiving a http
> request on port 25151, it then very quickly responds by writing the
> requests data on the socket and then returns to polling for new
> requests. Meanwhile my DMZ client is waiting for a response and eventually
> koan times out and throws an exception.
>
> I have ruled out any firewall issues since other mod_proxy configured URLs
> work fine such as the /cobbler URL. Seems the main difference, in terms of
> what happens on the main spacewalk server, is that only the /cobbler_api
> requests are then mod_proxy'ed again to the cobblerd process.
>
> The final kicker is that the same request from a machine going directly to
> my main spacewalk server has no problem making a call to any /cobbler_api
> URLs. Seems my problem is somewhere in the return path of the query:
> Perhaps step #5 in my diagram.
>
>
>     Spacewalk Proxy
>   +--------------------+
>   |                    |       1.
>   |   /cobbler_api  <--|----   DMZ Machine
>   |   mod_proxy        |
>   |     |           ---|--->   Response
>   |     | ^            |       6.
>   +-----+-+------------+
>         | |
>      2. | | 5.
>         | |
>         | |   Spacewalk Server
>   +-----+-+------------+
>   |     | |            |
>   |     V |            |
>   |  +------------+    |
>   |  | Apache     |    |
>   |  +------------+    |
>   |    mod_proxy       |
>   | 3.  |  ^           |
>   |     V  |  4.       |
>   |  +------------+    |
>   |  | Cobblerd   |    |
>   |  +------------+    |
>   +--------------------+

I have made some progress with my proxy server issue and now the problem is
a smaller, more manageable problem that I think our Spacewalk devs might
know the answer to.

The main change I made today was to update /etc/httpd/conf.d/cobbler-proxy.conf:
- Old lines:
  ProxyPass /cobbler_api https://spacewalk.example.com/download/cobbler_api
  ProxyPassReverse /cobbler_api https://spacewalk.example.com/download/cobbler_api
  RewriteRule ^/cblr/svc/op/ks/(.*)$ /download/$0 [P,L]

- Updated Version:
  ProxyPass /cobbler_api https://spacewalk.example.com/cobbler_api
  ProxyPassReverse /cobbler_api https://spacewalk.example.com/cobbler_api
  # RewriteRule ^/cblr/svc/op/ks/(.*)$ /download/$0 [P,L]

I image your response will be that I should not have done that. I removed
the download/ part of the URL after observing the URLs being retrieved from
internal clients and was relieved to see that it worked after my
modification.

And yet I may know why it was designed that way... to perhaps rewrite the
server url paths for any responses to be changed from mentioning my main
spacewalk server and instead the proxy address? I notices that the
download/ URLs are rewritten to go to /rhn/common/DownloadFile.do where I'm
guessing the rewriting logic should happen.

In the output of a "koan -D", I noticed the URL for a system KS file was:
http://spacewalk.example.com/cblr/svc/op/ks/system/myservername

Per the rewrite rules from the Proxy, that ends up being translated to:
http://spacewalk.example.com/download/system/myservername

The problem is that the later URL generates an error page stating:

  File Download Failed

  The file you requested could not be downloaded, likely due to one of
  the following reasons:
  
  1. The url has expired.
  2. The url has been modified.
  3. The Spacewalk server does not have read permissions on the specified file.
  Please revisit the page you received this url from to receive a new one.

Do you have any advice on how to troubleshoot the download/ ->
rhn/common/DownloadFile.do issues?

Thanks,
-- 
Jon Miller