Zertifikatsfehler beim E-Mail-Hostname verursacht sidekiq-Warteschlangenüberlastung, schwere Website-Instabilität

Ich hoste Discourse seit vielen Jahren selbst und hatte mehrere Instanzen auf einem ziemlich leistungsstarken Rechner am Laufen.

Heute bemerkte ich, dass eines meiner Foren ausgefallen war. Der erste Verdacht war mangelnder Festplattenspeicher, den ich behoben habe. Danach habe ich die Discourse-Instanz neu gestartet.

Seitdem fällt sie jedoch regelmäßig aus. Jedes Mal, wenn ich sie starte, sehe ich sofort, wie Sidekiq verrücktspielt und eine riesige Anzahl fehlgeschlagener E-Mail-Jobs auftritt, die auch dazu führen, dass Redis eine massive Menge an Zustand speichert, was meiner Meinung nach die eigentliche Ursache für das Problem mit dem Festplattenspeicher war. (Ich werde beim nächsten Mal, wenn ich die Maschine hochfahren kann, einen Flush durchführen, da ich sonst schnell keinen Speicherplatz mehr auf dieser Maschine haben werde und Discourse nicht einmal starten kann, um ihn zu leeren. Aber der Flush scheint den Festplattenverbrauch von Redis kaum zu reduzieren.)

Die Fehlermeldung deutet auf ein Problem mit der Zertifikatsnamenübereinstimmung hin, was ich etwas überraschend finde, da der von mir verwendete Mailserver intern ist und keine TLS-Verschlüsselung oder Authentifizierung benötigt. Ich konnte auf einer meiner anderen Instanzen (mit der gleichen E-Mail-Konfiguration) überprüfen, dass E-Mails nicht mehr funktionieren. In den Hauptproduktionsprotokollen sehe ich nur einen 422-Fehler, aber wenn ich etwas wie eine Passwortzurücksetzung sende, sehe ich in den Sidekiq-Protokollen eine ähnliche Fehlermeldung:

Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

Ich konnte verifizieren, dass ich E-Mails über die Befehlszeile senden kann, daher scheint dies kein Problem mit dem E-Mail-Server selbst zu sein, sondern etwas mit der Discourse-Konfiguration ist fehlerhaft.

Hier ist die ursprüngliche Mail-Konfiguration, die bis vor kurzem funktionierte:

DISCOURSE_SMTP_ADDRESS: outbound-relays.techservices.illinois.edu
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_ENABLE_START_TLS: false

Auch hier gilt: Dieser Mailserver ist intern und benötigt keinen Benutzernamen oder Passwort, und diese Einstellungen funktionierten bis vor kurzem. Ich habe mit DISCOURSE_SMTP_OPENSSL_VERIFY_MODE experimentiert, aber ich kann nicht sagen, ob es noch unterstützt wird. Unabhängig davon scheint es nicht zu helfen. Ich habe bemerkt, dass seit der Einrichtung dieser Foren ein paar neue E-Mail-Einstellungen hinzugefügt wurden, aber diese scheinen angesichts der Konfiguration dieses Mailservers nicht notwendig zu sein.

Jede Hilfe wäre willkommen! An diesem Punkt fällt es mir ehrlich gesagt sogar schwer, sicher zu sein, was falsch ist oder wie ich iterieren kann, da das Neuerstellen des Containers eine Weile dauert und die Fehlermeldung in den Produktionsprotokollen nur den 422-Fehler enthält und ich nicht herausfinden kann, wo ich nach der eigentlichen Ursache suchen soll. (Sie muss irgendwo sein, oder? Ich bin mir sicher, dass ich sie nur übersehe.)

1 „Gefällt mir“

Als Update, und nach dem Rat in einem anderen Thread, sendet dieser Befehl erfolgreich E-Mails aus dem Docker-Container:

echo message | s-nail -r "noreply@myforum.com" -s testing -S "smtp=same.email-service.com:25" my@address.com

Dies entspricht der E-Mail-Konfiguration, die ich verwendet habe, als dieses Problem auftrat. Beachten Sie, dass ich am Freitag auch ein Upgrade auf die neueste Discourse-Version über einen (erforderlichen) Befehlszeilen-Pull durchgeführt habe, was mich fragen lässt, ob ein kürzlicher Commit dieses Problem verursacht hat.

