You are here
Hi all!
I am currently using the TurnKey NextCloud LXC container and has done so for some time now. I have upgraded NextCloud through its webbased upgrade system, I am currently running NextCloud Hub 9/30.0.2. turnkey-version gives "turnkey-nextcloud-17.2-bullseye-amd64"
This gives me warnings that both MariaDB and PHP are now deprecated.
From time to time, I have logged into the container and also done a apt update/upgrade - this may possibly be counterproductive?
I saw somewhere that there is a turnkey 18 somewhere - how do I upgrade to that version? And will it upgrade MariaDB to 10.6<11.6? and PHP to 8.2/8.3?
Also I am wondering if it would help performance to split the install between solidstate for the OS+Appliance and spinning rust for the data files (the "dropbox" part of NC)?
Oh and then I would like to have my account verified :-)
First up, glad to have you here. :)
First up, great to have you onboard and I'm really glad to hear that TurnKey has been useful to you so far. Thanks too for providing all the info you have, makes it easier for all of us. :)
FWIW both the MariaDB and PHP versions in v17.x will continue to recevie security updates and generally be supported by Debian (the base of TurnKey) for quite some time.
Having said that, Nextcloud tends to move fairly quickly and often stops supporting older versions of dependencies - PHP in particular. So I'm assuming that when you say that they are "deprecated" that is in the context of Nextcloud specifically.
You don't really need to do it as TurnKey auto installs security updates every 24 hours. OTOH it certainly won't (at least shouldn't) do any harm.
But as you've noticed, it doesn't actually give you a newer version of the specific software. It simply pulls in the latest patched release (i.e. bugfixed) of the same version.
Updating/Upgrading TurnKey server appliances
Sorry for the time passed - life has been a bit busy the last few days. And thank You for letting me in :-)
Yes the deprecation of older PHP and MariaDB versions is from the NextCloud Project.
I tried to install a newer version of PHP through webmin (libapache2-mod-php8.3 and then libapache2-mod-php8.2) but I am getting:
The above with php8.3 - same result, different numbers for 8.2.
It seems that apt can stat the packages (and thus estimate the download and disk usage), but cannot locate the packages themselves on the mirror - which is not a standard mirror, as far as I can tell? I have not changed this knowingly.
I might go with the local TLKBAM backup into a new server. When looking at this, I had started to think of alternatives and maybe moving into a VM with split disk solution - SSD-based for the OS and application and HDD-based for the files. I might do this with a new TurnKey LXC container instead of setting up a VM from scratch.
Thank You all for your hard work!
Thanks for the extra info Jan
Thanks for the extra info Jan. BTW I took the liberty of reformatting your post for better readability. Unfortunately we had to disable the WYSIWYG (what you see is what you get) editor we had integrated into the website...
Before I get to what I hope is the solution to your issue, some more context and background re the newer PHP packages. You are correct that they do not come from a "standard mirror". They come from sury.org - rather than the default and primary debian and turnkey apt repos. While being a third party repo, it is a trustworthy source. The deb.sury.org repo is provided and maintained by Ondřej Surý. As he notes on the sury.org website (linked to above):
To your issue: You are definitely on the right track to install a newer PHP version. So good work! :)
And I think the error will be easy to fix. FWIW I think that the resolution is actually hinted in the output you shared - see the last line:
So try running "apt update" (essentially an alias for "apt-get update") before retrying the php8.3 install and it should "just work".
If not, please post back with the "apt update" output.
Actually, if that doesn't fail and the automated security updates haven't been intentionally disabled, that package info should already be updated daily!? If "apt update" works, not installing the secupdates might indicate some other issue? So could you please run "turnkey-install-security-updates" and post the output back here.
FYI, it's probably not important to you (especially if that works) - but here's an outline of the steps I took to confirm the likelihood of that being the issue:
First I tried pinging the domain - which worked, although the IP was different. That's not a surprise because it's provided via a CDN. But pinging the IP from your output (195.181.166.158) was also successful.
I then tried downloading one of the files from your output and confirmed that it did not exist (hence the 404).
Finally I checked the php8.3 directory on sury.org. The current PHP8.3 package versions (hence the filename) for "php8.3-common" is 8.3.14. I.e. "php8.3-common_8.3.14...". The versions that apt ins trying to install for you 8.3.2. Which suggests that your server has outdated package info.
Anyway good luck and hopefully that works.
As I noted above, regardless of whether it works or not, please provided the output of:
Apt signature verification failure
segment, but it apparently was not enough, and I did not have time to investigate further - please share what you did! (Post preview: I cheated and checked the HTML - so used pre tag instead of the code tag I used for the first post :-) I should have shared more, I guess. I have been using debian based distributions for ages, so I had already done an apt upgrade - which I should have included: As you requested the output of Same issue ...So close! :)
No problem at all. Yep "pre" tags are the ones. :)
Sorry I didn't realize that you already had some base Debian(ish) knowledge. I hope I didn't over explain, although I'd rather be more verbose than required, than less. It's hard to judge people's experience and even if it was unrequired info for you, someone else will come across this thread and it might help them...
From the output you've shared it looks like the sury.org key has expired (EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG). As you may have guessed, that's why the apt package list hadn't updated properly and apt install was trying to install outdated packages. It also means that all's good on the auto security updates which is nice.
Hopefully all you should need now is the current key and you'll be good to go. Get the current key like this:
You can just cross your fingers and try again if you want, but one thing worth checking is that the correct sury.org key location is in the relevant apt sources file/line. If my memory serves me correctly, we pre-configured the PHP sury.org apt list - with the required line and correct key path in the file /etc/apt/sources.list.d/php.list. But just in case I'm wrong (maybe we only did that in v18.x?) and it wasn't pre-configured by us and/or the key path doesn't match (and/or something else), have a quick grep:
The result will be "path/to/filename:matching-line". Assuming a PHP apt sources file of /etc/apt/sources.list.d/php.list, the desired result will be:
So long as the file has a '.list' file extension then the filename itself is irrelevant. The important bit is the '[signed-by=/usr/share/keyrings/deb.sury.org-php.gpg]'. I.e. a declaration of the specific key and the correct key path. If it's not there or the path is wrong, edit the relevant file and ensure it's exactly the same as above. (For anyone reading who is not on v17.x/Debian Bullseye - also replace "bullseye" with the relevant Debian codename). If you didn't configure that yourself (i.e. it was us) please let me know if it's not right so I can cross check with our buildcode and fix it if need be.
Once you've confirmed that's right - or you've updated it - you should be good to go. Just re-run the apt commands you already have and things should be golden and everything should "just work".
Assuming that the installation of the newer PHP version succeeds, the installation should automatically update your system to use the new PHP version as the default for both CLI and Apache, but to double check:
If for some reason that doesn't give expected results, assuming php8.3 (adjust if different version) you can try these commands:
Also; just in case you aren't aware, the php config (php.ini) files are version and context specific. The new version will just be the php package defaults. So you may want/need to adjust some values there. For php8.3 the new config files will be:
If you are unsure of which values to change, a diff between the old and new config files might help. E.g assuming 7.4 -> 8.3):
package signatures invalid
I'm 99% that the signed-by keyfile name/path is the issue
I'm 99% that the signed by keyfile name/path in your sources list is the issue.
The "signed-by" path in /etc/apt/sources.list.d/php.list needs to match the file path of the updated key. IIRC I downloaded the debsuryorg-archive-keyring.deb key package and checked the new key name and that is what I shared above. So I'm fairly confident that the difference between your sources.list entry and mine is the issue. Another possibility is that the key file name name changed (or I got it wrong).
Double check that the path I gave before is correct:
It should just return that path. I.e.:
If so, then edit the "signed by" in your sources file to match. I.e.:
If the 'ls' command returns a "No such file or directory" instead, then have a look in the /usr/share/keyrings/ directory:
That will list all the files in the directory, along with their respective details such as their permissions, size and last modified times. The most recent will be at the top. If there is more than one php/sury.org key it should be the higher one. Adjust the "signed-by" path in /etc/apt/sources.list.d/php.list to match and rerun apt update - that should fix it.
Had a further look into this:
Correct PHP version for NextCloud 30.0.4!?!
DISCLAIMER: Please read the full post - there is a plot twist ...
So I ended up installing PHP 8.4 and still NextCloud was complaining. I had forgotten to enable PHP 8.4 in
:Reloaded my NextCloud WebUI - no change - still complaining about running PHP 8.1 - went into
and rebooted the application (through Advanced) - stille no changeBack into
:Aha - php8.1 is still enabled - removed the two symlinks for 8.1:
Rebooted the application through
again. Now Nextcloud WebUI does not even come up but just get a text response back: Nextcloud 30.0.4 does not support PHP >= 8.4So I installed PHP 8.3 - BTW just installing
and likewise for 8.4 did not get me all the php-8.3/4 packages that were present as php-8.1 packages. I do not know if I need them all but decided to just install them all. Too see which php packages you have install do:and then it was time to set PHP 8.3 to be loaded:
And then for the last time: reboot the application through
. For now I have left both PHP 8.1 and 8.4 on the system. To lower my attack-profile as well as shrink the container, I ought to remove both PHP 8.1 and PHP 8.4, but so far they are still present in the system.MariaDB upgrade is next, but it is already late - time for bed - so that will have to be another day
The PHP memory limit is below the recommended value of 512 MB
Memory limit raised to 1G
Well I could really not leave it there ...
Went into both /etc/php/8.3/cli/php.ini and /etc/php/8.3/apache2/php.ini and changed the line
toAgain rebootet the application through confconsole and the error is now gone. But now I have another - Last background job ran more than an hour ago. I am hoping this is due to the memory limit. This time I AM going to bed :-)
Switched back to PHP 8.1 to allow cron jobs to run
Add new comment