Hallo, ich versuche, Discourse auf einer brandneuen Ubuntu 20.04 VM (habe auch CentOS Stream 9 und Ubuntu 22.04 und openSUSE MicroOS ausprobiert) in einem Testsystem zu installieren. Ich habe einige Erfahrung mit Discourse seit den Anfängen des Projekts und bewerte es jetzt für eine Migration. In diesem Fall wäre es für mydomain.tld (die Produktionsdomäne ist nur ein Forum und hat „forum“ im Namen und ist als solches bekannt, daher möchte ich definitiv kein discourse.mydomain.tld). Alle meine jüngsten Versuche, Discourse ohne Subdomain zu installieren, sind fehlgeschlagen. Ich weiß, dass es früher möglich war, da ich vor etwa 6 Jahren ein Discourse-Forum ohne Subdomain betrieben habe. Jetzt scheint die Installation erfolgreich abgeschlossen zu sein, aber die Seite wird nicht geladen. Unter Ubuntu wechselt es automatisch zu https://, auch wenn ich explizit http:// angebe, und es wird überhaupt nicht geladen. Und unter CentOS und MicroOS wird die Nginx-Willkommensseite von http:// geladen, und nichts wird mit https:// geladen.
Alle meine Versuche auf den oben genannten Betriebssystemen im selben VM funktionieren einwandfrei, wenn Discourse auf einer Subdomain unter discourse.mydomain.tld installiert wird, einschließlich der Let’s Encrypt-Autokonfiguration. Soweit ich das beurteilen kann, sind meine DNS-Einträge beim Domain-Registrar korrekt und ich habe eine ordnungsgemäße rDNS-Auflösung. Der Hostname des Servers in /etc/hosts zeigt 127.0.1.1 mydomain.tld mydomain, und das discourse-install-Skript wird mit der Domainnamen-Auflösungsprüfung erfolgreich ausgeführt.
Hier ist die Ausgabe von discourse-doctor. Ich habe auch das vollständige discourse-install-Protokoll, falls jemand daran interessiert ist:
DISCOURSE DOCTOR Sun Oct 9 13:32:47 UTC 2022
OS: Linux mydomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Found containers/app.yml
==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=mydomain.tld
SMTP_ADDRESS=mail.mydomain.tld
DEVELOPER_EMAILS=REDACTED
SMTP_PASSWORD=REDACTED
SMTP_PORT=587
SMTP_USER_NAME=admin@mydomain.tld
LETSENCRYPT_ACCOUNT_EMAIL=REDACTED
==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1
DOCKER PROCESSES (docker ps -a)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d6f7f53a81db local_discourse/app \"/sbin/boot\" 10 minutes ago Up 4 minutes 0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp app
Discourse container app is running
==================== PLUGINS ====================
- git clone https://github.com/discourse/docker_manager.git
No non-official plugins detected.
See https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb for the official list.
========================================
Discourse version at mydomain.tld: NOT FOUND
Discourse version at localhost: NOT FOUND
==================== MEMORY INFORMATION ====================
OS: Linux
RAM (MB): 2029
total used free shared buff/cache available
Mem: 1935 823 547 30 564 934
Swap: 2047 0 2047
==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 38G 8.0G 28G 23% /
==================== DISK INFORMATION ====================
Disk /dev/sda: 38.15 GiB, 40961572864 bytes, 80003072 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6643DB1B-E542-4DE1-A04C-C8EB4DAAD77E
Device Start End Sectors Size Type
/dev/sda1 528384 80003038 79474655 37.9G Linux filesystem
/dev/sda14 2048 4095 2048 1M BIOS boot
/dev/sda15 4096 528383 524288 256M EFI System
Partition table entries are not in disk order.
==================== END DISK INFORMATION ====================
==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Mail test skipped.
==================== DONE! ====================
Ohne Kenntnis der Domain ist es schwer zu helfen. Was passiert, wenn Sie versuchen, mit einem ausführlichen Curl von einem anderen Rechner im Internet zu Ihrer Domain.tld?
Hallo, danke für die Antwort. OK, das ist eine gute Idee, es scheint, dass die Verbindung nicht akzeptiert wird:
$ curl -v mydomain.tld
* Trying 1.2.3.4:80...
* connect to 1.2.3.4 port 80 failed: Connection refused
* Failed to connect to mydomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 80: Connection refused
$ curl -v https://mydomain.tld
* Trying 1.2.3.4:443...
* connect to 1.2.3.4 port 443 failed: Connection refused
* Failed to connect to mydomain.tld port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 443: Connection refused
Könnte es möglicherweise auf eine Einschränkung in der Discourse-Setup-Logik zurückzuführen sein, bei der erwartet wird, dass .tld etwas Gängiges wie .com oder .org ist? Ich habe nur eine 5-Dollar-.tech-Domain zum Testen erstellt.
Wo ist der Server gehostet? Was befindet sich zwischen ihm und dem Client?
Wenn Sie uns den FQDN mitteilen, können wir Ihnen bei der Fehlerbehebung helfen. So wie es jetzt ist, bitten Sie uns, Ihnen zu helfen, dies im Blindflug zu diagnostizieren, daher kann es eine Weile dauern, bis wir es eingrenzen können.
Ich habe discourse-setup verwendet. Ja, die Ports sind offen. Die Installation auf einer Subdomain funktioniert einwandfrei, und ich habe auch eine Docker-Installation eines Mailservers mit einer Weboberfläche auf derselben VM eingerichtet (aber später neu formatiert).
Hmm nein. Der Registrar ist Hover, die sind normalerweise ziemlich gut. Das ist bizarr, in 20 Jahren der Server-Einrichtung hatte ich nie Probleme mit Websites am Stamm einer Domain…
Vielen Dank, dass Sie mich darauf hingewiesen haben.
Sie könnten versuchen, Ihre NS auf Cloudflare umzustellen und von dort aus kostenlos zu testen, ob DNS das Problem ist.
Entschuldigen Sie die dumme Frage, meinen Sie damit, meinen lokalen DNS-Server auf Cloudflare einzustellen? (Ich benutze derzeit 8.8.8.8) Oder einen anderen DNS-Dienst für meine Domain zu verwenden?
Ich habe Hover danach gefragt, und sie haben mich auf Folgendes verwiesen:
Was Sie tun könnten, ist, einen Glue-Record zu verwenden. Dies macht Ihren Server zum DNS-Manager und leitet den Domainnamen an einen Nameserver weiter, den Sie mit Glue-Records einrichten können. Im Grunde wird Ihr Server zum Nameserver.
Das kommt mir immer noch wie eine falsche Fährte vor. Ich verstehe nicht, warum Discourse nicht im Stammverzeichnis der Domain funktionieren sollte, in der gleichen Situation, in der WordPress oder Drupal funktionieren würden?
Nein, ich meine, Sie müssen Ihre Domain nicht zwischen Registraren verschieben, aber Sie müssen die NS-Einträge bei Hover aktualisieren, damit Ihre Domain auf die DNS eines anderen Anbieters verweist, um diese Theorie zu testen. Derzeit sind sie auf ns1.hover.com und ns2.hover.com eingestellt.
Es ist ein sehr schneller und ziemlich schmerzloser Prozess. Wenn Sie sich für CloudFlare anmelden und versuchen, die Domain dort hinzuzufügen, erhalten Sie zwei neue Nameserver, die bei Hover eingegeben werden müssen. Hier gibt es eine Anleitung für die Hover-Seite:
Es ist eine Weile her, seit ich die Apex-Domain mit etwas anderem als Cloudflare verwendet habe. Ich werde dies in Kürze selbst testen, um zu sehen, ob ich andere Fallstricke entdecken kann. Die meisten Probleme mit der Apex-Domain gelten für CNAMEs, aber ich sehe jetzt, dass Sie einen A-Record verwenden.
Meine Vermutung ist, dass Sie eine Reihe von Neuerstellungen mit falsch konfigurierten Einstellungen durchgeführt haben und Let’s Encrypt nun aufgrund von Ratenbegrenzungen kein Zertifikat mehr ausstellen kann.
Wenn das der Fall ist, können Sie eine Woche warten oder versuchen, www als Subdomain zu verwenden, was heutzutage ohnehin eine gute Idee ist.
Sie können sich die Protokolle in /var/discourse/shared/log/var-log/nginx/access.log ansehen oder vielleicht
docker logs app
Ich erwarte, dass Sie Probleme mit dem nicht vorhandenen oder ungültigen Zertifikat sehen werden.
Fürs Erste habe ich SSL in der app.yml deaktiviert und einen Rebuild durchgeführt. Discourse wird jetzt auf Port 80 ohne Subdomain geladen.
Ich benutze jetzt auch Hetzner DNS als autorisierend. Ich bin mir nicht sicher, ob das den Unterschied gemacht hat oder ob es das fehlgeschlagene Let’s Encrypt-Zertifikatproblem war. Ich werde mich wieder melden, nachdem ich einen weiteren Rebuild durchgeführt habe, sobald ich wieder Let’s Encrypt-Zertifikate erstellen und SSL wieder aktivieren kann.
Wenn Sie mehr als ein paar Mal versucht haben, neu zu erstellen, werden Sie wahrscheinlich von Let’s Encrypt Raten-limitiert. Sie können dies umgehen, indem Sie Ihrer Zertifikat eine weitere Hostnamen hinzufügen.
Ja, aber ich glaube, dass diese Anweisungen nicht mehr funktionieren.
Der Grund, warum Sie keine Verbindung zu Port 443 herstellen, ist, dass das Zertifikat defekt ist und einen Fehler in Nginx verursacht.
Vielen Dank an alle für die schnellen Antworten. Es scheint, dass es tatsächlich nur eine Frage des Let’s Encrypt-Ratenlimits war. Ich habe eine neue Domain bei Hover erstellt und dieses Mal hat die Discourse-Installation ohne Subdomain einwandfrei funktioniert.
Hallo @pfaffman oder wer auch immer, dumme Frage: Wird das Let’s Encrypt-Zertifikat jedes Mal aktualisiert, wenn ich ./launcher rebuild app ausführe? Mit anderen Worten, werde ich auf weitere Ratenbegrenzungen stoßen, wenn ich ein wenig mit Versuch und Irrtum experimentiere und meine Discourse-Instanz mehrmals hintereinander neu erstelle (aber nicht komplett von vorne anfange)? Vielen Dank.