I don’t think that’s the case anymore.
3 Me gusta
Exactly @jomaxro. That is why I said
3 Me gusta
Oh. Sorry. I missed that change.
So if the user does not provide a let’s encrypt notification email address, discourse-setup now blindly enables let’s encrypt without verifying that the domain resolves to the current server. But if you do provide an email address then it does the check. This doesn’t seem like a very good idea.
Why force https when they don’t have a valid domain name? If the plan is to force everyone to use https all the time, then we should test if the domain name is valid and then refuse to run rather than give them a broken install.
The way that it works now, if you don’t provide a let’s encrypt email address and the domain doesn’t resolve to the server then discourse-setup appears to succeed, and it cranks up a web server that won’t accept connections because nginx can’t find a certificate. I think a better thing to do is to not ask for a let’s encrypt email address, use the (first?) developer email for let’s encrypt and still do the DNS test, but now this doesn’t belong in this topic.
2 Me gusta
No that’s not how let’s encrypt works. The email has nothing to do with domain validation. It’s used to alert the user if their certificate is due to expire and can’t be renewed. Validation is always done by DNS.
Let’s Encrypt can’t issue a certificate for an address which doesn’t meet the requirement for validation. If it did then the whole LE scheme would implode overnight.
4 Me gusta
No. It’s how discourse-setup works, or used to. It used to protect users from requesting a certificate when it was pretty sure that it would fail. Now, it’ll move ahead, request a certificate when it can’t possibly succeed, and not have any way of reporting to the user that it didn’t work, so it now fails silently with no warning.
1 me gusta
Again, why would it fail? Email isn’t a requirement for domain verification.
Failure never generated an email either.
The email is only there to tell the user later on if Let’s Encrypt is failing to renew and a cert is due to expire. If the cert renews without problem they’ll never see an email.
I don’t think that was the intent of the change. The intent was to enable SSL regardless of if an email is provided. We should still check the domain resolution cc @Falco
2 Me gusta
It will fall if the domain name doesn’t resolve to the host. The email address doesn’t matter, but if there is one Discourse setup will warn the user if the address doesn’t resolve.
4 Me gusta
La resolución de dominio debe pasar por @falco; de lo contrario, la configuración debe detenerse. Este es un cambio problemático.
4 Me gusta
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 ?
3 Me gusta
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?)
2 Me gusta
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.
3 Me gusta
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.
5 Me gusta
¡Genial, gracias por el análisis y la revisión!
Se ha fusionado la PR, por lo que ahora siempre validaremos DNS.
4 Me gusta
Este tema se cerró automáticamente después de 25 horas. Ya no se permiten nuevas respuestas.