Issue PHP by OS vendor marked outdated, but it isn't

[LightDot]

I'd like to discuss this before perhaps reporting it as a bug.

For example, on a fully updated CentOS 7 system:

# php -v
PHP 5.4.16 (cli) (built: Oct 30 2018 19:30:51)
# rpm -q php
php-5.4.16-46.el7.x86_64

Note above, this is not a vanilla PHP 5.4.16, this is Red Hat's 5.4.16-46.el7 (rebuilt by CentOS) that will receive full support until Q4 2020 and mission critical bugs and security support until June 30th, 2024. So more than 5 years of support left.

In Plesk's interface, PHP 5.4.16 by OS vendor gets reported as outdated to both the admin and the customers. Why is it being reported as such?

According to this Plesk article, this can't be turned off or adjusted either?

 

[andyxyz]

The only supported version of php at this point in time are 7.1 / 7.2 / 7.3

Any before this are now obsolete and will not receive any more security upgrades from PHP.

PHP: Supported Versions

While Centos may be patching bugs in the OS and php 5.4 the reality is that there will be LOT less activity around finding and patching bugs in 5.4 in general and therefore i think it is reasonable to label the versions as such in the interface.

It does not do anyone any harm to be reminded that their application should be upgraded to work with in-support versions of php.

 

[LightDot]

What you are saying is simply incorrect. Factually incorrect. Red Hat Enterprise Linux PHP 5.3.16-xx.el7 is fully supported at the moment, and will continue to be for a long time.

Red Hat - Backporting Security Fixes

Red Hat - Red Hat Enterprise Linux Life Cycle

Once Red Hat 8 comes out, and it looks like it will ship with PHP 7.2.xx, what will Plesk do once the vanilla PHP 7.2 EOLs? Mark fully supported Red Hat's PHP 7.2.xx obsolete again? That's just crazy.

The thing is, it does harm to misrepresent supported software as obsolete. We have customers that actually pay us to receive stable and supported systems that do not change under their feet as often as vanilla PHP does. We simply can't display "Obsolete" to them for something that isn't obsolete at all.

 

[ChristophRo]

change under their feet as often as vanilla PHP does. We simply can't display "Obsolete" to them for something that isn't obsolete at all.

It's labeled Outdated and this feels like the correct wording for me.
I even think it's great to let customers know that they use an outdated version of a software, so they may at least start to think about updating.
Also, labeling something as outdated does not automatically mean it's no longer getting updates or security fixes, so I can't see any problems with that.

As for using old/outdated PHP version.....I for myself don't see why there is such a big fuss about using a no longer supported PHP version.
In reality/practice, the security problem with PHP applications in a (shared) hosting environment is virtually never the used PHP version itself, but application specific bugs.

Moreover, the demand for using older PHP versions is still big, we install/use a self compiled and .deb packaged PHP5.3 on almost all our Debian9/Ubuntu18.04 servers and will most likely continue to do so when Debian10 comes out.
And to drop PHP5.6 is completely out of the question.

And just to get an idea on how popular PHP 5.6 still is - here a screenshot from one of our most busy server:

 

[Ales]

This is how it looks on our CentOS 7 / Plesk 17.8.11 servers:

I remedied the situation before our customers ever had a chance to notice.

I don't dream of showing them the word "Outdated" for something that a) isn't outdated b) they are paying us to take care of c) ... Well, we just like to keep our customers.

We've been using Plesk for a long time. Long. And while I think it's still the best general hosting control panel out there, occasionally they just drop the ball. Luckily, they have always left enough room for us to circumvent the situation. If they didn't, I'd be long gone.

When RHEL/CentOS 8 comes out, we'll re-package for CentOS 7 whatever they ship and keep that updated as our PHP 7.x on CentOS 7. And vice versa, when Plesk start supporting CentOS 8 and we start using it there, we'll re-package PHP 5.4.16-xx.el7 and offer it to our customers on CentOS 8. For as long as RHEL supports it.

I have no idea why Plesk isn't doing something like that...

As for those customers that want or need the latest and greatest (sic), they can use whatever Plesk ships as the latest and update all the time. Their choice.

@LightDot, feel free to PM me about this "outdated" thing. And do file a bug. I should have done that instead of just fixing it.

 

[andyxyz]

What you are saying is simply incorrect. Factually incorrect.

You seem to be going out the way to misinterpret my point. No matter what you want to happen PHP (the providers of php) will NOT be fixing old version of their software.. there is no argument here. You simply stating something to the contrary does not make it so.

You are relying on a OS vendor to supply security patches to a programming language. However, the rest of the world has moved on and there will simply be less effort put into finding said security issues in older version of PHP for the OS vendor to be aware of and therefore apply.

Hiding this fact from your customers does not seem good practise.

 

[Ales]

It's clear in my opinion, that some of us think that PHP support ends at the moment the upstream PHP project's support ends, while others think that PHP support ends when OS support for the PHP package ends, especially when talking about the support provided by prominent organizations such as Red Hat. We all know what Red Hat means for the open source community and how much of the actual engineering work is done by them.

I hope we can all agree that there is merit to both of those positions and both views should be respected. And while we can discuss the downsides or the upsides of either, that is not the issue or the topic here.

The issue is that Plesk has presumed to decide for us all and to report this decision directly to our customers. I wish that they would not presume to do such things.

The solution is very simple, give an option for the service providers to decide one way or another. It doesn't have to be prominent, a hidden setting somewhere is fine, just don't make the service providers fight their own control panel.

 

[LightDot]

@Ales, thanks for offering a solution for this issue. I think I can see where this is coming from and how it can perhaps be adjusted but I've sent you a PM to verify.

Just to make something clear, we aren't "hiding" anything from our customers. They are fully aware that they are being hosted on CentOS servers and we promote the long term support that comes from Red Hat via CentOS, including the information on backports. If this kind of support is something that's not good enough or important to some, well, let's just agree to disagree. Our customers are informed enough to be able to make their own mind (and they have a choice of alternative PHP versions that are also supported, among other things).

It's labeled Outdated and this feels like the correct wording for me.

See, that's just it... I'm aware that it's labeled "outdated" not "obsolete", as you can see from my first post, yet when the latter term was brought into discussion, I picked it up without thinking. I obviously easily interchange the term "outdated" with "obsolete", which brings me to:

Also, labeling something as outdated does not automatically mean it's no longer getting updates or security fixes, so I can't see any problems with that.

I'm not sure I'd agree but I can respect your opinion. English is not my first language, there might be that. But to take this further, seeing how easily I went from using "outdated" to "obsolete" suggests that a regular lay person might easily interchange outdated with obsolete, unsupported, insecure, dangerous or simply bad, especially if displayed in red. And, while some here might disagree, I simply don't consider current CentOS packages to be any of the above and wish not to convey them as such.