No creo que eso sea cierto ahora.
Exactamente @jomaxro. Por eso dije:
Oh. Lo siento. Me perdí ese cambio.
Así que si el usuario no proporciona una dirección de correo electrónico para las notificaciones de Let’s Encrypt, discourse-setup ahora habilita Let’s Encrypt ciegamente sin verificar que el dominio se resuelva al servidor actual. Pero si sí proporcionas una dirección de correo electrónico, entonces realiza la verificación. Esto no parece una buena idea.
¿Por qué forzar HTTPS si no tienen un nombre de dominio válido? Si el plan es obligar a todos a usar HTTPS todo el tiempo, deberíamos verificar si el nombre de dominio es válido y luego negarnos a ejecutar en lugar de darles una instalación rota.
La forma en que funciona ahora, si no proporcionas una dirección de correo electrónico de Let’s Encrypt y el dominio no se resuelve al servidor, entonces discourse-setup parece tener éxito, y levanta un servidor web que no aceptará conexiones porque nginx no puede encontrar un certificado. Creo que lo mejor sería no solicitar una dirección de correo electrónico de Let’s Encrypt, usar el correo electrónico del (primer?) desarrollador para Let’s Encrypt y aún así realizar la prueba de DNS, pero ahora esto no pertenece a este tema.
No, así no funciona Let’s Encrypt. El correo electrónico no tiene nada que ver con la validación del dominio. Se utiliza para notificar al usuario si su certificado está por expirar y no puede renovarse. La validación siempre se realiza mediante DNS.
Let’s Encrypt no puede emitir un certificado para una dirección que no cumpla con los requisitos de validación. Si lo hiciera, todo el esquema de LE colapsaría de la noche a la mañana.
No. Es así como funciona (o funcionaba) discourse-setup. Antes protegía a los usuarios de solicitar un certificado cuando tenía bastante certeza de que fallaría. Ahora, continúa adelante, solicita un certificado incluso cuando es imposible que tenga éxito y no tiene forma de informar al usuario de que no funcionó, por lo que ahora falla en silencio sin ninguna advertencia.
De nuevo, ¿por qué fallaría? El correo electrónico no es un requisito para la verificación del dominio.
El fallo tampoco generó un correo electrónico.
El correo electrónico solo está allí para informar al usuario más adelante si Let’s Encrypt no puede renovar y un certificado está a punto de expirar. Si el certificado se renueva sin problemas, nunca recibirán un correo electrónico.
No creo que ese fuera el objetivo del cambio. La intención era habilitar SSL independientemente de si se proporciona un correo electrónico. Deberíamos seguir verificando la resolución del dominio, @Falco.
Fallará si el nombre de dominio no se resuelve al host. La dirección de correo no importa, pero si hay una, la configuración de Discourse advertirá al usuario si la dirección no se resuelve.
La resolución de dominio debe pasar por @falco; de lo contrario, la configuración debe detenerse. Este es un cambio problemático.
Así que he realizado algunos cambios en una rama. Así es como funcionará:
Usando un nombre de host incorrecto:
root@droplet:/var/discourse# ./discourse-setup
¿Nombre de host para tu Discourse?: bad-domain.com
Comprobando tu nombre de dominio . . .
ADVERTENCIA:: Este servidor no parece ser accesible en bad-domain.com:443.
También falla la conexión a http://bad-domain.com (puerto 80).
Esto sugiere que bad-domain.com se resuelve a la dirección IP incorrecta
o que el tráfico no se está enrutando a tu servidor.
Busca en Google: "abrir puertos TU SERVICIO EN LA NUBE" para obtener información sobre cómo resolver este problema.
Si deseas continuar de todos modos, necesitarás ejecutar cp samples/standalone.yml containers/app.yml
y editar manualmente el archivo containers/app.yml.
Usando un nombre de host correcto:
root@droplet:/var/discourse# ./discourse-setup
¿Nombre de host para tu Discourse?: good-domain.com
Comprobando tu nombre de dominio . . .
Conexión a good-domain.com exitosa.
¿Dirección de correo electrónico para la(s) cuenta(s) de administrador? :
Los cambios están pendientes en
¿Se ve bien? @pfaffman @codinghorror ?
Comentario sobre por qué se necesitó este cambio en primer lugar
En primer lugar, me sorprende que en casi tres meses desde que se implementó este cambio no haya habido muchas quejas, e incluso el tema que llamó mi atención sobre esto no estaba teniendo problemas debido a este cambio, así que tal vez importa mucho menos de lo que creo.
Lo primero que no termino de entender es: ¿realmente quieren hacer que sea imposible configurar un sitio solo con HTTP mediante discourse-setup? Supongo que ya han tenido que hacer varias configuraciones de DNS para que el correo funcione, así que quizás no sea un problema tan grande pedirles que creen también el registro A.
Comentarios sobre el cambio
A menos que hayas realizado un cambio que no haya notado, el script crea app.yml antes de empezar a hacer preguntas, por lo que podrías simplemente decir algo como: “La instalación de Discourse sin configuración de DNS no es compatible. Para continuar sin configuración de DNS, edita app.yml según tus necesidades y ejecuta ./launcher rebuild app” y luego salir sin realizar el proceso de arranque inicial.
Además, si van a imponer que todos deben usar Let’s Encrypt y HTTPS, tendría sentido modificar standalone.yml y web_only.yml en consecuencia, y entonces se podrían eliminar esas complicadas instrucciones sed.
Más reflexiones
Desde el departamento de “este es mi problema”, mi script de instalación actual se ejecuta antes de que los usuarios puedan configurar el DNS, ya que creo el droplet por ellos, instalo Discourse, les envío un correo con instrucciones sobre DNS, espero a que el DNS esté configurado y luego modifico app.yml para habilitar las plantillas y establecer la dirección de Let’s Encrypt. Pero supongo que eso es solo por razones históricas; lo que debería hacer en su lugar es crear el droplet, configurar Mailgun, esperar a que el DNS esté listo y luego realizar la instalación. Eso aún permitiría que mi script utilice discourse-setup, lo cual me gusta hacer como prueba frecuente para verificar que sigue funcionando (¿no creo que ustedes estén realizando una prueba automatizada de discourse-setup, ¿verdad?)
Sí.
No he recibido ninguna queja sobre este cambio y, desde que se implementó, no veo muchos casos de instancias de Discourse solo con HTTP, porque cuando dices que algo es OPCIONAL, todos lo omiten sin pensarlo. En mi opinión, este es un gran cambio para establecer valores predeterminados seguros en Discourse, que es justo de lo que se trata la guía de 30 minutos.
¡Ah, eso es aún mejor, se necesitan menos instrucciones!
Ahora entiendo su fuerte reacción a este cambio, ya que rompió su configuración; lo siento por eso.
Recomendaría encarecidamente usar el archivo yml directo para cualquier automatización en lugar de apuntar al script interactivo.
tl;dr: Sí, con el pequeño ajuste de idioma que recomendé, esto me parece bien.
Concuerdo. ¡Cero quejas! Suena como un éxito.
¡No! No la rompió. (!) Solo noté de manera vaga que los sitios no se cargaban antes de realizar la segunda etapa de la instalación que habilita HTTPS. Y mi configuración no es responsabilidad tuya. (Oh, AHORA sí romperá mi script, pero de todos modos será mejor no realizar la instalación antes de configurar el DNS. No he realizado una instalación sin HTTPS en al menos un año.)
La razón por la que me gustaba que mi script usara discourse-setup es que aseguraba de manera extra especial que mis clientes de instalación recibieran una Instalación Estándar, y que cuando alguien dijera “Hice una instalación y no funcionó”, pudiera ejecutar mi script y hacer exactamente lo que deberían haber hecho, para luego decir: “Bueno, acabo de hacer una instalación y funcionó”. Pero no creo recordar ninguna vez en los últimos 3 años en la que encontrara un problema, así que quizás mi “prueba” no está sirviendo de nada a nadie.
¡Genial, gracias por el análisis y la revisión!
Se ha fusionado la PR, por lo que ahora siempre validaremos DNS.