I’ve wanted to get the Trac project control/issue tracking system running for quite a while. Unfortunately, when I first attempted it, there was a lot of building involved and the builds were complicated by a transition in progress on tools unsed internally by Trac.
Although I titled this “Get Trac up and running in Centos5”, I used the same procedures to also get it going on a Centos4 machine.
Here’s how:
First of all, install prerequisites.
- Install the EPEL repository into your YUM repo list. Consult the EPEL FAQ (search for YUM): http://fedoraproject.org/wiki/EPEL/FAQ
- Install the python-setup package (via YUM). NOTE: The Trac documentation says you need Python 2.5 or 2.6, but the 2.4 Python that comes with Centor5 (and Centos4) works just fine for me. There may be some advanced features that require more, but all the core functionality works under Python 2.4.
- Install the python-psycopg2 PostgreSQL driver if you intend to use PostgreSQL as your repository.
- If you plan on linking to a SVN repository, install SVN – Trac requires that the repository be on the same machine. I made a Xen Virtual Machine that contains apache, Trac, svn and CVS and that covers everything I need it to do.
Probably the best architecture for actually setting up and using the system is to place the data under the /srv directory, per the LSB/FHS recommendations. The software doesn’t care, but /srv is where server components are “supposed” to live. So I made /srv/trac, /srv/cvs and /srv/svn/repositories.
Subversion seems to work better when each project has its own repository. In CVS I used one repository for public access and one for private access.
Trac project environments are initialized like so:
trac-admin /srv/trac/myproject initenv
The easiest way to setup a trac project when you’re first getting started is to use a sqlite project database. However, for industrial use, I prefer PostgreSQL, since it’s more accessible and because it’s already part of my daily backup scheme. Also, it’s centrally-managed. Normally, each Trac sqlite project would have its own sqlite database in its own directory tree.
To migrate an sqlite Trac database, use the sqlite2pg script which you can find at http://trac-hacks.org/wiki/SqliteToPgScript. You can download the zipped source or just pull the script itself from their subversion archive (they provide a URL into the source repository tree).
sqlite2pg clones the sqlite Trac database into a PostgreSQL database – it does not alter the original sqlite database or your Trac environment. Here’s an example of its use – this is all on one line, despite how your web browser might fold it:
python sqlite2pg -e /var/trac/myproject -p postgres://trac_db_admin:secretpassword@dbhostname/trac_db
You’re supposed to be able to designate a schema by appending “?schema=myproject” onto the PostgreSQL URL, but this silently failed when I tried it. If you have multiple projects and can’t setup multiple schemas, then you’ll just have to create a new trac database for each project.
Once you’re done migrating, edit the trac conf/trac.ini file for the project to use the postgres URL in place of the sqlite URL. Restart apache just to clean everything out.
That’s it!