Überprüfe deinen Domainnamen . . .
WARNUNG: Port 443 des Computers scheint nicht über den Hostnamen ***.com erreichbar zu sein.
WARNUNG: Die Verbindung zu http://shoutam.com (Port 80) schlägt ebenfalls fehl.
Dies deutet darauf hin, dass ***.com zu einer IP-Adresse aufgelöst wird, die diese Maschine, auf der du Discourse installierst, nicht erreicht.
Das Erste, was du tun solltest, ist zu bestätigen, dass ***.com zur IP-Adresse dieses Servers aufgelöst wird.
Dies machst du normalerweise dort, wo du die Domain gekauft hast.
Wenn du sicher bist, dass die IP-Adresse korrekt aufgelöst wird, könnte es sich um ein Firewall-Problem handeln.
Eine Websuche nach “Ports öffnen DEIN CLOUD-SERVICE” könnte helfen.
Dieses Tool ist nur für die gängigsten Installationen konzipiert. Wenn du das obige Problem nicht lösen kannst, musst du containers/app.yml selbst bearbeiten und dann Folgendes eingeben:
./launcher rebuild app
Kann mir bitte jemand helfen, das zu lösen? Ich benutze Cloudflare.
Sie können es jedoch immer noch nicht installieren, da Let’s Encrypt direkten Zugriff auf die Ports 80 und 443 benötigt, um ein Zertifikat auszustellen.
Nachdem Sie Ihr Zertifikat erhalten und Discourse installiert haben, können Sie nach Themen suchen, wie Sie es mit Cloudflare dazwischen zum Laufen bringen (was die Verwendung der Cloudflare-Vorlage beinhaltet).
Guter Fang, das ist nicht Let’s Encrypt, sondern der ACME.sh-Client, der in Discourse verwendet wird und direkten Zugriff benötigt (Certbot hat DNS-Plugins, die zusätzliche Arbeit erfordern, aber diese Anforderung eliminieren). Ich habe nicht darüber nachgedacht, weil praktisch jede Discourse-Installation, die ich seit Jahren bereitgestellt habe, die Verwendung eines Reverse-Proxys erforderte, weshalb die interne SSL-Vorlage von Anfang an deaktiviert ist.
Ich bin mir nicht sicher, was Sie mit entfernt meinen, aber normalerweise dauert es ein paar Stunden, bis sich DNS verbreitet hat. Es könnte sich lohnen, eine Weile zu warten und es dann erneut zu versuchen.
Hier fehlen ziemlich viele Informationen, als dass wir wirklich mehr Hilfe anbieten könnten.
Heutzutage schlägt Cloudflare im Proxy-Modus (orangefarbene Wolke) nicht fehl, solange HTTPS nicht auf “strict” eingestellt ist, da sowohl :80 (HTTP) als auch :443 (HTTPS) direkt an den Server weitergeleitet werden.
Strict erzwingt die Umleitung des Traffics auf :80 zu SSL, und somit würde die Herausforderung fehlschlagen.
Es ist gut möglich, dass Sie eines oder mehrere der Grundlagen übersehen haben, aber ohne uns mitzuteilen, wo sich der VPS befindet und was Sie in DNS konfiguriert haben, werden wir bestenfalls raten, was hier vor sich geht.
Einige Anbieter verlangen, dass ACLs zwischen ihrem VPS und der Außenwelt eingerichtet werden – haben Sie überprüft, ob diese Ports extern geöffnet sind? Sind Sie sicher, dass der ‘a’-Eintrag, den Sie zu DNS hinzugefügt haben, auf die zugewiesene öffentliche IP-Adresse verweist? Gibt es Firewalls?
Das stimmt zwar bei einigen DNS-Anbietern, aber Cloudflare erzwingt eine TTL von 300 Sekunden für jede Adresse, die sie proxyen. Das bedeutet, dass alle vorgelagerten DNS-Server die alten Einträge innerhalb von fünf Minuten nach der Änderung abgelaufen haben werden.
Die Vorlage stellt lediglich sicher, dass die richtigen Client-IPs aus den zusätzlichen Header-Informationen extrahiert werden, die Cloudflare im Proxy-Modus hinzufügt. Sie ist für den Installationsprozess nicht wirklich relevant.
Wenn Sie mehrmals mit der orangefarbenen Wolke einen Neuaufbau durchgeführt haben, haben Sie wahrscheinlich die Ratenbegrenzungen von Let’s Encrypt erreicht. Die einfachen Lösungen sind, eine andere Subdomain zu verwenden oder eine Woche zu warten.
Funktioniert es, wenn ich den Droplet zerstöre und einen neuen erstelle?
Bitte beachten Sie, dass ich Discourse bereits zuvor erfolgreich installiert hatte, diesen Droplet aber wegen eines Fehlers in der Admin-E-Mail zerstört habe. Jetzt kann ich Discourse nicht mehr mit demselben Prozess installieren, den ich zuvor verwendet habe.
Diesen Thread wiederbeleben in der Hoffnung, dass die sachkundigen Kommentatoren mir auch helfen können.
Ich erhalte denselben Fehler wie der ursprüngliche OP.
Ich verwende derzeit Unraid und habe einen Container, der Nginix Proxy Manager ausführt. Firewall-Ports sind so konfiguriert, dass der gesamte Port 80/443-Verkehr an meinen NPM-Container gesendet wird. Ich habe erfolgreich viele Docker-Container mit meinem NPM-Container eingerichtet und alles hat gut funktioniert.
Ich habe eine UbuntuServer-VM installiert, die anfängliche Konfiguration durchlaufen, eine statische IP für die VM eingerichtet, Docker installiert und dann Discourse heruntergeladen, aber das Setup-Skript ist wie beim OP fehlgeschlagen.
Wenn Sie Nginx Proxy Manager verwenden möchten, müssen Sie Ihre app.yml von Hand konfigurieren. Sie können entweder Ihren Proxy lange genug ausschalten, damit discourse-setup ihn zuerst ausführen kann (Sie müssen trotzdem einige Dinge von Hand ändern), oder Sie kopieren aus samples/standalone.yml.
Ja, nach meinem Verständnis werden die YML-Dateien nach der Ausführung und Fertigstellung von discourse-setup gefüllt. Um dies zu erreichen, kann ich vielleicht den WAN-Verkehr auf meiner Firewall zu meiner UbuntuVM leiten, auf der ich Discourse installiere, und dann, nachdem es eingerichtet ist, meinen Verkehr zurück zum Reverse-Proxy leiten und dann meine app.yml-Datei konfigurieren.
Sie haben dies vergessen. Sie können die Option --skip-connection-test verwenden, um diesen Test zu überspringen und ihn auszuführen. Sie müssen die Ports immer noch von Hand bearbeiten, aber so können Sie das Skript verwenden, um die Datei zu erstellen und Ihre SMTP-Anmeldeinformationen einzugeben.