Context Navigation

Installing Trac as CGI

Please note that using Trac via CGI is the slowest deployment method available. It is slower than mod_python, FastCGI and even IIS/AJP on Windows.

CGI script is the entrypoint that web-server calls when a web-request to an application is made. To generate the trac.cgi script run:

trac-admin /path/to/env deploy /path/to/www/trac

trac.cgi will be in the cgi-bin folder inside the given path. Make sure it is executable by your web server. This command also copies static resource files to a htdocs directory of a given destination.

Apache web-server configuration

Use a ScriptAlias directive that maps an URL to the trac.cgi script (recommended)

Copy the trac.cgi file into the directory for CGI executables used by your web server (commonly named cgi-bin). You can also create a symbolic link, but in that case make sure that the FollowSymLinks option is enabled for the cgi-bin directory.

To make Trac available at http://yourhost.example.org/trac add ScriptAlias directive to Apache configuration file, changing trac.cgi path to match your installation:

ScriptAlias /trac /path/to/www/trac/cgi-bin/trac.cgi

Note that this directive requires enabled mod_alias module.

If you're using Trac with a single project you need to set its location using the TRAC_ENV environment variable:

<Location "/trac">
SetEnv TRAC_ENV "/path/to/projectenv"
</Location>

Or to use multiple projects you can specify their common parent directory using the TRAC_ENV_PARENT_DIR variable:

On some systems, you may need to edit the shebang line in the trac.cgi file to point to your real Python installation path. On a Windows system you may need to configure Windows to know how to execute a .cgi file (Explorer -> Tools -> Folder Options -> File Types -> CGI).

Mapping Static Resources

Out of the box, Trac will pass static resources such as style sheets or images through itself. For a CGI setup this is highly undesirable, because this way CGI script is invoked for documents that could be much more efficiently served directly by web server.

Web servers such as Apache allow you to create “Aliases” to resources, giving them a virtual URL that doesn't necessarily reflect the layout of the servers file system. We already used this capability by defining a ScriptAlias for the CGI script. We also can map requests for static resources directly to the directory on the file system, avoiding processing these requests by CGI script.

There are two primary URL paths for static resources - /chrome/common and /chrome/site. Plugins can add their own resources usually accessible by /chrome/plugin path, so its important to override only known paths and not try to make universal /chrome alias for everything.

Add the following snippet to Apache configuration before the ScriptAlias for the CGI script, changing paths to match your deployment:

If using mod_python, you might want to add this too (otherwise, the alias will be ignored):

<Location "/trac/chrome/common/">
SetHandler None
</Location>

Note that we mapped /trac part of the URL to the trac.cgi script, and the path /chrome/common is the path you have to append to that location to intercept requests to the static resources.

For example, if Trac is mapped to /cgi-bin/trac.cgi on your server, the URL of the Alias should be /cgi-bin/trac.cgi/chrome/common.

Similarly, if you have static resources in a project's htdocs directory (which is referenced by /chrome/site URL in themes), you can configure Apache to serve those resources (again, put this before the ScriptAlias for the CGI script, and adjust names and locations to match your installation):

Alternatively to hacking /trac/chrome/site, you can directly specify path to static resources using htdocs_location configuration option in trac.ini:

[trac]
htdocs_location = http://yourhost.example.org/trac-htdocs

Trac will then use this URL when embedding static resources into HTML pages. Of course, you still need to make the Trac htdocs directory available through the web server at the specified URL, for example by copying (or linking) the directory into the document root of the web server:

For better security, it is recommended that you either enable SSL or at least use the “digest” authentication scheme instead of “Basic”. Please read the Apache HTTPD documentation to find out more. For example, on a Debian 4.0r1 (etch) system the relevant section in apache configuration can look like this: