CentOS v5.2 - Updating PHP from v5.1.6 to v5.2.6

29 posts / 0 new
Last post
#1 Sat, 09/06/2008 - 05:04
molski

CentOS v5.2 - Updating PHP from v5.1.6 to v5.2.6

All,

For some applications I need to use PHP v5.2.x instead of PHP v5.1.6 (or lower). Updating PHP via "yum update php" isn't possible because the latest official CentOS v5.x release is PHP v5.1.6

On the Remi Repository (http://rpms.famillecollet.com/) is a RHEL5 PHP update available to PHP v5.2.6, when I want to update to this PHP version via this repository it will update the following packages:

[code:1] Package Arch Version Repository Size

Updating: php i386 5.2.6-1.el5.remi remi 1.3 M php-cli i386 5.2.6-1.el5.remi remi 2.5 M php-common i386 5.2.6-1.el5.remi remi 233 k Installing for dependencies: sqlite2 i386 2.8.17-2.el5.remi remi 170 k t1lib i386 5.1.1-7.el5 epel 194 k Updating for dependencies: php-eaccelerator i386 1:0.9.5.2-2.el5.remi remi 137 k php-gd i386 5.2.6-1.el5.remi remi 118 k php-imap i386 5.2.6-1.el5.remi remi 52 k php-mbstring i386 5.2.6-1.el5.remi remi 1.0 M php-mysql i386 5.2.6-1.el5.remi remi 82 k php-pdo i386 5.2.6-1.el5.remi remi 90 k php-soap i386 5.2.6-1.el5.remi remi 144 k php-xml i386 5.2.6-1.el5.remi remi 101 k php-xmlrpc i386 5.2.6-1.el5.remi remi 54 k

Transaction Summary

Install 2 Package(s) Update 12 Package(s) Remove 0 Package(s)

[/code:1]

I would like to know if updating this once via a 3rd party repo will cause problems on my CentOS v5.2 server with the latest Virtualmin (GPL) version.

And if it fails, how big is the chance that uninstalling these 3rd party packages and do a "yum install" for the official packages (like I use know, without any modifications) will fix the problems?

Thanks,

Molski

Sat, 09/06/2008 - 05:17
molski

Well.....after reading this useful post: http://bluhaloit.wordpress.com/2008/03/13/installing-php-52x-on-redhat-e...
I thought, what the hack, and updated PHP (as seen in my 1st post).

After I typed "php -v" (without restarting) it gave me the following error:

[code:1][root@# php5.2]# php -v
PHP Warning: PHP Startup: mcrypt: Unable to initialize module
Module compiled with module API=20050922, debug=0, thread-safety=0
PHP compiled with module API=20060613, debug=0, thread-safety=0
These options need to match
PHP 5.2.6 (cli) (built: May 7 2008 00:50:43)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
[root@# php5.2]# [/code:1]

After that I updated php-mcrypt via the same repository and restarted apache and it works perfect! apache, php, phpmyadmin, virtualmin (v3.60 GPL), everything works perfect (even without updating mysql).

Regards,

Molski

Fri, 10/17/2008 - 13:00 (Reply to #2)
Joe Pro Licensee
Joe's picture

I maintain a bleeding edge repository, documented here:

http://www.virtualmin.com/documentation/id,virtualmin_bleeding_edge_pack...

--

Check out the forum guidelines!

Sat, 01/10/2009 - 11:44 (Reply to #3)
JerryJaz

Hey Joe

Thanks for clearing my confusion.

I see that I can install older versions of phpMyAdmin and have done so.

My wife and patient partner asked why it takes so long between incremental upgrades being blessed into approved versions, and when I began to describe the interdependencies, she held up her hand and said, "I get it."

Thanks again for building, and maintaining, an immensely empowering product.

Jerry

Fri, 10/17/2008 - 23:21
molski

Very nice Joe!

Damn that I didn't knew about the Bleeding Edge Rep. before :)
The good thing is that in a few hours my (2nd hand) PowerEdge 1850 will be delivered and that will come instead of the PE650 I am using, so I was already planning for a new installation of VM, for me the perfect moment to (also) start using the bleeding edge repository, thanks Joe :)

Fri, 10/17/2008 - 23:37 (Reply to #5)
Joe Pro Licensee
Joe's picture

It's still early yet. I haven't added MySQL, SpamAssassin, and a few other bits and pieces yet, but plan to. I'm still working on them.

--

Check out the forum guidelines!

Fri, 10/17/2008 - 23:46
molski

For almost everything I can use the stable packages, but some PHP Apps I use, require PHP 5.2.6, so only PHP will do just fine for me (for now) ;)

Sat, 01/10/2009 - 10:43
JerryJaz

Hello friends-

I'm curious as to why Virtualmin would allow the upgrade of phpMyAdmin to 3.1.0 without a concurrent upgrade of PHP to 5.2.x as phpMyAdmin returns an error without it.

Please understand that I am a newbie in this area. I rely on Virtualmin (with tremendous gratitude) for the easy interface and worry-free admin of my sites and server software.

I have read the posts on upgrading to PHP 5.2 and it feels more complex than my fear factor rating.

Is there a future for the PHP 5.2 upgrade that will fall into the "recommended" category?

Thanks for allowing my bleeting about this.

Jerry

Sat, 01/10/2009 - 11:08 (Reply to #8)
Joe Pro Licensee
Joe's picture

<div class='quote'>I'm curious as to why Virtualmin would allow the upgrade of phpMyAdmin to 3.1.0 without a concurrent upgrade of PHP to 5.2.x as phpMyAdmin returns an error without it.</div>

It's a bug. I believe it is fixed in the next release. Apologies for any inconvenience.

<div class='quote'>Is there a future for the PHP 5.2 upgrade that will fall into the &quot;recommended&quot; category?</div>

No. There will <i>never</i> be a time when we recommend bleeding edge packages over stock OS versions--except for those folks who know they need it, know why they need it, and are equipped to deal with the additional risks involved. Though, I suspect, the bleeding edge repo <i>will</i> get more testing over time, and will probably get a bit more predictably usable and safe. So, the &quot;risks involved&quot; will get smaller as time goes by.

I've been doing this (administering servers, helping people fix servers, etc.) long enough to know that when folks get adventurous they eventually find themselves in a world of pain. Providing packages of bleeding edge stuff that is somewhat tested and maintained is less adventurous than having folks build their own PHP (or whatever) from scratch in order to get the new version. So, it's the lesser of two evils. ;-)

--

Check out the forum guidelines!

Thu, 01/15/2009 - 18:05
tabletguy

I have a similar problem, but it's not just phpMyAdmin. There are aready a couple of other packages / scripts that require 5.2. Additionally, Joomla has announced that their 1.6 version (not out yet) will require 5.2

Is there a time frame for when we should expect 5.2 to be &quot;non bleeding edge&quot;?

From reading about 5.2, it breaks backward compatibilty even with 5.1 series, so I'm certainly not anxious to get it, and wouldn't if I wasn't required to.

Perhaps there would be a way to run both 5.1 and 5.2 on the same server?

Thu, 01/15/2009 - 19:07 (Reply to #10)
Joe Pro Licensee
Joe's picture

<div class='quote'>Is there a time frame for when we should expect 5.2 to be &quot;non bleeding edge&quot;?</div>

It'll never happen in CentOS 5. The packaging policy for RHEL (on which CentOS is built) is to keep the same version throughout the life of the version. This is a feature, not a bug. Stability is king on RHEL/CentOS.

RHEL/CentOS 6, on the other hand, probably will have PHP 5.2 or 6.x.

<div class='quote'>Perhaps there would be a way to run both 5.1 and 5.2 on the same server?</div>

Oh, goodness. You just made me break out in a cold sweat.

Is it possible? Yes. Is it a good idea? Probably not.

I wasn't actually aware of any serious incompatibilities between 5.1 and 5.2. Are there specific applications that exhibit these problems?

--

Check out the forum guidelines!

Fri, 01/16/2009 - 21:10 (Reply to #11)
sgrayban

There are no incompatibilities between 5.1 and 5.2 that I am aware of.

Tue, 01/27/2009 - 03:48 (Reply to #12)
pixel_paul Pro Licensee
pixel_paul's picture

Just as a note, php 5.2.8 is out.....

Thu, 01/15/2009 - 23:22
molski

Guys,

Although PHP 5.2.6 is BleedingEdge, I still recommend to install it if your scripts require so.
It runs perfectly on my machine(s) without any issues!

Tue, 01/12/2010 - 06:09
tabletguy

After looking at the "bleeding edge" documentation page, I ran the rpm package at the bottom to generate a new ".repo" entry in /etc/yum.repos.d.

The documentation recommends using "yum includepkgs" to limit to php5.2 (which is what I want), however running yum on my server (Centos 5.4) it does not list an "includepkgs" (or "include" parameter in help. It DOES list an exclude parameter, however.

So, what is the next step to set it up to ONLY get php 5.2 from this repository?

While waiting for a reply, I've renamed the file to "virtualmin-bleed.xxxx" to avoid getting things automatically.

Personally, I wish we actually COULD have support for 5.1, 5.2, 5.3 (similar to php4 & 5). This would allow individual customizations. However, it seems from Joe's comments that this might be much more complicated to implement safely.

So, just the steps for limiting to php 5.2 would be appreciated. I read all the threads on this that I could find without any explanation of that step.

Fri, 01/15/2010 - 00:33
tabletguy

Anyone can tell me the changes to the .repo file to limit it to only the php 5.2 package?

Fri, 01/15/2010 - 22:42 (Reply to #16)
andreychek

Howdy,

Take a peek at the "man yum.conf" page, I think the parameter that will do what you want is:

       includepkgs
              Inverse  of  exclude. This is a list of packages you want to use from a repository. If this option
              lists only one package then that is all yum will ever see from  the  repository.  Defaults  to  an
              empty list.  Substitution variables, described below, are honored here.

So, "includepkgs" would go inside your .repo file, and would include a list of packages that you want from that particular repo.

-Eric

Sat, 01/16/2010 - 00:35
tabletguy

Thanks for finding the "includepkgs" parameter documentation. It didn't show up under the yum help command.

The concept is easy enough, but there's nothing that shows what exactly is a "package name". The man page doesn't have any examples.

For example, if I look at http://software.virtualmin.com/bleed/centos/5/i386/ there are many versions of php already there. So, I cannot even say "php5*" because that would include older versions. If I specify a single version, then how would it stay updated with new releases?

In my new .repo file, I have: http://software.virtualmin.com/bleed/rhel/$releasever/$basearch/

So, I still have two questions:

1) Why did the rpm generate "/rhel/" ? I am running Centos (I notice there is also a Centos branch -- should I change to use that?)

I looked here for examples: http://bund.com.au/~foo/linux/yum.html

2) There are many versions of php 5.2 already there. Additionally, it looks like a number of dependent packages (part of php?). So, it doesn't make sense to me that I could just say "includepkgs=php* which would include many versions at the same time, and also would exclude any dependencies. So, I know I need a space delimited list of package names, but don't know which IS the package name, and also whether or not it will automatically pull in any dependencies. Man page didn't say anything about that, nor the above referenced examples page.

Sorry to pester you about this.

Mon, 02/01/2010 - 21:41 (Reply to #18)
Joe Pro Licensee
Joe's picture

For example, if I look at http://software.virtualmin.com/bleed/centos/5/i386/ there are many versions of php already there. So, I cannot even say "php5*" because that would include older versions. If I specify a single version, then how would it stay updated with new releases?

Actually that wouldn't include anything from our repos. We don't have any "php5" packages in that repo or the CentOS 5 standard repository (nor does CentOS 5 OS repos). It's simply called "php".

You don't need to worry about older versions of anything in yum; because it always picks the latest version unless there is some specification for it to do otherwise. It's really hard to install old packages with yum; so hard, in fact, that worrying about it should never even enter your mind. It just won't happen accidentally. (There are Epochs which make packages that might look older to you and me get installed instead of newer, but that's pretty rare, and it's not usually something you have to think about either.)

So, include "php*", and you'll be fine, at least with our repos. For other third party repos, you might need to go a different route.

--

Check out the forum guidelines!

Thu, 02/04/2010 - 03:56
tabletguy

I think the wiki page could be fleshed out a bit with a good example.

I think I've gotten my system updated (although I don't know a good procedure to test this thoroughly).

1) I had to first run the rpm at the end of the wiki page to create a new .repo file 2) Edit the file and add an "includepkgs" for ALL the php packages. One should not include any of the version numbers. 3) From a command line, run "yum update php"

Here's an example of my includepkgs line

includepkgs=php php-cli php-common php-devel php-mysql php-bcmath php-dba php-debug-info php-embedded php-gd php-imap php-ldap php-mbstring php-mcrypt php-mhash php-mssql php-mysql php-ncurses php-odbc php-pdo php-pear php-pecl php-pgsql php-pspell php-snmp php-soap php-tidy php-xml php-xmlrpc

Fri, 10/22/2010 - 09:46 (Reply to #20)
glamor

this worked perfect for me tabletguy.

after you do this however, is it advisable to disable the bleeding edge repo?

i notice when i try to install something new for zip, because i've been trying to do "pecl install zip" without success, that it does this:

yum install libpcre3 libpcre3-dev
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* addons: centos.mirror.netriplex.com
* base: mirror.batblue.com
* extras: mirror.ash.fastserv.com
* updates: ftp.usf.edu
virtualmin-bleed                                                         |  951 B     00:00
Reducing Red Hat Enterprise 5 - x86_64 - Virtualmin Bleeding Edge to included packages only
Finished
Setting up Install Process
No package libpcre3 available.
No package libpcre3-dev available.
Nothing to do

also i agree, that the wiki page should include an example. it would be great. i know that you do a lot in supporting this repo however and we all appreciate your generosity.

Sat, 02/18/2012 - 03:17
jmunjr

I'm not sure if there is a newer thread, but I was wondering if there have been any known issues with updating to php 5.2.x with these bleeding edge repos... If so any idea for what? I basically have a few scripts I want to run that require it.

Sat, 02/18/2012 - 06:02
helpmin

worked fine for me. You could also try to upgrade to 5.3 (centos 5.7), but 5.2 worked better for me.

Sat, 02/18/2012 - 15:02
jmunjr

Thanks. Ummm I am running Centos 5.7 and I only have the PHP that comes with Virtualmin. I did a base install of Centos to make sure Virtualmin installed and worked as best possibly. Recommendations? Use the bleeding edge or go a different route to get to 5.3?

Sat, 02/18/2012 - 18:37
helpmin

php 5.3 is included from Centos 5.6. Try yum search php

Sat, 02/18/2012 - 22:37
jmunjr

Ok well this is what happens if I do

yum install php

Package php-5.1.6-27.el5_7.5.x86_64 already installed and latest version Nothing to do

Sure, I can manually install it but my Centos 5.7 does not have a php > 5.1.6

Mon, 04/16/2012 - 05:48
ashizak916

I found best article describing in details, It is worked me fine

http://www.discusswire.com/update-php-virtualmin/

Tue, 04/17/2012 - 04:10
duncanbbd

here's what I did to get this updated on my server, seems to have gone well apart from 'mcrypt' extension is missing. not a major issue at the moment, but unsure how to install mcrypt

rpm -ivh http://software.virtualmin.com/bleed/centos/5/i386/virtualmin-bleed-rele...

yum update php

edit: did a "yum install php-mcrypt" and it seems to have worked by taking mcrypt from the bleeding edge repository

Tue, 04/17/2012 - 04:18
duncanbbd

just a big thanks to you guys,
once I got my head around how you have things set up (wasn't too difficult :o) ) its been really easy

I wasn't sure about your bleeding edge repo (I mean how to use it), but its great.

best web admin I've ever used.

cheers Brian