We upgraded all of our servers to PHP 5.2.0 as soon as it came out last week!

Since serious security vulnerabilities have been discovered in all versions of
PHP up to and including 5.1.6 (including 4.x), it is recommended now that
everyone not wait for Cpanel to get around to making 5.2.0 available and
just go ahead and upgrade now.

We always manually compile PHP and don't bother with EasyApache because
we have always found it a whole lot simpler to just compile it ourselves.

Basically in a nutshell ....

Download the source from the PHP site and unpack the archive

Grab the "./configure" line from from your current PHP version using phpinfo()
and then go to the folder where you unpacked the source and run that
configure line you grabbed from your current PHP installation.

make

make test

make install

That's pretty much it! Usually doesn't take but a minute or two to upgrade.

We upgraded all of our servers to PHP 5.2.0 as soon as it came out last week!

Since serious security vulnerabilities have been discovered in all versions of
PHP up to and including 5.1.6 (including 4.x), it is recommended now that
everyone not wait for Cpanel to get around to making 5.2.0 available and
just go ahead and upgrade now.

Click to expand...

However, if you run Zend Optimizer, then the decision to upgrade is complicated by the fact that Zend still hasn't released a version compatible with PHP 5.2. Ioncube, on the other hand, has a 5.2-compatible version.

I am holding off until Zend becomes available, but will upgrade right away once it comes out. Otherwise the upgrade will break numerous client sites which run scripts that require Zend.

Grab the "./configure" line from from your current PHP version using phpinfo()
and then go to the folder where you unpacked the source and run that
configure line you grabbed from your current PHP installation.

make

make test

make install

That's pretty much it! Usually doesn't take but a minute or two to upgrade.

Click to expand...

Hey,

So that would just upgrade PHP correct? What if we wanted to run PHP4.4.4 as the main and PHP5.2 as a CGI.

I have PHP4 installed as a CLI and PHP5.1.6 installed as a CGI. I'm guessing I do not need to remove them before I do this. Just run that easyapache from the command line with all the options and it should replace them both with PHP4.4.4, correct?

Let me make sure I know what I'm doing before I try this out,

So first use easyapache to make the server run PHP 4.4.4. So now the server should have PHP 4.4.4 as an CLI and a CGI. Copy the folder /usr/local/bin/php (PHP4.4.4)somewhere on the server as a tmp location.

Then use easyapahce to make the server run PHP 5.2.0. So now the server should have PHP 5.2 as both CLI and a CGI. Copy the folder /usr/bin/php (PHP 5.2.0) somewhere on the server as a tmp location.

Then I copy the folder /usr/local/bin/php/ (PHP4.4.4 from my tmp location) to /usr/local/bin/php/. Then I also copy /usr/bin/php/ (PHP 5.2.0 from my tmp location) to /usr/bin/php/

Do I need to add anything to httpd.conf file? I'm just guessing something to the effect of .php5 is in the /usr/bin/php/ and so on?

Then I should be good to go, correct? If so, thats awesome!

Also, when installing like Zend and stuff, I'm guessing I would have to do two different installtions, one for the local version (PHP 4.4.4) and another for the bin version (5.2)?

I have PHP4 installed as a CLI and PHP5.1.6 installed as a CGI. I'm guessing I do not need to remove them before I do this. Just run that easyapache from the command line with all the options and it should replace them both with PHP4.4.4, correct?

Click to expand...

correct.. I'd make a copy of the binaries as php4 & php5.1.6 respectively.. that way if anything goes wrong you can quickly copy them back.

