You are here
Good Day - Hope the Christmas holidays are treating everyone well.
Nextcloud has starting yelling at me that my version is EOL and its time to upgrade. I have been putting it off but it seems the day has arrived.
So I am once again asking for your support. Ok, jokes aside.
I'm running TKL 16.1 / Debian 10.
Nextcloud is sitting at ver 23.0.12.
PHP ver 7.3.
So - What are the options?
Upgrading in place I suppose is going to be one option - but there is the issue of just how messy will the system become upgrading Debian, PHP, and Nextcloud (along with everything else). Will I miss something? Weird glitches?
Brand spanking new system (preferably on TKL 18) - nice clean and new setup, no system mess. But then how do I migrate the users and information? The documentation (https://docs.nextcloud.com/server/latest/admin_manual/maintenance/upgrad...) indicates no jumping major versions. So doubtful there is an easy "just use our migration tool to jump everything over!"
Option C - uh. No idea. Bring Your Own Answer (BYOA).
Of these, the upgrade in place seems the only actual answer. But as I like TKL and all it has, how can I upgrade one in-place? What pitfalls should I watch for?
Hi Timmy
Thanks for your kind wishes and apologies on my slow reponse (I was enjoying a little time off over Christmas/New Year). I hope that you had a lovely holidays.
There are 2 main options:
As noted on the relevant doc page we technically don't support the second ("in place") upgrade option as not all of our changes and tweaks are packaged. A system upgraded to a newer Debian release is sort of a hybrid of the old TurnKey release, with a new base OS and newer packages (inc TurnKey ones), but it won't receive any additional new default config tweaks. That's not a show stopper, but it will mean that things may not always work exactly the same on your system as they would in a "proper" TurnKey release. It's Linux so you can do whatever you want and odds are it will work fine plus I'll try to assist regardless, but unless you know your way around Debian really well, I recommend avoiding that option.
As such, I suggest migrating your data with TKLBAM.
Please note that the DB schema for MySQL/MariaDB users changed between v16.x & v17.x. Specifically, what was the mysql.user table is now a view (for backwards compatibility), with the user info now in a different table (I forget the name OTTOMH).
Unfortunately it was a while before I realised and the default TKLBAM (in both v17.x & v18.x) will choke on that. But I have since fixed the issue. For v17.x, the new package needs to be manually downloaded (see the TKLBAM v1.4.3.3 release page for details). All new releases of v18.0 (from here onwards) will include the fixed TKLBAM, but for the existing v18.0 builds (e.g. Nextcloud) you'll need to install it with apt:
The fixed version (on v18.x) is v1.4.6:
root@test ~$ apt policy tklbam tklbam: Installed: 1.4.6 Candidate: 1.4.6 Version table: *** 1.4.6 999 999 http://archive.turnkeylinux.org/debian bookworm/main amd64 Packages 100 /var/lib/dpkg/statusFTR there really isn't any reason why you need to use TKLBAM for that, it just makes it easier. You could do the data migration manually. The bits you'll need are the 'nextcloud' DB and the Nextcloud directory; /var/www/nextcloud (or directories; I forget when we moved the default data dir outside the default webroot? - it should be /var/www/nextcloud-data). After you've replaced the dir(s) and the DB, the only thing you should need to do is update the DB user password to match what's in your Nextcloud config. Rerunning the firstboot script should fix that (although again, it can be done manually if you prefer):
That will also regenerate some other stuff, so all logged in users will be logged out and will need to log back in again (not necessarily a bad thing IMO - but worth noting).
That will migrate your current Nextcloud site and data to the new server, so you'll still need to actually update Nextcloud itself.
My only concern there is that Nextcloud state:
So you'll need to upgrade like this: v23 -> v24 -> v25 -> v26 -> v27. But each of those versions has different PHP requirements (v24 has a minimum requirement of PHP7.4; max of PHP8.1 - but v18.x has PHP8.2). So it may actually be easier to hack on your current server (i.e. installed newer PHP as required) until you get your current install up to date. Then migrate to v18.x once you have a version that supports PHP8.2 (it seems that v26 is the first version to support PHP8.2).
Actually, migrating to v17.2 first might make that a bit easier!? That is already preconfigured to use PHP8.1 (from a trusted third party source - Debian 11/Bullseye only had PHP7.4). Nextcloud v24 supports PHP8.1 and Nextcloud v27 does too so you could do the whole update (to Nextcloud v27) in v17.x if you wanted. And then if you are still keen, you could migrate your data again to v18.x.
Sorry that I don't have better news for you, but hopefully that helps. Whatever you do, take a snapshot and/or a backup of your current server before doing anything (I prefer having both as snapshots are quicker and easier to recover to exactly where you were, but a backup is also really good to have IMO). And take notes along the way. That way if things go pear shaped at any point, you can roll back and get back to where you were relatively quickly and easily. Also, you can then share anything of value with us! :)
Thanks for your kind wishes
I did. No need to apologize; I had figured when I posted that this was already not an easy answer and pasting it on top of the holidays was more about remembering to actually write it while I had the time vs putting it off another week or two. I much prefer an accurate, considered answer a week later than a rushed answer an hour later.
I had forgotten about TurnKey Linux Backup and Migration, as I backup whole VMs via Proxmox Backup Server. To further edify, my network is comprised of a few Proxmox Virtual Environment hypervisors, running mostly TKL VMs. The network is closed from the outside, requiring VPN for access, so I'm not concerned about running for a short while on EOL software while I plan/execute a migration.
I will need to read up on TKLBAM, compose a list of questions, and then return here for further clarification and formulation of a plan of attack. Might take me a week as well.
Glad you were able to enjoy the time off.
Whilst we encourage TKLBAM, it's not neccessary
Just to be clear, whilst we encourage TKLBAM use, you can migrate your data without it. Nextcloud has a doc page noting how you can do a manual backup and I would expect that to work just as well (albeit with a bit more effort).
Good luck with it and please don't hesitate if you have any questions and/or hit any issues.
Resurrection Time
Hope you are having a good 4th Jeremy!
I'm trying to move through this migration update - on stage one - the jump to 17.2.
Diagnosing an Internal Server Error problem.
I'm seeing an error that is preventing access to mariadb when I directed the php logging to syslog.
"[Warning] Access denied for user 'nextcloud'@'localhost' (using password: YES)"
I've tried looking around but my search results are polluted with a host of mariadb problems that have nothing to do with our setup here. How can I resolve this?
bump
My deepest apologies for such a ridiculously slow response...
I really dropped the ball on this one! I really value your contributions and this is certainly no way of showing that to you! :(
So for what it's worth, my deepest apologies for such a ridiculously slow response... TBH I'm not sure how I missed this!? Especially with your (very gentle) bump(s)?! A colleague who has just started helping out with support bought your unanswered questions to my attention. So while I'm sure it's little consolation to you, big thanks to her!
I suspect that at this crazy late stage you've already resolved it. Regardless, I'll answer, just in case it's still an issue or you hit it again some other time. And/or it might be useful for others in the future.
On face value my guess is that for some reason the NC DB user password has got out of sync with the DB password in the Nextcloud conf.
TBH, I'm not sure what would have happened to get them out of sync, but I'm almost certain that's the issue. Given the error message, I'm pretty sure that the DB is still running, but that's probably the easiest thing to check first, so you may as well:
Near the top of the output, look for the line that starts "Active". If it says anything other than "active (running)" try starting it (otherwise skip down to the next section):
And recheck the status.
If it is now "active (running)", then retry accessing NC. If it still isn't restart Apache (it shouldn't need it but just in case):
If the DB refuses to start or stops again soon after, you'll need to troubleshoot why. Assuming that you are checking within 10 minutes of running the DB start command above (if not, rerun it):
Unless there is something obvious that you can address, post back with the journal output and I'll do my best to respond much faster this time...
Back to my suspicion of NC DB user and NC conf problem, there are a number of ways to do that. Off the top of my head I can think of 3. They should all be just as effective as one another and I recommend only trying one of them. But they should all be idempotent so it shouldn't matter if you try another.
As per always, when making any changes like this you should have a backup. If you are restoring a TKLBAM backup, then you should be good there, otherwise do a manual backup (unless you like living dangerously...). I also recommend just backing up the config file as that will be the only thing of consequence that will be changed and make winding that back super quick and easy. I.e.:
Then here are the 3 fixes - in descending order of both ease & and amount of system changes:
Regen all NC secrets
As noted above, this will regenerate ALL secrets and will invalidate all existing sessions. I wouldn't expect it to have any negative consequence, but if it does, just restore the conf file backup (copy it back) and try another
Just regenerate the NC DB user pass and sync with NC conf using the TKL "mysql" password firstboot script.
This does what the above firstboot script does, but only the DB related bit.
Manually reset NC DB use password to match NC conf
Copy the DB password from the NC conf file (/var/www/nextcloud/config/config.php). The password will be between (IIRC single) quotes. I'm not 100% sure of the format, but the line should look (or at least include) something like this:
If your DB is configured with "socket authentication" running the command below as root won't require a password. If it's using password auth for root then you'll need to include the '--password=' switch in the command below. I.e. before the bit in double quotes, add '--password="YOUR_ROOT_DB_PASSWORD"' (without single quotes):
Hopefully you should be all good now.
You're ALIVE!
Oh, and thanks to the new helper!
Add new comment