WHM – Recompiling Apache With Sensible Defaults

I’m probably going to regret using the wording ‘sensible defaults’ … what may seem sensible to me may well be not-sensible to others. Still, at the very least I’ll be able to explain how I recompile apache and why I choose certain settings. If you’ve never recompiled Apache on a WHM server then it can be a very scary task – so many options to choose from.

Before we get started you need to understand that if you are recompiling Apache on a server that already has several live sites then you need to look at the scripts that run on those sites. I’m going to suggest that you use PHP5 and suPHP but this could break some older scripts that won’t run on PHP5 and suPHP will cause ‘Server Errors’ if you have any world writable directories or files, or the ownership of the files does not match the CPanel account owner(s). If you are unsure about any of that, then please read the article: Upgrading WHM Apache To Use suPHP and PHP 5 as you will need to follow those instructions after the recompile.

If you are recompiling Apache on a shiny new server then there isn’t much that can go wrong! Regardless of that, this guide does carry a standard disclaimer. If anything breaks, that’s not my fault. These instructions are given in good faith and no warranty or guarantees are either implied or provided.

Step 1: Profile

This is the first screen you will see when you click on Software->Apache Update. By default the ‘Previously Saved Config’ profile will be selected. Click on the ‘PHP Security’ option as this will compile the suPHP module when we get to that step. After selecting the PHP Security profile, click on the ‘Start customizing based on profile’ button.

Step 2: Apache Version

For the Apache version, select Apache 2.2. This is the latest stable version and the version that works best with PHP5. It also has some performance improvements over version 2.0. After selecting Apache 2.2, click on the ‘Next Step’ button.

Step 3: PHP Major Version

Tick the box next to PHP 5. PHP 4 is a ‘dead duck’ and is no longer actively supported by the PHP developers (though they have said they may provide security fixes until Aug. 8 2008). PHP 5 is the current ‘stable’ and actively developed version of PHP. Do check though, if you have some scripts running, that they will work with PHP 5. You can generally find this out from the script developer’s website. After choosing PHP 5 click on the ‘Next Step’ button.

Step 4: PHP Minor Version

Choose the most recent release. These will always be ‘stable’ releases and it’s quite likely your server is running the previous version. At the time of writing this guide, PHP 5.2.6 is the most recent version. After choosing the minor version click on the ‘Next Step’ button.

Step 5: Short Options List

Unless you are positive that someone is going to NEED Microsoft Frontpage support, untick that sucker RIGHT NOW!. Yes..I was shouting when I said that. Seriously, frontpage extensions are a potential security risk and should never be enabled if they will not be used.

I generally tick the Mod suPHP, Ioncube Loader, Mod Security and Zend Optimizer and untick the rest. Whilst it adds a little extra ‘baggage’ to your web server there are many scripts that use Ioncube or Zend encoding so it may save you a little time and hair pulling some time in the future. suPHP and Mod Security will help protect your web server from attacks and exploits. As the CPanel docs say:

“ModSecurity is a web application firewall that can work either embedded or as a reverse proxy. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.”

Security is good. Say that a few times until you feel REALLY comfortable with it!

Don’t be too concerned by the ‘Are you fully aware…’ messages that pop up when you click on ‘More Info’ for Ioncube and Zend – these options generally don’t need any further tweaking or alterations after Apache is recompiled and even in the rare cases where something goes wrong there are plenty of good support docs around, online forums etc and Google is your friend :).

Once you’ve selected the 4 aforementioned options, click on the ‘Exhaustive Options List’ button.

Step 6: Exhaustive Options List

Ok now… remember your breathing exercises. Take a few deep breaths. Sure, there are ALOT of options there, but whose scared of of a bunch of tick boxes eh?

The first thing you will notice is that some of the options have orange text. These are options that are enabled by default in Apache and you can leave them all ticked, so we won’t mention them other than to say if it is orange – it should be enabled. Now, lets look at the other options I always enable.

Expires – this allows the generation of cache control and expires headers. This can be useful when someone is coming through a caching proxy as you can let the caching proxy know that it should fetch the current page instead of serving up an old page from the cache.

Fileprotect – remember that we said security is good? The fileprotect module prevents other users on your server from reading other peoples web root folders.

Headers – Not used extensively but this allows you to customize HTTP response and request headers. It’s the sort of thing that a script developer may use.

Imagemap – You don’t see imagemaps as often as in years gone by but there are still plenty of web pages and scripts that use them, so it would be silly not to include the imagemmap module.

Mod suPHP – We talked about this earlier. Security is good. Mod suPHP is good! You can find out all about it at http://suphp.org/

You should be able to skip past the ‘Other Modules’ section as those are the ones we set earlier. Now we move on to the PHP options.

Bcmath & Calendar – These are used by some popular scripts out there so I always enable them.

Curl & CurlSSL – Curl is often used for scripts such as PayPal IPN scripts and scripts that need to post information to another web site. Also, many hosts now disable the allow_fopen_url option in PHP and the alternative they do allow is Curl. Most script developers are aware of this, so Curl is often used as either the primary or ‘fallback’ option when posting forms or data to other sites.

FTP – Again, I include this because there are scripts that make use of PHP’s FTP functions so it is better to do it now than to have to re-compile again later.

Force CGI Redirect – This option is required in order for our suPHP option to work.

GD – This is a graphics library that is used in many, many PHP scripts.

Magic Quotes – This option helps prevent some SQL injection attacks, so it is basically an added security feature. If you have a script that falls over because of it, you can turn it off in the php.ini file. However, most well written scripts will check whether magic quotes is enabled and adapt accordingly.

Mbstring – Provides some multi-byte character encoding functions. Yep – that’s quite a mouthful but .. long story short .. there are scripts that use it and no harm in enabling it.

Mcrypt & Mhash – These options provide encrypting and hashing functions that are used by many scripts.

MySQL & MySQL of the system – Guess where WordPress stores its data .. in a MySQL database. Guess what language WordPress is written in … PHP. Need I say more? There are a huge number of PHP scripts that will need to access a MySQL database so these options are a no-brainer. MySQL of the system just means that it will use the MySQL libraries that are installed on your server rather than the built-in support that PHP has. Without going into details .. ‘of the system’ is better ticked than unticked. So, make sure you check both of these options.

Sockets – This is another often used feature in PHP so it’s best to turn it on now rather than have to recompile again later.

TTF – This option provides support for Freetype fonts which are used by some scripts.

Zlib – I usually leave this enabled though there aren’t all that many scripts out there that use it. It provides gzip compatible file compression/decompression functions.

Finally, you should make sure the ‘Proxy’ option is NOT enabled (unless you plan on providing some proxy services .. which the vast majority of us do not). and tick the box labelled ‘Save my profile with appropriate PHP 5 options set so that it is compatible with cpphp’.


Enable the following:

Always do latest PHP
Report Errors to cPanel

Now… take another deep breath and click on the ‘Save and build‘ button. Read the two popup windows – one is the confirmation and the other tells you that you shouldn’t interrupt the build. The build will take quite a while…perhaps an hour or more, so leave your web browser open and go make a cup of your favourite beverage … then sit back while the compiler does its thing.

As I said at the beginning … there’s no such thing as the perfect build and there is no ‘one build fits all’ solution. The defaults that I use should work for most servers. Feel free to comment and/or criticize though – I’m always open to suggestions and improvements.


Upgrading WHM Apache To Use suPHP and PHP 5

Filed under The Server Room | 1 Comment

I can almost see you shaking and shuddering at the thought of doing this but it’s probably not as bad as you think. Armed with a little bit of information and a few commands, you should find the upgrade goes fairly smoothly. I’ve just upgraded 2 of my own dedicated servers and apart form a couple of minor glitches the whole process went fairly smoothly.

I’m going to assume that you have the latest WHM version installed (with EasyApache support), you know how to use SSH and that you have a fairly good idea of what you are doing.

First up, lets look at what you need to do to get Apache upgraded to use PHP5 and suPHP.

1. Login to WHM as root

2. Click on Software->Apache Update in the left hand column.

3. Click on “PHP Security”

5. Click on “Start Customizing Based On Profile” and enable th options you want compiled into PHP. I usually go to the “exhaustive options” step and set it up just the way I want it.

Once that’s all done you can start the build. It could take a little while (mine takes around 20 minutes) so go make a cup of coffee and wait for the update to complete.

After the re-build

This is where you would generally start to sweat a little, but fear not … there’s not all that much that can go wrong if you follow my instructions.

Your first problem is going to be that your upgraded Apache/PHP will throw a ‘500’ error if it finds any files or directories under public_html that are world writable. This is an easy fix. All you need to do is to change directory to public_html (e.g. cd /home/username/public_html) for each cpanel account and run the following commands:

find . -type d -perm 777 -print | xargs chmod 755
find . -type f -perm 777 -print | xargs chmod 644
find . -type f -perm 666 -print | xargs chmod 644

Those commands will change any world readable directories and files to 755 and 644.

The other main thing you need to be wary of is scripts that expect the PHP register_globals setting to be on. This is very very bad. You will be able to tell because your forms won’t be posting some or all of the field values and you may just find some script functions and links trhat simply don’t do anything any more. Fortunately there are fewer and fewer scripts around that have this requirement, but if you find that you do have a script that has this requirement, there are a couple of options.

1. Add this command to the top of any files that aren’t working:


2. If you think there are too many files for step 1 you can edit your php.ini file and set the register_globals setting to ‘On’.

3. The recommended option – upgrade or replace the script. Register_globals opens some potential security exploits regardless of how you apply it, so if at all possible .. you should leave it set to ‘Off’.

I had one other error on the last server I updated. After setting the correct permissions I was getting a ‘404’ error. In the /etc/httpd/logs/error_log I could see the following error message several times:

(13)Permission denied: /home/*****/public_html/.htaccess pcfg_openfile
: unable to check htaccess file, ensure it is readable

The cause was right in front of me, but it took a while to work it out. At some point I must have accidentally changed the ownership of the public_html directory to username:username. The standard permissions are 750 which gives the owner write access and the group read access.

