The project management app Trac is something that was new to me a while back. I'd just installed t for a side project, and used the yum install without any issues. It took care of all the grunt work, and got me to the point where I could now create and use a trac project.

Trac is set up like what I see web frameworks go with. A main program that will install the framework in a project directory. In this case trac-admin , which is killer when you want to make multiple projects, and offers a cli interface to the project s framework configuration, etc.

This setup becomes awesome I found when you want to upgrade. Yum installed what it had packaged, the .10 version, but I had decided that I wanted to toy with bitten their automated build tool, which required .11 and up. So an upgrade was needed, yum couldn t be used, but I found that trac-admin has an upgrade command.

So I was poised to make the fun and scary transition into mixing a package managed install with a source install, not something that always goes well. I ve found that sometimes packagers change to install location from where the src install goes (looking at you nagios), and make some conflicts or at least confusion.

The upgrade process for the server then my app was as simple as:

wget http://ftp.edgewall.com/pub/trac/Trac-0.11.5.tar.gz
tar zxvf http://ftp.edgewall.com/pub/trac/Trac-0.11.5.tar.gz
cd Trac-0.11.5
python setup.py install
trac-admin /path/to/project upgrade
trac-admin /path/to/project wiki upgrade
/etc/init.d/httpd restart

This blew me away. I ve have never had a complicated app (relativily of course) upgrade so simply, and without any issues. The main install of trac from empty folder to working project manager was simple too, so perhaps I should have expected this, but really I think it is a testimony to how well the developers of Trac have though of the whole process of using their framework.

Problem caused by wordpress upgrade

My club uses Wordpress and I have our forums and subversion authenticate via the wordpress install's user table. This became very useful, and something that I tried to make sure I could apply on any new app I would install for the site.

When trying to get the same thing setup for an install of Trac I had just made I ran into a bit of trouble. With the old versions of wordpress this was pretty simple to do. Just a few lines in an apache conf file and we were golden.

With the most recent revisions though their implementation of password storage changed, causing the old setup to break for svn, and causing me a nice headache when trying to duplicate my old fix for svn onto trac. They went from a simple md5 hash to using a much more secure phpass. (why it isn't phppass I don't know)

The main problem with this is that this isn't an authentication encryption that apache's mysql handler could use. I tried to find a work around to get back to md5, but I couldn't find any. It was probably for the best anyhow, as I'd rather the site be more secure, than have more tools. No point in propagating something that could be exploited. Searching around some more I found the awesome work of Nikolay. given out on Barry's blog, and explaining the install process. Nikolay made an apache module to compile that added in the ability to use phpass. This compiled great and worked with the fedora install the server is on, so the old fix for subversion was working again, with a single line changed.

Subversion:

RedirectMatch ^(/repos)$ $1/
<Location /repos/>
     Options all
     DAV svn
     SVNParentPath /repos/gcc/
     SVNListParentPath on

     AuthName "MySQL authentication for SVN"
     AuthType Basic
     Require valid-user

     AuthMYSQLEnable on
     AuthBasicAuthoritative off
     AuthMySQLAuthoritative on

     AuthMySQLHost localhost
     AuthMySQLUser user
     AuthMySQLPassword password
     AuthMySQLDB wordpress_db
     AuthMySQLUserTable wp_users
     AuthMySQLNameField user_login
     AuthMySQLPasswordField user_pass
     AuthMySQLPwEncryption phpass
</Location>
CustomLog logs/svn_logfile "%t %u %{SVN-ACTION}e" env=SVN-ACTION

That is the config that makes sure that only people that have accounts on the wordpress blog can have access to the repos. I plan on soon adding in a SVN auth file to make the commit users more constrained, but at the moment, it isn't a priority.

The last line makes nice entries of SVN access in its own log file, which is very handy for debugging problems.

Trac

For trac I took the simple apache auth they provided on their website, and applied the same idea from svn to it:

<Location "/projects/project-name/login">
     AuthType Basic
     Require valid-user

     AuthName "Trac Auth"
     AuthMYSQLEnable on
     AuthMySQLAuthoritative on
     AuthMySQLHost localhost
     AuthMySQLUser wordpress
     AuthMySQLPassword password
     AuthMySQLDB wordpress_db
     AuthMySQLUserTable wp_users
     AuthMySQLNameField user_login
     AuthMySQLPasswordField user_pass
     AuthMySQLPwEncryption phpass
</Location>

I plan to use this type of database integration more, specifically with a wiki installation. Although I don't know of any wiki that could use this type of authentication as I am only familiar with mediawiki, and really only as a user.