./discourse-setup füllt DISCOURSE_SMTP_DOMAIN nicht aus

Installation
1

Hallo,

Das ./discourse-setup Bash-Skript füllt DISCOURSE_SMTP_DOMAIN nicht in der PUPS-Konfigurationsdatei aus.

Ich habe rake admin:create innerhalb des Containers verwendet und die folgenden Auswirkungen auf die GUI festgestellt:

image
image465×399 17.2 KB

image
image430×327 18.2 KB

2

Für eine Zeit lang war es mit dem Hostnamen gefüllt, da bin ich mir ziemlich sicher. Aber in den meisten Fällen spielt es auch keine Rolle.

3

gibt es einen regulären Ausdruck, den wir verwenden können, um die E-Mail-Domain nach dem @ in DISCOURSE_NOTIFICATION_EMAIL zu extrahieren

um Bereitstellungsfälle zu verstehen, in denen die E-Mail-Domain von der Web-Domain abweicht.

Etwas wie:

DISCOURSE_SMTP_DOMAIN=$(echo "$DISCOURSE_NOTIFICATION_EMAIL" | sed -E 's/^[^@]+@(.+)$/\\1/')
4

Diese Variable legt den EHLO-Hostnamen fest, der vom Client während der SMTP-Konversation verwendet wird.

Fast niemand benötigt sie, und es ist fast nie wichtig, worauf sie gesetzt ist.

(Ich bin auf null Situationen gestoßen, in denen sie eine Rolle spielt)

2 „Gefällt mir“
5

image
image941×491 63.2 KB

das lag daran, dass DO Port 587 blockiert hat, hätte 2525 verwenden sollen – aber ich bin mir nicht sicher, wie das mit Brevo funktioniert

6

Man könnte argumentieren, dass es standardmäßig Port 2525 verwenden oder den Leuten vorschlagen sollte, dass die meisten VMs SMTP-Ports blockieren und die meisten SMTP-Dienste Port 2525 zulassen (aber das wird eine Menge Worte).

7

Die Tatsache, dass Digital Ocean Port 587 blockiert, ist eine schreckliche, uninformierte Entscheidung ohne Grundlage in guter Praxis.

Ich bin überrascht, dass sie nicht aus demselben Grund begonnen haben, 2525 standardmäßig zu blockieren.

8

[quote=“supermathie, post:7, topic:390624”]Die Tatsache, dass Digital Ocean Port 587 blockiert, ist eine schreckliche, uninformierte Entscheidung ohne Grundlage in guter Praxis.
[/quote]

Ich stimme nicht zu. Ich bin mir ziemlich sicher, dass sie nicht die Einzigen sind, die das tun (aber ich habe Schwierigkeiten, das zu belegen). Das Seltsame ist, dass sie das schon immer irgendwie getan haben, aber dann letzten April (?) haben sie es für alle durchgesetzt. Aber „alle“ bedeutet so etwas wie „jeder nach dem nächsten Neustart“ (es könnte von etwas anderem abhängen, das einen Neustart erfordert), sodass es Monate dauern könnte, bis Sie neu starten (oder Ihren Droplet vergrößern oder so etwas) und es dann anfängt zu passieren.

Und sie bieten nicht einmal einen SMTP-Dienst an, sodass es keine Möglichkeit mehr geben wird, E-Mails zu senden, sobald sie 2525 blockieren. Ich habe viele Leute bei DO, da CDCK sie von Anfang an empfohlen hat (oder zumindest seit ich angefangen habe).

2 „Gefällt mir“
9

Wie haben Sie das herausgefunden? Haben Sie den emails:test rake-Task ausprobiert, und wenn ja, war er nützlich? Wussten Sie, dass es ihn gab?

10

Danke, Michael – hier ist, was bei der heutigen Installation tatsächlich passiert ist und wie ich herausgefunden habe, dass Port 587 die Ursache war.

Als ich zum ersten Mal ./discourse-doctor bei 50:30 ausführte, zeigte es deutlich, dass ausgehendes SMTP über 587 fehlschlug. In diesem Teil des Prozesses gab es nirgends erfolgreiche Test-E-Mails. Deshalb habe ich bei 51:38 den SMTP-Port auf 2525 geändert und den Container neu erstellt. Sobald die Anwendung wieder lief, war der erste Mail-Test bei 57:46 sofort erfolgreich.

Bei 57:58 bemerkte ich, dass mein Mailgun-Konto noch nicht aktiviert war – der Doctor hatte also Recht damit, dass das SMTP-Problem nicht an den Anmeldedaten lag, sondern daran, dass der Port von DigitalOcean blockiert wurde.

Da Brevo schneller einsatzbereit war, habe ich den Anbieter gewechselt: Ich begann die Einrichtung bei 58:40, wählte den kostenlosen Plan bei 1:01:12, tauschte die DNS-Einträge bei 1:02:29 und aktualisierte die SMTP-Einstellungen in app.yml bei 1:04:37. Bei 1:06:08 wies ich darauf hin, dass die GUI DISCOURSE_SMTP_DOMAIN anzeigt, auch wenn die Variable nicht durch ./discourse-setup befüllt wird, weshalb das leere Feld mich zunächst denken ließ, etwas sei falsch konfiguriert.

Nach Abschluss der Brevo-Konfiguration führte ich ./discourse-doctor erneut bei 1:42:10 aus, und bei 1:42:25 bestätigte es eine erfolgreiche ausgehende E-Mail – wieder über Port 2525.

Um Ihre spezifischen Fragen zu beantworten:

  • Wie habe ich herausgefunden, dass DigitalOcean 587 blockiert?
    ./discourse-doctor meldete sofort einen Fehler bei 587, und der Wechsel zu 2525 behob das Problem sofort. Das Video zeigt diese Abfolge deutlich.
  • Habe ich rake emails:test verwendet?
    Zu diesem Zeitpunkt nicht – ich verließ mich auf ./discourse-doctor und die Test-E-Mail der Admin-Oberfläche. Ich wusste nichts von emails:test, bis Sie es erwähnten. Ich werde es zukünftig definitiv verwenden, da es klarere Diagnosen innerhalb des Containers liefert.
  • Stand das fehlende DISCOURSE_SMTP_DOMAIN in Zusammenhang damit?
    Nein – das leere GUI-Feld war eine falsche Fährte. Das eigentliche Problem war, dass DigitalOcean Port 587 blockierte; sobald ich auf 2525 wechselte, funktionierten sowohl Mailgun (nach der Aktivierung) als auch Brevo einwandfrei.

Nochmals vielen Dank – Ihre Erklärung, was DISCOURSE_SMTP_DOMAIN tatsächlich beeinflusst (nur EHLO), hat geholfen zu klären, warum der fehlende Wert keine Rolle spielte.