2 „Gefällt mir“

Wann wurde der Container zuletzt neu erstellt?

Haben Sie außerdem die Redis-Warteschlange geleert?

2 „Gefällt mir“

Freitag Morgen, glaube ich. Ein normales Update über die Benutzeroberfläche löste die Notwendigkeit eines launcher app rebuild aus. Als ich später die Sidekiq-Protokolle untersuchte, schien es, dass der Rückstand ungefähr zu dem Zeitpunkt begann, als der Container neu erstellt wurde, aber es dauerte ungefähr 24 Stunden, bis die Redis-Protokolle den gesamten verfügbaren Speicherplatz auf dem Host aufgefressen hatten und tatsächlich zu Ausfallzeiten führten. Das Forum war jedoch wahrscheinlich schon vorher langsam, da Sidekiq verzweifelt versuchte, eine zunehmende Anzahl fehlgeschlagener E-Mail-Jobs bei 100% CPU-Auslastung erneut zu senden.

Ja.

Es beunruhigt mich jedoch, dass dies die Redis-Festplattennutzung anscheinend nicht reduziert hat. Ich habe einen Ordner redis_data, der derzeit 29 G groß ist, selbst nach dem Leeren. Vielleicht ist Redis wie MongoDB, in dem es schwierig sein kann, ihm Speicherzuweisungen zurückzugeben? Da dies 1/3 des verfügbaren Speichers auf dem Rechner ist, wird es ein Problem, aber ich werde das vorerst zurückstellen, um nur wieder E-Mails zum Laufen zu bringen.

1 „Gefällt mir“

Als Debugging-Hinweis: Gibt es eine Möglichkeit, eine Test-E-Mail von der Befehlszeile innerhalb des Containers zu senden, die denselben Codefluss verwendet, der auch von Discourse verwendet würde? (Das heißt, nicht von der Befehlszeile mit einem anderen Tool, was ich bereits überprüft habe und funktioniert.) Dies wäre hilfreich für das Debugging, da das Senden einer Test-E-Mail derzeit das Herumfummeln in der Weboberfläche und das Durchsuchen der Protokolle erfordert, um herauszufinden, was schief gelaufen ist. (Und bisher habe ich nur die 422-Fehler gefunden und nichts Nützlicheres, außer in den Sidekiq-Protokollen, die nicht erstellt werden, wenn der Test-E-Mail-Fluss verwendet wird.) Oder vielleicht könnte die Test-E-Mail-Oberfläche mehr Debugging-Informationen anzeigen?

Insgesamt vermute ich, dass die meisten Leute Discourse einrichten und nicht an diesen Punkt gelangen, ohne dass die E-Mail funktioniert, da sie benötigt wird, um anfängliche Einladungen usw. zu versenden. Aber ich finde die Debugging-Fähigkeiten in dem Fall, dass die E-Mail funktioniert hat und plötzlich aufhört, begrenzt. (Auch die Wiederholungslogik muss möglicherweise etwas angepasst werden, da sie in diesem Fall viel zu schnell wiederholt wird. Ein Zertifikatsfehler wird wahrscheinlich nicht wenige Sekunden nach dem ersten Versuch behoben sein…)

1 „Gefällt mir“

Vielleicht hilft E-Mail-Fehlerbehebung bei einer neuen Discourse-Installation. Ich glaube, Sie möchten

rake emails:test[user@domain]
3 „Gefällt mir“

Danke! Das ist hilfreich. Hier ist das Ergebnis:

Testing sending to user@domain using outbound-relays.techservices.illinois.edu:25, username: with plain auth.
======================================== ERROR ========================================
                                    UNEXPECTED ERROR

SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!

Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)
=======================================================================================

Ich werde den Container jetzt neu erstellen, um sicherzustellen, dass er und app.yml synchron sind. Aber insgesamt bin ich etwas verwirrt, warum dort steht, dass er „plain auth“ verwendet, da weder ein Benutzername noch ein Passwort in der Konfigurationsdatei app.yml angegeben sind.

Ist es lohnenswert, dies als Fehler einzustufen? Ich war anfangs zögerlich, da es sich um E-Mails handelt und es viele Möglichkeiten gibt, wie dies fehlschlagen könnte, von denen viele eine Kombination aus meiner Schuld / externen Änderungen wären. Aber soweit ich das beurteilen kann, stellt dies eine Konfiguration dar, die mehrere Jahre lang funktionierte und plötzlich mit einem Upgrade auf die neueste Version von discourse_docker nicht mehr funktionierte. Ist es möglich, dass sich kürzlich etwas daran geändert hat, wie die Konfigurationsdateien verarbeitet werden?

Was die Fehlermeldung selbst betrifft – ich konnte ein Zertifikat für diese Maschine abrufen und tatsächlich listet das Zertifikat einen anderen Hostnamen auf (ein anderes CNAME für dieselbe Maschine). Das Zertifikat selbst ist jedoch mehrere Jahre alt und lief auch vor etwa einem Jahr ab, aber erst kürzlich begann es, diesen Fehler auszugeben. Das lässt mich also vermuten, dass keine Änderung am Zertifikat das Problem verursacht.

2 „Gefällt mir“

Wenn ich eine Verbindung zu diesem Host herstelle und STARTTLS teste, erhalte ich ein Zertifikat, das nicht mit dem Hostnamen übereinstimmt:

Zertifikatskette
 0 s:/C=US/ST=California/L=Sunnyvale/O=Proofpoint, Inc./OU=ESP/CN=*.pphosted.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

und es ist noch nicht abgelaufen:

notBefore=Jun 12 00:00:00 2020 GMT
notAfter=Sep 14 12:00:00 2022 GMT

Ein Vorwärts- und Rückwärts-Lookup zeigt, dass die Mailserver tatsächlich mx0a-00007101.pphosted.com und mx0b-00007101.pphosted.com heißen.

outbound-relays.techservices.illinois.edu. 22 IN A 148.163.139.28
outbound-relays.techservices.illinois.edu. 22 IN A 148.163.135.28

28.139.163.148.in-addr.arpa name = mx0b-00007101.pphosted.com.
28.135.163.148.in-addr.arpa name = mx0a-00007101.pphosted.com.

Versuchen Sie, den Hostnamen, zu dem Sie eine Verbindung herstellen, zu einem dieser Namen anstelle des .edu-Namens zu ändern. Es muss keine Änderung am Zertifikat vorgenommen werden, es könnte eine Änderung am Hostnamen oder am Code gewesen sein. Aber der Fehler ist korrekt: Es gibt tatsächlich eine Diskrepanz zwischen dem Hostnamen und dem Zertifikat.

4 „Gefällt mir“

Danke @RGJ! Ich werde das versuchen.

Ich bin jedoch etwas nervös, diese Namen zu verwenden, da sie sich in Zukunft ändern könnten und nicht mit dem Hostnamen übereinstimmen, der für die Verwendung auf dem Campus zu diesem Zweck bereitgestellt wird. Gibt es eine Möglichkeit, diesen Fehler über app.yml-Einstellungen oder auf andere Weise zu deaktivieren?

1 „Gefällt mir“

Mein Ansatz war, die Dinge zuerst wieder zum Laufen zu bringen und dann herauszufinden, wie man sie besser machen kann.
Sie sollten DISCOURSE_SMTP_OPENSSL_VERIFY_MODE auf false setzen können, aber Sie sagten, Sie hätten das bereits versucht.

5 „Gefällt mir“

Ja, absolut! Das ergibt Sinn.

Ich glaube, ich habe versucht, diesen Wert auf none zu setzen, aber nicht auf false. Ich werde false ausprobieren.

2 „Gefällt mir“

OK, kann bestätigen, dass false nicht funktioniert. Werde none noch einmal versuchen.

1 „Gefällt mir“

Kann auch bestätigen, dass none nicht funktioniert.

Ich bin hier etwas ratlos, ob dieses Verhalten angemessen ist. DISCOURSE_SMTP_ENABLE_START_TLS ist auf false gesetzt, was für Leute, die keine E-Mail-Experten sind, wie mich, verwirrend sein sollte, dass ein Zertifikat eine Rolle bei diesem Fehler spielt. Würde das gleiche Problem auftreten, wenn die Maschine gar kein Zertifikat hätte? (Das kann ich offensichtlich nicht testen.) Wenn nicht, erscheint es noch seltsamer.

Ich werde mich vorerst für die temporäre Lösung entscheiden, aber irgendetwas daran erscheint mir seltsam.

1 „Gefällt mir“

Sicher. Ich kann mir vorstellen, dass, wenn ein Mailserver STARTTLS benötigt, er die STARTTLS-Einstellung überschreibt, aber DISCOURSE_SMTP_OPENSSL_VERIFY_MODE sollte immer noch einen Fehler verhindern können.

Kann das jemand reproduzieren?

2 „Gefällt mir“

@Geoffrey_Challen wie hast du es behoben?

Heute habe ich mein Forum auf 2.9.0.beta4 (c99a6b10fb) aktualisiert und jetzt habe ich den gleichen Fehler, Discourse kann keine E-Mails senden:
SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

Ich habe die Konfiguration des VPS und der E-Mail nicht geändert!

Meine app.yml:

  DISCOURSE_SMTP_ADDRESS: smtp.mydomain.info
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: info@mydomain.info
  DISCOURSE_SMTP_PASSWORD: "mypassword"
  DISCOURSE_SMTP_ENABLE_START_TLS: false           # (optional, standardmäßig true)
  DISCOURSE_SMTP_DOMAIN: mydomain.info             # (von einigen Anbietern erforderlich)
  #DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com    # (Adresse, von der Benachrichtigungen gesendet werden)

Versucht und nichts ändert sich …

Bitte, jetzt kann ich keine E-Mails senden und ich kann kein TLS verwenden, was kann ich tun?

2 „Gefällt mir“

Führen Sie diesen Befehl aus und sehen Sie, für welchen Hostnamen das Zertifikat bestimmt ist

openssl s_client -connect  smtp.mydomain.info:25 -starttls smtp -showcerts 2>&1|grep "depth=0"

Ersetzen Sie dabei smtp.mydomain.info natürlich durch die Adresse Ihres SMTP-Servers.

Versuchen Sie dann, festzustellen, ob Sie den SMTP-Server unter diesem Hostnamen erreichen können.

3 „Gefällt mir“

Danke für deine Hilfe @RGJ

Der Hostname ist CN = *.aruba.it, also anders als mydomain.info, und ja, ich kann den SMTP-Server über den Hostnamen und Telnet erreichen.

Alles funktionierte perfekt vor ./launcher rebuild app

Aber… ich habe DISCOURSE_SMTP_ENABLE_START_TLS: false, warum sucht es immer noch nach dem Zertifikat?

1 „Gefällt mir“

Sie können auf den Host mit einem Namen zugreifen, der mit dem Zertifikat übereinstimmt. Sie können den Serveradministrator bitten, den gewünschten Hostnamen zum Zertifikat hinzuzufügen.

Das ist eine gute Frage, aber Sie können ihre Antwort überflüssig machen, indem Sie den obigen Rat befolgen, oder das denke ich.

Eine weitere Frage ist, warum hat der Mail-Administrator es für Sie kaputt gemacht?

Vielleicht hat diese Einstellung vorher funktioniert und jetzt nicht mehr. Ob es einfacher ist, diesen Fehler zu finden oder den Hostnamen zu ändern und zu sehen, ob das Ihr Problem löst, ist unklar.

1 „Gefällt mir“

Niemand hat Änderungen vorgenommen, da bin ich mir sicher, ich habe nur ./launcher rebuild ausgeführt, um dieses Plugin zu installieren.

Sollte ich also den Hostnamen des VPS in etwas ändern, das mit .aruba.it endet?

1 „Gefällt mir“

Das klingt so.

Es ist möglich, dass es eine Regression gab, die das Problem verursacht hat, aber ich denke, dass Sie Ihr unmittelbares Problem durch eine Änderung des Hostnamens lösen können.

2 „Gefällt mir“