Following my quest to find a suitable VPS for my needs, it was time to get the newly released Bugzilla 3 installed and running. It did take me 3 or 4 attempts to get this right. As I’ve stated previously, I am no sysadmin, so my failures were probably simple inexperience. These are my notes to save myself some time should I need to do this again.
Note: What follows assumes a clean install of the VPS.
I had started with CentOS5. But I found that as soon as I hit the button to install LXAdmin, my VPS was rebuilt as CentOS4.4. In my first attempt and in the final stages of Bugzilla installation I felt I really needed the system to be using Apache rather than the default of lighttpd. I could not find any way of persuading LXAdmin to make this switch despite the control on the ‘server’ page of the admin user interface. I later found this support thread on the LXLabs forum, and I started again…
- Log-in to the HyperVM control panel
- Rebuild the OS
- Choose the centos-4-i386-afull template
We now need to get and run the LXAdmin SSE installer script (apache/bind) available from the LXLabs download centre. To do this I ssh’d into the the VPS shell as root…
wget http://download.lxlabs.com/download/lxadmin/production/lxadmin-install-master.sh
sh lxadmin-install-master.sh
Once the shell script has completed you have LXAdmin installed. You need to get yourself logged in as admin and change the password. I choose to do all my LXAdmin work through SSL:
https://yourIP:7777/
If you run ‘top’ back in the shell, you should see about 8 httpd processes running and no sign of lighttpd.
UPDATE 06/06/2007: LXAdmin have since published instructions for an ‘easy switch to Apache‘.
While in LXAdmin, we should set up a plan. I have no intention of polluting my system with any FrontPage stuff, so my basic plan has FrontPage extensions disabled. Once that’s done you might as well set-up the domain you are going to serve Bugzilla through – and a MySQL database for it – noting down the database name and password – which you’ll need later. It is important that this domain does not have FontPage extensions, as they will stuff-up the .htaccess file. Before continuing, use the “Misc Config” button to “Enable Cgi In Documentroot”.
The next step is to get some system libraries installed. These can all be installed with yum. So back to the ssh session, the following are what I installed, along with any dependencies where asked…
yum install xorg-x11
yum install xorg-x11-devel
yum install expat-devel
yum install ImageMagick-*
yum install libdbi-*
yum install gd
yum install gd-devel
At some point we’ll need to edit some config files. I haven’t used vi or emacs since I really did work with a VT200 terminal, and they are now well and truly forgotten. A simplified alternative is nano, so…
yum install nano
With that lot in-place, we are ready to actually install Bugzilla. Change directory to your web files directory and download Bugzilla…
cd /home/httpd/your.domain/httpdocs/www/
wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-3.0.tar.gz
Then use gunzip and tar to extract the files to your www folder. At this point if you are running a low memory VPS like mine (max 256MB) you might find it useful to stop Apache. (I had one of the modules fail to install because the installer ran out of memory, which I solved by stopping Apache.)
At this point follow the Bugzilla instructions for running:
./checksetup.pl –check-modules
followed by:
/usr/bin/perl -MCPAN -e ‘install **SOME_MODULE**’
Substituting **SOME_MODULE** in each case for a module listed in the report. In just-about every case, accepting the default when prompted did the job. However when GD is installed you are asked a series of questions with respect to image formats (png, jpeg etc). These are fine, but in the case of Animated GIF I found I needed to choose N, or the module would fail.
Note: Due to the low memory available to my VPS. I decided not to install or use MOD_PERL module (which I read requires 30Mb per httpd).
Next step is to establish the localconfig file as per the bugzilla configuration instructions…
You should now run checksetup.pl again, this time without the –check-modules switch.
Once localconfig has been created, you need to insert the mysql user and password details you established earlier. This is where nano comes in…
nano localconfig
Once you have saved the file, run checksetup.pl yet again. This time it will connect to the database and insert the tables. It should also have sorted out the .htaccess file.
We need to check that the httpd conf files are ok. There are a couple of changes I neeeded to make…
nano /home/httpd/your.domain/conf/lxadmin.your.domain
There are two <VirtualHost> blocks in this file, one for http (port 80) the other for https (port 443). For both you need to check the <Directorary> block relating to the www folder. In my case, the only change I made was “Options +Includes +ExecCgi” became “Options +Indexes +ExecCgi” in both blocks. Save the file and exit nano.
We could at this point restart Apache. However, unless you have any intention in future of hosting a FrontPage site I would (and did) remove the line that loads the frontpage_module. To do this…
nano /etc/httpd/conf/httpd.conf
The last line in this file loads the unnecessary module, and it can be commented out by prefixing a #. Doing so will save us wasting about 10Mb of RAM.
So at this point we can restart apache…
apachectl start
Our current working directory should still be www. If we now…
./testserver.pl http://your.domain/
All should be fine. If you get an error stating that localconfig is accessible, this is probably an issue with .htaccess. If you remove the .htaccess file, then re-run checksetup.pl, a new .htaccess file will be generated. Re-test and you should be ok.
As stated above this post is really my aide-memoire. It is not a substitute for reading and understanding either your hosting documentation, or the Bugzilla guide. However I hope it is of some help.
UPDATE: For some reason after following this install, my VPS would encounter a networking problem after a random period – usually not longer than 1.5 days. The quick fix was always a re-boot. However support from vaserv decided a re-install of BIND was required – which seems to have cleared the issue properly.
