HOW-TO Roll Back your PHP *when all else fails*

Alright, so you've installed some version of PHP5 and you realized something didn't go right. Maybe some sites aren't 5.0 compatible. Maybe you're having some server issues. For me, one big client needed 4.4.0 and I don't want to run both 5 and 4 on the same server.

Now I need to uninstall PHP 5.1.1 to gain functionality again.

Like the foothills of a bad relationship, all the frustration and seclusion that ends with the statement, "It's not you. . . it's me. . . I just want to get on with my life."

So, I've rolled back to PHP 4.4.0 using Gpan's RPMs
( refer to this thread http://forums.ev1servers.net/showthread.php?t=56844 )

Give Gpan loads of thanks and love. . . Standard disclaimers apply if not all goes right with this procedure. I'll help how I can, but BE VERY CAREFUL. You're literally breaking things to put them back together.


STEP 1 :
Now, first thing you do is download all the RPMs you're going to need for this and put them in their own directory.

This is what I did for RHEL 3

mkdir php440
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm


If you need RHEL 4,
Read this thread: http://forums.ev1servers.net/showthread.php?t=56844 and follow Gpan's instructions.


Now, try install them using
rpm -Uvh php*.rpm

Make notes of all the "php 5.1.1 is newer"
you'll have to [ rpm -e --nodeps ] each package that is preventing you from installing 4.4.0

Like this :
rpm -e --nodeps php
rpm -e --nodeps php-xmlrpc

Once that's done, try installing the PHP 4.4.0 RPMs again
rpm -Uvh php*.rpm


STEP 2 : Resolving Dependencies.
The two RPMs I found missing were JS and Sablotron.

Make another folder for these:
mkdir depends

Get the JS ( includes the dreaded libjs.so.1 ) :

RHEL 3:
wget http://dag.wieers.com/packages/js/js-1.5-0...el3.rf.i386.rpm
wget http://dag.wieers.com/packages/js/js-1.5-1...el3.rf.i386.rpm
wget http://dag.wieers.com/packages/js/js-devel...el3.rf.i386.rpm

RHEL 4 and other compilations here:
http://dag.wieers.com/packages/js/

rpm -Uvh js*.rpm

Sablotron I grabbed from Cheetaweb (all hail Gpan)
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm
wget http://mirror.cheetaweb.com/redhat/3ES/i38...el3.ct.i386.rpm

rpm -Uvh sablo*.rpm

Once the dependencies are taken care of go back to step 1 and install.


STEP THREE : Cleaning up
Now, you need to do the following:

cd /etc/php.d

remove the following files
bcmath.ini
dba.ini
dom.in,
soap.ini
xsl.ini

cd /etc
cp php.ini php.ini.back1 (essentially, just backup your php.ini)
pico php.ini

find the section with [bmath] and erase that whole section - save the file.

now do a:

/usr/local/sbin/set_pre_maintenance
/usr/local/sbin/set_maintenance
/usr/local/sbin/set_post_maintenance
service webppliance restart


Now, everything is working again, but I rebooted the server just in case. (If it's going to crash and I need a restore. . . I want it to do so in front of me, not at 1:45 am on Saturday when I'm stumbling around at the clubs and a client is screaming into my voicemail).

Good luck, I hope this is helpful, or at least points you in the right direction

Alright, having a bit of a problem here with my rollback, maybe someone can help me. . .

a PHP -V gives me the following error:

php -v
PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/bcmath.so' - /usr/lib/php4/bcmath.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/dba.so' - /usr/lib/php4/dba.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/dom.so' - /usr/lib/php4/dom.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/soap.so' - /usr/lib/php4/soap.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/xsl.so' - /usr/lib/php4/xsl.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP 4.4.0 (cgi) (built: Jul 12 2005 02:09:00)
Copyright © 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright © 1998-2004 Zend Technologies




-----Now, I'd say about 90% of the server is working fine, but several critical pages are not loading and the httpd logs echo the same inability to load these libraries.

I'm depressed mates . . . any help would be handy.

Remove the stray junk from /etc/php.d ... may be named bcmath.ini, dba.ini, dom.ini, soap.ini, xsl.ini --- cd there and grep for the missing modules to figure out what to delete.

[note: because of Catalyst's statement above and the following conversation below I've edited the directions on this rollback to add a small change]


Thanks Catalyst, I was able to clean up php.d ; but not sure how to make grep work for me.

How do I format the request with grep to check for the missing mods?

I did
rpm -qaV | grep missing
And I'm starting to get a small phonebook... is that what you meant?

*shakes head* I think you misunderstood.

Removing the 5x RPMs didn't clean up after themselves. `cd /etc/php.d` then `grep bcmath.so` ... if you get a match, edit the file and delete the line trying to load the missing .so (or delete the file if it's only one line).

