3.3. Windows
Making Bugzilla work on Windows is not more difficult than making it work on Linux. However, fewer developers use Windows to test Bugzilla and so we would still recommend using Linux for large sites to get better support.
3.3.1. Perl
You have two main choices to install Perl on Windows: ActivePerl and Strawberry Perl.
The ActivePerl Windows Installer can be downloaded from the
ActiveState website.
Perl will be installed by default 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.
The Strawberry Perl Windows Installer can be downloaded from the
Strawberry Perl website. Perl will be installed
by default into C:\Strawberry
.
One big advantage of Strawberry Perl over ActivePerl is that with Strawberry
Perl, you can use the usual tools available on other OSes to install missing
Perl modules directly from CPAN, whereas ActivePerl requires you to use its own
ppm
tool to download pre-compiled Perl modules from ActiveState.
The modules in the ActivePerl repository may be a bit older than those on CPAN.
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 release-X.X-stable https://github.com/bugzilla/bugzilla C:\bugzilla
where “X.X” is the 2-digit version number of the stable release of Bugzilla that you want (e.g. 5.0).
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. Some of them are mandatory, and some others, which enable additional features, are optional.
If you are using ActivePerl, these modules 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 mandatory 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
JSON-XS
Win32
Win32-API
DateTime-TimeZone-Local-Win32
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
If you are using Strawberry Perl, you should use the install-module.pl
script to install modules, which is the same script used for Linux. Some of
the required modules are already installed by default. The remaining ones can
be installed using the command:
perl install-module.pl <modulename>
The list of modules to install will be displayed by checksetup.pl
; see
below.
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:
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:
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.