3.3. Windows — Bugzilla 5.0 documentation

# 3.3. Windows

Making Bugzilla work on Windows is more difficult than making it work on Unix, fewer Bugzilla developers use it and so it's less well supported. We would particularly recommend against doing it for a large site. However, if you are still determined to go ahead, here's how.

## 3.3.1. ActiveState Perl

ActiveState make a popular distribution of Perl for Windows.

Download the ActiveState Perl 5.12.4 or higher MSI installer from the ActiveState website.

ActiveState Perl uses a standard Windows Installer. Install, sticking with the defaults, which will install Perl into `C:\Perl`. It is not recommended to install Perl into a directory containing a space, such as `C:\Program Files`.

Once the install has completed, log out and log in again to pick up the changes to the `PATH` environment variable.

## 3.3.2. Bugzilla

The best way to get Bugzilla is to check it out from git. Download and install git from the git website, and then run:

git clone --branch bugzilla-X.X-stable https://git.mozilla.org/bugzilla/bugzilla C:\bugzilla

where "X.X" is the 2-digit version number of the stable release of Bugzilla that you want (e.g. 4.4).

The rest of this documentation assumes you have installed Bugzilla into `C:\bugzilla`. Adjust paths appropriately if not.

If it's not possible to use git (e.g. because your Bugzilla machine has no internet access), you can download a tarball of Bugzilla and copy it across. Bugzilla comes as a 'tarball' (`.tar.gz` extension), which any competent Windows archiving tool should be able to open.

## 3.3.3. Perl Modules

Bugzilla requires a number of perl modules to be installed. They are available in the ActiveState repository, and are installed with the `ppm` tool. You can either use it on the command line, as below, or just type ppm, and you will get a GUI.

If you use a proxy server or a firewall you may have trouble running PPM. This is covered in the ActivePerl FAQ.

Install the following modules with:

ppm install <modulename>

- CGI.pm
- Digest-SHA
- TimeDate
- DateTime
- DateTime-TimeZone
- DBI
- Template-Toolkit
- Email-Sender
- Email-MIME
- URI
- List-MoreUtils
- Math-Random-ISAAC
- File-Slurp
- JSON-XS
- Win32
- Win32-API

The following modules enable various optional Bugzilla features; try and install them, but don't worry too much to begin with if you can't get them installed:

- GD
- Chart
- Template-GD
- GDTextUtil
- GDGraph
- MIME-tools
- libwww-perl
- XML-Twig
- PatchReader
- perl-ldap
- Authen-SASL
- Net-SMTP-SSL
- RadiusPerl
- SOAP-Lite
- XMLRPC-Lite
- JSON-RPC
- Test-Taint
- HTML-Parser
- HTML-Scrubber
- Encode
- Encode-Detect
- Email-Reply
- HTML-FormatText-WithLinks
- TheSchwartz
- Daemon-Generic
- mod_perl
- Apache-SizeLimit
- File-MimeInfo
- IO-stringy
- Cache-Memcached
- File-Copy-Recursive
- GraphViz

Warning

These lists have been extracted from Bugzilla's source code and have not been tested. Please let us know if you find errors in it of any sort.

Note

The `install-module.pl` script doesn't work with ActivePerl on Windows.

## 3.3.4. Web Server

Any web server that is capable of running CGI scripts can be made to work. We have specific instructions for the following:

- Apache
- Microsoft IIS

## 3.3.5. Database Engine

Bugzilla supports MySQL, PostgreSQL, Oracle and SQLite as database servers. You only require one of these systems to make use of Bugzilla. MySQL is most commonly used, and is the only one for which Windows instructions have been tested. SQLite is good for trial installations as it requires no setup. Configure your server according to the instructions below:

- MySQL
- PostgreSQL
- Oracle
- SQLite

## 3.3.6. localconfig

You should now change into the Bugzilla directory and run `checksetup.pl`, without any parameters:

checksetup.pl

`checksetup.pl` will write out a file called `localconfig`. This file contains the default settings for a number of Bugzilla parameters, the most important of which are the group your web server runs as, and information on how to connect to your database.

Load this file in your editor. You will need to check/change `$db_driver` and `$db_pass`, which are respectively the type of the database you are using and the password for the `bugs` database user you have created. `$db_driver` can be either `mysql`, `Pg` (PostgreSQL), `Oracle` or `Sqlite`. All values are case sensitive.

Set the value of `$webservergroup` to the group your web server runs as.

- Fedora/Red Hat: `apache`
- Debian/Ubuntu: `www-data`
- Mac OS X: `_www`
- Windows: ignore this setting; it does nothing

The other options in the `localconfig` file are documented by their accompanying comments. If you have a non-standard database setup, you may need to change one or more of the other `$db_*` parameters.

Note

If you are using Oracle, `$db_name` should be set to the SID name of your database (e.g. `XE` if you are using Oracle XE).

## 3.3.7. checksetup.pl

Next, run `checksetup.pl` an additional time:

checksetup.pl

It reconfirms that all the modules are present, and notices the altered localconfig file, which it assumes you have edited to your satisfaction. It compiles the UI templates, connects to the database using the `bugs` user you created and the password you defined, and creates the `bugs` database and the tables therein.

After that, it asks for details of an administrator account. Bugzilla can have multiple administrators - you can create more later - but it needs one to start off with. Enter the email address of an administrator, his or her full name, and a suitable Bugzilla password.

`checksetup.pl` will then finish. You may rerun `checksetup.pl` at any time if you wish.

## 3.3.8. Success

Your Bugzilla should now be working. Check by running:

testserver.pl http://<your-bugzilla-server>/

If that passes, access `http://<your-bugzilla-server>/` in your browser - you should see the Bugzilla front page. Of course, if you installed Bugzilla in a subdirectory, make sure that's in the URL.

If you don't see the main Bugzilla page, but instead see "It works!!!", then somehow your Apache has not picked up your modifications to `httpd.conf`. If you are on Windows 7 or later, this could be due to a new feature called "VirtualStore". This blog post may help to solve the problem.

If you get an "Internal Error..." message, it could be that `ScriptInterpreterSource Registry-Strict` is not set in your Apache configuration. Check again if it is set properly.

Next, do the Essential Post-Installation Configuration.

This documentation undoubtedly has bugs; if you find some, please file them here.