Witzker's picture

Hi, there is a system hint in overview:

I intend to try out The App Custom menu

Requirements:

  • PHP >= 8.0
  • App theming enabled

So Pls. let me know How to update to PHP 8.0

I'm not very clever in this server stuff, so Pls. tell me a simple method to update.

Is it somehow possible to this in webmin?

I tried to update on another Nextcloud instance with different descriptions but failed all times with lot of trouble, so I gave up and is ruined now!

I don't want to ruin my new Nextcloud now by doing something wrong!

Pls. Help

THX

Forum: 
Jeremy Davis's picture

Firstly, if you'd like to fix the broken one, please share some more info. It's almost certainly a fairly easy fix, but I'll need to understand the nature of the issue. The most likely problem is a missing module and/or or the wrong Apache PHP module being enabled. So if you want to fix it, please do share some more info.

Either way, you'll need to use the CLI (so not Webmin). I always recommend using SSH.

Also, I always suggest creating a backup before you make any changes like this - especially on a server that has data, so worst case you don't lose anything. Personally I usually like to also take a snapshot as that makes rolling back that particular server easier. In fact if it's a production server, I'll often take a snapshot, restore that to a new server and test on that (documenting as I go - so I can replay later) before attempting on the production server.

An alternate , albeit subpar option is to just fire up a new instance of whatever appliance (e.g. in this case Nextcloud) and do a quick test on that. You do need to be mindful that there may be edge cases where it works differently on a fresh instance vs an existing one (e.g. if the versions aren't exactly the same, have different configurations, etc) but it can be a "quick and dirty" test with minimal impact if it fails.

As to the "how to", development of a tool to make this super simple command has been on my backlog for a while, unfortunately, I still haven't got to it. The general process has been discussed multiple times here on the forums, so really I probably should post a canonical blog post "how to" - so there is a primary source. I haven't compared all my comments, but I suspect that I've given slightly different commands to run in different posts. Until then, you'll need to rely on what I've posted elsewhere. If you can provide feedback and we troubleshoot any issues together, perhaps we can develop the body of an authoritative blog post? Whilst I'm not sure there'll be any specific threads covering exactly what you want to do, (i.e. upgrading from a specific version to a specific version) may not be the covered, the general process is more-or-less unchanged for many years now.

From a quick glance, I think that this post might be the best one? (It appears to be the newest at least). As I said, there are others though; here, here and/or (by a community member some time ago) here (they all should get you close, if not all the way - you should be able to substitute PHP version). There are also numerous other threads where issues are discussed, so your issue may already be covered (no problem if you don't find it, but might save you having to wait for me).

My final word is that unless you have a need not to, I'd recommend only upgrading to the the latest stable PHP release (i.e. currently 8.1). It is possible to use older versions (e.g. 8.0), but it's more likely that things will "just work" if you go with the latest. It will also likely allow easier major version update in the future.

Hopefully that get's you started at least.

Witzker's picture

@  I think that this post might be the best one? 

Pls. Excuse me but if you read this it is exactly concerning what I wrote above!

This realy could'nt be you serious solution!

Pls. Remember your URL "TURNKEY"

This is nothing else as disaster!

So Stop!

How can we get a Turnkey script where user can choose their desired PHP version by simply choosing.?

Like you have e.g on a managed Webspace

Jeremy Davis's picture

Wow, I must say that I'm a bit surprised by your attitude. You've been around for a while and I am quite shocked by your demanding tone. Did you forget that TurnKey is an open source project, essentially a gift? Is this how you act when you are given a gift that isn't exactly to your specifications? If so, it must have been fun at your place over Christmas...

Look I get that it can be frustrating when the pieces you have don't all fit together nicely out of the box (welcome to my world - it's about 90% of my job). Regardless, I work my butt off for TurnKey because I love it and I care about the community we have here and I want to assist people to solve their problems. I want to make simple things easy and hard things possible. I get that TurnKey is not perfect and I agree, it would be wonderful if I could click my fingers and make it work how you wanted. I think everybody would be super happy with that, me included. But unfortunately, that's not how the world works. Just like you can't click your fingers and make it work, neither can I!

We have spent lots of time and effort crafting facility to include newer PHP for appliances that explicitly need it, but it has associated costs (e.g. you lose automated security updates for PHP) so it's a trade off that needs careful consideration (and one that I'm not super happy about TBH). So we don't use that unless we really need to. And as you've noticed, despite clear instructions that consistently work fine for me on a clean appliance, adding that functionality to an existing appliance can be problematic.

