4.3. OS Specific Installation Notes

Many aspects of the Bugzilla installation can be affected by the the operating system you choose to install it on. Sometimes it can be made easier and others more difficult. This section will attempt to help you understand both the difficulties of running on specific operating systems and the utilities available to make it easier.

If you have anything to add or notes for an operating system not covered, please file a bug in Bugzilla Documentation.

4.3.1. Microsoft Windows

Making Bugzilla work on windows is still a very painful processes. The Bugzilla Team is working to make it easier, but that goal is not considered a top priority. If you wish to run Bugzilla, we still recommend doing so on a Unix based system such as GNU/Linux. As of this writing, all members of the Bugzilla team and all known large installations run on Unix based systems.

If after hearing all that, you have enough pain tolerance to attempt installing Bugzilla on Win32, here are some pointers. Because this is a development version of the guide, these instructions are subject to change without notice. In fact, the Bugzilla Team hopes they do as we would like to have Bugzilla resonabally close to "out of the box" compatibility by the 2.18 release.

4.3.1.1. Win32 Perl

Perl for Windows can be obtained from ActiveState. You should be able to find a compiled binary at http://aspn.activestate.com/ASPN/Downloads/ActivePerl/.

4.3.1.2. Perl Modules on Win32

Bugzilla on Windows requires the same perl modules found in Section 4.1.2. The main difference is that windows uses ppm instead of CPAN.


C:\perl> ppm <module name>
        

Note

The above syntax should work for all modules with the exception of Template Toolkit. The Template Toolkit website suggests using the instructions on OpenInteract's website.

Tip

A complete list of modules that can be installed using ppm can be found at http://www.activestate.com/PPMPackages/5.6plus.

4.3.1.3. Code changes required to run on win32

Unfortunately, Bugzilla still doesn't run "out of the box" on Windows. There is work in progress to make this easier, but until that happens code will have to be modified. This section is an attempt to list the required changes. It is an attempt to be all inclusive, but there may be other changes required. If you find something is missing, please file a bug in Bugzilla Documentation.

4.3.1.3.1. Changes to checksetup.pl

In checksetup.pl, the line reading:


my $mysql_binaries = `which mysql`;
          

to


my $mysql_binaries = "D:\\mysql\\bin\\mysql";
          

And you'll also need to change:


my $webservergid = getgrnam($my_webservergroup)
          

to


my $webservergid = '8'
          

4.3.1.3.2. System Calls

In order to get system calls to work on win32's perl, you need to tell the windows shell what interpreter to use. This is done by changing the system calls. You will need to search all of Bugzilla's code for system calls. To tell perl your interpreter, it needs to be the first argument to the system call. For example, you'll need to change:


system("$webdotbase","-Tpng","-o","$pngfilename","$filename");
          

with


system("C:\\perl\\bin\\perl", "$webdotbase","-Tpng","-o","$pngfilename","$filename");
          

Tip

The grep command is very helpful in finding these system calls, assuming you have the cygwin utilities.

Note

It appears that the only system call remaining in the Bugzilla codebase is in showdependencygraph.cgi. Not changing this file will only cause dependency graphs to not function if the webdotbase paramater points to a local installation of GraphViz.

4.3.1.4. Serving the web pages

As is the case on Unix based systems, any web server should be able to handle Bugzilla; however, the Bugzilla Team still recommends Apache whenever asked. No matter what web server you choose, be sure to pay attention to the security notes in Section 5.6.4. More information on configuring specific web servers can be found in Section 4.4.

Note

If using Apache on windows, you can set the ScriptInterpreterSource directive in your Apache config, if you don't do this, you'll have to modify the first line of every script to contain your path to perl instead of /usr/bonsaitools/bin/perl.

4.3.2. Mac OS X

There are a lot of common libraries and utilities out there that Apple did not include with Mac OS X, but which run perfectly well on it. The GD library, which Bugzilla needs to do bug graphs, is one of these.

The easiest way to get a lot of these is with a program called Fink, which is similar in nature to the CPAN installer, but installs common GNU utilities. Fink is available from http://sourceforge.net/projects/fink/.

Follow the instructions for setting up Fink. Once it's installed, you'll want to run the following as root: fink install gd

It will prompt you for a number of dependencies, type 'y' and hit enter to install all of the dependencies. Then watch it work.

To prevent creating conflicts with the software that Apple installs by default, Fink creates its own directory tree at /sw where it installs most of the software that it installs. This means your libraries and headers for libgd will be at /sw/lib and /sw/include instead of /usr/lib and /usr/local/include. Because of these changed locations for the libraries, the Perl GD module will not install directly via CPAN, because it looks for the specific paths instead of getting them from your environment. But there's a way around that :-)

Instead of typing "install GD" at the cpan> prompt, type look GD. This should go through the motions of downloading the latest version of the GD module, then it will open a shell and drop you into the build directory. Apply this patch to the Makefile.PL file (save the patch into a file and use the command patch < patchfile.)

Then, run these commands to finish the installation of the GD module:

perl Makefile.PL
make
make test
make install
And don't forget to run exit to get back to CPAN.