¿Hay alguna forma de “revertir” Discourse a una versión anterior que funcione (por ejemplo, 2.8.0 estable o 2.9.0 beta3) hasta que esto se resuelva?
1 me gusta
Decidí dedicar media hora más a investigar esto y creo que encontré la causa.
Esto parece estar relacionado con el cambio a Rails 7, que actualizó net-smtp de 0.1.0 a 0.3.1, lo que cambió los valores predeterminados.
La forma en que la gema smtp llama a net-smtp no deshabilita enable_starttls_auto y openssl_verify_mode, solo lo habilita cuando está habilitado.
10 Me gusta
¡Buen trabajo, Richard! Eso me habría llevado dos horas, si no el doble. Para mí es más fácil sucumbir a lidiar con los nuevos valores predeterminados.
Ajá. Así que tenía algo de razón, es solo que puede que no sea muy difícil arreglarlo con una PR.
4 Me gusta
¡Buen trabajo @RGJ!
Mientras esperamos una solución, y aparte, sería bueno que este problema no causara la cascada de problemas que experimenté, lo que casi derribó mi foro por completo. Específicamente:
- Los fallos de correo electrónico parecen reintentarse muy rápidamente, lo que hace que la cola de sidekiq explote en tamaño y un uso de CPU del ~100% causado por estas tareas.
- Además, algo (ya sean fallos o reinicios) estaba haciendo que Redis escribiera enormes archivos temporales, supongo que conteniendo el estado de la cola de sidekiq. Si bien eran seguros de eliminar, rápidamente llenaron el disco, lo que causó más fallos, y así sucesivamente. Tuve algo de espacio en disco adicional que pude liberar para poder reiniciar el foro y averiguar qué estaba pasando, pero esto puede no ser cierto para todos. (También es algo difícil de confirmar que, en este caso, los archivos temporales de Redis son seguros de eliminar).
Mi suposición es que la solución más simple aquí es ralentizar el reintento de los trabajos de correo electrónico fallidos, o al menos de aquellos que no tienen restricciones de tiempo como los restablecimientos de contraseña. Lo que parece apropiado dado que es poco probable que los problemas de correo electrónico se resuelvan rápidamente, y la mayoría / todos los remitentes harán sus propios reintentos una vez que reciban un mensaje.
8 Me gusta
En mi caso, cuando me encontré con el fallo después de la actualización, estaba usando TLS con un servidor de terceros y el nombre en el certificado coincidía con el nombre del servidor SMTP. Sin embargo, solo tuve un fallo. No he reiniciado ni actualizado desde entonces para evitar problemas adicionales. Intentaré una actualización una vez que se publique el parche y veré cómo va.
2 Me gusta
Comenzaré creando un tema en Bug, pero dado que técnicamente es un problema en una gema anterior, no estoy seguro de cuánta prioridad recibirá.
3 Me gusta
+1 :preocupado: error realmente frustrante
1 me gusta
¿No se puede revertir el gem? Me sorprendería que no recibiera atención ya que es una funcionalidad “central”, la capacidad de enviar correos electrónicos y para algunos también está causando una interrupción debido a archivos temporales y al consumo de CPU que sobrecarga el servidor. La estabilidad central del foro se está viendo interrumpida aquí.
2 Me gusta
No olvide que esto se puede resolver fácilmente configurando correctamente su servidor de correo.
1 me gusta
AFAIK mi servidor está configurado correctamente. El nombre del certificado coincide con el nombre del host smtp, STARTTLS en el puerto 587. Me pregunto por qué me encontré con el problema.
Gracias por abrir un nuevo ticket. Dada tu comprensión, ¿podrías arrojar algo de luz sobre las combinaciones de las dos variables que señalaste en el archivo YML: cómo deben usarse para diferentes escenarios?
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Por ejemplo, solo tengo STARTTLS en el puerto 587 y ningún otro puerto utilizado por SMTP por razones de seguridad. ¿Deberían especificarse ambas variables en el archivo YML o solo una?
2 Me gusta
Depende.
Si su servidor SMTP está configurado correctamente, no debería necesitar ninguna de ellas.
Pero el problema ahora mismo es que no están haciendo nada en absoluto.
Envíeme un mensaje privado con el nombre de su servidor SMTP y echaré un vistazo para ver si puedo encontrar por qué no le funciona.
2 Me gusta
Tengo un servidor SMTP local sin soporte TLS/SSL y cuando uso StartTls=false no funciona 
1 me gusta
[quote=“Richard - Communiteq, post:56, topic:225778, username:RGJ”]tu servidor de correo correctamente también.
[/quote]
Buen punto, pero no siempre es nuestro servidor de correo. Estoy usando un servidor de correo interno que es mantenido por otro grupo, y por lo tanto no tengo control sobre los problemas del certificado o la configuración del servidor de correo.
Dicho esto, para otros que tengan problemas con esto, una opción puede ser configurar su propio servidor de correo en localhost y simplemente hacer que reenvíe el correo. Entonces usted tiene control sobre el servidor de correo al que Discourse se comunica, y su servidor de correo en localhost puede configurarse para lidiar con cualquier tipo de problema de upstream que pueda encontrar. Había hecho esto anteriormente, pero lo eliminé en algún momento ya que era más simple que Discourse se comunicara directamente con el servidor de correo de upstream. (Ups.)
1 me gusta
Por eso la instalación estándar recomienda proveedores de correo de terceros, en lugar de intentar usar una solución existente o autoalojada.
El correo es difícil por una multitud de razones, el hecho de que algo funcione hoy no significa que esté correctamente configurado, solo que la mala configuración no afecta el propósito original.
1 me gusta
La razón por la que elegí Discourse fue que se supone que es fácil de instalar y mantener para implementaciones pequeñas autohospedadas.
1 me gusta
Y lo es si sigues las recomendaciones.
Si optas por tomar un camino diferente, no es realmente posible hacer ninguna garantía.
1 me gusta
En resumen, ¿está diciendo que con Discourse ya no es posible utilizar un servidor SMTP sin TLS, SSL o StartTLS?
1 me gusta
No creo que nadie esté sugiriendo eso. Esto solo se relaciona con cómo surgió el problema y cuánto tiempo llevó encontrar la causa raíz.
La razón por la que solo vemos un puñado de casos aquí se debe al número relativamente pequeño de instalaciones con la gema actualizada que tampoco transmiten correo a través de alguna forma de transporte seguro.
Richard ya ha iniciado un tema sobre el error:
Para cualquiera que necesite que esto funcione antes, también puede habilitar TLS en su servidor de correo o cambiar temporalmente a un proveedor de correo que ofrezca transporte seguro.
1 me gusta
Tengo TLS habilitado con un certificado válido y nombre de host coincidente desde el principio y luego me encontré con el problema después de la actualización BETA 4 (461936f211) y publiqué los registros en el tema a continuación. Otro usuario también tiene problemas y, según él, sus certificados también están en orden:
1 me gusta
Eso es lo que me parece. Algunos de los comentarios en este hilo han sido francamente exasperantes.
Yo mismo aloja Docker-Discourse y uso mi host de Docker como servidor de correo electrónico. He tenido Discourse usando el puerto 25, sin TLS, para enviar correos electrónicos a través de la interfaz interna de Docker desde el principio, hace seis años. Esta es una configuración perfectamente razonable y perfectamente segura. Las transacciones eran 100% internas a mi propio host. Vea más arriba en el hilo mi configuración anterior.
Para mí, la solución fue hacer lo siguiente:
Agregue la dirección IP de la interfaz Docker interna del host como un host válido en el archivo de zona DNS de mi dominio. Es decir:
discourse-mail.jag-lovers.com A 172.17.0.1
Tenga en cuenta: Podría inventar cualquier nombre de host en el dominio jag-lovers.com, ya que utilizo un certificado comodín (CN = *.jag-lovers.com). Si no tiene un certificado comodín, asegúrese de usar un nombre de host que sea un CN o SAN válido en su certificado.
Tenga en cuenta también: La dirección IP que utilicé anteriormente es la dirección IP interna que mi host utiliza en la interfaz Docker para hablar con el contenedor Discourse-Docker. Es una dirección IP privada y no enrutable.
A continuación, cambie la configuración de la aplicación Discourse.yml para conectarse al nombre de host que acabo de crear, para usar TLS, para conectarse en el puerto 587 y para usar SASL para iniciar sesión en el host para cada transacción de correo electrónico (porque de lo contrario obtendrá un mensaje de error de retransmisión denegada).
DISCOURSE_SMTP_ADDRESS: discourse-mail.jag-lovers.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: REDACTED
DISCOURSE_SMTP_PASSWORD: "REDACTED"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (opcional, por defecto true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
DISCOURSE_SMTP_DOMAIN: jag-lovers.com
A continuación, reconstruya Discourse. Eso solucionó el problema para mí.
2 Me gusta