PHP 5.6 CentOS 7
13 Replies
Will this work? Or will it cause damage?
> To use the IUS packages in CentOS 7:
1. Install EPEL and IUS repositories:
yum –enablerepo=extras install epel-release
yum install
https://centos7.iuscommunity.org/ius-release.rpm 2. Install yum-plugin-replace and replace the php packages with php56u packages:
yum install yum-plugin-replace
yum replace --replace-with php56u php
3. Restart any services which depend on php, such as httpd.
Note that this will install the current version of 5.6, which at the time of posting is 5.6.16, and that a "yum update" will keep the packages up to date in future.
I'm not a complete server neophyte, but this is something I've not done before (use a different repository), so I asked Linode support about it. They had this to say:
> It's hard to say if upgrading will break anything within your Linode as an infrastructure provider we do have our limitations as to what we can Support. But those steps you've listed look correct based my readings.
A subsequent question to them about "What's the official policy then" garnered this in reply:
> The official stance by CentOS's maintainers is to update to the latest version of CentOS 7 and then update PHP accordingly. However, if you want to keep the same version of CentOS then using a different repository for PHP updates should be fairly safe. If you need to, you can always uninstall PHP and install it from a different repository or package.
I've personally used Remi's repository for Enterprise Linux, which covers RHEL and CentOS:
https://rpms.remirepo.net/enterprise/7/ But I hear that IUS is also very reliable.
So at this point, I'm a bit confused as to what path to take.
Software CollectionsPHP 5.6
Keep in mind that these packages do not provide the built-in PHP module for Apache. To get that, you will need to install from the httpd24
There is no real reason to require 5.6 over 5.4, since their differences are can be bridged with little work. I would understand an app that requires 7.1, which comes with major changes, but in all honesty, an app requiring 5.6 is just bad development. Even as a managerial decision, a good manager will want to support a long term release as supported by CentOS, a major corporate distro. Especially when some corporate environments will refuse to upgrade or use alternative repositories.
@IfThenElse:
The real problem is with the apps that require PHP 5.6.
There is no real reason to require 5.6 over 5.4, since their differences are can be bridged with little work. I would understand an app that requires 7.1, which comes with major changes, but in all honesty, an app requiring 5.6 is just bad development. Even as a managerial decision, a good manager will want to support a long term release as supported by CentOS, a major corporate distro. Especially when some corporate environments will refuse to upgrade or use alternative repositories.
PHP 5.6 was released almost 3 years ago, and PHP 5.5 was released 4 years ago. Even Debian Jessie has 5.6. Having reviewed their respective migration guides, there are several items which are not simple or are impossible to implement in code that supports PHP 5.4. A couple examples are argument unpacking (expanding an array to an argument list) and timing attack-safe string comparison (I'd love to see you implement that in PHP; your implementation will be wrong in subtle ways you won't realize).
On the downside, the 10-year long term support by Redhat is not exactly 10 years. In the "small letters" (or in very clear a big letters if you find the correct page in their site), it is stated that those 10 years are split in 3 different parts. The first part is around 5 years and that is when you get most of the backports.
Anyway, for me there is no issue. Officially its 5.4 and if you want you can use Software Collections to support 5.6 or 7.
@IfThenElse:
You make the same assumption as my PCI DSS friends. You look at the version number and you think that is all that matters
No, I don't. I'm well aware of RedHat's bastardized creations from backporting specific features from newer releases. Just look at RHEL6's kernel; it reports it's 2.6.32, but the reality is that it's some frankenstein half 2.6.32 half 4.x kernel. And then there's when Linux 3.0 first released, and things like Mozilla's NSS build system threw errors because the kernel version didn't start with "2.6"; Fedora solved this by just changing the kernel version to 2.6.40, rather than fixing the check in NSS (among others).
IUS
It is an important difference, since Software Collections will add fixes but will not offer regular upgrades of the same package, instead they release a new "collection". But it may work better for people who want to keep the old version of the packages around the system.
You can see a comparison of the two here:
I needed to install Moodle. Their newest version will not install without PHP 5.6.
None of the CentOS solutions seemed adequate. I deployed a small linode with Debian 8 and use that for the Moodle instance. It provides the added advantage of distributing the workload between two linodes.
Probably not the best option but it works until Redhat catches up with the rest of the internet world. (That seems to happen every couple of years.)
I should probably just migrate away from CentOS????
PHP 5.6.31
But for multiple PHP-FPM version support I am working on, looking at Remi YUM repo for PHP 5.6, 7.0, 7.1 and 7.2 alpha to install side by side with my source compiled PHP-FPM.
Demo at
and
so check it Remi at
Remi is a good and reliable repo, highly suggested. His PHP packages will replace the old CentOS packages and we know that upgrades are frequent and kept up to date.
