Zunächst einmal Anerkennung, wo sie angebracht ist: Der neue Installer ist eine deutliche Verbesserung. Wenn er funktioniert – was meist der Fall ist –, bietet er einen viel benutzerfreundlicheren Weg als der ältere manuelle Ablauf, und ich konnte damit saubere Installationen durchführen. Installer ausführen, Registrierung/Aktivierung wie gewohnt abschließen und dann app.yml nach meinen Spezifikationen anpassen. Kinderspiel. Vielen Dank an @Falco und das Team! Ein gewaltiger Unterschied zu den alten Zeiten der Discourse-Installation.
Ich schreibe dies, weil ich auch auf einen Hostnamen gestoßen bin, der mich zu schaffen gab, und ich glaube, diese Erfahrung könnte auf einige Bereiche hinweisen, in denen der Installer klarere Informationen für Self-Hoster liefern könnte.
Was funktioniert hat
Ich habe Discourse erfolgreich auf einem neuen Server installiert mit:
- eigener Domain: ja
- SMTP: ja
- dem aktuellen Installer-Ablauf
Die Installation erreichte:
Tallyho!
Herzlichen Glückwunsch, du hast Discourse installiert!
Registriere ein neues Konto, um loszulegen.
Es handelt sich also nicht um einen Beitrag mit der Aussage „Der neue Installer ist kaputt“. Der Installer kann sehr gut funktionieren.
Der schwierige Hostname
Bei einer anderen Installation, die denselben allgemeinen Weg nahm, war der Ziel-Hostname:
forum.domain.tld
Der Installer-Befehl war:
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
Die Auswahlmöglichkeiten waren ungefähr:
- 2 GB Swap-Datei erstellen: ja
- eigene Domain verwenden: ja
- Hostname:
forum.domain.tld - SMTP konfigurieren: ja
- SMTP-Anbieter: SendGrid
- SMTP-Port: 587
Der Installer erreichte:
[4/5] Domänenkonfiguration wird überprüft
? Überprüfung deines Domainnamens...
? Verbindung zu forum.domain.tld erfolgreich.
Anschließend schrieb er die Konfiguration und baute die App neu auf.
Aber die Seite wurde im Browser nicht sauber geladen. Das Symptom wurde schließlich zu:
forum.domain.tld hat die Verbindung abgelehnt
Wiederholte Versuche, neu zu bauen und zu versuchen, lösten das Problem nicht.
Discourse Doctor-Ergebnis
./discourse-doctor fand den App-Container und die erwarteten Konfigurationswerte. Der Container lief, und die Ports 80/443 schienen gebunden zu sein.
Aber es meldete:
Discourse-Version auf forum.domain.tld: NICHT GEFUNDEN
und später:
Discourse-Version auf localhost: NICHT GEFUNDEN
Das ließ das Problem anders wirken als eine gewöhnliche öffentliche DNS-Propagation allein.
ACME-Ratenbegrenzung
Früher in der Fehlerbehebungsphase versuchte ich auch Installationen mit den Discourse-Service-unterstützten Wegen:
- DiscourseID
- der
yoursite.discourse.diy-Ablauf
Dort trat das wiederholte Server-Hammering-/Wiederholungsverhalten auf, und dort zeigte das ACME-Protokoll eine Let’s Encrypt-Ratenbegrenzung:
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: too many certificates (5) already issued for this exact set of identifiers...
Der nützliche Protokollpfad war:
/shared/letsencrypt/acme.sh.log
Das war eine große Lektion. Aus Sicht des Browsers sah der Ausfall wie ein generisches Erreichbarkeitsproblem aus. Aber der eigentliche Blocker zu diesem Zeitpunkt war die Zertifikatsausstellung.
Der verwirrendste Teil war, dass der Installationsabschluss-/Endstatusblock dies nicht als handlungsorientierten Fehler anzeigte. Das finale nutzerseitige Symptom war nur, dass die Seite die Browserverbindung ablehnte.
Spätere Überprüfungen zeigten die Fehlerkette klarer:
ACME 429 Ratenbegrenzung
-> nullbyte .cer-Dateien unter /shared/ssl
-> nginx versucht, das nullbyte-Zertifikat zu laden
-> nginx-Start schlägt fehl
-> Ports 80/443 lehnen ab
-> Browser sagt: Verbindung abgelehnt
Feature-Anfrage, die in der Erfahrung begraben liegt:
Es wäre sehr hilfreich, wenn der Installer/Neuaufbau-Routine nach dem Zertifikatsschritt /shared/letsencrypt/acme.sh.log prüfen und Ratenbegrenzungsfehler wie diese anzeigte:
rateLimited
too many certificates
status: 429
Zum Beispiel:
Let's Encrypt-Ratenbegrenzung für diesen Hostnamen erreicht.
Warte bis zur in /shared/letsencrypt/acme.sh.log angezeigten retry-after-Zeit, bevor du es erneut versuchst.
Wiederholte Neuaufbauten helfen möglicherweise nicht.
Das würde Benutzern helfen, DNS-, SMTP-, app.yml-Quotierungs-, Docker- oder Firewallprobleme zu vermeiden, wenn das eigentliche Problem ACME ist.
Nach Ablauf der Ratenbegrenzung
Nachdem das Let’s Encrypt-Ratenbegrenzungs-Fenster abgelaufen war, sah ich immer noch eine verwirrende Domänenvalidierungssituation.
Der Installer meldete:
[4/5] Domänenkonfiguration wird überprüft
? Überprüfung deines Domainnamens...
? Verbindung zu forum.domain.tld erfolgreich.
Aber eine lokale DNS-Suche zeigte immer noch:
Resolve-DnsName -Name "forum.domain.tld"
mit:
Resolve-DnsName: forum.domain.tld : DNS-Name existiert nicht.
Wie können diese beiden Dinge koexistieren?
Ich kann mir mehrere Möglichkeiten vorstellen:
- Server und Arbeitsplatzrechner verwendeten verschiedene rekursive Resolver
- ein Resolver hatte veralteten NXDOMAIN-Cache
- DNS-Propagation war zu diesem Zeitpunkt teilweise
- der Installer überprüft etwas anderes als eine einfache DNS-Suche
- der Installer oder ein damit verbundener Dienst hatte Validierungszustand gecacht
Ich behaupte nicht, welche zutrifft. Ich stelle hauptsächlich fest, dass es aus Sicht des Benutzers schwierig ist, spätere DNS- oder Erreichbarkeitsfehler zu interpretieren, wenn der Installer „Verbindung erfolgreich“ sagt.
DNS-Isolierungstest
Um zu testen, ob dies nur langsame Cloudflare-Propagation war, fügte ich einen weiteren Eintrag in derselben Zone hinzu:
test.domain.tld
Innerhalb weniger Momente waren die Ergebnisse des öffentlichen DNS-Checkers grün.
Das ließ mich weniger zuversichtlich werden, dass die allgemeine Cloudflare-Propagation das gesamte Problem war. Es sah eher so aus, als wäre das Problem spezifisch für forum.domain.tld.
Vergleichsinstallationen
Ich hatte auch eine erfolgreiche Installation auf einem anderen Hostnamen:
discourse.domain2.tld
unter Verwendung desselben allgemeinen Installer-Pfads.
Ein weiterer Test-Hostname für DNS-Diagnosen war:
forum.domain3.tld
Die Vergleichsinstallationen waren es, die mich von „Der neue Installer ist kaputt“ wegbrachten und in Richtung „Hier ist etwas Hostname-spezifisches passiert.“ lenkten.
Aktuelle Theorie
Meine aktuelle Theorie, nicht bewiesen, ist, dass forum.domain.tld irgendwo außerhalb des Servers selbst einen hostnamenspezifischen gecachten/reservierten/erinnerten Zustand hatte.
Orte, über die ich nachdachte:
- DiscourseID
- der
yoursite.discourse.diy-Ablauf - Domänenvalidierung auf Installer-Seite
- eine gecachte Beziehung zwischen einem vorherigen Setup-Versuch und dem Hostnamen
Der Grund, warum ich über diese serviceunterstützten Wege nachdenke, ist, dass ich sie zuvor mit demselben Problem-Hostname versucht hatte, und das war auch der Weg, auf dem die wiederholten Versuche schließlich die Let’s Encrypt-Ratenbegrenzung trafen.
Wiederum ist dies eine Hypothese, keine Schlussfolgerung.
Fragen
- Kontaktiert der neue Installer während der Installation mit eigener Domain einen von Discourse kontrollierten Dienst?
- Reserviert, erinnert oder cached DiscourseID oder der
discourse.diy-Ablauf Hostnamen? - Gibt es einen Release-/Reset-Pfad für einen Hostnamen, der zuvor während der Einrichtung verwendet oder versucht wurde?
- Was überprüft
[4/5] Domänenkonfiguration wird überprüftgenau? - Könnte der Installer ACME-Ratenbegrenzungsfehler klarer anzeigen, bevor der Endstatus-/Ergebnisblock erscheint?
Was geholfen hätte
Drei Dinge hätten den Fehlerbehebungsweg viel klarer gemacht:
- Eine klare Installer-Warnung, wenn
/shared/letsencrypt/acme.sh.logeinen Ratenbegrenzungsfehler enthält. - Eine kurze Erklärung, was der Domänenvalidierungsschritt tatsächlich überprüft.
- Falls ein DiscourseID- /
discourse.diy- / Installer-seitiger Hostname-Cache oder -Reservierung existiert, eine sichtbare Möglichkeit, diesen Zustand zu inspizieren oder freizugeben.
Nochmals vielen Dank für die Arbeit am neuen Installer. Es fühlt sich wirklich an wie die richtige Richtung. Ich poste dies in diesem Geist: Es funktioniert wunderschön, wenn es funktioniert, und die raue Kante hier scheint die Art von Sache zu sein, die durch bessere Installer-Meldungen viel einfacher zu diagnostizieren wäre.
Geschrieben mit meinen Eingaben von meinem neuen besten Freund Codex.