Verificando el nombre de su dominio . . .
ADVERTENCIA: El puerto 443 del equipo no parece ser accesible usando el nombre de host: ***.com.
ADVERTENCIA: La conexión a http://shoutam.com (puerto 80) también falla.
Esto sugiere que ***.com se resuelve en una dirección IP que no llega a esta
máquina donde está instalando discourse.
Lo primero que debe hacer es confirmar que ***.com se resuelve en la dirección IP de este servidor.
Normalmente lo hace en el mismo lugar donde compró el dominio.
Si está seguro de que la dirección IP se resuelve correctamente, podría ser un problema de firewall.
Una búsqueda web de “abrir puertos SU SERVICIO EN LA NUBE” podría ayudar.
Esta herramienta está diseñada solo para las instalaciones más estándar. Si no puede resolver
el problema anterior, deberá editar usted mismo containers/app.yml y luego escribir
./launcher rebuild app
¿Alguien puede ayudarme a resolver esto? Estoy usando Cloudflare.
[quote=“Bhanu Sharma, post:2, topic:281990, username:itsbhanusharma”]tendrás que configurar Discourse para usar la plantilla de Cloudflare.
[/quote]
Pero aún así no podrás instalar, ya que Let’s Encrypt requiere acceso directo a los puertos 80 y 443 para emitir un certificado.
Una vez que tengas tu certificado y Discourse esté instalado, puedes buscar temas sobre cómo hacer que funcione con Cloudflare en el medio (lo que incluye el uso de la plantilla de Cloudflare).
Buena observación, no es Let’s Encrypt sino el cliente acme.sh utilizado en Discourse lo que necesita acceso directo (certbot tiene complementos de DNS que requieren trabajo adicional pero eliminan este requisito). No lo pensé porque básicamente todas las instalaciones de Discourse que he implementado en años han requerido el uso de un proxy inverso, por lo que la plantilla SSL interna se deshabilita de antemano.
No estoy seguro de a qué te refieres con eliminado, pero normalmente la propagación de DNS tarda un par de horas. Podría valer la pena esperar un tiempo y luego volver a intentarlo.
Falta bastante información aquí para que podamos ofrecer mucha más ayuda.
Hoy en día, Cloudflare no falla en modo proxy (nube naranja) siempre que HTTPS no esté configurado como estricto, ya que tanto :80 (HTTP) como :443 (HTTPS) se pasan directamente al servidor.
Estricto fuerza que el tráfico en :80 se redirija a SSL, y por lo tanto el desafío fallaría.
Es muy posible que te hayas saltado uno o más de los fundamentos, pero sin decirnos dónde se encuentra el VPS y qué has configurado dentro de DNS, estaremos adivinando en el mejor de los casos sobre lo que está sucediendo aquí.
Algunos proveedores requieren que se establezcan ACL entre su VPS y el mundo exterior: ¿has verificado que esos puertos estén abiertos externamente? ¿Estás seguro de que el registro ‘a’ que has añadido a DNS apunta a la dirección IP pública que se ha asignado? ¿Hay algún firewall presente?
Eso es cierto con algunos proveedores de DNS, claro, pero Cloudflare fuerza un TTL de 300 segundos en cualquier dirección que proxy. Eso significa que los servidores DNS upstream habrán caducado los registros antiguos a los cinco minutos del cambio.
Todo lo que hace la plantilla es asegurar que las direcciones IP de cliente correctas se extraigan de la información de encabezado adicional que Cloudflare añade cuando el modo proxy está habilitado, en realidad no es relevante para el proceso de instalación.
Si ejecutaste una reconstrucción varias veces con la nube naranja, es probable que hayas alcanzado los límites de velocidad con Let’s Encrypt. Las soluciones fáciles son usar un subdominio diferente o esperar una semana.
¿funcionará si destruyo el droplet y creo uno nuevo?
Tenga en cuenta que instalé discourse con éxito antes de este problema, pero destruí ese droplet porque hubo un error en el correo electrónico del administrador. Ahora no puedo instalar discourse usando el mismo proceso que usé antes.
Resucitando este hilo con la esperanza de que los comentaristas conocedores también puedan ayudarme.
Estoy recibiendo el mismo error que el OP original.
Actualmente estoy ejecutando Unraid y tengo un contenedor ejecutando Nginix Proxy Manager. Puertos del firewall configurados para enviar todo el tráfico de los puertos 80/443 a mi contenedor NPM. He configurado con éxito muchos contenedores docker con mi contenedor NPM y todo ha funcionado bien.
Instalé una VM de UbuntuServer, pasé por la configuración inicial, configuré una IP estática para la VM, instalé docker y luego descargué discourse, pero falló en el script de configuración tal como el OP.
Si desea utilizar Nginx Proxy Manager, deberá configurar su app.yml manualmente. Puede desactivar su proxy el tiempo suficiente para que discourse-setup se ejecute la primera vez (aún tendrá que cambiar algunas cosas manualmente) o copiar de samples/standalone.yml.
Sí, según mi entendimiento, los archivos yml se completan después de que discourse-setup se ejecuta y finaliza. Para lograr esto, tal vez pueda dirigir el tráfico WAN en mi firewall a mi UbuntuVM en la que estoy instalando discourse, luego, después de que esté configurado, volver a dirigir mi tráfico al proxy inverso y luego configurar mi archivo app.yml.
Olvidé esto. Puedes usar el modificador --skip-connection-test para que omita esa prueba y se ejecute. Aún necesitarás editar los puertos manualmente, pero te permitirá usar el script para crear el archivo e ingresar tus credenciales SMTP.