Now here’s the tricky part. Modules such as mod_rewrite that processes the .htaccess file are loaded in Apache and are global. So, instead of being executed as the account owner, they are executed as the default owner and group of Apache which is the ‘nobody’ user/group. Do you see the problem? Because only the owner and owner group have permissions, the user nobody does not even have read permissions to anything under public_html. When I looked at a few of the other accounts that were working okay, the ownership of the public_html directory was user and the group was nobody. So, as soon as I fixed the group , Apache was able to read the .htaccess file.

Those are the main issues you might see. Obviously you should also do your own search for things like ‘WHM suphp problem’ to find out if there are other things you need to be aware of, but for the majority of sites, the instructions I’ve given should go a long way toward a smooth upgrade.

After finishing this post, I found some excellent info at v-nessa.net. There’s a very complete guide to enabling suPHP which goes into settings and other options. I added an additional step the procedure I was using and that was to run the scripts:


..and another important step:

rm -f /temp/sess_*

This removes old session files that will more than likely be owned by ‘nobody’ and could cause problems for people who are using some of the sites on your server when you did the update.

What they do is tidy up some inconsistencies such as files with the wrong ownership. My most recent update, using the procedure mentioned above, involved a site that hosts around 150 CPanel accounts.


Those Annoying Website Permissions

This little ‘lesson’ is going to be partly a rant … but mostly just good information. The rant is directed at hosting companies that don’t enforce strict and consistent file ownership in their web server configurations. Not only are you doing your customers a disservice, but you also are the cause of so many scripts having to have some directories and files set to be world writable. That in and of itself isn’t necessarily a high risk, but it is completely unnecessary on a properly configured server.

Now that I’ve had my rant, lets look at how permissions work and why many hosting servers are improperly configured.

When a CPanel account is created, almost every file below the home directory of that account is ‘owned’ by the username of the account. This makes sense obviously, because as the owner of the web site that is associated with your CPanel account, you should have permission to add, edit and delete files. So, given that you are the ‘owner’ of the files in your CPanel account, why is it that you have to set files and directories to be writable by ‘everyone else’ in order for some scripts to function properly?

This has to do with how Apache is running on the server and, more importantly, WHO it is running as. A properly configured Apache server will be set to run in such a way that when it is displaying files from your web site it will be running as the ‘owner’ of your web site. This is why Apache allows you to set a ‘User’ and ‘Group’ for each vhost account … so that it can run with the correct permissions for each vhost.

The problem is that some web hsoting companies run their Apache server as the ‘nobody’ user. This doesn’t have an affect on your pages being displayed, but it means that if you are using a script that needs to update any files on your website, it just isn’t going to happen unless the files are set to be ‘world writable’. This is why you are sometimes instructed to set the ‘permissions’ to ‘666’ or ‘777’. That allows the ‘nobody’ user that Apache is running as to modify your files which are owned by your CPanel account.

Clear as mud? I hope not … but if you want to learn some more about Unix file permissions there’s a good guide at  http://www.hackinglinuxexposed.com/articles/20030417.html


Domain.com Is Fine But WWW.Domain.com Doesn’t Work!

This issue didn’t start out being a web problem. A client who was running MySQL 4.0.x needed an upgrade done to MySQL 4.1.x because of a new script they had bought. So, I trawled google for some info on the easiest way to do they upgrade (it was on a WHM-based server). That’s my first tip … it doesn’t matter how many years you have been administering/building/breaking servers … there will nearly always be someone who knows how to do the same job better, faster or cleaner. So, I rarely do anything without first searching around a little.

I found a nice, easy guide to doing this upgrade at WebHostGear and set about getting the job done. It all went to plan and after around 20 minutes the MySQL database had been upgraded. I checked a couple of sites by going directly to their domains (i.e. domain.com rather than www.domain.com) and it looked like all was well.

Some hours later, the client contacted me to tell me that one of the sites was down. I checked it using the address they gave me and sure enough, we were getting the default Apache ‘success’ page instead of the site. That told me straight away that for some reason, Apache wasn’t configured for the domain that I was trying to get to. So, first off I checked that CPanel and DNS were still okay (which they were) and then I did another search. At some point I saw a message from someone saying they had run  EasyApache  to rebuild their web server and since doing it they couldn’t get to any ‘www’ domains but could get to the domain itself.

A light immediately went on 🙂 and I checked a few of my clients domain and sure enough … same problem. It turns out that the EasyApache installer had set most of the ServerAlias config lines to the domain without the ‘www’. The fix is quite easy:

Edit /etc/httpd/conf/httpd.conf and check the ServerAlias for each virtual host. They should be set to www.domain.com rather than domain.com. After doing that, you need to run a command to update WHM’s config otherwise WHM will overwrite your changes. The command to make your changes ‘stick’ is:

/usr/local/cpanel/bin/userdata_update –update

After running that command, just restart your web server (service httpd restart) and it should all be good again.


Welcome To The Server Room

The server room is a new category where I’ll talk about some of the day to day problems that I see and how these problems were fixed. The most common issues are generally related to server software such as WHM, CPanel and all sorts of scripts. Solutions can always be found so this category should, over time, become quite a good dedicated server knowledge base.