WARNUNG: Port 443 des Computers scheint über den Hostnamen nicht erreichbar zu sein

Ich führe dies aus, um Discourse einzurichten: ./discourse-setup, aber ich erhalte den Fehler im Bild.
Wie kann ich diesen Fehler beheben? Ich verwende Ubuntu 18.04

Meine DNS-Einträge:

Mein sudo ufw status verbose:

Sie haben ein nicht druckbares Zeichen im von Ihnen eingegebenen Hostnamen:

image

Versuchen Sie es erneut, aber stellen Sie sicher, dass Sie es sauber eingeben. Wenn Sie kopieren/einfügen, stellen Sie sicher, dass die Quelle sauber ist.

1 „Gefällt mir“

Es gab keine Änderung.

Anscheinend läuft auf dieser IP bereits WordPress.

Ja, WordPress ist installiert. Kann ich nicht beides auf demselben Server nutzen?

Das ist möglich, aber nicht einfach. Du kannst discourse-setup nicht verwenden. Ich empfehle dir, es zunächst auf einem Server auszuprobieren, auf dem nichts anderes läuft.

Andere Websites auf derselben Maschine wie Discourse betreiben.

1 „Gefällt mir“

Ich habe diese Schritte befolgt, aber keine Ergebnisse erhalten. Gleichzeitig verwende ich WEBMIN.

Hat jemand noch andere Ideen?

Wenn die Anweisungen im von mir früher verlinkten Thema für dich nicht funktionieren, ist der einfachste Weg, Discourse auf einem eigenen Server zu betreiben.

Es wird sehr schwierig sein, es mit Webmin zum Laufen zu bringen.

Ich weiß, dass es schwierig sein wird, aber ich sehe mich nicht als Amateur. Ich habe die von dir verlinkten Anweisungen ausprobiert. Gibt es noch weitere Links, die ich lesen sollte?

Es gibt einige #howto-Themen zu diesem Problem.

1 „Gefällt mir“

Hey @Murto,

Nur als Hinweis: Ich finde, Discourse als Backend-Rails-Anwendung lässt sich viel einfacher einrichten, wenn man Rails so konfiguriert, dass es einen Unix-Domain-Socket anstelle eines TCP/IP-Ports verwendet, und die Discourse-Anwendung hinter einem Reverse-Proxy betreibt.

Auf diese Weise werden die TCP/IP-Ports nur über den Reverse-Proxy freigegeben, während die Discourse-Anwendung (und der Container) über einen Unix-Domain-Socket erreichbar ist. So kannst du beliebig viele Discourse-Container-Instanzen ausführen, ohne dich um Konflikte bei den TCP/IP-Sockets kümmern zu müssen. Meiner Meinung nach ist dies eine sehr saubere Methode, Discourse zu betreiben.

Auf dieser Seite gibt es zahlreiche HOWTOs und Tutorials, die dir helfen, dies einzurichten, falls du feststeckst und die Richtung etwas ändern möchtest. In der Discourse-Distribution findest du eine „socket“-Vorlage, mit der du den „Discourse-Teil der Konfiguration“ einrichten kannst. Anschließend richtest du einfach den Reverse-Proxy ein (dafür gibt es unzählige Tutorials) und „los geht’s“!

Ich hoffe, das hilft.

4 „Gefällt mir“

Ich konnte das Problem immer noch nicht beheben. Kann mir jemand das im Detail erklären? :roll_eyes:

Probier das aus:

netstat -lnptu | grep :443

Und dann:

kill -9 PID (ersetze PID durch die ausgegebene Nummer des obigen Befehls)

1 „Gefällt mir“

Ich empfehle, einen Reverse-Proxy auf Ihrem Server zu betreiben, der dem Internet zugewandt ist, und diesen so konfigurieren, dass er je nach Hostanfrage entweder an WordPress oder Discourse weiterleitet.

Beispielsweise können Sie einen Nginx-Dienst mit den Ports 80 und 443 auf dem Host ausführen und die Anfragen an blog.yourdomain an den WordPress-Dienst weiterleiten (entweder über einen internen Port auf Ihrem Host, falls Sie Apache + WordPress verwenden – in diesem Fall können Sie an den Apache-Port wie 8080 weiterleiten oder FastCGI nutzen).

Anschließend können Sie auf demselben Server Discourse betreiben, wobei Sie sicherstellen müssen, dass die Ports in app.yml auf ungenutzte Ports auf dem Host geändert werden, z. B. 8081, oder – wie von @neounix erwähnt – einen Unix-Socket verwenden. Die Anfragen an forum.yourdomain werden dann an diesen Port oder den Socket weitergeleitet. Um Discourse zu starten, müssen Sie im Discourse-Verzeichnis (normalerweise /var/discourse) den Befehl ./launch rebuild app ausführen.

In diesem Fall sollten Sie discourse-setup nicht ausführen, um eine 2-GB-Swap-Datei zu erstellen (diese wird hauptsächlich für Upgrades verwendet, die möglicherweise mehr Speicher benötigen, obwohl Sie sie eventuell nicht benötigen, wenn Ihr Server über viel Arbeitsspeicher verfügt), und auch die Datei app.yml nicht automatisch generieren lassen. Stattdessen sollten Sie dies selbst vornehmen. Falls Sie nicht wissen, was Sie in die Datei app.yml eintragen sollen, empfehle ich, die empfohlene Installation auf einem separaten Server durchzuführen – selbst wenn nur, um sich mit Discourse vertrauter zu machen und die generierte app.yml-Datei zu sehen, die Sie dann auf Ihrem geteilten Server verwenden können (dabei aber daran denken, die Ports anzupassen oder zu entfernen, falls Sie den Socket-Ansatz verwenden).

