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.

This entry was posted in General, Tips and tagged , , , , , . Bookmark the permalink.

3 Responses to Apache 2.2.6 + PHP4 suPHP + PHP5 suPHP

  1. Fred says:

    Hi Hawk

    That really helped allot – thank you

  2. I think you should give apache2-mpm-itk a try. it does what suphp in the apache level with very better performance. Debian/Ubuntu already come with it as a package.

    reference http://mpm-itk.sesse.net

  3. Tony says:

    Interesting Apache MPM, but one of the problems I’ve noticed when PHP is an apache module it seems to always do something funky like eating tons of ram. suPHP or anything running PHP as a CGI does not run into this issue so instead of using say 3GB of ram we’re using about 1GB for serving pages and handling PHP. The big killer of course is higher CPU usage.

    As well as that cPanel writes the conf files so it would require changing the vhost templates which actually is possible now. At this point though I do not know what all cPanel still plans to add to their templates so I don’t think it’s a good idea having a non standard template yet.

    What I think the best setup is would probably be mpm_worker with fastCGI, however for a shared environment it’s not the best setup. It’s however what I use when it’s a single site or a few sites where several waiting php threads for various sites is not too much of an overhead.

    I’ve tried running mpm_worker with suPHP, however I think something is funky with worker thread handling and the PHP scripts being executed. At random some scripts end up not killing themselves so over a few days you may have 100 PHP processes eating 40MB of ram and not doing anything. This can obviously be problematic. We ran it for a bit and apache was able to serve a lot of requests but we were stuck killing php processes every few days to keep the ram usage down. With mpm_prefork it has it’s own share of problems surprisingly. We’ve noticed that it does not suffer from the PHP CGI scripts not dying issue, however it likes to create a process that for whatever reason stops taking requests which our automated systems pick up and restart apache.

    Seems you just cannot win…

Leave a Reply

Your email address will not be published. Required fields are marked *