When I run sudo apt update I see this:
W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
As it’s only a warning I’m tempted to do nothing, but what do you advise? Thanks.
Hi, it appears to just mean that your gpg keys are not in the right place.
*Recommended:* Instead of placing keys into the /etc/apt/trusted.gpg.d directory, you can place them anywhere on your filesystem by using the Signed-By option in your sources.list and pointing to the filename of the key. See [sources.list(5)](https://manpages.debian.org/testing/apt/sources.list.5.en.html) for details. Since APT 2.4, /etc/apt/keyrings is provided as the recommended location for keys not managed by packages. When using a deb822-style sources.list, and with apt version >= 2.4, the Signed-By option can also be used to include the full ASCII armored keyring directly in the sources.list without an additional file.
However, it is only a recommendation (despite the deprecated apt-key tool) so it’s entirely safe to ignore at the moment. I’m not sure what the correct steps are to suppress this (I’m more of an Arch person) but simply ignoring it shouldn’t cause problems especially if you’re on a LTS release or not bumping your major versions
You could certainly try just clearing the trusted directory (rm -rf /etc/apt/trusted.gpg.d/*) but in my opinion it isn’t worth risking breaking your packages to get rid of a message like this.
A word of caution to anyone visiting this in future, this is not the solution to your problem and improper handling of rm -rf commands can potentially nuke your whole system beyond repair. So please exercise caution.
There is ample documentation available online on how to get rid of the warning about key depreciation, but the issue is not discourse specific so I’ll leave a link and advise reading it twice before blindly executing any commands there.
In my case it arguably is Discourse specific (though not in the way you mean) as I only have the server for a Discourse installation that followed the standard installation instructions.
But I’ll read the link you provided. Thank you.
Though an idiot’s guide would be much appreciated.
Take a full backup, set up a fresh instance of discourse and restore your backup there.
That way you don’t need to mess with anything and in 99% of cases your issue will be gone.
I’d need an idiot’s guide for that too!
For instance, I only learnt recently that a full backup includes not only the backup you get using the Discourse website but also the app.yml file.
If you’re not familiar with a shell, I would recommend downloading the backup off your current site and following standard restore procedure.
However, if you’re even a little comfortable in the shell or don’t want to deal with configuring a temporary site then I would recommend doing a CLI restore.
There are pretty elaborate guides already available for that:
This look simple, thanks. I’d be using a Digital Ocean droplet so imagine would have to update the DNS “A” record afterwards to the new IP address. I could reduce the TTL beforehand too. What about Amazon SES – I can’t remember but apart from re-enabling email (as in the guide) would there be any further steps to take?
Correct, if the machine has a new public IP you need to update the A record to point to the new server.
Email configuration shouldn’t change as long as your containers/app.yml file stays the same. If Amazon is limiting the IP that can send mail through the key then that’s different but otherwise nothing changes.