As I noted, I have spent tons of time on this issue already and it's documented numerous times. All of them should work, but as you can see (and demonstrated by your experience) there are edge cases and perhaps some details not spelled out as clearly as they should be. I was asking for your assistance to improve the situation! But it seems you're not interested in assisting, even to help yourself!?

In other news, since you've posted this, you'll be pleased to hear that I've spent about 35 hours of my "holidays" working on the tool I've mentioned to try to make it easier to install/change PHP versions. It's getting close, but I still have more work to do. My guess is that I'm perhaps half way. Now I'm back at work, with all the other priorities and distractions (such as trying to help people such as yourself) I'm not sure when I'll have time to finish it.

The irony is that if you'd take a couple of minutes to explain what your specific problem was, then like I said, I'm almost certain that it would have been an easy fix and you would have been up and running last week. I was more than happy to take the time to help you, but I need you to help me to help you!

If you care to show a little humility, re-read my previous post and try again, I'm still more than willing to assist you. If you feel that your previous post was ok and are expecting me to do it all for you, then I guess TurnKey probably isn't for you.

In specific response to your last bit:

How can we get a Turnkey script where the user can choose their desired PHP version by simply choosing?

Other than waiting for me to write it, I'm not sure? I'm not aware of any publicly available tool (not even a non-open source one) that does what you want; hence the need for me to write it. It doesn't sound like you are aware of one either, but if you are, please do share as it would save me a ton of time and effort.

I have the same over at my end running a fully updated TK nextcloud.

"You are currently running PHP 7.4.33. Upgrade your PHP version to take advantage of performance and security updates provided by the PHP Group ↗ as soon as your distribution supports it."

I don't think this issue is TK related though. More of a nextcloud thing.

It looks like php 8 does not even work yet on debian as far as i could tell from here.

https://help.nextcloud.com/t/php8-2-with-nextcloud-25-0-2/151769

 

Jeremy Davis's picture

AFAIK Nextcloud works fine with PHP8.1 but by default TurnKey v17.x (based on Debian 11/Bullseye) only includes PHP 7.4.

It is possible to install alternate versions of PHP (8.0, 8.1 or 8.2), but there are tradeoffs. As soon as you install an alternate PHP version, you loose the auto security updates and the stability provided by Debian PHP packaging (security fixes are backported to the system default version, without bumping the PHP version). This means that functionality should generally never change for the life of your server, but the security issues are patched. Whilst PHP minor updates seem to be pretty reasonable, there isn't the same guarantee of stability between different version of PHP from upstream. So once you atre using an alternate PHP version, it is on you to manually install the updates as they become available (i.e. via 'apt') and there is a chance that some functionality may change with a newer version (generally this shouldn't be an issue if the software is also well maintained - but it can happen).

Unless it is explicitly required (by the software itself - or perhaps via a third party module you are using) then IMO you are much better served by sticking with the default PHP included with the relevant Debian release whenever possible.

Witzker's picture

@Wow, I must say that I'm a bit surprised by your attitude. You've been around for a while and I am quite shocked by your demanding tone.

As I'm fare fare away to be any kind of expert on this matter, I'm more a use who wants to get independent of sharing data to the well known companies ...

I'm trying to understand all this server stuff to be able to self-host as much application as possible.

So I understud from Nextcloud to go to PHP8.

I also see that apps that are further developed switch to PHP 8.0 or 8.1.

I have also still a Nextcloud at my webspace at IONOS and want to host it asap on my own little server.

When I want to change PHP version on IONOS I simply goto the control center -> PHP -> and click PHP8.1

That's it.

So I thought That could not be a big deal.

Therefore, it is totally strange from my point of USER that does not know what behind all this – I asked for the same opportunity on your Debian where I put my Nextcloud on.

As it seems to me that it does not take rocket science to simply switch PHP versions.

Now as told above I found Hundreds of How's to switch To PHP8 on Debian Tremendous Threads on this – which is in my opinion an as Mr. Einstein says: If you cannot exlpan a thing in simple words ...

Witzker's picture

So I cannot edit my previous post!

I'm reading PHP 8 not supported, possibly untrustworthy repo, security problem, settings are lost after update 100ths of instructions with miserably long explanations that sometimes work - trial and error instructions from the fogged glass balls

..... The full quote by Albert Einstein is: "If you can't explain it simply, you don't understand it well enough." This quote emphasizes the importance of not only having knowledge about a subject, but also being able to convey that knowledge in a clear and understandable manner. In other words, if you truly understand something, you should be able to explain it in a simple and concise way that others can easily comprehend.

So, I conclude that Debian is apparently not suitable for hosting modern apps like Nextcloud that are constantly being developed.

Will you further publish your Nextcloud on Debian?

Which Linux will be the right one to install Nextcloud on?

I think if Debian will not provide an Up-to-date PHP version, it will get lost in time, space and meaning! 

This said as a USER !!

PS:

Your APPS were very, very helpful to get at least something running on my tiny server when I started.

I'm sure that I would have given up to try to understand all this server stuff, without your great apps and support.

So what's the future of Debian concerning supporting actual PHP versions?

What do you think?

Jeremy Davis's picture

Sorry, I'm not sure why you can't edit your previous post? It's a bit strange. Although our forums are pretty sub optimal IMO and I hope to move to something better at some point. Unfortunately that's another job on my endless, ever expanding "to do" list...

..... The full quote by Albert Einstein is: "If you can't explain it simply, you don't understand it well enough." This quote emphasizes the importance of not only having knowledge about a subject, but also being able to convey that knowledge in a clear and understandable manner. In other words, if you truly understand something, you should be able to explain it in a simple and concise way that others can easily comprehend.

Whilst I get that there is some grain of truth to the cliche (that was probably never said by Einstein) the simplification of something to a point that it can be explained to someone with no background knowledge, by definition requires avoiding the nuance and reduction of the complexity. I can do that for changing PHP version:

To change PHP version on TurnKey (or Debian or Ubuntu, etc), configure and enable the 3rd party PHP software repository (i.e. place where alternate software and/or software versions are available - somewhat like an "app store"), then install the desired version of PHP. You may need to manually enable the new PHP version before it can be used.

That completely encapsulates the required process assuming no background knowledge and even covers the most common issue. But it doesn't give enough nuance to actually do it yourself. So just like I understand how a nuclear reactor works, that doesn't mean that I have enough understanding that I could build my own!

So, I conclude that Debian is apparently not suitable for hosting modern apps like Nextcloud that are constantly being developed.

It''s not that simple! It seems to me that you are completely missing the nuance and seeing things in very black and white context. That's just not how the world is. A classic example is computer security. Security is not a "on/off" dichotomy as many people seem to think it is. It's a continuum and generally a tension and trade-off between usability and security.

The main thing that "securing" a server involves is shutting down or blocking off services, essentially reducing it's potential functionality. Limiting it's abilities as much as possible, without limiting access to the things you want to do. E.g. if you want to make a server really secure, don't put it online. In fact if you want to make your data really safe, don't allow anyone to access it! Encrypt it onto removable storage and password protect it with a really complex password, and perhaps a key as well, then lock that removable storage in a safe. Data secured! But now it's much harder to access for you as well...

So to bring it back to the specifics, Debian is built for stability first and foremost, with security a very close second. "Latest and greatest" features are the last concern. All the default components (e.g. PHP 7.4) are thoroughly tested not just individually, but within the whole Debian software ecosystem. Debian is built for users who want to spend their time using the system, not maintaining the system; for users who want the software they use today to act exactly the same way it did yesterday. Generally that is what server maintainers want, hence why Debian is considered one of the best distros for use as a server.

FYI when I say stability I'm not just referring to system stability (although you get that too), I mean API/ABI stability - i.e. the way that different software applications can talk to one another. During the Debian testing phase, all the default components are thoroughly tested not just individually, but within the whole Debian software ecosystem. Once released as "stable" any updates to software in a Debian release are only allowed to enter the ecosystem via carefully crafted mechanisms. Security issues are patched by specifically targeted patches that only address the specific security issue, making as few changes as possible. New software versions are only allowed in via a "backports" channel, that is not enabled by default and it not as widely used (and therefore not as widely tested).

That's why whilst PHP 7.4 is technically "end of life" (according to the PHP devs) - it's still maintained in Debian (and Ubuntu, Red Hat and many other industry focused Linux distros). PHP developers don't explicitly maintain the older versions, but they do work with Debian and other Linux distro security teams to assist backporting patches for older versions.

Having said all that, Debian is a "free and open" OS and there is facility to add third party repositories and install external software by a range of different methods. Whether or not those methods apply in the case of Debian is dependent on the resources of the specific external software developers.

Nextcloud (and other non-Debian developers) come from a completely different place, with a completely different set of limitations, motivations, desires and end goals. They generally don't want to dictate to users where their software can be run, they'd rather more people use it. But they also have resource limitations. And by their nature, they target and focus most on the platform(s) used by the largest group of users - regardless of whether that is the "best" platform or not.

