En primer lugar, un reconocimiento donde corresponde: el nuevo instalador es una gran mejora. Cuando funciona, que es la mayor parte del tiempo, ofrece un camino mucho más amigable que el antiguo flujo manual, y me permite realizar instalaciones limpias a través de él. Ejecutar el instalador, completar el registro/activación como siempre, y luego proceder a ajustar app.yml según mis especificaciones. Pan comido. Muchas gracias a @Falco y al equipo. ¡Qué diferencia enorme respecto a los viejos tiempos de instalación de Discourse!
Publico esto porque también me encontré con un nombre de host que me dio muchos problemas, y creo que la experiencia puede señalar algunos puntos donde el instalador podría ofrecer información más clara para los autoalojadores.
Qué funcionó
Instalé Discourse con éxito en un servidor nuevo utilizando:
- dominio propio: sí
- SMTP: sí
- el flujo de instalación actual
La instalación llegó hasta:
¡Tallyho!
¡Felicidades, has instalado Discourse!
Registra una nueva cuenta para comenzar.
Así que esto no es una publicación de “el nuevo instalador está roto”. El instalador puede funcionar muy bien.
El nombre de host problemático
En otra instalación, usando el mismo camino general, el nombre de host objetivo era:
forum.domain.tld
El comando del instalador fue:
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
Las elecciones fueron aproximadamente:
- crear archivo de intercambio de 2 GB: sí
- usar mi propio dominio: sí
- nombre de host:
forum.domain.tld - configurar SMTP: sí
- proveedor SMTP: SendGrid
- puerto SMTP: 587
El instalador llegó hasta:
[4/5] Verificando configuración del dominio
? Comprobando tu nombre de dominio...
? Conexión a forum.domain.tld exitosa.
Luego escribió la configuración y reconstruyó la aplicación.
Pero el sitio no se cargó correctamente en el navegador. El síntoma finalmente fue:
forum.domain.tld se negó a conectar
Los intentos repetidos de reconstruir/reintentar no lo solucionaron.
Resultado de Discourse Doctor
./discourse-doctor encontró el contenedor de la aplicación y los valores de configuración esperados. El contenedor estaba en ejecución y los puertos 80/443 parecían estar vinculados.
Pero informó:
Versión de Discourse en forum.domain.tld: NO ENCONTRADA
y más tarde:
Versión de Discourse en localhost: NO ENCONTRADA
Eso hizo que el problema pareciera diferente a una simple propagación de DNS pública.
Límite de tasa de ACME
Anteriormente en el proceso de solución de problemas, también intenté instalaciones usando los caminos asistidos por el servicio de Discourse:
- DiscourseID
- el flujo
yoursite.discourse.diy
Es ahí donde ocurrió el comportamiento de repetidos intentos de conexión/reintento, y donde el registro de ACME mostró un límite de tasa de Let’s Encrypt:
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: ya se han emitido demasiados certificados (5) para este conjunto exacto de identificadores...
La ruta de registro útil fue:
/shared/letsencrypt/acme.sh.log
Esta fue una gran lección. Desde el navegador, el fallo parecía un problema genérico de accesibilidad. Pero el verdadero bloqueo en ese momento era la emisión del certificado.
La parte más confusa fue que el bloque de estado final/completado de la instalación no mostró esto como un error accionable. El síntoma final visible para el usuario era simplemente que el sitio se negaba a conectar con el navegador.
Una revisión posterior mostró la cadena de fallos más claramente:
Límite de tasa ACME 429
-> archivos .cer de cero bytes bajo /shared/ssl
-> nginx intenta cargar el certificado de cero bytes
-> nginx falla al iniciar
-> los puertos 80/443 se niegan
-> el navegador dice conexión rechazada
Solicitud de función enterrada en la experiencia:
Sería muy útil si la rutina de instalación/reconstrucción verificara /shared/letsencrypt/acme.sh.log después del paso del certificado y mostrara errores de límite de tasa como:
rateLimited
too many certificates
status: 429
Por ejemplo:
Se alcanzó el límite de tasa de Let's Encrypt para este nombre de host.
Espera hasta el tiempo de reintento mostrado en /shared/letsencrypt/acme.sh.log antes de volver a intentarlo.
Las reconstrucciones repetidas pueden no ayudar.
Eso ahorraría a los usuarios perseguir problemas de DNS, SMTP, comillas en app.yml, Docker o firewall cuando el problema real es ACME.
Después de que se limpió el límite de tasa
Después de que se limpió la ventana de límite de tasa de Let’s Encrypt, aún vi una situación confusa de validación de dominio.
El instalador informó:
[4/5] Verificando configuración del dominio
? Comprobando tu nombre de dominio...
? Conexión a forum.domain.tld exitosa.
Pero una búsqueda de DNS local aún mostraba:
Resolve-DnsName -Name "forum.domain.tld"
con:
Resolve-DnsName: forum.domain.tld : El nombre DNS no existe.
¿Cómo pueden coexistir esas dos cosas?
Puedo imaginar varias posibilidades:
- el servidor y la estación de trabajo estaban usando resolutores recursivos diferentes
- un resolutor tenía un NXDOMAIN caducado en caché
- la propagación de DNS era parcial en ese momento
- el instalador verifica algo diferente a una búsqueda DNS simple
- el instalador o un servicio relacionado tenía un estado de validación en caché
No afirmo cuál es la verdadera. Principalmente observo que desde la perspectiva del usuario, que el instalador diga “conexión exitosa” puede hacer que los errores posteriores de DNS o accesibilidad sean más difíciles de interpretar.
Verificación de aislamiento de DNS
Para probar si esto era solo una propagación lenta de Cloudflare, agregué otro registro en la misma zona:
test.domain.tld
En cuestión de momentos, los resultados del verificador de DNS público eran verdes.
Eso me hizo menos confiado de que la propagación general de Cloudflare fuera el problema completo. Parecía más como si el problema fuera específico de forum.domain.tld.
Instalaciones comparativas
también tuve una instalación exitosa en otro nombre de host:
discourse.domain2.tld
usando el mismo camino general del instalador.
Otro nombre de host de prueba, para diagnósticos de DNS, fue:
forum.domain3.tld
Las instalaciones comparativas son lo que me alejó de “el nuevo instalador está roto” y hacia “algo específico del nombre de host ocurrió aquí”.
Teoría actual
Mi teoría actual, no probada, es que forum.domain.tld puede haber tenido algún estado en caché/reservado/recordado específico del nombre de host en algún lugar fuera del servidor mismo.
Lugares que me pregunté:
- DiscourseID
- el flujo
yoursite.discourse.diy - validación de dominio del lado del instalador
- alguna relación en caché entre un intento de configuración anterior y el nombre de host
La razón por la que me pregunto por esos caminos asistidos por el servicio es que previamente los había probado con el mismo nombre de host problemático, y ese también fue el camino donde los intentos repetidos finalmente chocaron con el límite de tasa de Let’s Encrypt.
Nuevamente, esto es una hipótesis, no una conclusión.
Preguntas
- ¿El nuevo instalador contacta un servicio controlado por Discourse durante las instalaciones de dominio propio?
- ¿DiscourseID o el flujo
discourse.diyreservan, recuerdan o almacenan en caché nombres de host? - ¿Hay alguna ruta de liberación/reinicio para un nombre de host que se usó o intentó previamente durante la configuración?
- ¿Qué verifica exactamente
[4/5] Verificando configuración del dominio? - ¿Podría el instalador mostrar fallos de límite de tasa de ACME más claramente antes del bloque de estado/resultado final?
Qué habría ayudado
Tres cosas habrían hecho que el camino de solución de problemas fuera mucho más claro:
- Una advertencia clara del instalador cuando
/shared/letsencrypt/acme.sh.logcontiene un fallo de límite de tasa. - Una breve explicación de lo que verifica realmente el paso de verificación de dominio.
- Si existe alguna caché o reserva de nombre de host del lado de DiscourseID /
discourse.diy/ instalador, una manera visible de inspeccionar o liberar ese estado.
Gracias nuevamente por el trabajo en el nuevo instalador. Realmente se siente como la dirección correcta. Publico esto en ese espíritu: funcionó maravillosamente cuando funcionó, y el borde áspero aquí parece el tipo de cosa que un mejor mensaje del instalador podría hacer mucho más fácil de diagnosticar.
Escrito con mis entradas por mi nuevo mejor amigo, Codex.