Hi,
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
1. CentOS 7 sports PHP 5.4, which has been officially EOL for quite some time, but Red Hat will provide security update backports until 2024. Which is fine.
2. Currently supported versions of Nextcloud (namely the 11.x and 12.x branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
3. The solution would be to go with Nextcloud 10, which only requires PHP 5.4, and which is also provided in package form by EPEL. 'yum info nextcloud' shows that the current EPEL version is 10.0.4... but a peek on the Nextcloud homepage shows me that this version is officially unsupported. Uh oh.
4. Some of the stuff I'm hosting on my CentOS 7 server (like CMSMS) is not compatible with PHP 7.x versions.
So right now I don't see a solution for this. As far as I can see, the "least evil" solution would be to pull in PHP 5.6 from Webtatic and go for Nextcloud 11.x, and have an EOL for both around next summer.
I'd be curious if some of you are familiar with this sort of dilemma (I guess so) and how you manage it.
Cheers,
Niki Kovacs
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Nicolas Kovacs Sent: den 19 september 2017 09:37 To: CentOS mailing list centos@centos.org Subject: [CentOS] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
Hi,
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
1. CentOS 7 sports PHP 5.4, which has been officially EOL for quite some time, but Red Hat will provide security update backports until 2024. Which is fine.
2. Currently supported versions of Nextcloud (namely the 11.x and 12.x branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
3. The solution would be to go with Nextcloud 10, which only requires PHP 5.4, and which is also provided in package form by EPEL. 'yum info nextcloud' shows that the current EPEL version is 10.0.4... but a peek on the Nextcloud homepage shows me that this version is officially unsupported. Uh oh.
4. Some of the stuff I'm hosting on my CentOS 7 server (like CMSMS) is not compatible with PHP 7.x versions.
So right now I don't see a solution for this. As far as I can see, the "least evil" solution would be to pull in PHP 5.6 from Webtatic and go for Nextcloud 11.x, and have an EOL for both around next summer.
I'd be curious if some of you are familiar with this sort of dilemma (I guess so) and how you manage it.
Been there, still doing that.
At work we have an OC-server v9 running off of CentOS 7.3 on which I installed PHP 5.6. I don't dare installing PHP 7 in case something breaks.
On my own private OC at home, I have OC v10 running with PHP 7.0. The only other service I have on that service is Piwigo which runs just fine with that php-version.
I agree however, everytime I want to mess with OC I get to do the php-dance... Irritating, but I guess that's the deal if you want the stability and compatibility CentOS is offering. -- //Sorin
Le 19/09/2017 à 09:48, Sorin Srbu a écrit :
I agree however, everytime I want to mess with OC I get to do the php-dance... Irritating, but I guess that's the deal if you want the stability and compatibility CentOS is offering.
This may be a very far-fetched idea, but here goes. I don't know much about Docker, just fiddled around with it a couple hours in a VM. Since I have to host various PHP applications with different requirements (some require 5.4, some 5.6, some 7.0), I wonder if it would be a solution in theory to host several PHP versions (e. g. several different LAMP servers) on the same physical machine using Docker.
Any suggestions?
Niki
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Nicolas Kovacs Sent: den 19 september 2017 10:01 To: centos@centos.org Subject: Re: [CentOS] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
Le 19/09/2017 à 09:48, Sorin Srbu a écrit :
I agree however, everytime I want to mess with OC I get to do the php-dance... Irritating, but I guess that's the deal if you want the stability and compatibility CentOS is offering.
This may be a very far-fetched idea, but here goes. I don't know much about Docker, just fiddled around with it a couple hours in a VM. Since I have to host various PHP applications with different requirements (some require 5.4, some 5.6, some 7.0), I wonder if it would be a solution in theory to host several PHP versions (e. g. several different LAMP servers) on the same physical machine using Docker.
Any suggestions?
For me that would be over-kill, but for others that have bigger solutions it might be a good idea. Docker is however bit of a white area on my map, here there be dragons. :-)
-- //Sorin
This may be a very far-fetched idea, but here goes. I don't know much about Docker, just fiddled around with it a couple hours in a VM. Since I have to host various PHP applications with different requirements (some require 5.4, some 5.6, some 7.0), I wonder if it would be a solution in theory to host several PHP versions (e. g. several different LAMP servers) on the same physical machine using Docker.
Try LXC containers. An LXC container is much more like a virtual machine, without much overhead. It has less a learning curve than Docker.
I have some scripts for setting up my lxc containers, and maintaining them: https://github.com/tpokorra/lxc-scripts See the Readme.
Hope this is useful, Timotheus
---------------------------------------------------------------- Diese Nachricht wurde versandt mit Webmail von www.tbits.net. This message was sent using webmail of www.tbits.net.
Am 19.09.2017 um 09:36 schrieb Nicolas Kovacs info@microlinux.fr:
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
- CentOS 7 sports PHP 5.4, which has been officially EOL for quite some
time, but Red Hat will provide security update backports until 2024. Which is fine.
- Currently supported versions of Nextcloud (namely the 11.x and 12.x
branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
Try to ask upstream (bugzilla) to evaluate an officially upgrade from 5.4 to 5.6, that would give you support until EOL of EL7.
-- LF
Le 19/09/2017 à 13:41, Leon Fauster a écrit :
Try to ask upstream (bugzilla) to evaluate an officially upgrade from 5.4 to 5.6, that would give you support until EOL of EL7.
Unfortunately I don't have a Red Hat account, so I can't submit any bug reports.
Niki
Am 19.09.2017 um 14:50 schrieb Nicolas Kovacs info@microlinux.fr:
Le 19/09/2017 à 13:41, Leon Fauster a écrit :
Try to ask upstream (bugzilla) to evaluate an officially upgrade from 5.4 to 5.6, that would give you support until EOL of EL7.
Unfortunately I don't have a Red Hat account, so I can't submit any bug reports.
https://bugzilla.redhat.com/createaccount.cgi
-- LF
On 09/19/2017 06:41 AM, Leon Fauster wrote:
Am 19.09.2017 um 09:36 schrieb Nicolas Kovacs info@microlinux.fr:
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
- CentOS 7 sports PHP 5.4, which has been officially EOL for quite some
time, but Red Hat will provide security update backports until 2024. Which is fine.
- Currently supported versions of Nextcloud (namely the 11.x and 12.x
branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
Try to ask upstream (bugzilla) to evaluate an officially upgrade from 5.4 to 5.6, that would give you support until EOL of EL7.
Or, how about you just use SCLs .. that is what they are for:
http://mirror.centos.org/centos/7/sclo/x86_64/rh/rh-php56/
Or even
http://mirror.centos.org/centos/7/sclo/x86_64/rh/rh-php70/
See:
On 09/19/2017 08:25 AM, Johnny Hughes wrote:
On 09/19/2017 06:41 AM, Leon Fauster wrote:
Am 19.09.2017 um 09:36 schrieb Nicolas Kovacs info@microlinux.fr:
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
- CentOS 7 sports PHP 5.4, which has been officially EOL for quite some
time, but Red Hat will provide security update backports until 2024. Which is fine.
- Currently supported versions of Nextcloud (namely the 11.x and 12.x
branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
Try to ask upstream (bugzilla) to evaluate an officially upgrade from 5.4 to 5.6, that would give you support until EOL of EL7.
Or, how about you just use SCLs .. that is what they are for:
http://mirror.centos.org/centos/7/sclo/x86_64/rh/rh-php56/
Or even
http://mirror.centos.org/centos/7/sclo/x86_64/rh/rh-php70/
See:
Or use openshift origin and setup a unique set of containers for each application that is a mix of whatever versions of things that you need:
Am 19.09.2017 um 15:25 schrieb Johnny Hughes johnny@centos.org:
On 09/19/2017 06:41 AM, Leon Fauster wrote:
Am 19.09.2017 um 09:36 schrieb Nicolas Kovacs info@microlinux.fr:
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
- CentOS 7 sports PHP 5.4, which has been officially EOL for quite some
time, but Red Hat will provide security update backports until 2024. Which is fine.
- Currently supported versions of Nextcloud (namely the 11.x and 12.x
branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
Try to ask upstream (bugzilla) to evaluate an officially upgrade from 5.4 to 5.6, that would give you support until EOL of EL7.
Or, how about you just use SCLs .. that is what they are for:
SCL's support for rh-php56 has ended (April 2018).
PHP's official support until 31 Dec 2018.
Or even
SCL's support until Nov 2019.
PHP's official support until 3 Dec 2018.
So, reasonable.
See:
Expecting that the next SCL release will provide PHP 7.1.
SCL packages should be preferred, instead of using 3rd party repositories (not arguing against any of them - more focusing manageability, integration, dependencies etc.).
-- LF
+1 SCL, as Johnny says this is what they are for. You can easily run multiple PHP versions via php-fpm, fastcgi etc.
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "johnny" johnny@centos.org To: "CentOS mailing list" centos@centos.org Sent: Tuesday, 19 September, 2017 14:25:08 Subject: Re: [CentOS] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
On 09/19/2017 06:41 AM, Leon Fauster wrote:
Am 19.09.2017 um 09:36 schrieb Nicolas Kovacs info@microlinux.fr:
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
- CentOS 7 sports PHP 5.4, which has been officially EOL for quite some
time, but Red Hat will provide security update backports until 2024. Which is fine.
- Currently supported versions of Nextcloud (namely the 11.x and 12.x
branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
Try to ask upstream (bugzilla) to evaluate an officially upgrade from 5.4 to 5.6, that would give you support until EOL of EL7.
Or, how about you just use SCLs .. that is what they are for:
http://mirror.centos.org/centos/7/sclo/x86_64/rh/rh-php56/
Or even
http://mirror.centos.org/centos/7/sclo/x86_64/rh/rh-php70/
See:
https://wiki.centos.org/SpecialInterestGroup/SCLo
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Am 2017-09-19 09:36, schrieb Nicolas Kovacs:
Hi,
I'm currently experimenting with OwnCloud and Nextcloud on a sandbox CentOS 7 server. I've been using OwnCloud for the last two years for my own purposes on a Slackware server, and I'm quite happy with it.
In my humble opinion, every admin who wants to host OwnCloud or Nextcloud on a RHEL/CentOS server is confronted with a version dilemma.
- CentOS 7 sports PHP 5.4, which has been officially EOL for quite
some time, but Red Hat will provide security update backports until 2024. Which is fine.
- Currently supported versions of Nextcloud (namely the 11.x and 12.x
branch) require a minimum of PHP 5.6. Which seems reasonable. But if I pull in PHP 5.6 from Webtatic, for example, I only get the "official" PHP support, which will end in 2018 for the 5.6 branch. And no security backports.
- The solution would be to go with Nextcloud 10, which only requires
PHP 5.4, and which is also provided in package form by EPEL. 'yum info nextcloud' shows that the current EPEL version is 10.0.4... but a peek on the Nextcloud homepage shows me that this version is officially unsupported. Uh oh.
- Some of the stuff I'm hosting on my CentOS 7 server (like CMSMS) is
not compatible with PHP 7.x versions.
So right now I don't see a solution for this. As far as I can see, the "least evil" solution would be to pull in PHP 5.6 from Webtatic and go for Nextcloud 11.x, and have an EOL for both around next summer.
I'd be curious if some of you are familiar with this sort of dilemma (I guess so) and how you manage it.
I'm not familiar with running PHP on CentOS at all.
IMO, the default PHP-RPMs are not designed to be used for anything as dynamic as Own or NextCloud (or just about any other PHP project that isn't already dead).
PHP has a completely different release-model than RHEL.
As such, the version of PHP that comes with RHEL will almost always be outdated.
RedHat knows this and it seems it's available via SCL (Software Collections).
There's this KB article about it:
https://access.redhat.com/solutions/2146821
The gist of this is:
"Resolution PHP v7.0 is available , however PHP v7.1 is still not available. We are already tracking this in a Feature Request to include rh-php-71 under Bug 1435193. PHP v7.0 was first made available for RHEL 6 & RHEL 7 via Red Hat Software Collections (RHSCL) v2.3 as the rh-php70 collection RHEA-2016:2730 - Product Enhancement Advisory"
https://www.softwarecollections.org/en/scls/rhscl/rh-php70/
With PHP, I try to stay as close to upstream as possible. If upstream EOLs a version, it's time to upgrade.
If you want something stable, don't run PHP.
On Tue, Sep 19, 2017 at 07:59:00PM +0200, rainer@ultra-secure.de wrote:
With PHP, I try to stay as close to upstream as possible. If upstream EOLs a version, it's time to upgrade.
If you want something stable, don't run PHP.
Unfortunately, with that philosophy but not much systems management experience, you end up with custom-compiled and local installs of PHP that get no security updates, particularly as you get version lock-in by the web application developers, or when you have a sysadmin move on to a new position or company.
I think the statement "If you want something stable, don't run PHP" is a very wise statement though.
Unfortunately the same can be said about Ruby, RoR, Python etc etc etc.
Personally I think it's perfectly reasonable to track Nextcloud upgrades combined with SCL major upgrades once every couple of years.
Check life times here: https://access.redhat.com/support/policy/updates/rhscl
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Jonathan Billings" billings@negate.org To: "CentOS mailing list" centos@centos.org Sent: Tuesday, 19 September, 2017 19:06:55 Subject: Re: [CentOS] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
On Tue, Sep 19, 2017 at 07:59:00PM +0200, rainer@ultra-secure.de wrote:
With PHP, I try to stay as close to upstream as possible. If upstream EOLs a version, it's time to upgrade.
If you want something stable, don't run PHP.
Unfortunately, with that philosophy but not much systems management experience, you end up with custom-compiled and local installs of PHP that get no security updates, particularly as you get version lock-in by the web application developers, or when you have a sysadmin move on to a new position or company.
I think the statement "If you want something stable, don't run PHP" is a very wise statement though.
-- Jonathan Billings billings@negate.org _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, September 19, 2017 1:42 pm, Nux! wrote:
Unfortunately the same can be said about Ruby, RoR, Python etc etc etc.
It is not as much true about languages themselves (though it is true, and I for one call python "sneaky snake" just because of that ;-), as about how the software using these languages is written. E.g. well known mailman. I never had it give me any trouble wherever I have/had it installed, even though it is written in "sneaky snake" (python). This is example of brilliantly written software! So, all these incompatibilities and upgrade trouble, or rather absence of thereof, is about how well the programmers have written their code. Namely, whether they use only fundamental abilities of the language which are unlikely to change for long time, or chase after one day fancy features that tend to evaporate quickly, or get transformed soon.
I probably should have put "rant" tags... or maybe shouldn't.
Valeri
Personally I think it's perfectly reasonable to track Nextcloud upgrades combined with SCL major upgrades once every couple of years.
Check life times here: https://access.redhat.com/support/policy/updates/rhscl
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Jonathan Billings" billings@negate.org To: "CentOS mailing list" centos@centos.org Sent: Tuesday, 19 September, 2017 19:06:55 Subject: Re: [CentOS] CentOS, PHP & OwnCloud/Nextcloud: the version dilemma
On Tue, Sep 19, 2017 at 07:59:00PM +0200, rainer@ultra-secure.de wrote:
With PHP, I try to stay as close to upstream as possible. If upstream EOLs a version, it's time to upgrade.
If you want something stable, don't run PHP.
Unfortunately, with that philosophy but not much systems management experience, you end up with custom-compiled and local installs of PHP that get no security updates, particularly as you get version lock-in by the web application developers, or when you have a sysadmin move on to a new position or company.
I think the statement "If you want something stable, don't run PHP" is a very wise statement though.
-- Jonathan Billings billings@negate.org _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Tue, September 19, 2017 1:42 pm, Nux! wrote:
Unfortunately the same can be said about Ruby, RoR, Python etc etc etc.
It is not as much true about languages themselves (though it is true, and I for one call python "sneaky snake" just because of that ;-), as about
<snip> Yeah, in addition to my reaction to "you're using *whitespace* as a syntax element?!", I had an early dislike of python, when each new sub-release broke things that had worked in the previous.
mark
On 19 September 2017 at 21:15, m.roth@5-cent.us wrote:
Valeri Galtsev wrote:
On Tue, September 19, 2017 1:42 pm, Nux! wrote:
Unfortunately the same can be said about Ruby, RoR, Python etc etc etc.
It is not as much true about languages themselves (though it is true, and I for one call python "sneaky snake" just because of that ;-), as about
<snip> Yeah, in addition to my reaction to "you're using *whitespace* as a syntax element?!", I had an early dislike of python, when each new sub-release broke things that had worked in the previous.
For what it's worth at this time I'd use one of the PHP7 options with the upstream
https://www.hogarthuk.com/?q=node/15
Getting the owncloud and nextcloud EPEL packages updated are on my to-do list, but family and work matters have limited my time in the recent months.
The EPEL versions cannot go to the latest though due to the minimum PHP version jump.
At this point I'd recommend you use the upstream archive (just untar/unzip it) and the most recent PHP in either IUS, remi or SCL (depending which repo you feel more comfortable with ... see my article for the differences but they are all trustworthy).
James
Straying OT ...
On Tue, September 19, 2017 1:42 pm, Nux! wrote:
Unfortunately the same can be said about Ruby, RoR, Python etc etc etc.
It is not as much true about languages themselves (though it is true, and I for one call python "sneaky snake" just because of that ;-), as about
<snip> Yeah, in addition to my reaction to "you're using *whitespace* as a syntax element?!", I had an early dislike of python, when each new sub-release broke things that had worked in the previous.
+1
As a sysadmin/programmer I really detest using indents to denote lexical level. But when I have ever expressed such opinions I am invariably shouted down and told that it makes programming easier and I'm just an elitist nerd. And don't get me started on the incompatible point releases.
P.
On 09/20/17 04:42, Pete Biggs wrote:
Straying OT ...
On Tue, September 19, 2017 1:42 pm, Nux! wrote:
Unfortunately the same can be said about Ruby, RoR, Python etc etc etc.
It is not as much true about languages themselves (though it is true, and I for one call python "sneaky snake" just because of that ;-), as about
<snip> Yeah, in addition to my reaction to "you're using *whitespace* as a syntax element?!", I had an early dislike of python, when each new sub-release broke things that had worked in the previous.
+1
As a sysadmin/programmer I really detest using indents to denote lexical level. But when I have ever expressed such opinions I am invariably shouted down and told that it makes programming easier and I'm just an elitist nerd. And don't get me started on the incompatible point releases.
That's not to say I don't indent ALL THE TIME, it certainly makes it far easier to read - don't let me get started about any HTML editor/word processor, that left justifies *completely* - but that it's a syntactic element, equivalent to semicolon in most other languages, disturbs me.
Enforcing good style by compiler...
mark
Am 2017-09-19 20:06, schrieb Jonathan Billings:
On Tue, Sep 19, 2017 at 07:59:00PM +0200, rainer@ultra-secure.de wrote:
With PHP, I try to stay as close to upstream as possible. If upstream EOLs a version, it's time to upgrade.
If you want something stable, don't run PHP.
Unfortunately, with that philosophy but not much systems management experience, you end up with custom-compiled and local installs of PHP that get no security updates, particularly as you get version lock-in by the web application developers, or when you have a sysadmin move on to a new position or company.
Yep. We've got a lot of those "abandoned" PHP webs that can't be moved because they only run on anything between PHP 4.4 and 5.5
Usually it's Typo3 or so. To move from Typo3 4.3 on PHP 5.3 to PHP 7, you'd have to upgrade to Typo3 6.something on that PHP5.3 host, then move that installation to a PHP 5.5 host, where you could upgrade to Typo3 7 LTS, which you could then move to a PHP 7 host. Obviously, none of the custom extensions and a lot of "hacks" would survive even the first upgrade/move - and thankfully usually everybody is sane enough to even think about doing that.
You'd have to start from scratch, which would cost the customer real money (would have to pay some agency to re-design the website), so it never gets done. This is especially true for customers from the hospitality sector, which are especially stingy for any kind of expenditures. Because, as everybody can see, the website still runs and as such it does not need an upgrade.
I think the statement "If you want something stable, don't run PHP" is a very wise statement though.
PHP is not stable in the same sense as RHEL 7 is stable. On RHEL, it's sort-of stable - but only for a rather small amount of PHP modules. And as such, it's not (IMO) useful for anything but legacy stuff that you can't move or upgrade.