Our server (CentOS 6.2) is failing PC compliance audits on PHP 5.3. I suspect patches have covered the vulnerabilities and the security audit service is happy to accept logs to show these and then sign off as OK...
But they require us to submit these quarterly and it's a pain... we are also unable to upgrade some of our CMS frameworks (XOOPS, Zen Cart) until we move up to a later version of PHP.
PhP 5.4.* is stable... but then we see they just announced 2 days ago that PHP 5.5.13 is stable.
I'm planning to engage Tier 3 Engineering/Linux RedHat/CentOS expert at GoGrid to do the upgrade.
Before I do I'm looking to understand/decide:
1) Are there issues with CentOS 6.2 and upgrading to PHP 9.5.*
2) Would it be better to not be too aggressive and just upgrade to 5.4.* for now? I always worry that not going to the latest version will mean we will be forced to upgrade again within a few months. I know that late last year there were still issues with PHP 5.5.* but as of July 27th it is rated as "stable."
Comments anyone?
Howdy,
Well, I do understand your predicament; it can be tedious to deal with the processes of PCI companies.
The other side of the issue though is that we don't tend to recommend using packages other than the ones provided with your distro.
The distro's PHP versions are well tested, they include improvements and optimizations not included by default, and the version doesn't change.
If you have someone packaging PHP for you, they would need to do that same thing each time a new PHP version came out. And it's possible one of those updates will include changes that cause a problem in one of your applications. But it can also be difficult to keep up with manually packaging PHP versions.
You can see how often PHP versions are released by browsing the Changelog here:
http://php.net/ChangeLog-5.php
In order to remain PCI compliant, you would need to update each time they pushed out a new release... it looks like there have been four releases in the 5.4.x, and another four releases in the 5.5.x branch, since May.
With that in mind, in my opinion, I would find packaging a custom PHP version to be more of a pain than submitting quarterly reports :-)
If one of your main goals was to enable you to run newer web apps, you could always install a second PHP version, using the instructions here:
https://www.virtualmin.com/documentation/web/multiplephp
That version won't solve your PCI issues, but it would provide a newer PHP version.
Now, if you found a reliable repository that handled packaging the latest PHP version for you, that would improve things and make it simpler than manually building it each time.
The only issue then is related to the stability (what exactly is changing when updating PHP? Are any of my apps going to break?)
While it's still not something I'd recommend for a production server, if it's something I had to do, I'd much rather have an existing repository that handled the update for me automatically when I ran "yum update". Again though I'd want to be certain that repository was reliable, and was going to be maintained for the long haul.
As an alternative to all that, you could always just build a script to collect all the data you need to send into the PCI company. Have that script email it to you once a quarter, then just pass it along to your PCI company. Then you get to maintain the stability of your PHP apps, while not having to deal with tedious processes :-)
-Eric
Well I stuck my neck out and had them up grade to 5.5.15
zenCart worked out of the box..
Word Press, DokuWiki and XOOPS and OC Portal are in trouble.
Wish me luck!
As it turns out what is happening is that PHP is not executed at all. Apache is returning... e.g. the initialization file (usually "index.php") as plain text instead of sending it to PHP to be interpreted. So, hopefully, the apps themselves are not really "broken" but we just need to get *.php files to be sent to the interpreter. Any ideas?
All is well... silly business: cached sessions/cookies on the local browser were being called on the web server after the upgrade... and this (very bizarre) caused Apache to serve the plain text php file. After clearing the local browser cache and reloading, the pages worked just fine. Go Figure!