Is someone working on Nextcloud 16 support? I think there might be a problem with Debian Stretch since we will need php version 7.1 or later for Nextcloud 16. Please let me know what you think.

Forum: 
Jeremy Davis's picture

We do intend to build an updated appliance soon(ish) but I don't have a clear ETA. However, it's worth noting that you should be able to update Nextcloud fairly easily as per their docs.

Also, I suspect that you originally wrote a body to your post, but the spam filters blocked it (they can sometimes be a little aggressive and yet still some spammers manage to get through...). So I have tweaked your user account to avoid most of the spam traps.

One thing that got lost in the spam filter: Nextcloud 16 requires at least php7.1, but Debian Stretch is on version 7.0 (EOL 1st of December). That's why you cannot upgrade that easily on Stable.

Jeremy Davis's picture

OK, thanks for the heads up on that! :)

So, that may well delay the release of an updated appliance providing Nextcloud v16.0.

Whilst Debian provide backported security updates for PHP7.0 (so the fact that it's EOL upstream isn't really an issue), many apps have moved on and now require PHP7.1+. Until Debian Buster goes stable (sometime mid year? - will include PHP7.3) we'll likely make do by installing a newer PHP version (most likely PHP7.2) from https://deb.sury.org/. FWIW he's one of the main PHP package maintainers for both Debian and Ubuntu, so we're in good hands there.

My plan is to actually include the deb.sury.org components in all LAMP/LAPP based appliances, but leave it disabled by default (unless required, e.g. by Nextcloud). That would allow other apps (that currently only require PHP7.0) to stick with PHP from stable, but provides an upgrade pathway for apps that will require a newer version in the future. That would make it relatively easy for users to update themselves too if/when required.

That sounds like the ideal way to go. Thanks for the reply.

https://www.c-rieger.de/nextcloud-using-one-shell-script/

It builds on Debian 9 and uses PHP 7.3 from https://packages.sury.org/php/. Maybe that's the easiest way to create a Nextcloud 16 machine with an A+ rating.

Jeremy Davis's picture

Thanks for sharing the link. I'l have a look over the script and see what it does and if they're doing anything we're not (that we think is a good idea), then I'll implement it into our buildcode. I must say that I don't envy him trying to maintain multiple bash scripts totalling ~2500+ lines. That must be a massive pain!

Because we have a library of ~100 appliances and some of the others will need newer PHP too, it makes much more sense for us to maintain our existing buildcode. FWIW the way that our buildtools are set up, all the shared code is in a separate repo. So for example the code to install an alternate version of PHP (we're currently using 7.2, but we might instead go for 7.3) will only need to be written once and multiple appliances can inherit it. There is some stuff in that script you shared (FWIW the actual scripts are here) that I wouldn't do in our appliances, but there is some interesting stuff (like a fix for an issue I wasn't aware of!).

Thanks again for sharing! :)

besttoiletguides's picture

Give me more advice

Jeremy Davis's picture

Just a quick heads up that we are close to releasing an updated v15.2 Nextcloud appliance. That will include PHP7.2 by default and Nextcloud v16.0.1. The new release will also include Redis (one option amongst the new caching requirements for v16.x+)

I'll announce it via a blog post ASAP, although that may be a little delayed. However, as soon as it's available, I'll update the download links on the Nextcloud appliance page. I hope to also post back here too, but just wanted to let you all know it's on the way... :)

In preparation, for those that are already using an earlier release of our Nextcloud appliance, probably the easiest way to migrate an existing Nextcloud to the new appliance will be via TKLBAM. So take a backup of your existing appliance. Then launch a new instance (of the v15.2 app; once released). Then, rather than doing a full tklbam-restore (which will wipe out some of the required config in the v15.2 TKL release), it's better to just restore the Nextcloud app itself (i.e. Nextcloud, it's data and it's DB). To do that (assuming running as root; otherwise prefix commands with 'sudo'):

mkdir /tklbam-dump
tklbam-restore BACKUP_ID --raw-download=/tklbam-dump
tklbam-restore /tklbam-dump --skip-packages --limits="mysql:nextcloud /var/www/nextcloud"

Please note that those instructions assume that you haven't done significant modification/customisation of your server (if you have, you may wish to restore additional filesystem locations via including them in the limits). Also I haven't done a "real world" test of that, but it should be close, if not exactly right.

4ps4all's picture

I tried to migrate Turnkey14.1-nextcloud Proxmox container to a  new Turnkey15.1-nextcloud new Proxmox container using TKLBAM in local.

I didn't have success.

My free tier period with AMAZON is ended, anyway I have a turnkey hub login.

I'm considering to find a way to make amazon work again ,and to link it again to turnkey hub.

Anyway it seems to me more interesting to find a way to use TKLBAM locally with PROXMOX.

I have used the --address and the --dump=DIR options with tklbam with not good results

I disabled 3rd apps in nextcloud and putted nextcloud in maintenance mode before to run tklbam-backup.

TEST 1

source container

tklbam-backup --address file:///mnt/otherdisk/tklbam/backup
tklbam-escrow /mnt/otherdisk/tklbam/keyscp -rp /root/tklbamPROVA/ root@192.168.1.135:/root/

destination container

 tklbam-restore --address file:///root/tklbamPROVA/tklbam --keyfile=/root/tklbamPROVA/key --skip-packages --limits="mysql:nexcloud /var/www/nextcloud"

 

TEST 2

source container

tklbam-backup --dump=/root/tklbam-dump
rsync -avz /root/tlkbam-dump root@YOURIPNUMBER:/root/

destination container

tklbam-restore /root/tklbam-dump --skip-packages --limits="mysql:nextcloud /var/www/nextcloud"

IMO in both cases the problem is the database. impossible to run nextcloud upgrade cause of database, apache errors referred to database too.

I wrote a procedure that seems to work, https://www.turnkeylinux.org/forum/support/tue-20190618-2058/upgrademigr... but it would be better to have Tklbam working in local too.

My first time using tklbam-backup tklbam-restore, any help?

Jeremy Davis's picture

Without knowing the specifics of the errors which you are encountering, I can't really offer much insight. If you could share the specific error message(s) you are seeing (i.e. within the browser, within Nextcloud logs and Apache error log messages too).

My only thought is that perhaps the Nextcloud DB user (or perhaps just user password) doesn't get transferred when only migrating the Nextcloud DB itself. Hopefully the exact error messages should assist me to clarify if that's the issue or not.

Add new comment