Soy nuevo en Discourse y me he quedado atascado durante la instalación. Creé una máquina virtual con Ubuntu Server 18.04 y seguí más o menos las instrucciones de instalación.
Cuando digo “más o menos”, me refiero a que, en lugar de un servidor en la nube, estoy utilizando Ubuntu Server. No instalé Docker manualmente, sino que dejé que discourse-setup lo hiciera por mí. Además, aún no tengo configurado un servidor de correo, aunque proporcioné respuestas razonables durante el proceso de configuración. No estoy seguro de si esto es lo que está impidiendo que funcione. El DNS está correctamente configurado y el servidor tiene una dirección IP estática asignada.
Después del proceso de inicialización, cuando navego al FQDN del servidor, veo la página “Welcome to nginx!” en lugar de la página “Congratulations, you installed Discourse!”.
Esta instalación es para un entorno de laboratorio y no será accesible públicamente.
La única forma de ver esa página es si has redirigido el DNS al servidor incorrecto, o si NGINX está fuera del contenedor, ocupando el puerto 80 e impidiendo que el contenedor responda.
Si apunto mi navegador web directamente a la dirección IP del servidor, también obtengo la página de bienvenida de Nginx.
Cuando estoy conectado por SSH al servidor Ubuntu: marc@community:~$ locate nginx /var/discourse/image/base/install-nginx marc@community:~$
Además, mientras estoy en el servidor Ubuntu: sudo find / -iname "*nginx*"
…muchos archivos bajo /var/lib/docker/overlay2… /var/discourse/image/base/install-nginx /var/discourse/shared/standalone/letsencrypt/deploy/nginx.sh /var/discourse/shared/standalone/log/var-log/nginx
Si Docker estuviera escuchando en :80, algo que cualquier instalación exitosa lograría (y que sería necesario para que nginx dentro del contenedor pueda ver algo), verías:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
docker-pr 890 root 4u IPv6 961922 0t0 TCP *:http (LISTEN)
Si nginx no está instalado fuera del contenedor y Docker no está escuchando en ese puerto, entonces la única otra forma de estar viendo la página de bienvenida de nginx es una mala configuración de la red.
Parece que tienes razón. Salida al ejecutar nmap desde mi portátil hacia la dirección IP del servidor:
Iniciando Nmap 7.01 ( https://nmap.org ) el 2020-04-10 23:34 AEST
Informe de escaneo de Nmap para community.aureus-group-sb.com (192.168.12.35)
El host está activo (latencia de 0.0010 s).
No se muestran: 999 puertos cerrados
PUERTO ESTADO SERVICIO
22/tcp abierto ssh
Dirección MAC: 0C:8B:FD:CD:AF:EB (Intel Corporate)
Nmap finalizado: 1 dirección IP (1 host activo) escaneada en 1.74 segundos
Recuerda, un problema de red podría ser, pero no se limita a:
Una política en la VM que bloquea el acceso (ufw o similar)
Una política en el servidor virtual que bloquea el acceso (modo de red no configurado correctamente)
Una política en la red no configurada correctamente (ACLs entre subredes)
DNS configurado incorrectamente
Solo es un problema de Discourse si ninguna de las anteriores es cierta. Estás siguiendo la instalación estándar, pero por tu propia admisión estás instalando en un entorno que de ninguna manera es estándar.
Si tu organización puede gastar los $5/mes, podría ser más barato, en términos de tu tiempo, poner esto en la nube y limitar el firewall del VPS en la nube para que solo sirva páginas de vuelta a tu entorno.
Por el momento, me centro principalmente en el aspecto de aprendizaje al configurar esto. Una vez que tenga el control, sin duda exploraremos opciones de alojamiento.
En cuanto a los aspectos de red que mencionaste:
ufw está inactivo e iptables está en ejecución: No he realizado cambios en la instalación predeterminada del servidor Ubuntu.
** Al revisar la configuración de iptables, la cadena de entrada tiene una política para aceptar todo, al igual que la cadena de salida. La cadena de reenvío tiene algunas referencias relacionadas con Docker (ver a continuación).
La única interfaz de red virtual (vNIC) de la máquina virtual está configurada en modo puente, conectándose directamente a la red física.
La laptop desde la que estoy trabajando y la máquina virtual están en la misma subred.
No estoy seguro de cuáles son los requisitos exactos para DNS. Intenté encontrar esas especificaciones, pero no pude localizar un documento definitivo. En lo que respecta a DNS, sin embargo, puedo hacer ping al servidor por nombre, FQDN y dirección IP. No estoy seguro de si se necesita algo más relacionado con DNS.
¿Qué política de red existe entre la VM y el mundo exterior?
Si el git pull tuvo éxito y pudiste ejecutar discourse-setup, ¿habría algo que impidiera la conexión con GitHub para descargar el contenido del contenedor?
Si el servidor no es accesible mediante una dirección válida, Let’s Encrypt fallaría. ¿Modificaste el archivo YML para desactivar HTTPS?
La VM puede conectarse a Internet y no tiene restricciones para acceder a GitHub. Al ejecutar discourse-setup, dejé en blanco la opción Correo electrónico de la cuenta de Let’s Encrypt? (Presiona ENTER para omitir) [me@example.com]:.
Dejar ese campo en blanco significa que no recibirás alertas sobre problemas con el certificado; no impide que el contenedor intente habilitar Let’s Encrypt.
Ok, hemos señalado algunos problemas más graves, pero no están relacionados con la pregunta original. Tienes nginx en algún lugar de tu red mostrando una página, pero según tus pruebas en la máquina virtual, no tienes nginx instalado ni Docker escuchando.
Una vez que averigües cómo está sucediendo esto, el segundo paso será configurar correctamente el archivo YML. Por ahora, necesitas encontrar el origen de esa página.
Esto es lo que he aprendido. Si apago el servidor, no puedo hacer ping a él (ni por dirección IP, nombre ni FQDN). Cuando intento acceder a la dirección IP en el navegador, obtengo la página estándar de “No se puede conectar” de Firefox.
Por lo tanto, concluyo que no hay conflicto de direcciones IP.
Después de encender la VM, ahora tampoco puedo conectarme con el navegador; nuevamente aparece la página estándar de “No se puede conectar”. El comportamiento ahora coincide con lo que esperábamos según la salida de lsof -i:80.
He echado un vistazo dentro del contenedor mediante docker exec -it <cont.id> /bin/bash y verifiqué la salida de ps aux. Allí aparecía la siguiente línea: