Let's Encrypt SSL-Zertifikat erneuert sich zum 2. Mal hintereinander nicht automatisch

Hallo zusammen. Ich brauche etwas Hilfe bei der Fehlerbehebung. Zum zweiten Mal in Folge wurde mein Let’s Encrypt SSL-Zertifikat nicht automatisch erneuert. Nachdem ich die entsprechenden Threads hier gelesen hatte, gelang es mir jedes Mal, das Zertifikat zu erneuern, indem ich das alte entfernte und die Anwendung neu erstellte. Ich war der Meinung, dass dies beim nächsten Mal zu einer automatischen Erneuerung führen würde. Das tat es nicht.

Ich sehe keine Hinweise darauf, dass ein cron-Job irgendwo läuft, der versucht, das Zertifikat zu erneuern. Ich gehe davon aus, dass ich auf den verschiedenen Orten auf dem Host-Rechner suchen sollte und nicht innerhalb des Docker-Containers. Liege ich damit richtig? crontab -l sagt „no crontab for root“ und ich sehe nichts in /etc/cron*.

Infolgedessen bin ich mir nicht sicher, ob mein Server (1) nicht versucht, das Zertifikat zu erneuern, oder (2) es versucht und fehlschlägt. Ist jemand bereit, mich bei der Fehlerbehebung zu unterstützen?

Da ich leider shared/standalone/{letsencrypt,ssl} gelöscht habe, um das Zertifikat neu bereitzustellen, habe ich keine alten Protokolle, die ich überprüfen könnte. Wie kann ich zumindest überprüfen, ob der cron-Job installiert ist, damit ich die Protokolle beim nächsten Versuch der Systemerneuerung des Zertifikats überprüfen kann?

Danke.

2 „Gefällt mir“

Ich denke, es könnte das letzte Mal gewesen sein, dass dies passiert ist. Es gab eine Korrektur im Dezember:

Vielen Dank, aber ich würde sehr gerne die Einstellungen überprüfen, um festzustellen, ob die bevorstehende Verlängerung wahrscheinlich stattfindet. Ich weiß nicht, wie ich diese Einstellungen überprüfen kann, daher bitte ich jetzt um diese Hilfe.

Anscheinend soll es einen Cronjob geben. Wo ist er? Ich sehe keinen auf meinem Server aufgeführt. Ist dies nicht wirklich ein Cronjob, sondern eine geplante Aufgabe in Rails?

Ich habe in /var/discourse/shared/standalone/letsencrypt/acme.sh.log (auf dem Hostsystem) gesehen, dass Discourse mein SSL-Zertifikat überprüft hat und die Antwort „It’s still valid“ (Es ist noch gültig) lautete. Ich nehme also an, dass dies ein Beweis dafür ist, dass Discourse versuchen wird, das Zertifikat rechtzeitig zu erneuern.

Nun möchte ich wissen, wie dieser „cron“-Job konfiguriert ist? Handelt es sich dabei wirklich um einen cron-Job auf Linux-Ebene oder nur um eine wiederkehrende geplante Aufgabe in Rails, die etwas wie whenever verwendet? Kann ich dies untersuchen und überprüfen, ohne den Quellcode durchzusehen? Könnte ich dies mit der Rails-Konsole oder was auch immer das 2026 ist, herausfinden? (Ich habe lange nicht mehr in Rails gearbeitet.)

Danke.

Ach ja, ich habe endlich gelernt, dass dieser Fehler auf eine undokumentierte, nicht sehr klare, offensichtlich unerwartete magische Abkürzung zurückzuführen ist: „Wenn es mit / beginnt, dann muss es ein Regex sein.“ Ich verstehe den gesamten Kontext noch nicht, aber das scheint es zu sein.

Das ist die Duck-Typing-Kultur für dich: wunderbare Flexibilität mit dem Risiko, dass Kunden eine Überraschung erleben, wenn man Dinge nicht aufschreibt. :wink:

Es scheint ratsam zu sein, Pups::ReplaceCommand zu stärken, um sorgfältiger zu prüfen, ob to wie ein Regex aussieht oder nicht. Oder was auch immer es tut, das annimmt, dass es etwas eval()uieren soll, anstatt es als Ersatztext zu behandeln.

Ich vermute, das fällt in die Kategorie Aufräumarbeiten, für die niemand Zeit oder Energie hat? Wenn mir jemand hilfreiche Beispiele dafür zeigen könnte, wie sich ReplaceCommand verhalten muss, könnte ich vielleicht etwas Zeit und Energie dafür spenden.

Immerhin habe ich eine bessere Vorstellung davon, was vor sich geht, aber dieses Wissen beginnt bereits zu verblassen, noch bevor ich diesen Satz beendet habe. :person_shrugging: