Trac is currently deployed on twistedmatrix.com using a custom build of postgres on an old version of Ubuntu on some old hardware.

We have a new, better piece of hardware donated by Dreamhost, and we may get newer, better hardware donated in the future. So we'd like to move it around.

Moving trac is possible - we even have new hardware - but the enterprising administrator who would like to help us with this needs to be aware of a few issues.

Trac, along with postgres, is installed into ~trac-migration on cube. Postgres is compiled into ~/.local/ and the database cluster is in ~/Database/. This was done because we are running Ubuntu 8.04 LTS, and the most recent packaged version of Postgres for that platform is 8.3, and we were told by some trac developers that upgrading to 8.4 would help.

The newer hosting is running on Debian, which is still kind of old, but does have a system packaged install of postgresql-8.4. So when Trac is moved we should use the system installed database instead, since this will get automatic security updates.

The other thing that needs to be updated is the SVN repository mirror, which is replicated to be local to Trac so that the source browser works. Our production version control system is on wolfwood.twistedmatrix.com, and each revision is pushed over to cube.twistedmatrix.com by a post-commit hook.

Once the database moves, the high scores daemon needs to be moved as well, since it talks to the same database.

Trac also sends emails when tickets are done, so the local mail server needs to be able to send mail on behalf of Twisted.

DiffResource (currently deployed in ~diffresource on cube) needs access to the trac database and I think the SVN mirror.

Finally there is the web server, but its configuration is fairly centralized in ~www-data.

So, a handy brief list of dependencies for Trac to work on a new host is:

• web server
• postgres
• highscores server
• diffresource
• svn mirror

Other questions:

• mailman (hosted beneath the main web server)?
• exim4 (twistedmatrix.com mx)?
• HTTP latency measurements (currently all measuring over localhost, should stay that way)?