On the roadmap: deprecation of PHP 7.4

In most cases it works fine, but when documenting it here as general solution for Debian Bullseye admins (as we thought about above), also 1% broken systems are a problem, respectively readers of the guide would need to be made aware of the implications.

Are you currently using PHP 8.0 or 8.1, e.g. because you are using Nextcloud 25? Then

apt install phpmyadmin

and see for yourself. Or (in general) you are a Debian Buster user and this summer it will be removed from the repo (it supports only ā€œstableā€ and ā€œoldstableā€, not ā€œoldoldstableā€), or you want to switch to Bookworm now, which is not (yet) supported by the repo. Or you install packages/software which require a specific (or max) version of either libssl/openssl/libgd/libpcre/libsodium/libidn/libxml/libzip/libzstd/ā€¦ shipped by your Debian repo while Ondrejā€™s repos ships (and the PHP packages depend on) newer versions. Or some ARMv6 RPi admin is following the guide and makes the system unbootable that way (yes it is!). Just some of the issues we were faced with.

Trust me, we installed the repo for some tenth of thousands of admin, and we got, I didnā€™t count, but let it be 100 related bug reports/support requests (less than 1%) for our ~1.5 man spare time support team, and by chance found some also on other forums, like Pi-hole and also here (if I remember right), usually since admins found a too new PHP version after apt upgrade on their system which broke the PHP applications or at least their CLI (depending on how sockets were configured). And those were only the ones who were not able to solve it by themselves or were not aware of the underlying issue. And of course, who needs to read instructions to install a newer PHP version than offered by Debian, is more likely not able to solve issues without help. So keep in mind the audience we would write the guide for.

I donā€™t use phpMyAdmin, so no idea if the Sury repos are going to cause issues with it.

So far, Iā€™m only running a test instance on Debian 11, because Iā€™m planing to migrate from Ubuntu to Debian once Bookworm got releasedā€¦

My production instance is still on Ubuntu 20.04. Iā€™m running the same instance (in a VM) since I started with Nextcloud (Probably with NC13 or 14). It has since been upgraded from Ubuntu 18.04 to 20.04, and it survived several MariaDB and PHP upgrades. Both from the third party repos of MariaDB and Sury respectively.

However, I donā€™t do PHP ā€œupgradesā€, I usually reinstall it. If everything is documented, this does take less than 15 minutes including configuration. Btw. my documentation is heavily based on Carsten Riegerā€™s guide, with slight adjustments.

This happened once to me, and I just re-installed the correct version.

Yes of course, I can only speak from my own experience. But issues like that can also come up if you are using the packages from the Debian or Ubuntu repos, especially if you are hosting multiple sites with different applications on the same machine / LAMP stack. I guess, these dependency issues are one of the main reasons why Docker, or containers in general, got so popularā€¦ :wink:

As mentioned, in most particular cases it works well, and admins with some experience are able to deal with mentioned issues or avoid them in the first place. But you are not among the target audience of such a guide (you do not need it) and Iā€™m talking about a risk that a statistically small, but absolutely still large number admins/systems running into mentioned issues without the knowledge or self-documentation practice to solve it quickly, if we have some HowTo/guide promoted here.

No, if you run the applications on the PHP version shipped by the official Debian/Ubuntu version, such can never happen (on a ā€œstableā€ and older Debian and LTS Ubuntu). Package software versions are fixed, only bug and security patches are backported and compatibility between packages is moreless guaranteed, especially when its about such basic widely used frameworks/runtimes/libraries like PHP.

I can see what you mean, and I tend to agree. Nextcloud should probably wait one more release until they ultimately deprecate support for PHP 7.4.

On the other hand, for people who donā€™t want to bother with such things, there are various alternatives available, like Nextcloud-AIO or the official Docker images, which I think are better suited for most home users anyways.

This doesnā€™t help people who now have a bare metal install now, data, database and config migration to those appliances isnā€™t always trivial, and they have various limitations as well, especially being not fully configurable, and the container engine brings further resource needs, complexity and inherently risks, like our Discourse broke down for a few minutes yesterday night after an upgrade because of: Daemon cannot start containers without apparmor Ā· Issue #44900 Ā· moby/moby Ā· GitHub
Someone with limited experience to diagnose service startup issues, search for the right keywords or like me just tries apt install apparmor according to the error log, may be stuck for a longer time.

