ATTENZIONE: La porta 443 del computer non sembra essere accessibile tramite nome host

Sto eseguendo questa operazione per configurare Discourse: ./discourse-setup, ma sto ricevendo l’errore mostrato nell’immagine.
Come posso risolvere questo errore? Uso Ubuntu 18.04

I miei record DNS:

Il mio sudo ufw status verbose:

Hai inserito un carattere non stampabile nel nome host digitato:

image

Riprova, assicurandoti di digitare il nome in modo corretto. Se stai copiando e incollando, verifica che l’origine sia pulita.

1 Mi Piace

Non ci sono stati cambiamenti.

Sembra che su quell’indirizzo IP sia già in esecuzione WordPress.

Sì, WordPress è installato. Non posso usarli entrambi sullo stesso server?

È possibile, ma non è facile. Inoltre, non puoi utilizzare discourse-setup. Ti consiglio di provarlo prima su un server che non esegue altre applicazioni.

Eseguire altri siti web sulla stessa macchina di Discourse.

1 Mi Piace

Ho seguito questi passaggi ma non ho ottenuto risultati. Nel frattempo uso WEBMIN.

Qualcuno ha altre idee?

Se le istruzioni nell’argomento a cui ho linkato in precedenza non funzionano per te, la cosa più semplice è eseguire Discourse su un server dedicato.

Sarà molto difficile farlo funzionare con Webmin.

So che sarà difficile, ma non mi considero un principiante. Ho provato le istruzioni che hai linkato. Ci sono altri link che dovrei leggere?

Ci sono alcune guide su come affrontare il problema.

1 Mi Piace

Ciao @Murto,

A titolo informativo, trovo che Discourse, in quanto applicazione backend Rails, sia molto più semplice da configurare se si imposta Rails per utilizzare una socket di dominio Unix invece di una porta TCP/IP; e si configura l’applicazione Discourse dietro un proxy inverso.

In questo modo, le porte TCP/IP sono esposte solo tramite il proxy inverso, mentre l’applicazione Discourse (e il contenitore) è esposta tramite una socket di dominio Unix; puoi eseguire quante istanze di contenitori Discourse desideri senza dover preoccuparti di conflitti tra socket TCP/IP. A mio avviso, questo è un modo molto pulito per eseguire Discourse.

Ci sono numerosi HOWTO e tutorial su questo sito per guidarti nella configurazione, nel caso ti blocchi e voglia cambiare leggermente direzione. Nella distribuzione di Discourse è disponibile un modello “socket” che puoi utilizzare per configurare la “parte di Discourse della configurazione”; dopodiché ti basta impostare il proxy inverso (ci sono innumerevoli tutorial su come farlo) e “via libera!”.

Spero sia d’aiuto.

4 Mi Piace

Non sono ancora riuscito a risolvere il problema. C’è qualcuno che può spiegare nei dettagli? :roll_eyes:

Prova questo:

netstat -lnptu | grep :443

e poi:

kill -9 PID (sostituisci PID con il numero di processo ottenuto dal comando precedente)

1 Mi Piace

Consiglio di configurare un reverse proxy sul tuo server esposto a Internet, in modo che reindirizzi a WordPress o Discourse in base all’host.

Ad esempio, esegui un servizio nginx sulle porte 80 e 443 sull’host, e configura il proxy per inoltrare le richieste a blog.tuodominio al servizio WordPress (sia tramite una porta interna dell’host, se stai usando Apache + WordPress, nel qual caso potresti reindirizzare alla porta di Apache, come 8080, sia utilizzando fastcgi).

Successivamente, sullo stesso server puoi eseguire Discourse, assicurandoti di modificare le porte nel file app.yml per utilizzare porte non occupate sull’host, come 8081, oppure di utilizzare una socket Unix come suggerito da @neounix. In questo modo, le richieste a forum.tuodominio verranno inoltrate a quella porta o alla socket. Per avviare Discourse, dovrai eseguire ./launch rebuild app nella directory di Discourse (solitamente /var/discourse).

In questo caso, non dovresti eseguire discourse-setup per creare un file swap da 2 GB (principalmente utilizzato per gli aggiornamenti, che potrebbero richiedere più memoria, anche se potresti non averne bisogno se il tuo server dispone di molta memoria) e per generare il file app.yml. Dovrai invece creare questi file manualmente. Se non sai cosa inserire nel file app.yml, ti consiglio di eseguire l’installazione consigliata su un server separato, anche solo per familiarizzare con Discourse e vedere il file app.yml generato, che potrai poi utilizzare sul tuo server condiviso (ricordando di modificare le porte o rimuoverle se utilizzi l’approccio con socket).

Ti consiglio di seguire uno dei topic howto a riguardo, se non riesci a procedere ulteriormente.

2 Mi Piace

Puoi spiegare come eseguire il processo di reverse proxy? Ho imparato cosa fare, ma non so come farlo.

Non ho un esempio a portata di mano perché non utilizzo un proxy davanti, anche se credo di averlo implementato qualche tempo fa. In ogni caso, non c’è nulla di segreto: dovrebbe funzionare come con gli altri reverse proxy. Di seguito trovi una panoramica di ciò che va fatto utilizzando le porte (e non le socket):

  1. Assicurati di avere un servizio WordPress in esecuzione su una porta diversa da 80 e 443 (ad esempio: 8443) e funzionante. Puoi provare a esporlo prima su Internet per verificare che funzioni.

  2. Fai lo stesso con Discourse, mappando su porte diverse.

Cambia:

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

In (ad esempio):

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

Nel tuo file app.yml (se non ce l’hai, ti consiglio di eseguire Discourse su una macchina standalone seguendo la guida ufficiale solo per vedere come funziona, e poi dare un’occhiata al file app.yml generato in /var/discourse/containers/). Ecco un esempio di file app.yml: discourse_docker/samples/standalone.yml at master · discourse/discourse_docker · GitHub

  1. Installa nginx e, nel suo file di configurazione, aggiungi le direttive del proxy. Dovrebbero essere simili al seguente estratto di esempio:
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;
    }
}

Questo presuppone che WordPress sia in esecuzione sulla porta 8080 e Discourse sulla porta 8081. Assicurati di configurare un firewall per bloccare l’accesso a queste porte (i provider cloud bloccano di solito tutte le porte per impostazione predefinita, tranne la 22, quindi potrebbe non essere necessario).

In questo caso, dovrai occuparti tu della generazione dei certificati SSL/TLS (puoi farlo con certbot eseguito periodicamente tramite un cron job, quindi ho già incluso i percorsi /.well-known/acme-challenge/ nella configurazione di nginx).


Come detto sopra, questa è solo una panoramica e potrei aver tralasciato qualcosa. Devi prestare particolare attenzione all’URL di base a causa della modifica delle porte (per verificare che non tenti di reindirizzare l’utente a https://tuodominio:8081 invece di https://tuodominio, e apportare le modifiche necessarie per farlo funzionare).

Questo potrebbe non essere necessario se WordPress è in esecuzione in un contenitore con la porta 80 o 443 all’interno del contenitore. Con Discourse dovrebbe andare bene anche così. Il problema che potrebbe sorgere riguarda https: potrebbe reindirizzare a http perché utilizza la porta http nel proxy, quindi dovresti verificare se ciò accade e correggerlo in tal caso.

3 Mi Piace

Grazie per il tuo aiuto. Procederò con l’applicazione e informerò sulle transazioni.