Painlessly run version 5.2.x and 5.3.x on the same apache port simultaneously.

Several persons have indicated that they could not get this working per my instructions below. For a more thorough explanation, see Chris Breidert’ s follow-up blog post. One of these days, when I get more time, I’ll go through a vanilla installation and add any additional instructions, etc.

I’d just upgraded to Ubuntu 10.10 on my PC. However, the default PHP package was version 5.3.x and I needed 5.2.x. Some projects needed the newest version, others would be crippled by it. While looking for a way to have two versions of PHP running simultaneously on Ubuntu 10.10, I struck success.

In this post, I’ll explain step-by-step how you too can  build a development platform where you can work on PHP 5.2.x and 5.3.x projects simultaneously–without ever having to restart Apache.

Why?

My primary development computer is a Macbook Pro, but sometimes I like to change things up and work from my PC installed with the latest version of Ubuntu (10.10 at the time of writing.) Ubuntu 10.10 (A.K.A Maverick Meerkat) comes with PHP 5.3.x (currently 5.3.3.)

While using version 5.3.x, I noticed that some of my development projects were broken (like my website that needs curl!) On the other hand, I have another development project that is “cutting-edge” and must run PHP 5.3.x. I couldn’t just downgrade to PHP 5.2.x (which seemed to be the bulk of solutions offered for my predicament.)

Switching versions is easy on my Mac, thanks to MAMP. I just swap versions through the MAMP control panel. However, I really wanted the same flexibility on Ubuntu. Not only did I find a solution, I found one that I prefer to MAMP because I can run either version simultaneously. Here’s how I did it.

Step 1: Get PHP source code.

Download the most current version of PHP 5.2.x (5.2.14 at the time of writing.)

http://us.php.net/downloads.php

You can download this to anywhere like ~/src or wherever. Extract it with tar xzvf php-file (for .tar.gz variant) or tar xjvf php-file  (for .tar.bz variant) depending on which version you downloaded. Change directories into the folder you just extracted.

Step 2: Install PHP development libraries.

Source code

sudo apt-get install libxml2-dev libmysqlclient-dev libcurl4-gnutls-dev libcurl4-openssl-dev libpng12-dev libjpeg62-dev

Credit to Dave Parrish for the dev packages and configure options, plus most of the other information here.

Step 3: Configure and make.

Source code

./configure --prefix=/opt/php5.2 \
--with-config-file-path=/opt/php5.2 \
--with-mysqli \
--with-mysql \
--with-curl \
--with-gd \
--with-jpeg \
--with-jpeg-dir \
--enable-cli \
--enable-fastcgi \
--enable-discard-path \
--enable-force-cgi-redirect

Source code

make && sudo make install

Step 4: Setup fast-cgi.

Just install the Debian package.

Source code

sudo apt-get install libapache2-mod-fastcgi

To enable the module, run:

Source code

sudo a2enmod fastcgi

Restart Apache.

Step 5: Enable mod_actions.

mod_actions was already available for me to use. I simply had to enable it:

Source code

sudo a2enmod actions

Restart Apache.

Step 6: Setup php5-cgi wrapper.

Create a /usr/lib/cgi-bin/php5-cgi file:

Source code

#!/bin/sh
PHP_FCGI_CHILDREN=1
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /opt/php5.2/bin/php-cgi

Also ripped off from Dave Parrish.

Make your wrapper executable:

Source code

sudo chmod +x /usr/lib/cgi-bin/php5-cgi

Step 7: Make an Include file for VirtualHosts.

I made a simple include file under /etc/apache2/ called php52.conf:

Source code

#include for sites that still need to run at php 5.2.x
 
ScriptAlias /php5-cgi /usr/lib/cgi-bin/php5-cgi
 
Action application/x-httpd-php5 /php5-cgi
AddHandler application/x-httpd-php5 .php .php5 .php4 .php3 .phtml

Credit to jameso for this pearl.

Step 8: Include php52.conf in all VirtualHosts where PHP 5.2.x is needed.

Source code

<VirtualHost *.80>
 
# ...
 
#needs to run version 5.2.x of PHP
Include php52.conf
 
</VirtualHost>

That’s it! Now I can simply insert my Include directive for any websites that I’m developing that are not ready for PHP 5.3.