I donā€™t think that PHP 7.4 support can be re-enabled easily now, NC26 is in beta already, and reasonably from developer perspective the motivation is absolutely minimal. So I write this more to make you guys aware form end user perspective and about possible issues and topics like this (saw just now) to come up.

Letā€™s look and solve this forward. Iā€™ll use the weekend to write some HowTo about the matter.

Yeah sure, but for home users e.g. Nextcloud-AIO is perfectly fine as it is. They usually donā€™t need to tweak much. And yes youā€™re of course right, if you already using it on bare metal, itā€™s not easy to migarte, especially if youā€™re just a home user, without an IT background, that copy & pasted the commands from some random guideā€¦

Sorry but the guy in the other thread, is a bad example. Heā€™s talking about enterprises that donā€™t want to install third party repos. My first question would be, why is he using Debian instead of one of the recommend distributions like RHEL or Ubuntu in an enterprise environment? And why is he using the community edition of Nextcloud? The enterprises I know are all using RHEL, very few are using Ubuntu or Debian, mostly because some appliance requires it, and all of them have support contracts for mission critical software and for their appliances. To me this sounds more like some small business MSP or someone that offers hosted Nextcloud services, without thinking everything through before he started. Or maybe he is just a home / small business user who thought his statement would carry more weight if the word Enterprise is included. :wink:

1 Like

Installing from repo is the way on Bullseye

This is exactly what you are expected to do when running Debian stable. :person_shrugging:

1 Like

Yes, you are right, sorry didnā€™t want to open to can of worms on this issue :smile:. However, more emotionally than rationally driven issues will appear, so good to have something at hand to link and close the pointless discussion :smile:.

Installing what from which repo?

Read what I wrote about potential issues when using it. So I clearly disagree that this is what one is ā€œexpected to doā€ as an unconditional general recommendation. Upgrading to Debian Bookworm with the little Nextcloud 25 hack I posted above is what, based on my experience, will cause admins less issues. But of course, highly depends on the system setup, other used software, admin knowledge/experience, finally personal preference.

I read what you wrote, but the point of Debian is you are expected to either:

  • Stick with stable branch
  • Pin packages
  • Use repositories
  • Change to Testing branch, which is what Ubuntu bases off of

This is how Debian works. As it is a community distribution, there is no enterprise support available (which is why Ubuntu exists).

Absolutely, running a server is a serious commitment. Same reason I have not upgraded to Bookworm yet, but this discussion of Debian stable is not related to Nextcloud. Sounds like you are running into difficulties, which is perfectly understandable. Like @bb77 pointed out, this is a lot of conflation.

1 Like

Iā€™m not running into difficulties myself, but Iā€™m a developer of a Debian based distro (FLOSS/non-professional/spare time project) which offers a fully scripted bare metal Nextcloud installation, similar to NextcloudPi but with ~200 other software options. We implemented PHP 7.3 via Ondrejā€™s PHP repo on Stretch that time, coincidentally when Nextcloud dropped PHP 7.0 support that time. And from the about 40.000 systems with this setup, we are receiving support requests until today. So we are kind off in the middle of software developers and end users, and I do want to use this experience to give people some more at hand than ā€œthis is your problem, deal with itā€.

I :heart: DietPi. Thanks for working on it @MichaIng! I totally lost the thread of you being related to that project and read this as a series of emotional responses as opposed to an actual discussion. Re-opened in the hope there might be a productive discussion beyond what has already been announced and discussed extensively.

Would it be better to have a Diet Pi specific discussion on your forum? Or, can you link to related topics you are hinting at that might add to this discussion. Thanks!

1 Like

I really appreciate your developer efforts and Iā€™m really sorry you hit issues in the past. This doesnā€™t mean you will hit same issues in the futureā€¦ But your intention goes into wrong direction: the problem is not Nextcloud dropping support of PHP 7.4 the problem is Debian stable ships EOL/EOS PHP version. Stability is the key of Debian philosophy and for this reason this is very valuable and maybe most widely used distroā€¦ IMHO the problem is better addressed there. Packages related to security and exposed to public must be somewhat currentā€¦ nobody can seriously expect new applications to run ran on 3y old librariesā€¦

