You are here
I upgraded linux version of V15.x appliance to buster.
turnkey-version returns turnkey-wordpress-15.2-stretch-amd64
apt-get update returns following
Reading package lists... Done
W: GPG error: http://archive.turnkeylinux.org/debian buster-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9F3DF15B48406D14
E: The repository 'http://archive.turnkeylinux.org/debian buster-security Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: GPG error: http://archive.turnkeylinux.org/debian buster Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 1C7082DDE779614F
E: The repository 'http://archive.turnkeylinux.org/debian buster Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
How do I update any turnkey specific packages so that turnkey-version is uptodate?
We've rotated our keys, you need to get the latest key(s)
Firstly, the output of "turnkey-version" comes from the file /etc/turnkey_version. So if you wish to change what that outputs, then you can edit that file to whatever you like. Although considering that we've changed quite a bit in v16.x (and not all of it is packaged) changing your server version to '16.0' would not quite be correct. Really your server IS 'turnkey-wordpress-15.2-stretch-amd64' but with the underlying OS upgraded to Buster.
So if you truly want WordPress v16.0, then you'll need to migrate your WordPress data to a v16.0 WordPress server...
As per above, whilst it is possible to upgrade the base OS, and that will give you a hybrid of TurnKey and Debian, that's not where we put our energy. We do very little testing of Debian upgrades. We're big fans of the model of "treat VMs like cattle rather than pets". So we focus out energy on users migrating data from one version to the next, rather than upgrading the server itself (obviously there's nothing wrong with doing updates). In a perfect world, we might package our keys, so that the upgrade is a bit easier, and we may well do that at some point, but unfortunately ATM that's not how it is.
So regarding the new keys, as of v16.0 we've moved to a "best practice" of storing the keys outside of /etc/apt (they're now in /usr/share/keyrings) and also specifying the key within the relevant source.list lines. So you have 2 choices. Either the easy path and just add the missing keys to your current setup. Or update to the way we do things now, either via migrating your data, or via re-implementing the changes we've made in your server.
If you want to take the easy path and just get it working (and disregard "best practice" and the changes we've made in v16.x) then you can just import the keys like this:
If you want to follow our lead, but don't want to migrate your data to a new v16.0 server, then unfortunately for now, you'll need to inspect the build code yourself. I'm sorry that I don't have the time and/or energy to double check how we set it up and explain how to recreate the work that we put into v16.0.
Add new comment