Hola, estoy intentando instalar Discourse en una VM nueva de Ubuntu 20.04 de prueba (también probé CentOS Stream 9 y Ubuntu 22.04 y openSUSE MicroOS). Tengo algo de experiencia con Discourse desde los primeros días del proyecto y ahora lo estoy evaluando para una migración. En ese caso sería a mydomain.tld (el dominio de producción es solo un foro y tiene “foro” en su nombre y es bien conocido como tal, así que definitivamente no quiero discourse.mydomain.tld). Todos mis intentos recientes de instalar Discourse sin un subdominio han fallado. Sé que solía ser posible porque ejecuté un foro de Discourse de esa manera hace unos 6 (?) años sin un subdominio. Ahora la instalación parece completarse con éxito, pero el sitio no carga. En Ubuntu cambia automáticamente a https:// incluso cuando pongo explícitamente http://, y no carga en absoluto. Y en CentOS y MicroOS carga la página de bienvenida de Nginx http://, y nada carga con https://.
Todos mis intentos en los sistemas operativos anteriores en la misma VM funcionan bien cuando Discourse se instala en un subdominio en discourse.mydomain.tld, incluida la autoconfiguración de Let’s Encrypt. Hasta donde puedo decir, mis registros DNS son correctos en el registrador de dominios y tengo una resolución rDNS adecuada. El nombre de host del servidor en /etc/hosts muestra 127.0.1.1 mydomain.tld mydomain y el script discourse-install tiene éxito con la verificación de resolución del nombre de dominio.
Aquí está la salida de discourse-doctor, también tengo el registro completo de discourse-install si alguien lo quiere:
DISCOURSE DOCTOR Sun Oct 9 13:32:47 UTC 2022
OS: Linux mydomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Found containers/app.yml
==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=mydomain.tld
SMTP_ADDRESS=mail.mydomain.tld
DEVELOPER_EMAILS=REDACTED
SMTP_PASSWORD=REDACTED
SMTP_PORT=587
SMTP_USER_NAME=admin@mydomain.tld
LETSENCRYPT_ACCOUNT_EMAIL=REDACTED
==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1
DOCKER PROCESSES (docker ps -a)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d6f7f53a81db local_discourse/app \"/sbin/boot\" 10 minutes ago Up 4 minutes 0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp app
Discourse container app is running
==================== PLUGINS ===================
- git clone https://github.com/discourse/docker_manager.git
No non-official plugins detected.
See https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb for the official list.
========================================
Discourse version at mydomain.tld: NOT FOUND
Discourse version at localhost: NOT FOUND
==================== MEMORY INFORMATION ====================
OS: Linux
RAM (MB): 2029
total used free shared buff/cache available
Mem: 1935 823 547 30 564 934
Swap: 2047 0 2047
==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 38G 8.0G 28G 23% /
==================== DISK INFORMATION ====================
Disk /dev/sda: 38.15 GiB, 40961572864 bytes, 80003072 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6643DB1B-E542-4DE1-A04C-C8EB4DAAD77E
Device Start End Sectors Size Type
/dev/sda1 528384 80003038 79474655 37.9G Linux filesystem
/dev/sda14 2048 4095 2048 1M BIOS boot
/dev/sda15 4096 528383 524288 256M EFI System
Partition table entries are not in disk order.
==================== END DISK INFORMATION ====================
==================== MAIL TEST ===================
For a robust test, get an address from http://www.mail-tester.com/
Mail test skipped.
==================== DONE! ====================
Hola, gracias por la respuesta. OK, esa es una buena idea, parece que no está aceptando la conexión:
$ curl -v mydomain.tld
* Trying 1.2.3.4:80...
* connect to 1.2.3.4 port 80 failed: Connection refused
* Failed to connect to mydomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 80: Connection refused
$ curl -v https://mydomain.tld
* Trying 1.2.3.4:443...
* connect to 1.2.3.4 port 443 failed: Connection refused
* Failed to connect to mydomain.tld port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 443: Connection refused
¿Podría deberse a alguna limitación en la lógica de configuración de Discourse, donde espera que .tld sea algo común como .com u .org? El mío es solo un dominio $5.tech que creé para pruebas.
¿Dónde está alojado el servidor? ¿Qué hay entre él y el cliente?
Proporcionarnos el FQDN nos ayuda a solucionar problemas. Tal como está, nos está pidiendo que ayudemos a diagnosticar esto con los ojos vendados, por lo que puede llevar tiempo determinarlo.
Usé discourse-setup. Sí, los puertos están abiertos. La instalación en un subdominio funciona bien, y también configuré una instalación de Docker de un servidor de correo con una interfaz web en esta misma VM (pero luego la reformateé).
Hmm no. El registrador es Hover, normalmente son bastante buenos. Eso es extraño, en 20 años de configurar servidores nunca he tenido problemas con sitios web en la raíz de un dominio…
Podrías intentar cambiar tu NS a CloudFlare y probar si el problema es el DNS desde allí sin costo alguno.
Disculpa la pregunta tonta, ¿quieres decir configurar mi DNS local en Cloudflare? (Actualmente estoy usando 8.8.8.8) ¿O usar un servicio DNS diferente para mi dominio?
Le pregunté a Hover al respecto y me remitieron a esto:
Lo que podrías hacer es intentar usar un registro Glue. Esto hará que tu servidor sea el administrador de DNS y dirigirá el nombre de dominio a un servidor de nombres que puedes configurar usando registros Glue. Básicamente, tu servidor se convierte en el servidor de nombres.
Esto todavía me parece una pista falsa. ¿Por qué Discourse no funcionaría en la raíz del dominio en la misma situación en la que funcionarían Wordpress o Drupal?
No, me refiero a que no necesitas mover tu dominio entre registradores, pero sí necesitarás actualizar los registros NS en Hover para que tu dominio apunte al DNS de un proveedor diferente y así probar esta teoría. Actualmente están configurados en ns1.hover.com y ns2.hover.com.
Es un proceso muy rápido y bastante indoloro. Si te registras en CloudFlare e intentas añadir el dominio allí, te darán dos nuevos servidores de nombres que deben ser introducidos en Hover. Aquí tienes una guía para el lado de Hover:
Ha pasado un tiempo desde que usé el apex con algo que no fuera CloudFlare. Voy a probar esto en un momento para ver si puedo detectar algún otro problema. La mayoría de los problemas con el apex se aplican a los cnames, pero ahora veo que estás usando un registro a.
Mi mejor suposición es que hiciste un montón de reconstrucciones con algo mal configurado y ahora Let’s Encrypt no emitirá un certificado debido a la limitación de velocidad.
Si ese es el caso, puedes esperar una semana o intentar usar www como subdominio, lo cual es realmente una buena idea hoy en día.
Puedes ver los registros en /var/discourse/shared/log/var-log/nginx/access.log o quizás
docker logs app
Espero que veas problemas con el certificado inexistente o inválido.
Por ahora, deshabilité SSL en app.yml e hice una reconstrucción, y Discourse ahora se está cargando en el puerto 80 sin un subdominio.
También estoy usando ahora Hetzner DNS como autoritativo. No estoy seguro de si esto marcó la diferencia o si fue el problema fallido del certificado Let’s Encrypt. Volveré a informar después de otra reconstrucción una vez que pueda crear certificados Let’s Encrypt nuevamente y volver a habilitar SSL.
Si ha intentado reconstruir más de un par de veces, es probable que letsencrypt le esté limitando la velocidad. Puede solucionar esto añadiendo otro nombre de host a su certificado.
Gracias a todos por sus rápidas respuestas. Parece que, efectivamente, solo fue una cuestión del límite de Let’s Encrypt. Creé un nuevo dominio en Hover y esta vez la instalación de Discourse funcionó bien sin subdominio.
Hola de nuevo @pfaffman o a quien corresponda, pregunta tonta: ¿Se actualiza el certificado de Let’s Encrypt cada vez que ejecuto ./launcher rebuild app? En otras palabras, ¿me encontraré con más limitaciones de velocidad si hago un poco de prueba y error y reconstruyo (pero no empiezo completamente desde cero) mi instancia de Discourse varias veces seguidas? Muchas gracias.