Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Would the following works fine without any issues? I have apc cache installed, the other packages the usual php configuration.

 yum update php

would that be enough?

it is an active server, so want to make sure and see what should I take into consideration to make this less painful.

share|improve this question
up vote 5 down vote accepted

For people running PHP-based web sites, it's almost always required to track bug fix changes as well as the security fixes that Red Hat might provide. As you know they rarely provide bug fix updates, due to "enterprise" version locking, even for something like PHP where you really need them.

On my production web servers I have used the remi repository for many years. It provides current versions of PHP, MySQL, Symfony, and many related packages that need such updates on a regular basis. As of this writing, it provides PHP 5.4.33 and MySQL 5.5.40. (PHP 5.5 is available in remi-php55.)

The main difference you will notice is that your PHP bugs start going away... :)

share|improve this answer
I added remi repo using a centos on a VM and it worked. thanks! – Dreaded semicolon Nov 26 '12 at 13:15
I chose before i tried your suggestion. and didn't want to change. but now done. thanks – Dreaded semicolon Nov 27 '12 at 17:27

As madhatter reminded me, a yum update will bring you up to the latest redhat php release, at the time of writing this appears to be: 5.3.3-14.el6_3

In any event your plan of action should be something along the lines of:

  1. Schedule a maintenance window
  2. Create a test plan
  3. Shutdown apache
  4. update php yum update php
  5. start apache
  6. Execute test plan

If your test plan fails you can downgrade php, yum downgrade php that said I would test this all using a "throw away" vm, that way you can run through all of this without any risk to the production system.

Is there a particular need for 5.3.4 or is this just a security concern?

Note: redhat backport security and bug fixes into their releases.

5.3.3-14 for instance indicates php 5.3.3 with 14 redhat itterations:


  • Mon Jun 25 2012 Joe Orton - 5.3.3-14
  • add security fix for CVE-2010-2950

  • Wed Jun 13 2012 Joe Orton - 5.3.3-13

  • fix tests for CVE-2012-2143, CVE-2012-0789

  • Tue Jun 12 2012 Joe Orton - 5.3.3-12

  • add fix for CVE-2012-2336
share|improve this answer
Sorry, a rare downvote for an answer here, because that simply won't do what the OP wants. It'll definitely bring php-5.3.3 up to Red Hat's latest patch state for 5.3.3, but that's not the aim of his or her game. – MadHatter Nov 23 '12 at 8:47
@MadHatter ah indeed, that does bring it to: 5.3.3-14.el6_3 edited my answer. – Oneiroi Nov 23 '12 at 8:52
Downvote recanted! Have an upvote instead. – MadHatter Nov 23 '12 at 9:06
thanks for the answer, yes we need to upgrade to 5.3.4 to fix a php bug that is causing us a lot of trouble. it is fixed in 5.3.4. – Dreaded semicolon Nov 23 '12 at 10:43
This is the bug I want to fix without turning off zend.enable_gc: – Dreaded semicolon Nov 23 '12 at 10:52

CentOS 6 does not have PHP 5.3.4 in the standard repositories, which you can see here. yum update php will not upgrade you to 5.3.4.

Think long and hard about why you want to upgrade. CentOS and it's upstream vendor have not included 5.3.4 yet because it has not been tested.

If you really want to continue, you can check out the list of Third Party Repositories. I don't actually see any that have PHP 5.3.4 but I didn't look too hard.

Once you find a repo with the packages you want, gather your current list of PHP packages with rpm -qa | grep php. Run yum update php and it should show you what it wants to update. It should match everything in your currently installed list but have newer versions. If yum doesn't match your currently installed list, don't update.

share|improve this answer
Much better answer, though still wrong about why C6 doesn't have php 5.3.4. The answer is in Red Hat's patching policy, which says that whatever version of a tool RHEL6 has on ship date, that will be the version of that tool it will have through its whole life. RH will backport patches, and make sure that that their php5.3.3 stays usable for the life of EL6, but they will never upgrade it. CentOS faithfully mirrors upstream in this, as in nearly all, respects. – MadHatter Nov 23 '12 at 9:03
Thanks, I need to either downgrade it to earlier version like 5.2 or upgrade to 5.3.4. there is a bug in the versions between with Garbage Collection. that redhat policy then it would mean centos6 will continue to have buggy php. I guess I have no choice but to use third party? – Dreaded semicolon Nov 23 '12 at 10:49
Actually RHEL version locked several months before they even went into beta. Which is frustrating because of the PHP bug that will never get fixed... – Michael Hampton Nov 23 '12 at 11:55
@MadHatter: that makes sense. Thus the custom 5.3.3-24 minor versioning in their standard packages, where it's still PHP 5.3.3, but with only certain chosen and tested critical fixes matching only some PHP official version 5.3.24 updates. – bob-the-destroyer May 27 '15 at 4:24
@bob-the-destroyer: close. Rather, it's the 24th version of php-5.3.3 that RH have released, each with slightly more fixes to the 5.3.3 codebase, most of which fixes are backported from later versions. – MadHatter May 27 '15 at 6:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.