Como puedes ver en la captura de pantalla, he conseguido “instalar” Discourse. Pero no consigo asignar un certificado SSL válido.
Para que conste, estoy enrutando esto a través de mi Synology NAS con un proxy inverso que eleva el puerto 89 a 443 con websocket y el puerto 89 y 449 (mapeados a 80 y 443 respectivamente en el app.yml).
Por lo que puedo decir, he hecho todo lo que se suponía que debía hacer para configurarlo todo.
Tengo un certificado apuntando a subdomain.domain.com pero todavía se resuelve a domain.com.
No entiendo completamente tu situación actual, ¿estás ejecutando Discourse detrás de un proxy? Si es así, probablemente solo necesites exponer el puerto 80 y dejar que tu servidor proxy maneje HTTPS/SSL.
¿Eso significa que estás implementando Discourse en una nube privada/en las instalaciones? Si la respuesta es sí, entonces un problema común es intentar acceder al sitio en LAN vs WAN, si esta es tu causa y acceder al sitio desde otra red parece estar bien es decir, solo intenta acceder al sitio desde tu red móvil entonces revisa esto ref.
¿Cómo está configurado, por Discourse? Si no es por Discourse, entonces probablemente solo necesites exponer el puerto 80.
Pido disculpas por no haber proporcionado la aclaración necesaria.
Estoy usando un proxy inverso para dirigir la dirección IP 192.168.1.XXX a un subdominio, es decir, discourse.mydomain.com, así que, en resumen, sí, está en las instalaciones.
Actualmente es inaccesible a través de LAN o WAN (móvil).
Después de ejecutar sudo netstat -tlnp | grep LISTEN, veo los puertos 89 y 449 listados, pero acceder a la IP local, por ejemplo, 192.168.1.XXX:449 (o 89), no funciona.
Y, por supuesto, el proxy inverso (desde el NAS Synology) no ayuda, por lo que el subdominio que he configurado es un callejón sin salida.
Para total claridad, la máquina en la que intento alojar Discourse es una VM alojada en una máquina con XCPNG. El sistema operativo de la VM es la última versión de Ubuntu Server (CLIN).
Hummm, si entiendo correctamente, 192.168.1.XXX es tu dirección IP privada en la LAN, y probablemente tengas una dirección IP pública, que tu ISP te da. Así que solo para que quede claro, en tu registro DNS deberías tener tu dirección IP pública configurada para apuntar a tu subdominio, no a tu dirección IP privada (en la LAN), y en segundo lugar, tu router podría necesitar ser configurado para permitir el tráfico entrante y enrutarlo a tu IP privada 192.168.1.XXX. Y tu ISP debería permitir el tráfico entrante.
Alternativamente, puedes simplemente tunelizar tu tráfico local a un servidor remoto para que no necesites modificar la configuración de tu router o pensar si tu ISP permite el tráfico entrante.
Entonces, ¿cuál es tu caso, tunelizar tráfico o permitir el tráfico entrante a través de NAT o DMZ?
No llegué tan lejos. Me encontré con una serie de otros errores que me impidieron realizar una buena instalación, por lo que no pude activar “force_https”.
Tendré que tomar otra ruta. Disculpa las molestias.