Important. I am using VirtualHost configurations. This allows me to leave PHP 5.3.x enabled globally via the Apache module and turn on PHP 5.2.x specifically for each vhost. If you develop in the typical way of accessing a website via http://localhost/someproject, consider using the Apache Directory directive instead. It should work, but I haven’t tested.

I’ve been with my current company for 10+ years (at the time of writing.) It’s been a roller-coaster ride with ownership changing hands several times. But I’ve managed to hang on and I’m still riding even after the most recent change in drivers. Unfortunately, many have fallen out over the years and that leaves me to do two jobs: Web programmer and IT Administrator. Finding time to do both jobs well can be a problem to say the least.

Nagios is for IT Teams only

The last network cut-over I did was back in November of 2009 (and lasted through December.) After getting all of our services set up, I did some research and decided to give nagios a spin. What I found is that it’s very time consuming to install and configure. Furthermore, I ran out of time and had to leave much of the network monitoring incomplete. I just didn’t have the time to configure each machine with all those wonderful plugins, etc.

Desperation is the Mother of Necessity

Last week, a relatively significant Website that a partner company hosts in our network went down (well, it’s their network also,  but I’m kinda the head overseer since they too are very small now. This is an odd relationship really.) After dusting off my ruby-on-rails deployment skills to attempt to find out why rails had fails (bad pun!) I found that a postgres database had stopped responding because its server’s /var partition had filled up. Had I had the time to totally incorporate nagios, I would have gotten a timely email or SMS stating that a partition was nearly full. It’s been several months since i dabbled with nagios, but it seems like configurations like this took some time to get up and running. So, this time, I went searching for a new IT monitoring solution. As luck would have it, I was recently listening to a podcast on the TWiT networked called FLOSS Weekly. As a guest, they had the community manager for zenoss on that episode. He mentioned that zenoss is easy to configure, so I took a look. I also took a look at others (opennms, zabbix to name a few.) In the end, there were two things I liked about the prospect of zenoss that swayed me in that direction:

1. Python/Zope (in case I ever needed to look at the source. I know python to an extent.)
2. No client software to install just native snmp.

The latter one was the clincher. Remember that I said time was not a luxury I had? So far zenoss has performed this role amazingly well.

Zenoss to the Rescue

Zenoss has a pretty recent vmware player appliance that includes a linux OS with zenoss installed and configured. I just happened to have a vmware ESXi server. I did a little research, and all you need to do to convert from vmware player to vmware ESX(i) is to use a single command (this requires turning on ssh on your ESXi box in case you have the free version like us. Otherwise there’s vCli or something else with a name I can’t recall ):

vmkfstools -i zenoss_player_file.vmdk zenoss_new.vmdk

Make sure you change the filenames accordingly. After that, I created a virtual server (Redhat 32bit.) I gave it  1 GB of RAM and a couple of processors. Be sure to select the option to use an existing disk from the datastore (I got mine in there in the first place using  wget via SSH console in case you wondered.)

Finally, I booted the new server and changed the defaults. I now had a fully-functioning zenoss core server with minimal effort on my part.

SNMP Client Configurations

This part was easy to implement but I struggled to find the best way to go about it. Ultimately, I ended up using the config file from a screencast tutorial. This screencast from Castix was a big help. I made a slight change to “lock down” SNMP a bit better so just my zenoss server can access SNMP data:

## sec.name source community
com2sec notConfigUser 10.77.1.29 public
com2sec notConfigUser localhost public

…where 10.77.1.29 is the IP for my zenoss server.

On my Debian boxes I had to make a slight change to the /etc/defaults/snmp file to allow SNMP services to be exposed to remote hosts (see the screencast link above.) For my CentOS boxen, I noticed that I all had to do was replace the snmpd.conf file.

I did a simple Device Add and everything useful to know about the box is automatically gathered and displayed. From there you just setup your alert rules and you now have IT monitoring. Easy by comparison!

I’m still learning a thing or two in my spare time but so far, zenoss is just great! For now, I’m a new zenoss convert.

Here’s a screencast video I made to demonstrate downloading the ie7 installer (the installer still does a WGA check but once you have the file, you can try and hack it.) I used firefox so I could pretend to be a browser running ie in windows to get past the first check. This is hard to see (I should have set my resolution higher.) By the way, I did not discover this. I heard it on a TWiT podcast and wanted to confirm this. So much for WGA checking.

Note: I should have increased my screen resolution. If you want to read what I did, follow the embedded youtube link.