Hallo,
ich bin neu bei Discourse und bin während der Installation hängen geblieben. Ich habe eine Ubuntu Server 18.04-VM erstellt und mich dann grob an die Installationsanweisungen gehalten.
Mit „groß
Ist Nginx auf dem Server installiert? Das sollte nicht der Fall sein. Aber discourse-setup sollte das erkannt haben. Sind Sie sicher, dass Ihre DNS-Einstellungen korrekt sind?
Nginx ist auf dem Server nicht installiert. Was die DNS-Konfiguration betrifft, so habe ich einen A-Record und einen PTR-Record für den Server eingerichtet. Welche weiteren Anforderungen gibt es?
Marc.
Die einzige Möglichkeit, diese Seite zu sehen, besteht darin, dass Sie DNS auf den falschen Server umgeleitet haben oder dass NGINX außerhalb des Containers läuft, Port 80 belegt und verhindert, dass der Container antwortet.
Wenn ich meinen Webbrowser direkt auf die IP-Adresse des Servers richte, wird ebenfalls die Nginx-Willkommensseite angezeigt.
Bei einer SSH-Verbindung zum Ubuntu-Server:
marc@community:~$ locate nginx
/var/discourse/image/base/install-nginx
marc@community:~$
Zusätzlich, während ich auf dem Ubuntu-Server bin:
sudo find / -iname "*nginx*"
…viele Dateien unter /var/lib/docker/overlay2…
/var/discourse/image/base/install-nginx
/var/discourse/shared/standalone/letsencrypt/deploy/nginx.sh
/var/discourse/shared/standalone/log/var-log/nginx
Zeigen Sie uns das Ergebnis von:
lsof -i:80
Der Befehl lsof -i:80 liefert keine Ausgabe.
Dann wird also nichts auf Port 80 gehört?
Wenn Docker auf :80 lauschen würde – was bei einer erfolgreichen Installation der Fall sein sollte (und für nginx innerhalb des Containers erforderlich ist, um etwas zu sehen) – würdest du Folgendes sehen:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
docker-pr 890 root 4u IPv6 961922 0t0 TCP *:http (LISTEN)
Wenn nginx nicht außerhalb des Containers installiert ist und Docker nicht auf diesem Port lauscht, dann ist die einzige andere Möglichkeit, dass du die nginx-Willkommensseite siehst, eine Fehlkonfiguration des Netzwerks.
Sie scheinen recht zu haben. Ausgabe von nmap auf meinem Laptop zur IP-Adresse des Servers:
Starting Nmap 7.01 ( https://nmap.org ) at 2020-04-10 23:34 AEST
Nmap scan report for community.aureus-group-sb.com (192.168.12.35)
Host is up (0.0010s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
MAC Address: 0C:8B:FD:CD:AF:EB (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds
Denken Sie daran: Ein Netzwerkproblem kann, ist aber nicht beschränkt auf:
- Eine Richtlinie auf der VM, die den Zugriff blockiert (ufw oder ähnlich)
- Eine Richtlinie auf dem virtuellen Server, die den Zugriff blockiert (Netzwerkmodus nicht korrekt konfiguriert)
- Eine Richtlinie im Netzwerk, die nicht korrekt konfiguriert ist (ACLs zwischen Subnetzen)
- Falsch konfiguriertes DNS
Es ist nur ein Discourse-Problem, wenn keines der oben genannten Punkte zutrifft. Sie folgen zwar der Standardinstallation, geben aber selbst zu, dass Sie in einer Umgebung installieren, die alles andere als standardisiert ist.
Wenn Ihre Organisation die 5 $/monatlich aufbringen kann, könnte es rein zeitlich betrachtet günstiger sein, dies in der Cloud zu betreiben und die Cloud-VPS-Firewall so einzuschränken, dass sie nur Seiten an Ihre Umgebung zurückliefert.
Im Moment geht es mir hauptsächlich um den Lernaspekt beim Einrichten dieses Systems. Sobald ich das im Griff habe, werden wir uns sicherlich die Hosting-Optionen ansehen.
Bezüglich der von Ihnen aufgeführten Netzwerkaspekte:
- ufw ist inaktiv und iptables läuft: Ich habe keine Änderungen an der Standardinstallation von Ubuntu Server vorgenommen.
** Bei der Betrachtung der iptables-Konfiguration hat die Eingangs-Kette eine Richtlinie, alle Pakete zu akzeptieren, ebenso wie die Ausgangs-Kette. Die Weiterleitungs-Kette enthält einige Docker-bezogene Verweise (siehe unten). - Das einzige vNIC des VMs ist im Brückenmodus konfiguriert – es verbindet sich direkt mit dem physischen Netzwerk.
- Der Laptop, an dem ich arbeite, und das VM befinden sich im selben Subnetz.
- Ich bin mir nicht sicher, was die genauen Anforderungen für DNS sind. Ich habe versucht, diese Spezifikationen zu finden, konnte aber kein endgültiges Dokument ausmachen. Was DNS betrifft, so kann ich den Server jedoch sowohl per Name, FQDN als auch per IP-Adresse anpingen. Ich bin mir nicht sicher, ob im Zusammenhang mit DNS noch etwas anderes eingerichtet sein muss.
Welche Netzwerkrichtlinie besteht zwischen der VM und der Außenwelt?
Wenn der git pull erfolgreich war und Sie discourse-setup ausführen konnten, was hätte dann verhindert, dass eine Verbindung zu GitHub hergestellt wird, um den Inhalt des Containers herunterzuladen?
Wenn die Serveradresse nicht öffentlich erreichbar ist, würde Let’s Encrypt fehlschlagen. Haben Sie die YML-Datei geändert, um HTTPS zu deaktivieren?
Die VM kann eine Verbindung zum Internet herstellen, und es gibt keine Einschränkungen beim Zugriff auf GitHub. Während der Ausführung von discourse-setup habe ich die Option E-Mail-Adresse für das Let’s Encrypt-Konto? (ENTER zum Überspringen) [me@example.com]: leer gelassen.
Ich habe keine YML-Dateien geändert.
Wenn Sie dieses Feld leer lassen, werden Sie nicht über Zertifikatsprobleme benachrichtigt. Dies verhindert jedoch nicht, dass der Container versucht, Let’s Encrypt zu aktivieren.
Ok, wir haben einige größere Probleme hervorgehoben, die sich aber nicht auf den OP beziehen. Irgendwo in Ihrem Netzwerk läuft nginx und zeigt eine Seite an, aber laut Ihren Tests auf der virtuellen Maschine ist nginx nicht installiert und Docker hört nicht zu.
Sobald Sie herausgefunden haben, wie das passiert, besteht der nächste Schritt darin, die YML-Datei korrekt zu konfigurieren. Zunächst müssen Sie die Quelle dieser Seite finden.
Ich habe das Gleiche gedacht. Lass mich etwas recherchieren, um herauszufinden, woher diese Seite stammt.
Hier ist das, was ich gelernt habe. Wenn ich den Server herunterfahre, kann ich ihn nicht anpingen (IP-Adresse, Name und FQDN). Wenn ich die IP-Adresse aufrufe, erhalte ich die Standardseite „Keine Verbindung
Ich habe den Container mit docker exec -it <cont.id> /bin/bash geöffnet und die Ausgabe von ps aux geprüft. Dort befand sich folgende Zeile:
root 2030 0.2 0.0 2160 1328 ? Ss 14:10 0:01 runsv nginx
Das deutet darauf hin, dass nginx innerhalb des Containers läuft. Die Ausgabe von nsenter -t 1446 -n netstat -plnt zeigt jedoch Folgendes:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 3606/unicorn master
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN 3590/postmaster
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 3591/redis-server *
tcp6 0 0 :::5432 :::* LISTEN 3590/postmaster
tcp6 0 0 :::6379 :::* LISTEN 3591/redis-server *
Bedeutet das, dass der Container nicht auf den Ports 80 und 443 lauscht?