Further investigation revealed that the standard install of Apache 2.0.22 was present but not running, and they also had Apache 1.3.37 installed in a non-standard location, and both yum and rpm knew nothing about it (the client uses CentOS), hence I hadn’t noticed it at first. Had I known more about WHM I’d have known immediately what was happening.

WHM is a piece of software for making linux servers easy to manage over a web interface. As such it seems to do a good job (I don’t have a lot of experience with it so can’t recommend or reject it). But, to do it’s work it adjusts many features of the server including the locations in which software is installed, and it doesn’t use the server’s package manager to install the software so the package manager will usually know nothing about the software. This isn’t a problem if you do all your work through WHM and cPanel, but once you mix this with direct interaction with the server OS to install and configure software the non-standard set-up generated by WHM can be confusing.

As an example, I mentioned yesterday my problems finding the apache-devel-1.3.37.rpm package to install. I thought I needed this because, having found that Apache 1.3.37 was installed, I thought that apxs wasn’t present. apxs is a tool for building Apache modules and that’s exactly what I needed to do but calling apxs resulted in a “command not found” error. However, in reality apxs was installed, it’s just that the shell didn’t know about it. Referring to it by its full path (/usr/local/apache/bin/apxs) worked fine.

So if your installing and configuring software on a server that is running WHM, don’t assume software will be where you expect it to be.

I was even more annoyed when I discovered I didn’t need the package after all, but more on that tomorrow.