Since we seem to have lots of issues with our Trac install (most
people find it slow; some find its availability disappointing), I
thought I'd look at the Trac website to find out how their dev team
advises on these matters. Well, the conclusion is simple: we're using
the 'tracd' method of running Trac and this is certainly the only way
how *not* to do it.
They advise CGI for small sites or FastCGI/WSGI for larger sites. I
estimate us to be in the latter category, so I took my own VPS (which
is in the former category, but also runs Trac) and configured it for
FastCGI. The steps turn out to be quite simple. I volunteer to make
the same changes on c-l.net (which drewc already set me up for), but
I'm posting here for review. The last thing I'd want is to open up a
security hole in the site.
Steps are:
* Install mod_fcgid (although I used mod_fastcgi, which is older and
not recommended by the Trac team; it works though)
* Add the script handlers and the script alias to the httpd.conf file
within the virtual host section for trac.c-l.net:
AddHandler fastcgi-script .fcgi
ScriptAlias / /path/to/apache/cgi-bin/trac.fcgi/
* copy the 'web/' subdir of the installed Trac into the cgi-bin directory
* copy in the cgi-bin directory "fcgi_frontend.py" to "trac.fcgi"
* add to the trac.fcgi script - before the first 'import' statement:
import os
os.environ['PYTHON_EGG_CACHE'] = "/tmp/httpd-egg-cache"
os.environ['TRAC_ENV_PARENT_DIR'] = "/path/to/parent/trac/project/dirs"
* create /tmp/httpd-egg-cache with the user and group used to run
httpd and '700' access settings
* restart apache
Comments?
The effect of the change is this: by default, a single trac.fcgi
application will be loaded - just as with our current situation.
However, on high demand, additional instances will be spawned -
contrary to the current situation, where a single tracd will try to
handle all requests. When the load is over, the number of servers is
scaled back to normal (1).
Bye,
Erik.
