Giusto! Ho stupidamente applicato la configurazione nella pagina sopra elencata, rispetto ad altri file di configurazione nginx e non riuscivo a capire perché il proxy non ascoltasse 80:443 per discourse…
Ecco cosa mi aspettavo di vedere:
server {
listen 80;
server_name discourse.mydomain.com;
return 301 https://$host$request_uri; # routing to https
}
server {
listen 443 ssl
listen [::]:443 ssl;
server_name discourse.mydomain.com;
ssl_certificate /etc/letsencrypt/live/discourse.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/discourse.mydomain.com/privkey.pem;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
location / {
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:; # using socket
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
}
Mi dispiace Stephen per la confusione, ho solo usato il nome dello strumento a cui si fa riferimento nell’articolo. Capisco che NPM e nginx (come) proxy manager siano cose diverse, ecco perché ho usato le lettere maiuscole…
Questo è esattamente quello che sto cercando di fare e capisco che non puoi supportarlo. Tuttavia, qualsiasi suggerimento/link sarebbe apprezzato!
Non posso proprio, Jay: sto cercando di aiutare un amico a distribuire l’app e non posso modificare la configurazione del loro server. Ecco perché devo risolvere il problema di nginx…
Tra l’altro, la mia comprensione è:
Discourse è in ascolto sulle porte 80/443.
nginx svolge il ruolo di uno switch, inoltrando le richieste a diverse applicazioni, in base al loro nome di dominio:
netxcloud.mydomain.com cerca di raggiungere la porta 80 → la richiesta viene instradata a server_IP:8000
crm.mydomain.com cerca di raggiungere la porta 80 → la richiesta viene instradata a server_IP:9000
discourse.mydomain.com cerca di raggiungere la porta 80 → la richiesta viene instradata a http://unix:/var/discourse/shared/standalone/nginx.http.sock: (spero che i due punti finali non siano un errore di battitura) poiché lo script di configurazione ha configurato discourse per ascoltare questo socket.
Proverò a configurare di nuovo nginx questo pomeriggio. Qualcuno può confermare la sintassi esatta per il socket: http://unix:/var/discourse/shared/standalone/nginx.http.sock:? Voglio assicurarmi che i due punti finali non siano un errore di battitura…
In effetti… ho applicato in discourse.conf le modifiche che avevo proposto venerdì scorso e Discourse ora funziona bene! Almeno riesco a raggiungere la pagina di benvenuto ma non ricevo l’email di attivazione, che non è correlata a Discourse (sospetto che il mio amico non abbia creato l’account email richiesto ).
Ti devo un caloroso ringraziamento per l’aiuto che mi hai fornito e spero di non tornare troppo presto su questo forum!
La prima cosa che controllerò è se forums@mydomain.com è stato configurato per inviare per conto di noreply-forums@mydomain.com, questo deve essere verificato presso il tuo provider di posta elettronica.
========================================
Discourse 2.9.0.beta9
Discourse version at forums.mydomain.com: Discourse 2.9.0.beta9
Discourse version at localhost: NOT FOUND
==================== DNS PROBLEM ====================
This server reports NOT FOUND, but forums.mydomain.com reports Discourse 2.9.0.beta9 .
This suggests that you have a DNS problem or that an intermediate proxy is to blame.
[... ]
Testing sending to myprivatemail@yahoo.fr using ssl0.ovh.net:465, username:forums@mydomain.com with plain auth.
======================================== ERROR ========================================
UNEXPECTED ERROR
Net::ReadTimeout
====================================== SOLUTION =======================================
Il problema di posta potrebbe essere collegato al presunto problema DNS? Non ho un “proxy intermedio”, sto solo eseguendo nginx come server proxy web…
Questo è probabilmente il tuo problema. Puoi provare una porta diversa? Ho visto i migliori risultati con la porta 587 se è supportata dal tuo provider di posta elettronica.
Dovrai commentare questa riga o impostarla su true se cambi la porta a 587.
No, il mio provider di posta elettronica (lo stesso del provider di hosting) consente solo la porta 465. A proposito, ho letto che devo impostare il record SPF e DKIM per il dominio (è questo sottodominio?) e non ho ancora impostato nessuno di questi: potrebbe avere un impatto?
Sto navigando nel post ma ho dimenticato alcune informazioni:
Il DNS è gestito dal nostro provider di hosting (per alcuni servizi), diciamo sul ServerA.
Discourse è in esecuzione su un altro server (ServerB) che è ospitato da un provider diverso.
La mia comprensione è quindi: Discourse su ServerB si connette al server di posta su ServerA, autenticandosi con email/password per utilizzare il servizio SMTP fornito dal provider di hosting di ServerA.
Questa è una configurazione anomala o posso ancora usare la normale configurazione email di app.yml qui?
).
