Step-by-step Install Bugzilla

Interview Questions

Bugzilla FAQ

55. Step-by-step Install Bugzilla

Installation of bugzilla is pretty straightforward, particularly if your machine already has MySQL and the MySQL-related perl packages installed.

The software packages necessary for the proper running of bugzilla are:
1. MySQL database server and the mysql client (3.22.5 or greater)
2. Perl (5.004 or greater, 5.6.1 is recommended if you wish to use Bundle::Bugzilla)
3. DBI Perl module
4. Data::Dumper Perl module
5. Bundle::Mysql Perl module collection
6. TimeDate Perl module collection
7. GD perl module (1.8.3) (optional, for bug charting)
8. Chart::Base Perl module (0.99c) (optional, for bug charting)
9. DB_File Perl module (optional, for bug charting) 9. 10.The web server of your choice. Apache is recommended.
11.MIME::Parser Perl module (optional, for contrib/bug_email.pl interface)

You should untar the Bugzilla files into a directory that you're willing to make writable by the default web server user (probably "nobody"). You may decide to put the files off of the main web space for your web server or perhaps off of /usr/local with a symbolic link in the web space that points to the Bugzilla directory. At any rate, just dump all the files in the same place, and make sure you can access the files in that directory through your web server.

Once all the files are in a web accessible directory, make that directory writable by your webserver's user. This is a temporary step until you run the post-install checksetup.pl script, which locks down your installation.
Lastly, you'll need to set up a symbolic link to /usr/bonsaitools/bin/perl for the correct location of your perl executable (probably /usr/bin/perl). Otherwise you must hack all the .cgi files to change where they look for perl, or use The setperl.csh Utility, found in Useful Patches and Utilities for Bugzilla. I suggest using the symlink approach for future release compatability.
After you've gotten all the software installed and working you're ready to start preparing the database for its life as a the back end to a high quality bug tracker.
First, you'll want to fix MySQL permissions to allow access from Bugzilla. For the purpose of this Installation section, the Bugzilla username will be "bugs", and will have minimal permissions.
Next, we create the "bugs" user, and grant sufficient permissions for checksetup.pl, which we'll use later, to work its magic. This also restricts the "bugs" user to operations within a database called "bugs", and only allows the account to connect from "localhost". Modify it to reflect your setup if you will be connecting from another machine or as a different user.
Remember to set bugs_password to some unique password.

mysql > GRANT SELECT,INSERT,UPDATE,DELETE,INDEX,
ALTER,CREATE,DROP,REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY
'bugs_password';
mysql> FLUSH PRIVILEGES;

Next, run the magic checksetup.pl script.
It will make sure Bugzilla files and directories have reasonable permissions, set up the data directory, and create all the MySQL tables.
bash# ./checksetup.pl
The first time you run it, it will create a file called localconfig.

What's localconfig for ?
This file contains a variety of settings you may need to tweak including how Bugzilla should connect to the MySQL database.

The connection settings include:
1. server's host: just use "localhost" if the MySQL server is local
2. database name: "bugs" if you're following these directions
3. MySQL username: "bugs" if you're following these directions
4. Password for the "bugs" MySQL account above

You should also install .htaccess files that the Apache webserver will use to restrict access to Bugzilla data files. Once you are happy with the settings, re-run checksetup.pl. On this second run, it will create the database and an administrator account for which you will be prompted to provide information. When logged into an administrator account once Bugzilla is running, if you go to the query page (off of the Bugzilla main menu), you'll find an "edit parameters" option that is filled with editable treats. Should everything work, you will have a nearly empty Bugzilla database and a newly-created localconfig file in your Bugzilla root directory.

The second time you run checksetup.pl, you should become the user your web server runs as, and that you ensure that you set the "webservergroup" parameter in localconfig to match the web server's group name, if any. I believe, for the next release of Bugzilla, this will be fixed so that Bugzilla supports a "webserveruser" parameter in localconfig as well.

(Continued on next question...)