Installing Bugzilla on a CentOS cPanel VPS

This article is designed to hopefully assist someone not have to go over the same troubles as I experienced installing the latest stable Bugzilla onto my cPanel server. To say it gave me a headache is an understatement.

To begin with everything went smoothly. It was all good. I followed the instructions for the Bugzilla installation, and ran the various perl scripts, which said I needed to install some additional modules to make Bugzilla work. That was no problem, so I thought, because I had CPAN installed and set up.

Most of the modules went on OK, and everything looked good. But then I started receiving e-mails from users of another site written in perl that resides on the server. They were getting Internal Server Errors galore. Premature end of script headers. Oh joy.

So I went on the hunt for what could be going on. I ran the perl script manually for the site that was complaining. It borked with some file or other that couldn’t be found in the @INC path. That’s odd, because it was working before I tried installing the JSON::RPC module from CPAN. I ran the Bugzilla ‘checksetup.pl’ script again and now that borked with files missing from @INC.

What the?

I tried using CPAN to install the missing modules that the checksetup.pl script was now complaining about. One went on, then CPAN itself stopped working! Now I was really confused.

I did some googling around, discovered some fairly useful information to put things back and got CPAN up and running again. I can’t give specifics of this because it really depends on what you did prior to getting here as to what you’ll need to look for. Hopefully though you read this BEFORE you bork your CPAN install šŸ™‚

Long story short, I have two Perl binaries on my system, compiled with different @INC paths.

That
Is
A
NightmareĀ 

I discovered it quite by accident. One was in /usr/bin/perl – the other was /usr/local/bin/perl. Running from the command line was using /usr/local/bin/perl, but web scripts (and the checkconfig.pl script) were coded to use /usr/bin/perl.

At this point in time I have renamed the /usr/bin/perl version to /usr/bin/perl.sav and softlinked to /usr/local/bin/perl since all my CPANing and tweaking was done with the /usr/local/bin/perl variant (which used a /usr/local/ prefix to its @INC path).

This seems to have fixed Bugzilla, and kept the other site happy too. I’ve yet to test whether it’s broken cPanel now though!

Centos 5 in VirtualBox – High CPU Usage FIXED

CentOS LogoLet me give some background to the problem. You’re running CentOS 5 under VirtualBox, perhaps on OSX Leopard Server or indeed possibly another host operating system. You’ve noticed that even when the guest is utterly idle, the processor on the host is hovering at 50% or above. Or maybe only 20% but really, when the guest is idle, why is VirtualBox using ANY host processor.

I noticed that I don’t have this issue with Ubuntu (can’t remember which version) so I figured it had to be a Linux kernel issue rather than a VirtualBox issue.

After much scouring of Google, and receiving some excellent, but highly convoluted answers such as recompile the guest kernel with CONFIG_NO_HZ=y and CONFIG_HIGH_RES_TIMERS=y (neither of which the kernel with Centos 5 understands) and so I went down the path of recompiling my own CentOS kernel.

But now I have found a very simple answer. Forget about recompiling your own CentOS kernel, you don’t need to. You can simply pass a boot time parameter into the kernel using the grub menu.lst

divider=10

The problem comes because the CentOS kernel is compiled with theĀ CONFIG_HZ_1000=y andĀ CONFIG_HZ=1000 options. This (I’m told) basically means the kernel is trying to service interrupts at a rate of 1000 per second – which is fair and reasonable on normal hardware. But it makes a lot of extra work for a VM which is virtualising those interrupts. Setting the divider to 10 means you drop the amount of time spent generating interrupts and so the VM has less work to do – hence less processor use on the host.

The full line in /boot/grub/menu.lst for my running kernel now looks like this;

kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10

I’ve also found since making this change that the guest seems a LOT more responsive and snappy. Odd really since the 1000Hz kernels are meant to be snappier. Oh well, Virtualization is a strange art of its own rulemaking and I’m just a user!

Hope that helps someone else.