Upgrading WHM Apache To Use suPHP and PHP 5
By Gary on Mar 2, 2008 in The Server Room
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:
ini_set(”register_globals”,”On”);
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:
/scripts/postsuexecinstall
/scripts/chownpublichtmls
..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.
Popularity: 41% [?]
Was this article useful? If it was, you might like to buy me a drink.
1 Trackback(s)
You must be logged in to post a comment.