He estado autoalojando Discourse durante muchos años, y he tenido varias instancias configuradas y funcionando felizmente en una máquina bastante potente.
Hoy noté que uno de mis foros se había caído. El culpable inicial parecía ser la falta de espacio en disco, lo cual arreglé. Luego reinicié la instancia de Discourse.
Sin embargo, ha seguido cayéndose regularmente desde entonces. Cada vez que la arranco, veo inmediatamente que sidekiq se vuelve loco y una gran cantidad de trabajos de correo electrónico fallidos, que también están haciendo que redis almacene una gran cantidad de estado, lo que creo que fue la causa real del problema de espacio en disco. (Voy a hacer un flush la próxima vez que pueda poner en marcha la máquina, ya que si no lo hago, me quedaré rápidamente sin espacio en esta máquina y ni siquiera podré iniciar Discourse para hacer el flush. Pero el flush no parece reducir mucho el uso del disco de redis).
El mensaje de error indica algo sobre una falta de coincidencia en el nombre del certificado, lo cual me sorprende un poco ya que el servidor de correo que estoy usando es interno y no requiere TLS ni autenticación. Pude verificar en una de mis otras instancias (usando la misma configuración de correo electrónico) que el correo había dejado de funcionar. Todo lo que puedo ver en los registros principales de producción es un error 422, pero cuando envío algo como un restablecimiento de contraseña, veo un error similar en los registros de sidekiq:
Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
He podido verificar que puedo enviar correos electrónicos desde la línea de comandos, por lo que esto no parece ser un problema con el servidor de correo en sí, solo algo roto con la configuración de Discourse.
Aquí está la configuración de correo original que funcionaba hasta hace poco:
DISCOURSE_SMTP_ADDRESS: outbound-relays.techservices.illinois.edu
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_ENABLE_START_TLS: false
Nuevamente, este servidor de correo es interno y no requiere nombre de usuario ni contraseña, y estas configuraciones funcionaban hasta hace poco. He estado experimentando con DISCOURSE_SMTP_OPENSSL_VERIFY_MODE, pero no puedo decir si todavía es compatible. De todos modos, no parece ayudar. Noté algunas configuraciones de correo nuevas que se agregaron desde que configuré estos foros, pero no parecen necesarias dada la configuración de este servidor de correo.
¡Cualquier ayuda sería apreciada! En este punto, honestamente incluso me cuesta estar seguro de lo que está mal o de cómo iterar, ya que reconstruir el contenedor lleva tiempo y el mensaje de error en los registros de producción solo tiene el error 422 y no puedo encontrar dónde buscar la causa raíz real. (Debe estar en algún lugar, ¿verdad? Estoy seguro de que simplemente me lo estoy perdiendo).