Gibt es eine Möglichkeit, Discourse auf eine ältere funktionierende Version (z. B. 2.8.0 Stable oder 2.9.0 Beta3) „herunterzustufen“, bis dies behoben ist?
Ich habe beschlossen, noch eine halbe Stunde darauf zu verwenden, und ich glaube, ich habe die Ursache gefunden.
Dies scheint mit der Umstellung auf Rails 7 zusammenzuhängen, wodurch net-smtp von 0.1.0 auf 0.3.1 aktualisiert wurde, was die Standardeinstellungen geändert hat.
Die Art und Weise, wie das smtp-Gem net-smtp aufruft, deaktiviert enable_starttls_auto und openssl_verify_mode nicht, sondern aktiviert sie nur, wenn sie aktiviert sind.
Gute Arbeit, Richard! Das hätte mich zwei Stunden gekostet, wenn nicht doppelt so lange. Für mich ist es einfacher, mich mit den neuen Standardeinstellungen abzufinden.
Aha. Ich hatte also irgendwie Recht, nur dass es vielleicht nicht allzu schwierig wäre, es mit einem PR zu beheben.
Gute Arbeit, @RGJ!
Während wir auf eine Lösung warten, wäre es nebenbei gut, wenn dieses Problem nicht die Kaskade von Problemen verursachen würde, die ich erlebt habe und die mein Forum fast vollständig zum Absturz brachten. Insbesondere:
- Die E-Mail-Fehler scheinen extrem schnell wiederholt zu werden, was dazu führt, dass die Sidekiq-Warteschlange explodiert und die CPU-Auslastung durch diese Aufgaben bei ~100 % liegt.
- Außerdem verursachte etwas (entweder Abstürze oder Neustarts), dass Redis riesige temporäre Dateien schrieb, die vermutlich den Zustand der Sidekiq-Warteschlange enthielten. Obwohl diese sicher zu entfernen waren, füllten sie schnell die Festplatte, was weitere Abstürze verursachte und so weiter. Ich hatte etwas anderen Speicherplatz, den ich freimachen konnte, um das Forum neu zu starten und herauszufinden, was los war, aber das ist möglicherweise nicht bei jedem der Fall. (Es ist auch einigermaßen schwierig zu bestätigen, dass in diesem Fall die temporären Redis-Dateien tatsächlich sicher gelöscht werden können.)
Ich vermute, dass die einfachste Lösung darin besteht, die Wiederholung fehlgeschlagener E-Mail-Jobs zu verlangsamen – oder zumindest bei denen, die keine zeitlichen Einschränkungen haben, wie z. B. Passwort-Resets. Dies scheint angemessen zu sein, da E-Mail-Probleme wahrscheinlich nicht schnell gelöst werden und die meisten / alle Mailer ihre eigenen Wiederholungen durchführen, sobald sie eine Nachricht erhalten.
In meinem Fall, als ich nach dem Upgrade auf den Fehler gestoßen bin, wurde TLS mit einem Drittanbieterserver verwendet und der Name auf dem Zertifikat stimmte mit dem SMTP-Servernamen überein. Ich hatte jedoch nur einen Fehler. Ich habe seitdem nicht neu gestartet oder ein Upgrade durchgeführt, um weitere Probleme zu vermeiden. Ich werde ein Update ausprobieren, sobald der Patch veröffentlicht wurde, und sehen, wie es läuft.
Ich werde damit beginnen, ein Thema in Bug zu erstellen, aber da es sich technisch gesehen um ein Problem in einem Upstream-Gem handelt, bin ich mir nicht sicher, wie viel Priorität dies erhalten wird.
+1 :besorgt:wirklich frustrierender Fehler
Kann das Gem nicht zurückgerollt werden? Ich wäre überrascht, wenn dem keine Aufmerksamkeit geschenkt würde, da dies eine „Kern“-Funktionalität ist, die Möglichkeit, E-Mails zu senden, und für einige verursacht es auch einen Ausfall aufgrund von temporären Dateien und CPU-Überlastung des Servers. Die Kernstabilität des Forums wird hier gestört.
Bitte vergessen Sie nicht, dass dies auch einfach durch eine ordnungsgemäße Konfiguration Ihres Mailservers behoben werden kann.
Soweit ich weiß, ist mein Server richtig konfiguriert. Der Zertifikatsname stimmt mit dem SMTP-Hostnamen überein, STARTTLS auf Port 587. Ich frage mich, warum ich das Problem hatte?
Vielen Dank, dass Sie ein neues Ticket eröffnet haben. Könnten Sie angesichts Ihres Verständnisses etwas Licht auf die Kombinationen der beiden Variablen werfen, die Sie in der YML-Datei erwähnt haben – wie sollten sie für verschiedene Szenarien verwendet werden?
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Zum Beispiel habe ich aus Sicherheitsgründen nur STARTTLS auf Port 587 und keine anderen Ports, die von SMTP verwendet werden. Sollten beide Variablen in der YML-Datei angegeben werden oder nur eine?
Das kommt darauf an.
Wenn Ihr SMTP-Server korrekt konfiguriert ist, benötigen Sie keine von beiden.
Aber das Problem ist im Moment, dass sie überhaupt nichts tun.
Schicken Sie mir eine PM mit dem Namen Ihres SMTP-Servers und ich werde nachsehen, ob ich herausfinden kann, warum es bei Ihnen nicht funktioniert.
Ich habe einen lokalen SMTP-Server ohne TLS/SSL-Unterstützung und wenn ich StartTls=false verwende, funktioniert es nicht ![]()
[quote=„Richard – Communiteq, Beitrag: 56, Thema: 225778, Benutzername: RGJ“]auch Ihren Mailserver richtig.
[/quote]
Guter Punkt, aber es ist nicht immer unser Mailserver. Ich benutze einen internen Mailserver, der von einer anderen Gruppe gewartet wird, und habe daher keine Kontrolle über Zertifikatsprobleme oder die Konfiguration des Mailservers.
Das gesagt, für andere, die damit kämpfen, könnte eine Option darin bestehen, Ihren eigenen Mailserver auf localhost einzurichten und ihn einfach weiterleiten zu lassen. Dann haben Sie die Kontrolle über den Mailserver, mit dem Discourse spricht, und Ihr Mailserver auf localhost kann so konfiguriert werden, dass er mit allen möglichen Upstream-Problemen umgeht, auf die Sie stoßen könnten. Ich hatte dies zuvor getan, es aber irgendwann entfernt, da es einfacher war, Discourse einfach direkt mit dem Upstream-Mailserver sprechen zu lassen. (Ups.)
Deshalb empfiehlt die Standardinstallation die Nutzung von E-Mail-Anbietern von Drittanbietern, anstatt zu versuchen, eine bestehende oder selbst gehostete Lösung zu verwenden.
E-Mail ist aus einer Vielzahl von Gründen schwierig. Nur weil etwas heute funktioniert, heißt das nicht, dass es richtig konfiguriert ist, sondern nur, dass die Fehlkonfiguration den ursprünglichen Zweck nicht beeinträchtigt.
Der Grund, warum ich Discourse gewählt habe, war, dass es für kleine selbst gehostete Installationen einfach zu installieren und zu warten sein soll.
Und das ist der Fall, wenn Sie die Empfehlungen befolgen.
Wenn Sie sich entscheiden, einen anderen Weg zu gehen, ist es nicht wirklich möglich, irgendwelche Garantien zu geben.
Sie sagen also zusammenfassend, dass mit Discourse kein SMTP-Server mehr ohne TLS, SSL oder StartTLS verwendet werden kann?
Ich glaube nicht, dass irgendjemand das vorschlägt. Dies bezieht sich nur darauf, wie das Problem entstanden ist und es Zeit brauchte, um die Ursache zu finden.
Der Grund, warum wir hier nur eine Handvoll Fälle sehen, liegt an der relativ geringen Anzahl von Installationen mit dem aktualisierten Gem, die auch keine E-Mails über eine Form von sicherem Transport weiterleiten.
Richard hat bereits ein Thema zu dem Fehler gestartet:
Wer dies früher benötigt, kann entweder TLS auf seinem Mailserver aktivieren oder vorübergehend zu einem Mailanbieter wechseln, der einen sicheren Transport anbietet.
Ich habe TLS von Anfang an mit einem gültigen Zertifikat und übereinstimmendem Hostnamen aktiviert und bin dann nach dem Upgrade auf BETA 4 (461936f211) auf das Problem gestoßen und habe die Protokolle im unten stehenden Thema gepostet. Ein anderer Benutzer hat ebenfalls Probleme und seiner Meinung nach sind seine Zertifikate ebenfalls in Ordnung:
Das höre ich auch. Einige der Kommentare in diesem Thread waren geradezu ärgerlich.
Ich hoste Docker-Discourse selbst und verwende meinen Docker-Host als E-Mail-Server. Seit Anbeginn, vor sechs Jahren, lasse ich Discourse Port 25 ohne TLS verwenden, um E-Mails über die interne Docker-Schnittstelle zu versenden. Dies ist eine vollkommen vernünftige und vollkommen sichere Konfiguration. Die Transaktionen waren zu 100 % intern auf meinem eigenen Host. Siehe weiter oben im Thread für meine alte Konfiguration.
Für mich bestand die Problemumgehung darin, Folgendes zu tun:
Fügen Sie die interne IP-Adresse der Docker-Schnittstelle des Hosts als gültigen Host in der DNS-Zonendatei für meine Domain hinzu. D.h.:
discourse-mail.jag-lovers.com A 172.17.0.1
Bitte beachten Sie: Ich konnte jeden beliebigen Hostnamen in der Domain jag-lovers.com erfinden, da ich ein Wildcard-Zertifikat (CN = *.jag-lovers.com) verwende. Wenn Sie kein Wildcard-Zertifikat haben, stellen Sie sicher, dass Sie einen Hostnamen verwenden, der ein gültiger CN oder SAN auf Ihrem Zertifikat ist.
Bitte beachten Sie auch: Die oben verwendete IP-Adresse ist die interne IP-Adresse, die mein Host auf der Docker-Schnittstelle verwendet, um mit dem Discourse-Docker-Container zu kommunizieren. Es ist eine private, nicht weiterleitbare IP-Adresse.
Ändern Sie als Nächstes die Discourse app.yml-Konfiguration, um sich mit dem gerade erstellten Hostnamen zu verbinden, TLS zu verwenden, Port 587 zu verwenden und SASL für die Anmeldung am Host für jede E-Mail-Transaktion zu verwenden (da Sie sonst eine Meldung über abgelehnte Weiterleitung erhalten).
DISCOURSE_SMTP_ADDRESS: discourse-mail.jag-lovers.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: REDACTED
DISCOURSE_SMTP_PASSWORD: "REDACTED"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, standardmäßig true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
DISCOURSE_SMTP_DOMAIN: jag-lovers.com
Bauen Sie Discourse als Nächstes neu. Das hat das Problem für mich behoben.