Wordpress, Pair.com hosting, and php-cgiwrap
My site is hosted with Pair. Recently, I had been having lots of problems with PHP exceeding the allocated 16 megs of memory and being killed by Pair’s monitoring scripts — sometimes 3 or 4 times an hour.
I fixed the problem and thought I’d share for anyone else in my situation.
Don’t run Wordpress under php-cgiwrap
This is the real fix. The two items below seem to help, but this is the solution: don’t take Pair’s advice and run WP under php-cgiwrap. When using php-cgiwrap, Wordpress turns into an incorrible memory hog.
php-cgiwrap offers added security, since Wordpress will run as your user on the box, allowing you to chmod important files (e.g. wp-config.php) to 600. However, the benefits of the security are outweighed in this case by the fact that it just makes your site kinda unreliable.
When you switch to the normal WP/PHP situation — running PHP as an Apache module — you’ll need to relax some of the permissions in wp-content/ and WP’s cache/ directory. You also need to make wp-config.php world-readable (the nobody/www user has to be able to read it). This isn’t a problem for accessing the file from the Web — the database settings are hidden in PHP variables, not exposed to a Web user — but if you’re skittish, you can require() the database values from an external file.
Use WP-Cache
Well, it’s almost a given these days. Has to be the most useful plugin for Wordpress, but this alone couldn’t save my PHP process under php-cgiwrap — even when I bumped the expiration time up to 12 hours.
Disable Wordpress’ internal cache
I don’t know if this helped, but it didn’t seem to hurt. And from this thread, the WP cache seems like a bad idea, anyhow.
February 20th, 2007 at 2:07 pm
I have a couple WP sites running on Pair shared hosting and have run into exactly the same issues. I have a site running WP 2.0.7 under php-cgiwrap, with WP-Cache, and I get the crap out “Internal Server Error” message a few times per 100 requests, more often on the admin side. I have another site on another account (i.e. different server) that’s set up the same but runs WP 2.1. It seems better and I rarely get an error. I don’t know if it’s WP that’s better or I’m just on a different server with less load issues. I noticed that the queries were audited and updated for improved efficiency for WP 2.1, but I don’t know if that’s the difference.
Questions:
1. Have you had any experience running WP 2.1 at Pair? Under php-cgiwrap? If so, could you share your observations?
2. Do you know of a host with the WP application-running-as-user security model, plus the PHP-running-as-Apache-module performance?
February 20th, 2007 at 6:58 pm
I am running 2.0.4 at the moment, so I can’t test it under php-cgiwrap.
Unfortunately I have no experience with hosts besides Dreamhost and Pair. I much prefer Pair, of course. It was so hard to find a decent host that I’m living with having some directories world-writable :(
July 15th, 2007 at 11:11 pm
I had a memory problem running MediaWiki on pair under cgiwrap. I put in a support ticket, and my account was granted 32MB for the oomkiller, no questions asked.
Last week while on vacation, all my MediaWiki sites became inoperative. This appears to correspond to the recent FreeBSD 6.2 upgrade (phpinfo now reports the OS as 6.2), which has mucked up the way I employed cgiwrap from within .htaccess. Still searching for a solution on my own before I put in another support ticket.
July 16th, 2007 at 1:21 pm
The following morning, with some prompt support from pair, I was able to get my site working again.
It turns out the new release is incompatible with the old cgiwrap, which I recall installing into my local cgi directory directly from pair.com itself.
The support tech replaced this with new one on my behalf. I asked the tech why they didn’t upgrade my cgiwrap binary themselves as part of the upgrade process. He replied (in my words) “we don’t know who might have recompiled things, so we don’t upgrade binaries in user space willy nilly”.
So far as I recall, my cgiwrap binary is byte for byte identical to the no-longer-viable file commended by pair for the old release under 4.8. In my view, they didn’t look very hard to find and replace–or even notify–affected customers.
-rwxr-xr-x 1 foo users 5797628 Jul 16 09:32 php5.cgi
-rwxr-xr-x 1 foo users 5554920 Nov 3 2006 php5.cgi-FreeBSD48
I’m fairly certain I just copied this from /usr/www/cgi-bin/php5.cgi as the pair support site recommends. I certainly didn’t put myself up to compiling this by hand.
If anyone else wants to check if they had the same outdated official pair version:
MD5 (php5.cgi-FreeBSD48) = 0f367029cf066626dc83a78695758f00
Note I just discovered I was a full security update behind the most recent version of this file on the old 4.8 platform.
From the current http://www.pair.com/support/notices/62-upgrade.html
<<<
If you need to continue using PHP 4 for your applications, it is available as a CGI program. You can follow these instructions ahead of time to switch over to using PHP 4 via CGI:
…
Action application/x-pair-php4 /cgi-sys/php4.cgi
AddType application/x-pair-php4 .php
If you have previously been using this technique to run PHP 5 as a CGI, you will be able to remove those lines from .htaccess and begin using the Apache module.
>>>
The upgrade notice doesn’t point out that if you have set up your site security under account context (chmod -R ~/public_html o-rwx) this change won’t work. It doesn’t point out that you can continue to use CGI to serve php5, but *only* if you upgrade your php5.cgi.
At this point, my top level Mediawiki is working again, but none of my mod_rewrite virtual hosts are working.
Turns out the new release was incompatible with one of my existing mod_rewrite rules.
This was not especially easy to diagnose under pressure. You can’t activate the mod_rewrite log facility on the custom pair installation. In a message you can only view from the Account Center:
[Mon Jul 16 11:50:52 2007] [alert]
/usr/www/users/foo/.htaccess: RewriteLogLevel not allowed here
[Mon Jul 16 11:49:39 2007] [alert]
/usr/www/users/foo/.htaccess: RewriteLog not allowed here
A frantic bout of commenting out different random fragments of mod_rewrite rules in my .htaccess file determined that one of my existing rewrite rules no longer works the same way, but instead leads to the deadly “no input specified” error for the site involved.
I love the stability and security and support I get from pair, but I’m consistently less enthusiastic about their ability and willingness to communicate vital restrictions or requirements up front. Their 6.2-upgrade document is a terse smattering of tidbits.
I filled out a customer response survey from pair at some point in the last year, and I pointedly said exactly that.
It’s a lesson they still need to learn. I don’t understand it from a business perspective either, because up front communication is far less expensive than one-on-one support tickets.
At the end of the day I do have my site working again, and I have a strong preference to stick with the devil I know, and this probably won’t come around again until FreeBSD 9.3 But why the four hours of extraterrestrial fire drill? It makes no sense.