AFAIK, there are no equivalents for these modules in PHP 4x, and they're unnecessary.

I see. . . ::bows sheepishly:: I was confused. . .

I'm trying that now and I removed the [bcmath] entry out of PHP.ini . . .

We'll see how it works.

I still have a set of pages not responding, they just come up blank, which tells me something is still missing in my php install. ::sighs::

Typing in "grep bcmath.so" seems to just hang. How long do you think it'll take?

Did you save a copy of your 4x /etc/php.ini?

Of course. . . you think I'll need to put it back up?

I've tried going through all my old PHP.ini files previously.

UPDATE:
Just tried replacing my old PHP.INI with the current ones. It didn't work.

You should either have display_errors or log_errors & error_log turned on --- if you're getting a blank page, there's an error somewhere. Can fix it if ya don't know what it is. ;-)

You know, I finally got it figured out yesterday. It had nothing to really do with the rollback, (although cleaning out the last bits of the php5 install was nice and did take care of the PHP -v error.)

I thought I had all the error_log and log_errors turned on both for MySQL and PHP via the PHP.INI.

Well, quite simply the script I was worried about was re-routing all errors to its own error handler (which was incomplete and broken). Had to call a genius to help.

Fun. . . I had NO idea what was going on until we figured that out, inputted a work-around (bypassed it's error reporting with a default PHP error reporting on several of the scripts).

Got the proper error and he immediately knew what to do.

Basically, session tables were too full for PHPs 8meg limit. Table emptied, client told to make a proper cookie handler for those pages. All is good now.

Thanks a lot Catalyst!

*nod* ... Been there, done that. Why half these guys won't do a simple, booleanized "SELECT sesssion_id FROM sessions WHERE session_id=`$this_user_session`" rather than filling up the available memory with a limitless comparison is beyond me. ;-) And I won't even get started on Error Handling...

Ach, aye you are absolutely right m'noble sir. Needles in haystacks or eyes. . . I was so certain I messed up the PHP install, even after having multiple people look it over. Nope, bad scripting strikes again.

It's a learning process for all things.

I never had anything work flawlessly the first time before, but this did.

I tried installing php5 on my server, but could not get it to work. This killed my phpMyAdmin, as it tried to download the page instead of opening it in the browser.

The php on the domains was fine, and I wanted it to stay that way, so I followed the instructions here, using the php files from the Cheetaweb RPM archive and I was good to go.

not only did it fix my problem with phpMyAdmin, I was able to upgrade from php 4.3.9 to php 4.4.2 in about fifteen minutes!

Thanks!

To ElfinStrider

Just wanted to say thank you SOOOOO much for this post. By mistake I updated to php5 thru yum and my client's sites dissapeared. Thanks to your post, I got back php 4 and everything is now back to normal. Truly did save my life. Thank you thank you thank you!!!

There are a few fixes you can do which should in most cases fix your compatibility issues with php5. For instance, throwing the following in a common or global include file for the script could fix many issues though will not make the HTTP variables super global:



In your php.ini file, you could make the following change (should fix the blank page issue some people have):

short_open_tag = On

Enabling globals may be required for some older or poorly written scripts to run:

register_globals = On

I just look at it this way, why downgrade to php4 when php5 has been out for a long long wile now.

Worst case, running poth php4 and php5 together would not be hard to do when running in 3.5 comp. mode, use mod_suphp. I made some changes to the mod_suphp source which will allow both to run perfectly on an ensim box. Maybe I will throw together a howto some day when I have time, did not really think anyone was looking to do it.