In your scenario, I'd run easyapache as you state, then
cp /usr/local/bin/php /usr/local/bin/php4.4.4
cp /usr/bin/php /usr/bin/php4.4.4
(instead of copying them to a temp location.. the filesize wont be so huge as to cause disk space problems and then they're just there for later in case a bad cpanel upgrade accidentally overwrites the php binaries.

you're not copying the folders, just the php executable files

easyapache should add the .php5 stuff to httpd.conf for you if it's not already there... you shouldn't have to do anything to httpd.com.
so, here's the procedure I'd recommend for you:

as for zend and ioncube, you shouldn't have to do anything as long as you're on the latest version of both.
they'll sense the correct php version and do the right thing and both, as far as I recall, are compatible with php 4.4+ through php 5.1.6.
the newest ioncube works with 5.2.0 ..
the latest zend optimizer doesn't work with 5.2.0 yet, they're supposed to have a new version out within a few weeks, but who knows.

so, when I have 4.4 as cgi and 5.2 as cli ... how to easy switch between versions ?
can I define per account using 4.4 or 5.2 ?

Wojtek

Click to expand...

well. I suppose you could, but it would be a nightmare to maintain and would introduce performance problems... but, and this is not a HOWTO, I'll just mention the basic idea of what you need in order to accomplish this as far as I know--there might be a better way.

I did have a situation where one particular users shopping cart only ran on php4 and I was running php5 on the server in general. here's what I did:

in /usr/local/apache/conf/httpd.conf
find the VirtualHost entry for the particular ServerAlias in question.
for my case, it was just the shopping cart that needed php4, so that was all under the 'shopping' drectory.

you'll have to create php4wrapper and put this in the appropriate place UNDER EACH webroot that you want to run php4 and customize it as appropriate:
#!/usr/local/bin/php4
<?
ini_set('extension_dir','/home/USERNAME/public_html/shopping');
ini_set('open_basedir','/home/USERNAME/public_html/shopping');
ob_start();
$HTTP_SERVER_VARS['SCRIPT_NAME']=$_SERVER['PATH_INFO'];
$HTTP_SERVER_VARS['SCRIPT_FILENAME']=$_SERVER['PATH_TRANSLATED'];
$_SERVER['SCRIPT_NAME']=$_SERVER['PATH_INFO'];
$_SERVER['SCRIPT_FILENAME']=$_SERVER['PATH_TRANSLATED'];
include($_SERVER['PATH_TRANSLATED']);
ob_end_flush();
?>

in this case, the shopping cart required ioncube, so the ioncube extensions were loaded in their webroot...under php5 ioncube and zend can co-exist together happily in the system area.

also note, the php4-CLI binary is called /usr/local/bin/php4
It should work much the same with the php4-cgi binary, in which case, I'd recommend it be here: /usr/bin/php4

I also compiled PHP4 with the appropriate options so it would put its libs in /usr/local/bin/php4 instead of the default /usr/local/bin/php which might cause problems for php5.

this adds a little overhead to each page load since, you have apache doing a suexec which creates a shell, which then runs the shell script which launches php... you then have to modify some php global variables in order to get them to contain the correct values they would if it were executed directly by apache.

I suppose, if it's something you're just doing for now to appease the few holdouts who wont or cant yet move to php5, then it's not so bad, since you'll just have to do the work once and as they get up to php5 speed, you can remove the Directory entries from their virtualhost section in httpd.conf...
if you're going to be maintaining php4 version and patches and whatever else comes along with it for a long term, this is going to become very tedious.

My first recommendation is, if it's at all possible, just move all the PHP4 people to one host machine, and as they upgrade migrate them to a php5 server.... once everyones off the php4 server, then turn it into a php5 only machine and reprovision your clients at a later date.

This solution might be inconvenient for people where you're not also managing their root dns registration, since they'll have to update their nameserver IP's once now and possibly again later, but it reduces the performance problems you're going to face and reduces the number of things that can go wrong.

Hope that helps

[EDIT].. in general, I retain previous versions for people who have scripts that call them manually.
for example:
/usr/bin/php -> /usr/bin/php5.2.0
/usr/bin/php5 -> /usr/bin/php5.2.0
/usr/bin/php5.1.4 /usr/bin/php5.0.5
/usr/bin/php4 -> /usr/bin/php4.4.4
/usr/bin/php4.4.4

so, if people had something running in cron (PHP-CLI) which required a specific php version, they could just reference the specific one.. either major or major.minor revisions...
if one was removed because of a specific security concern, their script would report an error and they could test and adjust it for a new version.

so, based on your question.. having different people using different versions of CLI is easy under these circumstances, they just have to pick which php they want to use.. the default (/usr/local/bin/php) is the ALWAYS LATEST version. /usr/local/bin/php[4,5] is the ALWAYS LATEST of the particular major version.

the above referenced, is for if you have clients who need their websites to run on anything other than the latest (PHP-CGI) release (/usr/bin/php)