3.4. 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.4.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.4.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.4.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.4.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 on Windows

* Microsoft IIS


3.4.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.4.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.4.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.4.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.

======================================================================

To report bugs in and suggest updates for this documentation, please
file them on our bug tracker.
