¡Correcto! He aplicado tontamente la configuración en la página mencionada anteriormente, en comparación con otros archivos de configuración de nginx y no pude entender por qué el proxy no escuchaba en 80:443 para discourse…
Esto es lo que esperaba ver:
server {
listen 80;
server_name discourse.mydomain.com;
return 301 https://$host$request_uri; # enrutamiento a 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;
# Añade index.php a la lista si estás usando PHP
index index.html index.htm index.nginx-debian.html;
location / {
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:; # usando 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;
}
}
Como referência, npm e o nginx proxy manager são coisas diferentes. Você está confundindo sua terminologia e, portanto, as pessoas que tentam ajudá-lo.
Lo siento Stephen por la confusión, solo usé el nombre de la herramienta que se menciona en el artículo. Entiendo que NPM y nginx (como) proxy manager son cosas diferentes, por eso usé mayúsculas…
Esto es exactamente lo que estoy intentando hacer y entiendo que no puedes dar soporte en esto. Sin embargo, ¡cualquier pista / enlace sería apreciado!
Simplemente no puedo, Jay: estoy intentando ayudar a un amigo a desplegar la aplicación y no puedo modificar la configuración de su servidor. ¡Por eso tengo que solucionar el problema de nginx!
Por cierto, mi entendimiento es:
Discourse está escuchando en los puertos 80/443.
nginx está desempeñando el papel de un conmutador, distribuyendo las solicitudes a diferentes aplicaciones, basándose en su nombre de dominio:
netxcloud.mydomain.com intentando acceder al puerto 80 → la solicitud se enruta a server_IP:8000
crm.mydomain.com intentando acceder al puerto 80 → la solicitud se enruta a server_IP:9000
discourse.mydomain.com intentando acceder al puerto 80 → la solicitud se enruta a http://unix:/var/discourse/shared/standalone/nginx.http.sock: (espero que los dos puntos finales no sean un error tipográfico) ya que el script de configuración ha configurado discourse para escuchar en este socket.
Intentaré configurar nginx de nuevo esta tarde. ¿Alguien puede confirmar la sintaxis exacta para el socket: http://unix:/var/discourse/shared/standalone/nginx.http.sock:? Quiero asegurarme de que los dos puntos finales no sean un error tipográfico…
De hecho… He aplicado en discourse.conf las modificaciones que propuse el viernes pasado y ¡Discourse ahora funciona bien! Al menos puedo acceder a la página de bienvenida, pero no recibo el correo de activación, lo cual no está relacionado con Discourse (sospecho que mi amigo no creó la cuenta de correo solicitada ).
Te debo un sincero agradecimiento por la ayuda que brindaste y ¡espero no volver a este foro muy pronto!
Finalmente, de vuelta antes de lo esperado, ¡pero probablemente podrás echarme con tus geniales sugerencias!
La situación es:
Discourse en funcionamiento, Docker (o Portainer) indica que el contenedor está en buen estado y puedo acceder a la página de bienvenida forums.mydomain.com.
No recibo ningún correo de activación, a pesar de que la cuenta de correo técnico se ha creado correctamente (proveedor de alojamiento = OVH).
He probado a enviar un correo desde esta cuenta técnica (con la configuración a continuación) = OK.
Lo primero que comprobaré es si forums@mydomain.com se ha configurado para enviar en nombre de noreply-forums@mydomain.com, lo cual debe verificarse en su proveedor de correo electrónico.
========================================
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 =======================================
¿Podría el problema del correo estar relacionado con el supuesto problema de DNS? No tengo un “proxy intermedio”, solo ejecuto nginx como servidor proxy web…
Este es probablemente tu problema. ¿Puedes probar con un puerto diferente? He visto mejores resultados con el puerto 587 si tu proveedor de correo electrónico lo admite.
Necesitarás comentar esto o establecerlo en true si cambias el puerto a 587.
No, mi proveedor de correo electrónico (el mismo que mi proveedor de alojamiento) solo permite el puerto 465. Por cierto, he leído que necesito configurar los registros SPF y DKIM para el dominio (¿es este subdominio?) y aún no he configurado ninguno de estos: ¿podría tener algún impacto?
Estoy navegando por la publicación pero he olvidado información:
El DNS es administrado por nuestro proveedor de hosting (para algunos servicios), digamos en ServerA.
Discourse se ejecuta en otro servidor (ServerB) que está alojado por un proveedor diferente.
Mi entendimiento es entonces: Discourse en ServerB se conecta al servidor de correo en ServerA, autenticándose con email/contraseña para usar el servicio SMTP proporcionado por el proveedor de hosting de ServerA.
¿Es esta una configuración anormal o todavía puedo usar la configuración de correo electrónico normal de app.yml aquí?
).
