Install Bugzilla on Shared Hosting

15 Aug 2013
Posted by Kiran

Though I work with an IT major, my time at work is mostly spent on Microsoft Outlook and Excel and rarely do I get to get my hands dirty with actual code. Hence, as a hobby, I spend time building some applications in my spare time and that helps me keep in touch with coding.

I recently embarked upon a project to build a Drupal module of sizeable proportions. As I worked on it, I soon found that ideas were flowing and bugs were being discovered faster than I could keep track of them. I realized that if I was to do any serious — even if informal — development, a Project Management/Bug Management software was essential.

Having heard quite a bit about Bugzilla, I set out to install an instance for my own personal use. As it turns out getting Bugzilla working is not for the faint of heart.

The initial steps to setup Bugzilla are the same as those documented in the Bugzilla Documentation. However, here are some aspects of the installation that finally got Bugzilla working on my Shared hosting account:


1. Ensure all Perl modules are installed
After you have run:

./ --check-modules

you will receive a set of Perl modules that need to be installed. The script also provides you with the command that needs to be run to install each of those required modules.

For example, to install the DateTime module, run:

/usr/bin/perl DateTime

2. Use suexec
Once all Perl modules have been installed, you will rerun This time, it will create a localconfig file which you will edit to put in details of the Database, User and Password.

Here, you must also change $use_suexec=0 to $use_suexec=1.

Once this is done, and you have rerun once more, the installation should be complete.

3. Edit
If you use a shared hosting account to host your Bugzilla instance, chances are that any user-installed Perl modules sit in a location different from /usr/local or /usr/lib. This could lead to errors similar to:

Can't locate Date/ in @INC (@INC contains: . lib/x86_64-linux-thread-multi lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at Bugzilla/ line 21.
BEGIN failed--compilation aborted at Bugzilla/ line 21.
Compilation failed in require at Bugzilla/Install/ line 21.
BEGIN failed--compilation aborted at Bugzilla/Install/ line 21.
Compilation failed in require at Bugzilla/ line 15.
BEGIN failed--compilation aborted at Bugzilla/ line 15.
Compilation failed in require at line 21.
BEGIN failed--compilation aborted at line 21.
Compilation failed in require at index.cgi line 19.
BEGIN failed--compilation aborted at index.cgi line 19.

This error typically indicates that Perl running via the webserver could not locate the necessary Perl libraries to run the CGI script. In a Unix shell, Perl searches for libraries within the paths that are part of the $PERL5LIB environment variable. However, environment variables available to us on Shell are not the same in the web environment. Hence, changing this environment variable doesn't help solve such errors.

To get around this problem, you can use the which or find Unix shell commands to find the actual path where this library or file is located.

If the file can be found anywhere within the $PATH, it could be found by running:


If there is a specific location within the user's home directory where user-installed Perl libraries are installed, you could try running:

cd /home/user
find . -name

Once, you have found the path where the Perl library/file is available, you should include that path in the @INC that Perl uses to find libraries. This can be done by editing the file to introduce the lines such as:

  1. use lib qw(. /home/user/lib/perl5/);
  2. use lib qw(. /home/user/lib/perl5/share/perl5/);
  3. use lib qw(. /home/user/lib/perl5/lib64/perl5/);

after the line use strict;. Here you will need to replace the paths such as /home/user/lib/perl5/ to point to the location you have identified earlier.

This solves the problem with the libraries not being found. You may have to redo these steps for every library that Bugzilla reports as missing.

4. Use DateTime library
Another error I faced in my Bugzilla Installation was when I tried to setup Whining via the Administration interface. Here, I got an error stating:

Can't locate object method "now" via package "DateTime" at editwhines.cgi line 386.

I solved this error by introducing one more line into

  1. use DateTime;

This solves the problem and gets Bugzilla working!

5. Disable Caching
You might also want to consider disabling caching on your Bugzilla installation. I found it particularly useful if you have multiple developers, with different levels of access, working together and possibly sharing computers. You can do this by editing your .htaccess and introducing the following lines:

FileETag None
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"

These lines should go inside the <IfModule mod_headers.c> and </IfModule> segments.


I hope that the above steps help you in getting a working instance of Bugzilla on your shared hosting account. However, since Bugzilla is a complex system you could well face errors not faced by me since every system and every webhosting account is different. Do leave a comment if you have encounterd any other issue and if you have already managed to solve it, do let us know how you did that.