Apache 2.2.6 + PHP4 suPHP + PHP5 suPHP

This afternoon we were forced to make an early upgrade on one of our servers to Apache 2.2.6 with the suPHP setup due to memory leak issues relating to Apache 1.3.3.9 and PHP 4.4.7 DSO.

We’ve been testing this setup on several servers that were one time production and contained some web sites on them still. So we were well aware of all problems that could crop up during this migration and had been working with cPanel to resolve any of the issues relating to building this new setup.

We went ahead with our build which went fine we were up and running in under an hour with Apache 2.2.6 and PHP4 as well as PHP5 running suPHP. suPHP is a much more secure setup than Apache module or CGI with it’s only negative being problems it can cause if permissions are not set properly. But as I said we were well prepared for this migration and already knew how to solve the permission problems.

The first step in our migration was to change the permissions of folders from 777 or other folder permissions that would cause suPHP to throw errors. So here’s the command we ran:

find /home/*/public_html -type d -exec chmod 755 {} \;

So what this command does is go through and chmod any folder to 755. It’s not perfect by any means it would set folders that were set to 0 to 755. But this is very rare in a shared environment so we believe it outweighed the negatives big time.

The next problem is PHP files as funny as it seems some users do set their PHP files to permissions other than the default 644. So we ran the following command to solve that problem:

find /home/*/public_html -name ‘*.php’ -o -name ‘*.php[345]’ -o -name ‘*.phtml’| xargs chmod -v 644

This command would cover all the php extensions we would be seeing in our configuration and set them to the correct setting of 644. As with the directories it poses problems if the intended was to not give access to the PHP files. But this is very rare in a shared setup when users do not have SSH or very few use it often.

After that you have the issue of some files being owned by nobody. Some scripts like to create files and as a result they’ll be owned by nobody. So this simple script should fix those problems:

#!/bin/bash cd /var/cpanel/users for user in * do chown -R $user.$user /home/$user/public_html/* done

What it does is chown all the files and folders to that specific user based on /var/cpanel/users There are of course other issues associated with doing the upgrade. Some users make use of .htaccess files to set php configuration lines using php_flag var setting. Having a .htaccess file use the php_flag directive will result in a 500 error be produced. Here is a common example setting we see:

php_flag register_globals on

This will not work in suPHP and now must be set using a php.ini file. The ini file is set in the directory it should take affect in and will be as follows:

register_globals = on

So you’ll notice it’s exactly like as if the configuration was set directly in the main php.ini file.

We looked into attempting to fix this problem with commands or scripts as well. Unfortunately it deemed dangerous to be doing and more problematic that it would be worth. Very few users use the .htaccess to change PHP values. Also if the user is using it to set more than register_globals we’d need to move other type of values into a php.ini file as well. With that also make sure no to break the .htaccess file so comment out the php flag values.

Onto the good stuff what happened when we were finished everything. Well to sum it up with a few words we were very impressed with Apache 2.2.6 with suPHP performance wise. We now see about half the ram usage we saw before when running Apache 1.3.3.9 and PHP as a DSO. We figure this is related to of course Apache 2.2’s better resource management but also the fact PHP processes are truly separated and are not part of apache at all. Now when a person visits a page a PHP CGI is essentially generated and ran as the user. When the page is completed the process is killed off it’s not sitting around like we saw in our Apache 1.3 configuration.

Well that sums up our experience with migration to Apache 2.2.6 with PHP4 and PHP5 running as suPHP setups. We hope this helps anyone out there looking to migrate and of course shows our current shared and reseller customers the sort of performance gain they’ll see when their servers are upgraded to this setup.