Updating an old platform, and running PHP4 and PHP5 together.

Jane and I wanted to set up WordPress blogs with all the bells and whistles, and we had a quiet “pajama” weekend on tap.  My poor old server is running an old SuSE distribution (9.2) which hasn’t been supported with updates for several years now.

So you know what the food chain is like for manual updates. This requires that library, this patch, etc.

My system was way behind for Apache 2, running MySQL 4.0, and PHP 4. WordPress runs fine on PHP 4 (as best I could tell), but right away we found that we wanted plugins that required PHP 5.

I’ve come to hate distribution RPM files, and trying to navigate the weird package layouts of config files, libraries, binaries, data, and log files. I’ll venture that the problem isn’t really RPM files inherently, but the particular choices made by SuSE in (for instance) their apache distribution are just mind-blowingly convoluted. I also struggle with rpm’s myriad options and puzzling behaviors and interactions.

So, indulge me, I decided to build everything from source and install to /usr/local (though MySQL was very good about providing pre-built binaries in non-RPM form).

The PHP 5 build wanted Apache libraries, and rather than install an apache-dev package, I decided to build the latest from source. Apache is a nice smooth build. Their default install in /usr/local is really easy to manage (which made SuSE’s Apache choices that much more befuddling). I kept my old httpd config file and directory structure, and eventually threw out SuSE’s /etc/init.d/apache2 script in favor of a simple one that runs apachectl.

MySQL was a much more difficult upgrade. I started off blundering right into the latest 5.1 to see what would happen. First problem, their binary wanted the latest C++ standard libraries. No one offers that as a simple binary download! (Why bother? Everyone gets it from their distribution.) That meant building gcc.

The gnu C compiler has a few straightforward library prerequisites that I was able to build without too much trouble, but the compiler build itself is a monster, about three hours of build time. The build worked great, and I confess that I didn’t put together the required infrastructure to run a full gcc test suite — that would have been a few more hours, I’m sure.

But there it was — a fresh new gcc and libstdc++. To get the libraries out of your build directory, you have to find them in the tree and “make install” each component individually. Not too difficult, but it’d be a nice thing to find in the documentation. Now be sure /usr/local/lib is in your load path or LD_LIBRARY_PATH includes it.

MySQL 5.1 came up fine, which gave me the surprise discovery that I can’t upgrade directly from 4.0 to 5.1. I had to backup and install 4.1, do its upgrade, then 5.0, do its upgrade, then 5.1. In the end, all of the data survived just fine, including all the users and permissions through several admin schema updates.

With Apache and MySQL all current and running, that left PHP5. It built and installed as an Apache module just fine. The next discovery is that at least one of the sites I host was not capable of running PHP5.

A search found several blog entries talking about how to make PHP4 and PHP5 co-exist peacefully — run one as an Apache module, and the other as a CGI. Individual directories can be directed to the appropriate handler.

I had no trouble getting either PHP4 or PHP5 to run as an Apache module, but it took some study to figure out why PHP wouldn’t run as a CGI using the instructions written maybe last year.

PHP can build a command line module two ways, as a straight command line interpreter (CLI) or as a CGI processor. Granted that the CGI module has security considerations, but still many distributions provide both versions as php and php-cgi executables. There are configure options to enable or disable both.

What they don’t tell you in the INSTALL file is that the makefile will refuse to build the CGI version if you include the apache extension system (apxs).

So based on this experience, I have a few recommendations:

• Don’t be shy about building from source, and installing to /usr/local. It’s nice and clean most of the time. Be sure you have /usr/local/lib in your LD_LIBRARY_PATH environment.
• For the two versions of PHP, use a –prefix variable of /usr/local/php4 and /usr/local/php5 to keep them separate.
• Watch out for this “feature” of PHP’s “make install”: It will put a LoadModule line in your httpd.conf file. If you end up with both PHP4 and PHP5 modules loaded, apache will not run. (Sorry for the downtime, guys!)
• In your .htaccess files AddHandler directive, watch out for using just “php-script” as the handler type. If your httpd.conf is as muddled as mine, it’s likely to be in use somewhere else and cause confusion. I used “php5-script” and everything worked.
• “Premature end of script headers” is a catch-all apache error that just means something went wrong with your CGI script. It’s horribly unhelpful, and could point to any number of different problems. In my case, the really BIG problem is that I was trying to do CGI scripting with the CLI version of PHP. The CLI version doesn’t bother writing headers at all.

Maybe soon now I’ll go through all my Apache httpd.conf includes and clean everything up, then flip over PHP4 to CGI and PHP5 to apache module.

This project made me a lot more confident about an upcoming new server build sometime later this year. That’s definitely due. And not SuSE this time, probably Ubuntu’s server edition.

Catch you next time …