Ich rate Ihnen, eines der #howto-Themen dazu zu verfolgen, falls Sie nicht weiterkommen.

2 „Gefällt mir“

Kannst du erklären, wie der Reverse-Proxy-Prozess funktioniert? Ich habe zwar gelernt, was zu tun ist, aber ich weiß nicht, wie man es umsetzt.

Ich habe kein Beispiel zur Hand, da ich keinen Proxy davor verwende, obwohl ich glaube, dass ich dies vor einiger Zeit implementiert habe. Auf jeden Fall gibt es kein Geheimnis; es sollte so funktionieren wie bei anderen Reverse-Proxys. Im Folgenden finden Sie eine Übersicht darüber, was mit Ports (und nicht mit Sockets) zu tun ist:

  1. Stellen Sie sicher, dass ein WordPress-Dienst auf einem Port läuft, der nicht 80 oder 443 ist (Beispiel: 8443) und funktioniert. Sie können versuchen, ihn zunächst dem Internet auszusetzen, um zu prüfen, ob er funktioniert.

  2. Machen Sie dasselbe mit Discourse und weisen Sie verschiedene Ports zu.

Änderung:

expose:
  - "80:80"   # http
  - "443:443" # https

Zu (zum Beispiel):

expose:
  - "8081:80"   # http
  - "8444:443" # https

In Ihrer app.yml-Datei (falls Sie keine haben, empfehle ich, Discourse zunächst auf einem eigenständigen Server gemäß dem offiziellen Leitfaden laufen zu lassen, um zu sehen, wie es funktioniert, und die generierte app.yml-Datei unter /var/discourse/containers/ anzusehen). Hier ist ein Beispiel für die app.yml-Datei: discourse_docker/samples/standalone.yml at master · discourse/discourse_docker · GitHub

  1. Installieren Sie nginx und fügen Sie in der Konfigurationsdatei die Proxy-Direktiven hinzu. Diese sollten ähnlich wie im folgenden Beispiel-Auszug aussehen:
upstream blog {
    server localhost:8080;
}

server {
    server_name blog.barinaklar.com;
    server_tokens off;
    listen 80;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://blog.barinaklar.com$request_uri;
    }
}

server {
    server_name blog.barinaklar.com;
    server_tokens off;
    listen 443 ssl;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass           http://blog;
        proxy_redirect		 off;
        proxy_set_header	 Host $host;
        proxy_set_header	 X-Real-IP $remote_addr;
        proxy_set_header	 X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header	 X-Forwarded-Host $server_name;
        proxy_set_header	 X-Forwarded-Proto $scheme;
    }
}

upstream forum {
    server localhost:8081;
}

server {
    server_name forum.barinaklar.com;
    server_tokens off;
    listen 80;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://forum.barinaklar.com$request_uri;
    }
}

server {
    server_name forum.barinaklar.com;
    server_tokens off;
    listen 443 ssl;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass           http://forum;
        proxy_redirect		 off;
        proxy_set_header	 Host $host;
        proxy_set_header	 X-Real-IP $remote_addr;
        proxy_set_header	 X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header	 X-Forwarded-Host $server_name;
        proxy_set_header	 X-Forwarded-Proto $scheme;
    }
}

Dies setzt voraus, dass WordPress auf Port 8080 und Discourse auf Port 8081 läuft. Stellen Sie sicher, dass eine Firewall den Zugriff auf diese Ports blockiert (Cloud-Anbieter blockieren standardmäßig meist alle Ports außer 22, sodass dies möglicherweise nicht erforderlich ist).

In diesem Fall sind Sie für die Generierung der SSL/TLS-Zertifikate verantwortlich (Sie können dies mit Certbot tun, das regelmäßig in einem Cron-Job ausgeführt wird; daher habe ich bereits die Pfade /.well-known/acme-challenge/ in der nginx-Konfiguration aufgenommen).


Wie oben erwähnt, ist dies nur eine Übersicht, und es könnte sein, dass ich etwas übersehen habe. Sie sollten besonders auf die Basis-URL achten, da sich die Ports geändert haben (um zu prüfen, ob nicht versucht wird, den Benutzer zu https://yourdomain:8081 statt zu https://yourdomain weiterzuleiten, und ggf. Änderungen vornehmen, damit es funktioniert).

Dies ist möglicherweise nicht erforderlich, wenn WordPress in einem Container mit Port 80 oder 443 innerhalb des Containers läuft. Bei Discourse sollte es ebenfalls in Ordnung sein. Das Problem, das auftreten kann, betrifft https; es könnte zu http weitergeleitet werden, da im Proxy der http-Port verwendet wird. Prüfen Sie daher, ob dies der Fall ist, und beheben Sie es gegebenenfalls.

3 „Gefällt mir“

Vielen Dank für Ihre Hilfe. Ich werde mich bewerben und die Transaktionen informieren.