I'm not a great fan of Bugzilla but due to a lack of other decent and packaged bug tracking suites in Debian testing I have installed it. There are a number of reasons I don't like Bugzilla some are petty others not so. I've been using Bugzilla to report bugs for years but even now I find it difficult to use. The underlying bug tracking is good and the feature set excellent but the user interface is one of the biggest dogs dinners that I have ever seen. Nothing seems to be in a logical location.

Style is a real problem too, look at the way the Mantis bug tracking system displays bugs and then look at the way a default install of Bugzilla displays them. Mantis formats the page nicely and colour codes the bugs for quick location. Bugzilla, on the other hand, presents you with plain, virtually style free, table that I find exceedingly hard to read.

Finally, this is the second time I've installed Bugzilla on Debian. The first time was such a disaster I gave up and installed Mantis. This time I had no choice as Mantis isn't in testing any more - fortunately the Bugzilla package seems to have improved somewhat and after a bit of struggling I've got the thing working.

Installing Bugzilla

Before starting the install process make sure that you have MySQL installed and running. Also ensure that you have created a root@localhost permissions with a password and permissions to create databases and users. You will need to use the root@localhost login during the install of Bugzilla.

The install process is quite straight forward. Simply select Bugzilla in aptitude or another package manager and let it do all the hard work. There are quite a few questions to answer but they are well explained. If you haven't followed the advice above and made sure the root@localhost account is working on MySQL the install of the Bugzilla database will fail. Unlike some other packages (Bacula springs to mind) the Bugzilla packages lets you have a second shot at installing the database.

Once Bugzilla is installed you will have configuration files in /etc/bugzilla, web site files in /var/www/bugzilla and cgi files in /usr/lib/cgi-bin/bugzilla. This last location was the cause of many problems due to URL rewriting.

The setup I will explain below is for running Bugzilla in it's own sub-domain such as bugzilla.example.com. The setup for running it under an existing domain is slightly different but I suspect most people who are going to be running Bugzilla probably actually want it in its own domain.

In /etc/bugzilla is a directory called sites this directory is used to hold the configuration files for domain level installs of bugzilla. In this directory create a subdirectory called bugzilla.example.com and copy the four configuration files (dbconfig-params, index.html, localconfig, params) in /etc/bugzilla in to it.

Now it is necessary to set up a virtual host in apache to run the site. There are examples in /usr/share/doc/bugzilla/examples but I found them only to be any use as a guide line. The virtual host definition I ended up with was:

<VirtualHost 81.5.183.106:80 >
ServerAdmin bugzilla@example.com
ServerName bugzilla.example.com
DocumentRoot /var/www/bugzilla/
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
SetEnv X_BUGZILLA_SITE "bugzilla.example.com"
SetEnv X_BUGZILLA_WEBPATH "/"
RewriteEngine On    # Rewrite the index access to the CGI path. This avoids the use of the
    #HTML redirect file and causes the next rule to be processed as well.
    RewriteRule ^/index.html /index.cgi [N]    #All requests for cgi get dumped to the relevant bugzilla script.
RewriteRule ^/(.*\.cgi.*) /cgi-bin/bugzilla/$1 [PT]
</VirtualHost>

The script alias is needed to draw the correct scripts into the bugzilla domain we have created. The two rewrite rules then ensure that all links in the Buzilla application always work. The [N] at the end of the first rewrite rule is needed ensure that requests for index.html actually do end up at index.cgi.