Often too, whilst new versions invariably introduce new bugs, they also usually introduce new features. So from a software developers perspective, you often want users to use your new features (and report the new bugs) ASAP - as that will guide future development. Maintaining compatibility with specific (especially older) PHP versions also has tradeoffs (to code complexity and performance). So whilst maintaining older versions is desirable to some degree, it has a cost to developers, one that has reducing returns as the older version continues to age. The smaller the team and more limited the resources, the higher the cost to future development of maintaining older versions, compatible with older versions of platforms such as PHP.

So we have a tension between the features and value of a stable platform like Debian and software that is rapidly changing like Nextcloud.

But that's where 3rd party PHP (as provided by Sury) comes in. It allows you to make compromises to the stability of Debian (which don't negatively affect the existing components too much), whilst maintaining the flexibility required by Nextcloud (and other similar PHP apps). So it's a tradeoff.

Finally, it's worth noting that, despite the warnings in Nextcloud, the latest release (i.e. v26.0.0) is the first that actually requires PHP 8.0 or higher. The current "stable" release (v25.0.5) still runs on PHP 7.4. So strictly speaking, you don't yet need a PHP version higher than 7.4. Regardless, we will be releasing a new Nextcloud appliance with PHP 8.1 and newer Nextcloud within the next week or so. You should be able to migrate your data to that and then you won't even need to install newer PHP yourself.

Despite my crazy long post, I realized that I still didn't explicitly respond some of your points:

Your APPS were very, very helpful to get at least something running on my tiny server when I started. I'm sure that I would have given up to try to understand all this server stuff, without your great apps and support.

Thanks for your kind words. I'm glad that TurnKey has provided you with value and if nothing else, has got you started.

So what's the future of Debian concerning supporting actual PHP versions?

To clarify, they support the versions of PHP that are included.

But I assume that you are referring to Debian supporting a newer version of PHP?! The way that Debian works, the current release; known as Debian 11 and/or Debian Bullseye won't ever receive a newer version of PHP! Once it is released as "stable" that is the version it it includes for the life of the OS, which is: 5 years LTS (long term support) from release date or up to 10 years from release if you are happy to pay for ELTS - extended long term support.

The next release of Debian; v12 and/or Bookworm will be the basis of TurnKey v18.x. It looks like it will have PHP 8.2. Considering that when Bullseye was at a similar point whilst PHP was "frozen" at 7.4, PHP 8.0 was already stable. It will remain to be seen, but I suspect that it will work out much better for TurnKey v18.x/Debian 12/Bookworm. E.g. if Debian 11/Bullseye had PHP 8.0, it wouldn't be quite so bad...

Jeremy Davis's picture

Thanks for posting back. Apologies if my earlier response seemed a bit over the top. The point of it was/is that I spend a ton of time working on TurnKey (more than is probably healthy). We're a small team of committed people who work for very small wages (compared to what we could earn working for big tech companies) so we're making tons of personal sacrifices to do what we love and hopefully help make user's live easier. Your previous message struck me as entitled and demanding and when we're giving so much of ourselves to provide TurnKey - which is available for free - that felt pretty frustrating. I'm assuming that English isn't your first language, so I suspect there may have been some "lost in translation" stuff going on too.

AFAIK whilst PHP 8.1 is recommended (and required for the new "beta" release v26.0.0. FYI looking at the GitHub releases it appears to be "stable", but within Nextcloud it doesn't note it as "an available update" - unless you enable the "Beta" update channel.

AFAIK the newer Nextcloud versions (i.e. v26+) will actually require a newer PHP version than what our v17.x has. There will be an updated Nextcloud applinace released really soon that will include PHP 8.1 out of the box.

When I want to change PHP version on IONOS I simply goto the control center -> PHP -> and click PHP8.1

I know nothing about IONOS but the functionality you speak of didn't just magically appear. The easy ability to change PHP version with the click of a button has been built by someone and likely consists of hundreds of lines of proprietary code. That code was developed by someone and paid for by IONOS; either bought from a third party, or a directly paid contractor or staff member. There is no open source equivalent that I am aware of. If I was aware of one, we would have integrated it already and you and I wouldn't be having this discussion. :)

As I'm sure I've mentioned, I have ideas about how we might be able to provide similar functionality. But that requires that either we pay someone to develop the code, or I have to do it. With our limited resources (and my limited time, due to a ton of competing priorities) an easy way to change PHP versions is just not high enough priority for us to dedicate the required resources. FWIW, I usually work 10+ hours a day already and often dedicate hours of my personal time to work on TurnKey related development and/or problem resolution that I'm interested in, but I can't justify spending "work time" on.

I won't dig in too deep, but hosting platforms that provide "control panels" (like it sounds IONOS does) have another distinct advantage when it comes to this sort of thing. Ultimately they control the server and via a "point and click" control panel, they can limit the things that the end user is able to do. That is both a good and bad thing, depending on your perspective (and depending on whether everything "just works" or not). As you noted, it means you have less control over your data. On the other hand, it also limits the things that you can do wrong and problems that can occur - because what you can do is limited by the UI.

