Running external FastCGI XMLRPC server behind Apache 2.2

Another frustration and several lost hours worth few lines in blog. My goal was to run our FastCGI application locally behind a Web server. Our production setup has Lighttpd, but installing it on my just reinstalled MacBook looked a bit too much. Well, not now having lost so many hours trying to figure out few steps, but nevertheless…

Another frustration and several lost hours worth few lines in blog. My goal was to run our FastCGI XMLRPC server locally behind a Web server. Our production setup uses Lighttpd, but installing it on my just reinstalled MacBook looked a bit too much. Well, not anymore, having lost so many hours trying to figure out few steps, but nevertheless…

What we have

  • A standalone FastCGI application that serves XMLRPC and is already started by hand or another way (active fcgi back-end mode) running on e.g. post 8081
  • A Web server acting as a front-end running on e.g. post 8080

All we need is to forward the XMLRPC calls from clients received by the front-end to the back-end.


server.modules += ( "mod_fastcgi" )
$SERVER["socket"] == ":8080" {
fastcgi.server = (
"/RPC2" =>(( "host" => "",
"port" => 8081,
"check-local" => "disable",
"docroot" => ""))) }

(I have removed a lot of ‘beautification’ for brevity).

Well, this caused me hours of trial and error, but finally it is shockingly simple

Listen 8080
FastCgiExternalServer /var/www/blah -host
<VirtualHost *:8080>
RewriteEngine On
RewriteRule ^/RPC2$ /blah [QSA,L]

So where is the catch? Well, there seem to be several. And I am not saying that they are completely not described, it is just that it was not obvious for some reason. Anyway…

  1. The path to the external FastCGI server. There is no ‘blah’ in my ‘/var/www/’ ! Moreover, my application has a totally different name, but… that does not matter. What does matter is that the path mentioned before the ‘blah’ MUST exist and Apache MUST have access to it. As correctly described in some very good documentation this is just a ‘handle’, but Apache still checks whether it has proper access rights to this path. So DO NOT put ANY path there as some may suggest, but make sure it is a valid one. The easiest ‘hack’ is to use the overall DocumentRoot.
  2. Depending on your implementation of the FastCGI XML-RPC server you may want to rewrite ^/$ or ^/RPC2$, but note that here you have to use the same name ‘/blah’ provided for the external FastCGI server. This is the only place the name is needed to have the mapping (pretty confusing actually and looks more like a hack to me).

After all the mod_proxy_fastcgi seemed like a better alternative, but that one is only for Apache 2.3, while I am happily stuck with 2.2 on MacOSX Snow Leopard for the moment.

Happy configuring!

SSL + svn under Apache

Ok, I really need to document this for future. This costs waaaay too much time even having clues from all kinds of places.

Anyway, I was busy making a simple script to update a site remotely by triggering an svn checkout. Easy thing except for that the connection to repository is done using HTTPS and guess what – the certificate needs to be accepted. Trying things like ‘–trust-server-cert’ (needed to upgrade to svn 1.6.x for trying this out, on Ubuntu point to the Lucid repository if anyone needs it) didn’t help. Then I played ‘smart’ and logged in under the Apache user and tried to do the same trick manually. I’ve got to the point of accepting the certificate, etc, but… next time the same story.

Well, what ought to happen was that the user home folder (/var/www in my case) was NOT owned by the Apache user, but by the root. Damn… all the certificate acceptance stuff simply went nowhere, but I didn’t get a single warning on that!

So the solution was simple – make /var/www owned by the actual Apache user (www-data in my case under Ubuntu), log in under this user (sudo so www-data) and perform the operations I needed with the svn repository manually ONCE not forgetting to accept the certificates PERMANENTLY of course. Since then everything works fine.

Life goes by…

Giving up on PHP

Quick and dirty prototyping in python instead of PHP (+MySQL).

Original date: 2008-12-22

I have spent a lot of time trying to figure out how to get my time registration app (php + mysql) up and running on my old FreeBSD laptop. After several unsuccessful attempts, abscence of properly installed mod_php and perhaps a lot of other things gave up. I can quickly do the minimal thingy using python!

I have added .py to the cgi script handlers:

AddHandler cgi-script .py

Made a simple script to connect to the MySQL database, but it failed miserably. No output was generated. After several attempts it seems that the import statement fails. Ok, put a try/except clause around and output the result. Hmmm, the result is rather interesting:

(Can’t extract file(s) to egg cache The following error occurred while trying to extract file(s) to the Python egg cache: [Errno 13] Permission denied: ‘/nonexistent’ The Python egg cache directory is currently set to: /nonexistent/.python-eggs Perhaps your account does not have write access to this directory? You can change the cache directory by setting the PYTHON_EGG_CACHE environment variable to point to an accessible directory. )

Ok, it seems that my www user (which does not have any home folder of course!) attempts to create cache folder under his (non-existing) home folder. Adding (perhaps not very secure)

SetEnv PYTHON_EGG_CACHE /tmp/apache/

to the virtual host configuration helped for now (you need mod_env for this). The cache can be created.
Ideally you would need a proper home directory with a restricted access for the apache user account.

If the server comes up with a very descriptive message like

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

This may simply means that your beauty (script) contains just a small typo. Very handy indeed. The following two lines help a lot:

import cgitb