Lorsque j’exécute sudo apt update, je vois ceci :
W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease : La clé est stockée dans l’ancien trousseau de clés trusted.gpg (/etc/apt/trusted.gpg), voir la section DÉPRECIATION dans apt-key(8) pour plus de détails.
Comme ce n’est qu’un avertissement, je suis tenté de ne rien faire, mais que me conseillez-vous ? Merci.
Bonjour, il semble que cela signifie simplement que vos clés gpg ne sont pas au bon endroit.
*Recommandé :* Au lieu de placer les clés dans le répertoire /etc/apt/trusted.gpg.d, vous pouvez les placer n'importe où sur votre système de fichiers en utilisant l'option Signed-By dans votre sources.list et en pointant vers le nom du fichier de la clé. Voir [sources.list(5)](https://manpages.debian.org/testing/apt/sources.list.5.en.html) pour plus de détails. Depuis APT 2.4, /etc/apt/keyrings est fourni comme emplacement recommandé pour les clés non gérées par les paquets. Lors de l'utilisation d'un sources.list de style deb822, et avec une version apt >= 2.4, l'option Signed-By peut également être utilisée pour inclure la totalité du trousseau de clés blindé ASCII directement dans le sources.list sans fichier supplémentaire.
Cependant, ce n’est qu’une recommandation (malgré l’outil apt-key obsolète), il est donc tout à fait sûr de l’ignorer pour le moment. Je ne suis pas sûr des étapes correctes pour supprimer cela (je suis plutôt une personne d’Arch), mais l’ignorer ne devrait pas causer de problèmes, surtout si vous êtes sur une version LTS ou si vous ne mettez pas à jour vos versions majeures.
Vous pourriez certainement essayer de simplement vider le répertoire trusted (rm -rf /etc/apt/trusted.gpg.d/*), mais à mon avis, cela ne vaut pas le risque de casser vos paquets pour vous débarrasser d’un message comme celui-ci.
Un mot d’avertissement à tous ceux qui liront ceci à l’avenir : ce n’est pas la solution à votre problème et une mauvaise manipulation des commandes rm -rf peut potentiellement anéantir votre système entier au-delà de toute réparation. Veuillez donc faire preuve de prudence.
Il existe de nombreuses documentations en ligne sur la façon de se débarrasser de l’avertissement concernant la dépréciation des clés, mais le problème n’est pas spécifique à Discourse, je laisserai donc un lien et conseillerai de le lire deux fois avant d’exécuter aveuglément les commandes qui s’y trouvent.
Dans mon cas, c’est sans doute spécifique à Discourse (bien que pas de la manière dont vous l’entendez) car je n’ai le serveur que pour une installation de Discourse qui a suivi les instructions d’installation standard.
Mais je vais lire le lien que vous avez fourni. Merci.
Bien qu’un guide pour les nuls serait très apprécié.
Faites une sauvegarde complète, configurez une nouvelle instance de Discourse et restaurez votre sauvegarde là-bas.
De cette façon, vous n’avez pas besoin de toucher à quoi que ce soit et dans 99% des cas, votre problème aura disparu.
J’aurais aussi besoin d’un guide pour les nuls à ce sujet !
Par exemple, j’ai appris récemment qu’une sauvegarde complète inclut non seulement la sauvegarde que l’on obtient via le site web de Discourse, mais aussi le fichier app.yml.
Si vous n’êtes pas familier avec le shell, je vous recommande de télécharger la sauvegarde de votre site actuel et de suivre la procédure de restauration standard.
Cependant, si vous êtes un peu à l’aise avec le shell ou si vous ne voulez pas vous occuper de configurer un site temporaire, je vous recommande d’effectuer une restauration en ligne de commande.
Il existe déjà des guides assez détaillés à ce sujet :
Cela semble simple, merci. J’utiliserais une droplet Digital Ocean, donc j’imagine que je devrais mettre à jour l’enregistrement DNS “A” par la suite avec la nouvelle adresse IP. Je pourrais également réduire le TTL à l’avance. Qu’en est-il d’Amazon SES – je ne me souviens plus, mais à part réactiver les e-mails (comme dans le guide), y aurait-il d’autres étapes à suivre ?
Correct, si la machine a une nouvelle adresse IP publique, vous devez mettre à jour l’enregistrement A pour qu’il pointe vers le nouveau serveur.
La configuration des e-mails ne devrait pas changer tant que votre fichier containers/app.yml reste le même. Si Amazon limite l’IP qui peut envoyer des e-mails via la clé, c’est différent, mais sinon rien ne change.
Merci. Je vais peut-être faire cela bientôt alors. J’ai mis à niveau Ubuntu vers 24.04 avec Discourse in situ. Cela semblait fonctionner correctement, mais ce doit juste être une conséquence imprévue.