mod_apparmor looks really good, and would indeed make it much safer to run vanilla mpm_prefork/mod_php in a mass vhosting scenario without the performance penalty of mpm_ITK.

The only downside I could see is the administrative overhead of defining ‘hats’ for each vhost and distributing these across a cluster. Definitely seems like something to investigate further though perhaps it could be useful in addition to MPM_itk…

Unfortunately MPM_itk completely rules out shared memory opcode caching. It is possible to do file-based opcode caching though, and in this case MPM_itk helps to keep things nice and secure – writing cached files under the ownership of the system user associated with the vhost.

File-based caching also has a useful side-effect in a clustered web server setup, as it can save the server having to fetch the PHP source across the network assuming you cache to a local disk (most web clusters use NFS or similar to distribute files). This can make quite a difference to request throughput under high load.

Another thing to note is that we currently use PHP 5.3.1 on our vCluster, and opcode cache support for this has been quite patchy. Xcache 1.3.x was the first to support it, and eaccelerator have support in their latest release candidate.

I tried out eaccelerator-0.9.6-rc1 a few weeks ago but ran into stability issues. I see they have -rc2 now so I’ll go back and see if things have improved. I have not tried xcache yet. I’ll definitely block out some time to put latest xcache/eaccelerator to the test soon, and will post the results here.

http://andytson.com/blog/2010/01/techniques-for-creating-a-secure-shared-web-server/

APC definitely will not work in mpm-itk, whereas xcache and eaccelerator support file-based caching (xcache using a memory-mapped file, which would be better).

The simple reason is mpm-itk’s processing model discards modified or newly allocated shared-memory after each request.

Alternatively, as mentioned in my blog article, there is mod_apparmor, which doesn’t change the apache processing model at all. I’m planning to write a more detailed blog post on it sometime soon.

I had a heck of a time trying to secure Apache for a *small* shared hosting environment (nothing close to what it sounds like you are running) while still allowing APC which speeds up my PHP sites so much. I ended up doing FastCGI with APC but I admit it is very resource intensive and would not scale to thousands of small sites.

I’d be very interested in your thoughts on opcode caches in your setup. Again – great article!

To get a threaded Apache you’d need to use MPM_worker, which excludes using MPM_itk since Apache can only use a single MPM. It might be possible to combine the two, but I’m not sure (doubt?) whether it would be safe for a worker thread to attempt to change effective user id without affecting other workers too. I’d need to investigate that.

And, while PHP will technically run under a threaded web server, PHP itself carries no thread safe guarantees. Although these days they claim the core is thread safe, but that certainly couldn’t be assumed for any extensions without much closer inspection.

I’ll comment on those extra points another time

Would love to know how to get those “extra points”…

Simon
http://www.osbornebrook.co.uk