CentOS, PHP & OwnCloud/Nextcloud: The Version Dilemma

Home » CentOS » CentOS, PHP & OwnCloud/Nextcloud: The Version Dilemma
CentOS 20 Comments

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

Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

20 thoughts on - CentOS, PHP & OwnCloud/Nextcloud: The Version Dilemma

  • Le 19/09/2017 à 09:48, Sorin Srbu a écrit :

    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


    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

  • —–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 :

    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

  • 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

    ————————————————————–

  • Am 19.09.2017 um 09:36 schrieb Nicolas Kovacs :

    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.

  • SCL’s support for rh-php56 has ended (April 2018).

    PHP’s official support until 31 Dec 2018.

    SCL’s support until Nov 2019.

    PHP’s official support until 3 Dec 2018.

    So, reasonable.

    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.).

  • Am 2017-09-19 09:36, schrieb Nicolas Kovacs:

    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.

  • 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.

  • Am 2017-09-19 20:06, schrieb Jonathan Billings:

    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.

    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.

  • 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

    ++++++++++++++++++++++++++++++++++++++++
    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:

    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

  • 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 …

    +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.

  • 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

LEAVE A COMMENT