Ich glaube nicht, dass das noch zutrifft.
Genau, @jomaxro. Deshalb habe ich gesagt:
Oh. Entschuldigung, ich habe diese Änderung übersehen.
Wenn der Benutzer also keine E-Mail-Adresse für Let’s Encrypt-Anmeldungen angibt, aktiviert discourse-setup Let’s Encrypt nun blind, ohne zu prüfen, ob die Domain auf den aktuellen Server aufgelöst wird. Wenn jedoch eine E-Mail-Adresse angegeben wird, erfolgt die Prüfung. Das scheint keine besonders gute Idee zu sein.
Warum HTTPS erzwingen, wenn keine gültige Domain vorhanden ist? Wenn der Plan ist, HTTPS für alle jederzeit zu erzwingen, sollten wir prüfen, ob der Domainname gültig ist, und den Vorgang ablehnen, anstatt eine fehlerhafte Installation zu ermöglichen.
So wie es derzeit funktioniert, scheint discourse-setup erfolgreich zu sein, wenn keine Let’s Encrypt-E-Mail-Adresse angegeben wird und die Domain nicht auf den Server aufgelöst wird. Es startet einen Webserver, der keine Verbindungen akzeptiert, da Nginx kein Zertifikat findet. Ich denke, es wäre besser, nicht nach einer Let’s Encrypt-E-Mail-Adresse zu fragen, stattdessen die (erste?) Entwickler-E-Mail für Let’s Encrypt zu verwenden und dennoch den DNS-Test durchzuführen. Allerdings gehört das nicht mehr in dieses Thema.
Nein, so funktioniert Let’s Encrypt nicht. Die E-Mail-Adresse hat nichts mit der Domänenvalidierung zu tun. Sie dient dazu, den Benutzer zu benachrichtigen, wenn sein Zertifikat bald abläuft und nicht verlängert werden kann. Die Validierung erfolgt immer über DNS.
Let’s Encrypt kann kein Zertifikat für eine Adresse ausstellen, die die Anforderungen für die Validierung nicht erfüllt. Wenn dies der Fall wäre, würde das gesamte LE-System über Nacht zusammenbrechen.
Nein. So funktioniert discourse-setup (oder funktionierte es zumindest). Früher schützte es Benutzer davor, ein Zertifikat anzufordern, wenn es ziemlich sicher war, dass dies scheitern würde. Jetzt fährt es fort, fordert ein Zertifikat an, wenn ein Erfolg unmöglich ist, und hat keine Möglichkeit, dem Benutzer mitzuteilen, dass es nicht funktioniert hat. Es schlägt also nun stillschweigend ohne Warnung fehl.
Wiederum: Warum sollte es fehlschlagen? Eine E-Mail ist für die Domainverifizierung nicht erforderlich.
Beim Fehler wurde ebenfalls keine E-Mail generiert.
Die E-Mail dient lediglich dazu, den Benutzer später darüber zu informieren, falls Let’s Encrypt beim Erneuern scheitert und ein Zertifikat abläuft. Wenn das Zertifikat problemlos erneuert wird, erhalten sie niemals eine E-Mail.
Ich glaube nicht, dass dies die Absicht der Änderung war. Die Absicht war, SSL unabhängig davon zu aktivieren, ob eine E-Mail-Adresse angegeben wurde. Wir sollten dennoch die Domainauflösung überprüfen. cc @Falco
Es wird fehlschlagen, wenn der Domainname nicht auf den Host aufgelöst wird. Die E-Mail-Adresse ist irrelevant, aber wenn eine vorhanden ist, wird Discourse den Benutzer warnen, falls die Adresse nicht aufgelöst werden kann.
Die Domänenauflösung muss @falco bestehen, andernfalls sollte die Einrichtung abgebrochen werden. Das ist eine schlechte Änderung.
Also habe ich einige Änderungen in einem Branch vorgenommen. So wird es funktionieren:
Bei Verwendung eines falschen Hostnamens:
root@droplet:/var/discourse# ./discourse-setup
Hostname für dein Discourse?: bad-domain.com
Prüfe deinen Domainnamen . . .
WARNUNG:: Dieser Server scheint unter bad-domain.com:443 nicht erreichbar zu sein.
Eine Verbindung zu http://bad-domain.com (Port 80) schlägt ebenfalls fehl.
Dies deutet darauf hin, dass bad-domain.com auf die falsche IP-Adresse aufgelöst wird
oder der Datenverkehr nicht an deinen Server weitergeleitet wird.
Google: "offene Ports DEINER CLOUD-DIENSTLEISTUNG" für Informationen zur Lösung dieses Problems.
Wenn du trotzdem fortfahren möchtest, musst du cp samples/standalone.yml containers/app.yml ausführen
und die Datei containers/app.yml manuell bearbeiten.
Bei Verwendung eines korrekten Hostnamens:
root@droplet:/var/discourse# ./discourse-setup
Hostname für dein Discourse?: good-domain.com
Prüfe deinen Domainnamen . . .
Verbindung zu good-domain.com erfolgreich.
E-Mail-Adresse für Admin-Konto(s)? :
Änderungen sind unter folgendem Link pending:
Sieht das gut aus, @pfaffman @codinghorror?
Kommentar dazu, warum diese Änderung überhaupt nötig war
Zunächst bin ich überrascht, dass es in den fast drei Monaten, seitdem dies so gehandhabt wird, nicht zahlreiche Beschwerden gegeben hat. Selbst das Thema, das mich auf diese Änderung aufmerksam gemacht hat, hatte aufgrund dieser Änderung keine Schwierigkeiten. Vielleicht ist das also weniger wichtig, als ich denke.
Das erste, was ich nicht wirklich verstehe, ist: Wollt ihr wirklich, dass es unmöglich wird, eine http-only-Website mit discourse-setup einzurichten? Ich vermute, sie müssen bereits eine Reihe von DNS-Einstellungen vorgenommen haben, damit die E-Mail-Funktion arbeitet. Vielleicht ist es also kein so großes Problem, sie auch den A-Eintrag erstellen zu lassen.
Feedback zur Änderung
Sofern ihr keine Änderung vorgenommen habt, die mir entgangen ist, erstellt das Skript app.yml, bevor es Fragen stellt. Ihr könntet also einfach etwas wie „Die Installation von Discourse ohne DNS-Konfiguration wird nicht unterstützt. Um ohne DNS-Konfiguration fortzufahren, bearbeitet app.yml entsprechend euren Bedürfnissen und führt ./launcher rebuild app aus
Ja.
Ich habe zu dieser Änderung keinerlei Beschwerden erhalten, und seit sie live ist, gibt es nicht mehr viele Discourse-Instanzen, die nur HTTP verwenden. Denn wenn man etwas als OPTIONAL bezeichnet, überspringen es alle ohne weitere Überlegungen. Meiner Meinung nach ist dies eine großartige Änderung, um sichere Standards für Discourse zu gewährleisten, worum es uns im 30-Minuten-Leitfaden geht.
[quote=“pfaffman, post:11, topic:141911”]
Sofern du keine Änderung vorgenommen hast, die mir entgangen ist, erstellt das Skript app.yml, bevor es mit den Fragen beginnt. Du könntest also einfach etwas wie „Die Discourse-Installation ohne DNS-Konfiguration wird nicht unterstützt. Um ohne DNS-Konfiguration fortzufahren, bearbeite app.yml entsprechend deinen Bedürfnissen und führe ./launcher rebuild app aus
tl;dr: Ja, mit der kleinen sprachlichen Anpassung, die ich empfohlen habe, sieht das für mich gut aus.
Zustimmung. Keine Beschwerden! Klingt nach einem Erfolg.
Nein! Das hat sie nicht. (!) Ich habe nur sozusagen bemerkt, dass die Seiten nicht erreichbar waren, bevor ich die zweite Installationsphase durchgeführt habe, die HTTPS aktiviert. Und meine Einrichtung ist nicht deine Verantwortung. (Oh, JETZT wird mein Skript kaputtgehen, aber die Installation vor der Einrichtung von DNS zu unterlassen, ist ohnehin besser. Ich habe seit mindestens einem Jahr keine nicht-HTTPS-Installation mehr durchgeführt.)
Der Grund, warum es mir gefallen hat, dass mein Skript discourse-setup verwendet, ist, dass es besonders sicherstellt, dass meine Installationskunden eine Standard-Installation erhalten. Und wenn jemand sagt: „Ich habe eine Installation durchgeführt, aber sie hat nicht funktioniert,
Cool, danke für die Analyse und den Review!
Ich habe den PR gemergt, sodass wir jetzt immer DNS validieren.