Wenn ich sudo apt update ausführe, sehe ich dies:
W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Der Schlüssel ist im veralteten trusted.gpg-Schlüsselbund (/etc/apt/trusted.gpg) gespeichert. Details finden Sie im Abschnitt DEPRECATION von apt-key(8).
Da es sich nur um eine Warnung handelt, bin ich versucht, nichts zu tun, aber was raten Sie mir? Danke.
Hallo, es scheint einfach zu bedeuten, dass sich Ihre GPG-Schlüssel nicht an der richtigen Stelle befinden.
*Empfohlen:* Anstatt Schlüssel in das Verzeichnis /etc/apt/trusted.gpg.d zu legen, können Sie sie überall auf Ihrem Dateisystem ablegen, indem Sie die Option Signed-By in Ihrer sources.list verwenden und auf den Dateinamen des Schlüssels verweisen. Einzelheiten finden Sie in [sources.list(5)](https://manpages.debian.org/testing/apt/sources.list.5.en.html). Seit APT 2.4 wird /etc/apt/keyrings als empfohlener Speicherort für Schlüssel empfohlen, die nicht von Paketen verwaltet werden. Bei Verwendung einer sources.list im deb822-Stil und mit apt-Version >= 2.4 kann die Option Signed-By auch verwendet werden, um den vollständigen ASCII-gepanzerten Schlüsselring direkt in die sources.list aufzunehmen, ohne eine zusätzliche Datei.
Es handelt sich jedoch nur um eine Empfehlung (trotz des veralteten apt-key-Tools), daher ist es im Moment absolut sicher, sie zu ignorieren. Ich bin mir nicht sicher, welche die richtigen Schritte sind, um dies zu unterdrücken (ich bin eher ein Arch-Nutzer), aber das einfache Ignorieren sollte keine Probleme verursachen, insbesondere wenn Sie eine LTS-Version verwenden oder Ihre Hauptversionen nicht aktualisieren.
Sie könnten natürlich versuchen, das vertrauenswürdige Verzeichnis einfach zu leeren (rm -rf /etc/apt/trusted.gpg.d/*), aber meiner Meinung nach lohnt es sich nicht, das Risiko einzugehen, Ihre Pakete zu beschädigen, nur um eine solche Meldung loszuwerden.
Ein Wort der Warnung an alle, die dies in Zukunft lesen: Dies ist nicht die Lösung für Ihr Problem, und ein unsachgemäßer Umgang mit rm -rf-Befehlen kann Ihr gesamtes System irreparabel zerstören. Seien Sie daher bitte vorsichtig.
Es gibt reichlich Dokumentation online darüber, wie man die Warnung vor der Schlüssel-Veralterung loswird, aber das Problem ist nicht spezifisch für Discourse, daher werde ich einen Link hinterlassen und empfehlen, ihn zweimal zu lesen, bevor Sie dort blind Befehle ausführen.
In meinem Fall ist es wohl spezifisch für Discourse (wenn auch nicht so, wie Sie es meinen), da ich den Server nur für eine Discourse-Installation habe, die den Standard-Installationsanweisungen gefolgt ist.
Aber ich werde mir den von Ihnen bereitgestellten Link ansehen. Danke.
Obwohl eine Idiotensichere Anleitung sehr willkommen wäre.
Erstellen Sie ein vollständiges Backup, richten Sie eine neue Instanz von Discourse ein und stellen Sie Ihr Backup dort wieder her.
Auf diese Weise müssen Sie nichts verändern, und in 99 % der Fälle wird Ihr Problem behoben sein.
Ich bräuchte dafür auch eine Idiotensichere Anleitung!
Zum Beispiel habe ich erst kürzlich erfahren, dass ein vollständiges Backup nicht nur das Backup umfasst, das man über die Discourse-Website erhält, sondern auch die Datei app.yml.
Wenn Sie mit einer Shell nicht vertraut sind, würde ich empfehlen, das Backup Ihrer aktuellen Seite herunterzuladen und der standardmäßigen Wiederherstellungsprozedur zu folgen.
Wenn Sie sich jedoch ein wenig mit der Shell auskennen oder keine Lust haben, eine temporäre Seite zu konfigurieren, würde ich empfehlen, eine Wiederherstellung über die CLI durchzuführen.
Dafür gibt es bereits ziemlich ausführliche Anleitungen:
Das sieht einfach aus, danke. Ich würde einen Digital Ocean Droplet verwenden, daher müsste ich danach wahrscheinlich den DNS „A“-Eintrag auf die neue IP-Adresse aktualisieren. Ich könnte auch vorher die TTL reduzieren. Was ist mit Amazon SES – ich erinnere mich nicht, aber abgesehen vom erneuten Aktivieren von E-Mails (wie in der Anleitung) wären weitere Schritte erforderlich?
Korrekt, wenn die Maschine eine neue öffentliche IP-Adresse hat, müssen Sie den A-Eintrag aktualisieren, damit er auf den neuen Server zeigt.
Die E-Mail-Konfiguration sollte sich nicht ändern, solange Ihre Datei containers/app.yml gleich bleibt. Wenn Amazon die IP einschränkt, die über den Schlüssel E-Mails senden kann, ist das etwas anderes, aber ansonsten ändert sich nichts.
Danke. Das werde ich dann vielleicht bald tun. Ich habe Ubuntu auf 24.04 mit Discourse in situ aktualisiert. Es schien alles in Ordnung zu sein, aber das muss wohl eine unvorhergesehene Folge sein.