For better or worse, TurnKey does not have that problem. But it does mean that you have control for both good and bad. It makes our life harder (than say IONOS) in many respects, because we have no idea of what you have done or what you might do to your server in the future. FWIW the most common issues we encounter with our custom software, is when a user's system is in a particular state that we hadn't anticipated.

As it seems to me that it does not take rocket science to simply switch PHP versions.

You are absolutely correct, it does not take rocket science to change PHP versions. Even on TurnKey, it's really not that hard (the hard part is creation of a UI that allows it to be done with the click of a button and accounts for a range of possible states). But it does require following instructions and running some commands in a terminal. It's nowhere near a "one click" solution and there are issues that can occur, things that can go wrong (another reason why a simple "one click" UI is hard), but it's really not that hard! I reckon if things go smoothly it would take no more than 10-15 minutes.

I get that using the CLI (command line interface) can seem a little intimidating if you're used to "point and click" GUI (graphical user interface), but once you get over that, a whole new world of awesomeness opens up. Personally, I find CLI much easier, especially for the sort of things on a server. One of the biggest advantages is that it usually provides much better feedback than a GUI. Don't get me wrong, GUIs aren't all bad and I use them for a lot of stuff on my desktop in day to day life. But for managing a server, most software is designed for CLI first, so once you get your head around it, the CLI is much more powerful and not that hard to use and it's much easier to work out what has gone wrong when things don't "just work".

Now as told above I found Hundreds of How's to switch To PHP8 on Debian Tremendous Threads on this – which is in my opinion an as Mr. Einstein says: If you cannot exlpan a thing in simple words ...

I think you've misinterpreted the data available to you and jumped to an incorrect conclusion. Just because there are numerous threads on changing PHP version doesn't in any way suggest that it's a complex procedure. To illustrate my point, google "how to wash your face". Wow, literally thousands of results - including hundreds of step-by-step videos on YouTube! That must mean it's a really complex problem that only an expert can resolve! :)

If you look at the "PHP version changing" threads/tutorials/etc, they are all pretty much the same steps, doing the same thing. There is some nuance to individual threads and comments - e.g. people having specific problems. Perhaps they missed a step and got an unexpected result/error? Perhaps the behavior of something has subtlety changed since the previous version? Perhaps other things they had already tried (but didn't mention when posting) meant the info shared was no longer directly relevant in their scenario (but not obviously so)? But otherwise, they are generally all doing the same thing - as I suspect all the face washing tutorials are!

Part of the reason why there are so many threads here on our forums is that it's a pretty common problem these days (wanting to update PHP version) and instead of reading the existing discussions and documentation; many users just start a new thread (when there are other threads that already exist - essentially what you did).

Answering a new thread such as yours explicitly (i.e. if I had again detailed the steps required - rather than directing to you to existing info), just adds to the issue. Plus it's also incredibly time consuming for me . Whilst the procedure itself is pretty easy, documenting it takes much more time - especially the way I tend to do it...

To be clear, if you hit issues, I'm more than happy to assist. But as per my initial response, the expectation is that you put in a bit of work yourself. If you are not willing to do that, then self hosting is probably not for you. I guarantee that this won't be the first issue you hit, and if you're not willing to roll up your sleeves, have a go and learn about the systems that you will need to maintain, then I anticipate that it's going to cause you endless frustration and pain.

just a few hoops to jump through if your dead set on php 8.2+

 

Debian is perfectly capable to stay relevant as many USERs will understand that sometimes stabilty means not having every shiny new toy available out of the box ;)

Jeremy Davis's picture

FWIW as part of the next (and hopefully final) v17.x release we have just released a new v17.2 Nextcloud appliance. As noted in the "changes", it includes Nextcloud v26.0.0 and PHP 8.1 OOTB (Nextcloud v26.x requires PHP 8.0+).

Witzker's picture

Great THX!!

Where to discuss moving the existing Cloud to the new Server?

Jeremy Davis's picture

You should be able to use TKLBAM.

If you don't want to use TKLBAM, then you can manually migrate your data from your existing server to a new one.

If you have any issues, please start a new thread. Provide as much detail as possible. In particular provide details such as:

  • which resources you are using - e.g. links to docs, blog posts, forum threads, etc.
  • what steps you've taken, including which commands you have run, etc.
  • any exact error messages you see - ideally please post as text, rather than trying to post screenshots (screenshots are good for GUI, text is better for CLI)

Add new comment