everburning

We’ve been talking a bit about code reviews at work, I do a bit of this now by reading commit emails, and have been wondering if there was an easier solution. To that end, I started looking around for software that could help us out.

I ended up beating on Review Board for about six hours before getting it installed. Now that it’s running it looks pretty nice. I think we’ll end up doing more post-commits then pre-commits but hopefully it’ll fit into our workflow.

Anyway, I though I’d put up a quick post on what I needed to do it get it running. The docs do a good job of getting the base install done. So give that a gander but come back here before you start running rb-site install.

We need to setup our MySQL database before running the rb-site. I did this by initializing a reviewboard MySQL database with a reviewboard user. I then granted all priviledges by executing:

GRANT ALL PRIVILEGES ON reviewboard.* TO 'reviewboard'@'localhost'
            IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON reviewboard.* TO 'reviewboard'@'% '
            IDENTIFIED BY 'some_pass' WITH GRANT OPTION;

Once rb-site install is run you’ll need to configure your webserver. In my case I ended up using Apache with FastCGI. When I tried to use the mod_python option the webserver would get a Segmentation Violation and terminate. Not so good.

The provided Apache FastCGI configuration script didn’t work for me and I ended up using the following.

AddHandler fastcgi-script fcgi

FastCGIExternalServer "/var/www/reviews/htdocs/reviewboard.fcgi" -host 127.0.0.1:3033 -idle-timeout 60

<VirtualHost *:8888>
    ServerName reviews.local
    DocumentRoot /var/www/reviews/htdocs

    # Alias static media requests to filesystem
    Alias /media /var/www/reviews/htdocs/media
    Alias /errordocs /var/www/reviews/htdocs/errordocs

    # Error handlers
    ErrorDocument 500 /errordocs/500.html

    # Direct all other requests to the fastcgi server
    RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^/(.*)$ /reviewboard.fcgi/$1 [QSA,L]
</VirtualHost>

The first parameter to FastCGIExternalServer needs to be the full path to reviewboard.fcgi as if it existed in your DocumentRoot. Nothing else seemed to work for me.

Note, if you’re using VirtualHosts you’ll also need to make sure the NamedVirtualHost option is enabled in your httpd.conf file (or whatever your main Apache config file is named).

Now, this will run, but it won’t work. The reason it won’t work is that it needs an external server to send the FastCGI requests too. You can run this server by executing: rb-site manage /var/www/reviews/ runfcgi method=threaded port=3033 host=127.0.0.1 protocol=fcgi. You’ll notice the host and port match up to those specified in the Apache config file.

I ended up creating a simple shell script to handle starting and stopping the rb-site server.

#! /bin/sh

# chkconfig: 2345 90 90

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="reviewboard daemon"
NAME=reviewboard

case "$1" in
  start)
    echo -n "Starting $DESC: $NAME"
    /usr/bin/rb-site manage /var/www/reviews/ runfcgi method=threaded port=3033 host=127.0.0.1 protocol=fcgi
    echo "."
    ;;
  stop)
    echo -n "Stopping $DESC: $NAME"
    pkill rb-site
    echo "."
    ;;
  *)
    echo "Usage: NAME {start|stop}" >&2
    exit 3
    ;;
esac

exit 0

With that I was able to login and start playing with Review Board. I ended up doing a bit of extra work to disable registration (which is kind of nasty as I had to edit the base HTML templates and urls.py) but everything seems to be working well now.

So, I’ve been working at integrating some more of our test code into our automated build system at work and have spent a day trying to figure out why everything was failing with the tests. They ran fine in my lab, they’d run fine individually but when I used rake to run them everything would bomb.

Eventually, I found out that all the rspec tests were being run twice. The first set of tests all passed the second set all failed. After a while I also realized the second set of tests were being run in the background. Odd, very odd.

Fast forward another hour, a lot of digging in the rspec code and I realized it’s because we fork inside the spec files. We fork and execute the server we want to test. rSpec sets up an at_exit handler to run the specs at exit if they haven’t been run. That at_exit handler would run number of forks + 1 times for each spec file.

I finally found Don’t get forked by rSpec, setup the at_exit { exit! } code in my spec files and everything is happy again.

Wheeee…

Well, as usual, it’s been quite a while since I last posted. Lots going on the past month or two. As you know, I got a job a AideRSS where I’ve been having a lot of fun working with Rails, MySQL, Ruby and a few other bits. Lots of interesting stuff happening on both the front and back-end systems.

Along with the job, we’ve moved into our new house in Waterloo. Stacy and I have been busy unpacking and organizing stuff for the last couple of weeks. Most stuff is sorted out now I think, Canada Post finally found our mail from the two week hold they had on stuff and both of us are settling in pretty well. Just waiting on the last few pieces of furniture to arrive.

Since we’ve finally got a house, and a bit of a yard, we picked up a puppy on Saturday. We got ourselves a little Welsh Corgi which we’ve named Odin. He’s been a lot of fun so far. Lots of energy and lots of sleep seem to be the orders of the day.

There have been lots of other fun side trips, losing of Foosball tournaments, wine tasting and other goings on that I’m leaving out at the moment.

Hopefully I’ll get back into some more regularly schedule writing now that things are starting to settle down. Although, I appear to be getting volunteered to do a presentation at DevWaterloo tomorrow so we’ll see what happens.

It’s now official. As of August 5th I’ll be an employee of AideRSS doing development work. Stacy and I are taking a week in between my finishing at Security Compass and my start at AideRSS to take a vacation which will be nice.

This also means that we’ll be moving to Waterloo in the near future. We just need to sell the condo and find a house to live in over there. It’ll be nice to get out of the city and back to Waterloo again.

Working for Security Compass was a great experience and all the guys there are fantastic, along with knowing a lot about computer security. The work was a lot of fun, who can complain with getting paid to break things? But, with everything good comes the bad. In this case, the travel. As you probably know, I’ve spent a lot of time on the road the last few months. The amount of flying and hotel starts to wear you down and it’s doubly so when you’re married. So, I decided it was time to change.

On the amusing side, my last flight back from Seattle I qualified for Air Canada Elite status. Of course I won’t be flying very much but I’m Elite for 2008 and 2009, heh.

Now you know why we went out and purchased a car.

Security Compass released two beta tools in the Exploit-Me series. These tools, XSS-Me and SQL Inject-Me, are Firefox plugins to help test for security vulnerabilities.

XSS-Me does Cross Site Scripting (XSS) injection against the forms on a page. This will send a predefined set of attack strings against the website to see if the site reflects the content back to the user.

SQL Inject-Me is a tool to do some SQL injection tests against an application. It will send a series of SQL commands and attempt to make the database return an error message to the user.

Anyway, check out the Exploit-Me site and give the tools a try. If you find any issues you can report them to bugs at securitycompass.com.

Oh, and as an added bonus, the tools are being released under the GPL v3. We’re working on getting bug tracking, mailing lists and all that other infrastructure setup for the project.