supporting very very old libraries requires additional effort from application developers:

  • if you keep supporting PHP 7.4 you remain limited to 7.4 feature set
  • you canā€™t use improved language constructs introduced in later versions
  • you need more testing
  • and again security suffers
    (donā€™t tell about backports - as mentioned earlier backports are far from complete)

The only problem I can see on Nextcloud side - there is no good supply chain management. At this time we should talk about PHP 8.0 deprecation. NC26 will be the last version which is completely covered by PHP8.0 security supportā€¦ NC27 must remove PHP 8.0 alreadyā€¦

Just to clarify my position - in my eyes ā€œsupportā€ doesnā€™t mean the application doesnā€™t run on this library - itā€™s more like ā€œthe project doesnā€™t careā€ - like no tests, no bug reports etcā€¦ if somebody want to use it - do it your own risk. If it doesnā€™t run feel free to ship some backports but donā€™t blame the project if something brakes with old libraryā€¦

1 Like

You misunderstood my intention: I do not want to discuss here whether Debian policies are right or wrong. Those are long standing for decades and wonā€™t change. Iā€™m looking only from the end user perspective here, which do now have the issue, regardless what we think about Debian or how reasonable the decision to drop PHP 7.4 was.

Instead:

Iā€™ll ping you guys for a review, in case you use/used/administered Debian anyway.

We have this long solved for our users, they wonā€™t face any issues and are also taken by hand with a script for an upgrade to Bookworm. This is for non-DietPi Debian Bullseye users :wink:.

No support in fact means that Nextcloud is denying to be accessed, neither via web interface, nor via CLI, which is the only reason why a transition version with PHP 7.4 + 8.2 support would have been helpful: On the roadmap: deprecation of PHP 7.4 - #27 by MichaIng

Itā€™s only about documenting and promoting solutions for admin here, who are stuck because of this, including the risks/pitfalls of each.

:sunglasses:

you spot the problem very good. The root cause of this gap is Nextcloud dropped support for 7.4 too lateā€¦ and this my most important point all the time - deprecation of dependencies must be announced early enough to make the admins and maintainers aware of the upcoming changes and look for solutions. It would not have solved the ā€œDebian issueā€ jumping from 7.4 to 8.2 but admins would have been forced to find solutions and add 8.0 or 8.1 to their running Debian stable. As we have 3 major actors with different goals and lifecycles the might be no good solution for everybodyā€¦

If announcing it early to give admins sufficient time is important, how can dropping support earlier than be right at the same time? The time between announcement and dropping support is important, and if this is too short, either announcing it earlier, or dropping support later would address this :smile:. However, I think it was announced sufficiently early in November last year. Given how long Nextcloud versions are supported, even for professional environments without support contract, it should be sufficient time to find a solution without every staying on an EOL Nextcloud version. Leaning about options, their implications and which suites best for the individual case, is what I want to help with.

Having some clear policy about supported PHP versions so that we can know now at what date PHP 8.0 and PHP 8.1 will stop being supported by Nextcloud (given ending support from PHP side is known), is still a good idea.

Btw, I think the issue with Debian stable is a one time case with this release. Debian always starts freezing states at the beginning of the year and a new PHP version is always released at the end of the year. Ondrej (Debian PHP package maintainer) actually wanted to merge PHP 8.0 into Debian Bullseye, but he was a little too late merging it into unstable to go through the regular process for the release team to accept. All other packages need to adapt their dependencies (always a two step transition process on both ends), all needs to be tested a while in unstable etc. Ondrej learned from this which is the reason why PHP 8.2 now is in Debian Bookworm. So in two years Debian stable wonā€™t have an unsupported PHP version and ā€œjumpā€ will be smaller from PHP 8.2 to 8.4. If schedules stay the same, this stays true for future Debian releases as well :slightly_smiling_face:.

4 Likes

I wrote a HowTo about how to upgrade to Nextcloud 26 on Debian Bullseye, using either Ondrejā€™s PHP repository or upgrading the system to Bookworm: HowTo: Upgrade to Nextcloud 26 on Debian Bullseye

Everyone is invited to give feedback, in the hope we have something helpful to give admins at hand who have not so much experience. I aim to collect and update it with solutions for possible issues and maintain it as (community) support thread for the process as well.

11 Likes

Thank you so much @MichaIng , Iā€™m sure this is gonna be helpful for many. I added your work to the first post

3 Likes

Thank you so much! You saved the day!

closing the topic as php74 support finaly ended!