Я занимаюсь самостоятельным хостингом Discourse уже много лет и имел несколько экземпляров, которые успешно были настроены и работали на довольно мощной машине.
Сегодня я заметил, что один из моих форумов перестал работать. Первичной причиной, как казалось, было отсутствие места на диске, что я и исправил. После этого я перезапустил экземпляр Discourse.
Однако с тех пор он продолжает регулярно падать. Каждый раз при запуске я сразу вижу, что sidekiq начинает работать некорректно, и возникает огромное количество неудачных задач по отправке электронной почты. Это также приводит к тому, что redis хранит огромный объем состояния, что, по моему мнению, и стало реальной причиной проблемы с нехваткой места на диске. (В следующий раз, когда мне удастся запустить машину, я планирую выполнить очистку, так как если я этого не сделаю, место на машине быстро закончится, и я даже не смогу запустить Discourse для выполнения очистки. Однако очистка, похоже, мало влияет на использование дискового пространства redis.)
Сообщение об ошибке указывает на несоответствие имени сертификата, что меня немного удивляет, поскольку используемый мной почтовый сервер является внутренним и не требует TLS или аутентификации. Я смог проверить на одном из своих других экземпляров (с той же конфигурацией почты), что отправка электронной почты перестала работать. В основных логах production я вижу только ошибку 422, но при отправке, например, запроса на сброс пароля в логах sidekiq появляется аналогичная ошибка:
Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
Я смог проверить, что отправку электронной почты можно выполнить через командную строку, поэтому проблема, похоже, не в самом почтовом сервере, а в чем-то сломанном в конфигурации Discourse.
Вот исходная конфигурация почты, которая работала до недавнего времени:
DISCOURSE_SMTP_ADDRESS: outbound-relays.techservices.illinois.edu
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_ENABLE_START_TLS: false
Еще раз подчеркну, что этот почтовый сервер внутренний, не требует имени пользователя или пароля, и эти настройки работали до недавнего времени. Я экспериментировал с параметром DISCOURSE_SMTP_OPENSSL_VERIFY_MODE, но не могу сказать, поддерживается ли он еще. В любом случае, это не помогло. Я заметил несколько новых настроек почты, добавленных с момента настройки моих форумов, но они, похоже, не нужны с учетом конфигурации этого почтового сервера.
Буду признателен за любую помощь! На данный момент я даже с трудом могу быть уверен в том, что именно не так, или как двигаться дальше, поскольку пересборка контейнера занимает много времени, а сообщение об ошибке в логах production содержит только ошибку 422, и я не могу понять, где искать реальную первопричину. (Она должна быть где-то, верно? Я уверен, что просто упускаю её.)