Mark's picture


I have a client with the following appliances running on VMware:

lamp - debian 9.13, turnkey-lamp-14.2-jessie-amd64
observium - debian 9.13, turnkey-observium-15.0-stretch-amd64
wordpress - debian 10.7, turnkey-wordpress-16.0-buster-amd64
nextcloud - debian 10.7, turnkey-nextcloud-15.2

They have been neglected due to lack of client Linux skills.

They have asked me to resolve, but when I try to update with apt-get, this fails due to the appliances being so old.

What is my best method to get them to the latest versions?

In-place dist-upgrade, or provision new appliances in parallel, then migrate data over?

Is data migration for these straight-forward?

Thanks in advance.

Jeremy Davis's picture

Hi Mark, welcome to TurnKey!

First up, we're running a bit behind schedule currently, so the latest stable release of all of our appliances is v16.x (based on Debian 10/Buster). We're still working on a newer v17.x (based on current Debian 11/Bullseye) and hopefully that will be available sometime in the coming weeks.

So, whilst some of the appliances you are working with are old, all of them should still successfully be able to update software installed via package management (i.e. 'apt'). So if apt-get update/upgrade/etc is failing, then that is not expected behaviour. Please fell free to share the error messages so that I can assist you to resolve that.

Having said that, it's worth noting that not all software is installed via package management though. So whilst 'apt-get upgrade' will get you part of the way there, it won't update everything. Of the appliances you note, Observium, WordPress and Nextcloud are all installed direct from upstream source code. So that specific software will need to be updated independently. All the software that comprises the LAMP appliance should be upgradeable via apt, although I'm assuming that it is a base for other software.

To see how TurnKey versions relate to default Debian version check the TurnKey version Debian version matrix. So you can see that it looks like the LAMP appliance has already had a Debian "in place" upgrade.

As TurnKey is Debian under the hood, the LTS (and ELTS) is applicable. So updating LAMP and Observium should be considered something of a priority. The other 2 are less urgent as they will continue to be supported by LTS for another few years. Personally, I would wait until we release the v17.0 builds and take care of them then. (FYI, please note that we technically and officially only support the current stable release, but we always give "best effort" support for our products, regardless of age).

TL; DR - anwser your specific question...

As for the actual upgrade pathway (essentially your question...!) either migrating the data or a Debian "in place" upgrade (i.e. dist-upgrade) are valid options. Again, we only officially and technically support data migration, but provide "best effort" support regardless.

Having said that, I would recommend migrating the data. That way you can be assured to get all the other included goodies that have been added (but are not provided via package management). For example, CLI tools (e.g. composer, wp-cli, occ etc) and TurnKey convenience wrapper scripts (runs commands as webserver user; e.g. turnkey-composer, turnkey-wp, turnkey-occ). It also means that you are not carry cruft forward (as you do when you do an in-place upgrade). And perhaps the best point, the existing server can remain as is. Only once everything is working perfectly on the new server do you need to update configs (e.g. DNS mapping) and decommission the old server(s).

Unfortunately, it isn't always super simple, but you can use our built in backup and data migration tool; TKLBAM (linked to our SaaS offering; TurnKey Hub to do some of the heavy lifting.

An overview of the process I would recommend is:

  • link current server to Hub and create backup
  • link new server to the Hub and download backup data
  • selectively restore data
  • test and celebrate! :)

For example, to migrate Nextcloud:

On old server:

tklbam-init YOUR_HUB_API_KEY

(where YOUR_HUB_API_KEY is your actual Hub API key)

Then on the new server:

tklbam-init YOUR_HUB_API_KEY
mkdir -p /tklbam-dump
tklbam-restore BACK_ID --raw-download=/tklbam-dump
tklbam-restore /tklbam-dump --skip-packages --limits="/var/www/nextcloud mysql:nextcloud"

(where YOUR_HUB_API_KEY is your actual Hub API key and BACK_ID is the backup ID of your Nextcloud backup)

The last line above should reset the Nextcloud DB access and also regenerate salts.

Note that all files from your backup are in /tklbam-dump and relative to root ('/'). I.e. if you want to check the old Apache config, have a look at /tklbam-dump/etc/apache/site-available/nextcloud.conf.

As a final word, I recommend that you document everything and leave it in a file in root's home (e.g. /root/readme-migration.txt or similar). Please also feel free to share it with us too!

Any questions, issues, etc - please do not hesitate to ask. I try to respond at least once a day (work days, sometimes weekends too...). Sometimes that slips but if you sign up to the Hub, you'll get hold of me quicker via the support there.

Add new comment