Проблемы с Discourse 3.5.0.beta2-dev — SMTP и фоновые задачи

Ниже приведён отчёт, подготовленный для меня ChatGPT на основе моего реального опыта установки Discourse (я не очень разбираюсь в технологиях, поэтому полагался на помощь ИИ в выполнении сложных задач). В данный момент мне не нужна помощь, но я надеюсь, что этот отчёт может стать полезной обратной связью по поводу версии 3.5.0.beta2-dev.

==================

Уважаемая команда Discourse,

Я хочу поделиться некоторыми деталями устранения неполадок, связанных с электронной почтой, с которыми я столкнулся при работе с Discourse 3.5.0.beta2-dev. Мне не требуется прямая помощь, так как я решил вернуться к версии 3.4.0.beta4-dev, но надеюсь, что этот отчёт поможет выявить потенциальные проблемы в последней версии разработки.


1. Краткое описание проблемы

Я выполнил чистую установку Discourse на новом экземпляре Vultr, используя SMTP-сервис 20i (smtp.stackmail.com). Однако письма никогда не доставлялись, несмотря на:

  • Успешный тест подключения к SMTP (openssl s_client -connect smtp.stackmail.com:587 -starttls smtp).
  • Отсутствие ошибок в почтовых логах 20i (что указывает на то, что Discourse фактически не отправлял письма).
  • Сбои Sidekiq при обработке задач по отправке почты.

Это было неожиданно, поскольку несколько недель назад я успешно установил Discourse 3.4.0.beta4-dev на идентичный экземпляр без каких-либо проблем с почтой.

После тщательной отладки я обнаружил, что моя текущая установка неожиданно использовала Discourse 3.5.0.beta2-dev, что, вероятно, и стало причиной проблем.


2. Выявленные ключевые проблемы

A. Письма не доставлялись

  • Настройки SMTP были правильными, что подтверждено ручным тестированием (тесты swaks и openssl прошли успешно).
  • Письма помещались в очередь Sidekiq, но никогда не доставлялись.
  • Почтовые логи 20i не показывали ни отказов, ни попыток доставки (что говорит о том, что сообщения никогда не покидали Discourse).
  • В production.log не было ошибок, связанных с почтой (команда grep "smtp" ничего не вернула).

B. Проблемы с Sidekiq и Redis

  • Изначально Sidekiq не работал (Sidekiq::Workers.new.size возвращал 0).
  • Ручная перезагрузка Sidekiq (sv restart sidekiq) не удалась, так как Sidekiq отсутствовал как служба.
  • Redis работал (redis-cli ping возвращал PONG), но логи Discourse всё ещё показывали ошибки подключения к Redis (Errno::ECONNREFUSED).
  • Логи Sidekiq указывали на сбои задач из-за проблем с подключением к Redis, хотя Redis, как было подтверждено, был активен.
  • Ручный запуск Sidekiq (bundle exec sidekiq) позволил обрабатывать задачи, но письма всё равно не отправлялись.

C. Несоответствие версий между установками

  • Моя предыдущая установка (которая работала) была на версии 3.4.0.beta4-dev.
  • Моя текущая установка неожиданно использовала версию 3.5.0.beta2-dev, несмотря на использование того же метода настройки.
  • Поскольку почта работала идеально в 3.4.0.beta4-dev, я подозреваю регрессию или разрушительное изменение в версии 3.5.

3. Предпринятые действия (все не увенчались успехом)

Мы последовательно попробовали следующие решения:

:white_check_mark: Подтвердили подключение к SMTP с помощью:

openssl s_client -connect smtp.stackmail.com:587 -starttls smtp  # Успешно
swaks --to my-email --server smtp.stackmail.com --port 587 --auth LOGIN  # Успешно

:white_check_mark: Проверили, что письма помещались в очередь:

Jobs.enqueue(:user_email, type: :test_message, to_address: 'masden@kumagaku.ac.jp')  # Вернул ID задачи
Sidekiq::Queue.new("default").size  # Вернул 0 (что означает, что задача была обработана)

:white_check_mark: Проверили логи Discourse:

grep "smtp" /shared/log/rails/production.log  # Ошибок, связанных с SMTP, не найдено
  • Сбои подключения к Redis (Errno::ECONNREFUSED в production.log).

:white_check_mark: Перезапустили и вручную запустили службы:

sv restart sidekiq  # Не удалось, служба отсутствует
redis-cli ping  # Подтверждено, что работает
bundle exec sidekiq  # Задачи обрабатывались, но письма не отправлялись

:white_check_mark: Проверили, не блокирует ли 20i письма:

  • В почтовых логах 20i не было отказов или попыток доставки.
  • Если бы письма отклонялись, в логах должна была бы быть запись, но ничего не появилось.

4. Вывод: Откат к версии 3.4.0.beta4-dev

После тщательной отладки я решил полностью удалить установку и переустановить версию 3.4.0.beta4-dev, поскольку моя предыдущая установка на этой версии работала безупречно.

Хотя мне не требуется прямая помощь, я хотел сообщить об этих проблемах, потому что:

  • Обработка почты могла измениться в версии 3.5, что препятствует передаче SMTP.
  • Отсутствие службы Sidekiq и ошибки Redis указывают на проблемы с обработкой фоновых задач в версии 3.5.
  • Поскольку я смог установить 3.4.0.beta4-dev без проблем, это говорит о возможной регрессии в версии 3.5.

Я надеюсь, что этот отчёт поможет выявить потенциальные проблемы в Discourse 3.5.0.beta2-dev.

С уважением,
Кирк

2 лайка

Это ожидаемо, так как это текущая версия.

Довольно многие используют ту же последнюю версию, Sidekiq работает, а значит, работают и письма.

Так что вам, возможно, понадобится помощь, поскольку в таком случае вы не сможете выполнить пересборку.

И было бы гораздо лучше, если бы кто-то взял эту тему под контроль, но я бы сказал, что у нас уже есть темы о остановленном Sidekiq. Поиск может помочь.

4 лайка

У меня по-прежнему возникают трудности с установкой Discourse. Вот ещё один отчёт, составленный ChatGPT. Я считаю, что он точно отражает мой опыт.

Отчёт: Проблемы с установкой Discourse и отсутствием службы Sidekiq

Контекст:
Мы попытались выполнить чистую установку Discourse на экземпляре Vultr, намереваясь создать стабильную и рабочую развёрнутую систему. Однако мы столкнулись с серьёзными проблемами, особенно с отсутствием служб, таких как Sidekiq, что препятствовало доставке электронной почты и фоновой обработке задач.


Краткое описание encountered проблем

  1. Установлена неожиданная версия
  • Вместо ожидаемой v3.4.0.beta4-dev установка по умолчанию перешла на tests-passed, загрузив потенциально нестабильную версию.
  • Файл VERSION отсутствовал, поэтому не было ясно, какая именно версия была установлена.
  1. Отсутствует служба Sidekiq
  • Директория /etc/service/sidekiq отсутствовала внутри контейнера Discourse.
  • Это привело к тому, что все фоновые задачи (электронная почта, уведомления, запланированные задачи) не выполнялись.
  1. Проблемы с репозиторием Git Discourse
  • Запуск команды git rev-parse --abbrev-ref HEAD внутри контейнера вернул tests-passed, что подтверждает установку нежелательной версии.
  • Git выдал ошибку “detected dubious ownership” (обнаружено сомнительное владение), потребовав ручного вмешательства (git config --global --add safe.directory /var/www/discourse).
  1. Возможные проблемы с зависимостями
  • Даже если будет проверена более старая версия Discourse, существует опасение, что во время установки могут быть подтянуты новые зависимости (Ruby, Redis, Sidekiq), что потенциально вызовет проблемы совместимости.
  • Если зависимости Discourse не зафиксированы правильно, установка может вести себя непоследовательно в разных средах.
  1. Ограничение скорости выдачи SSL-сертификатов
  • Попытка получить новый SSL-сертификат Let’s Encrypt не удалась из-за превышения лимита скорости.
  • Это привело к тому, что Nginx не смог запуститься, так как не смог загрузить ожидаемый файл сертификата.

План следующих шагов

  1. Полная очистка и повторная установка
  • Полностью удалить /var/discourse и заново клонировать репозиторий.
  • Вручную проверить стабильную версию (например, v3.4.1) перед запуском установки.
  • Использовать ./discourse-setup вместо полагания на параметры по умолчанию, чтобы обеспечить правильные настройки.
  1. Обеспечить установку Sidekiq
  • Перед пересборкой убедиться, что служба sidekiq правильно включена в процесс сборки.
  • Если Sidekiq отсутствует после пересборки, вручную проверить его установку с помощью команды bundle list | grep sidekiq.
  1. Зафиксировать зависимости на стабильных версиях
  • Избежать проблем, связанных с зависимостями, явно используя известный стабильный образ Docker Discourse (например, discourse/discourse:2.0.20240101).
  • Зафиксировать версии gem-пакетов внутри контейнера (bundle install --deployment --without test development).
  1. Повторить попытку выпуска SSL-сертификата
  • Дождаться сброса лимита скорости Let’s Encrypt и повторить попытку генерации SSL-сертификата.
  • Если проблемы сохранятся, рассмотреть возможность временного использования самоподписанного сертификата для устранения неполадок.

Запрос обратной связи

Учитывая эти трудности, мы были бы признательны за мнение команды Discourse и сообщества по следующим вопросам:

  • Отсутствие Sidekiq в /etc/service/ при чистой установке – Столкнулся ли кто-нибудь ещё с этой проблемой?
  • Лучшие практики обеспечения стабильности зависимостей – Есть ли рекомендуемый способ фиксации версий зависимостей для установок Discourse?
  • Возможные проблемы с установкой tests-passed по умолчанию – Может ли быть проблема с тем, как версии извлекаются?

Любые insights будут полезны перед тем, как мы приступим к повторной установке. Заранее спасибо!

На самом деле это не нестабильная версия. Это значение по умолчанию для всех форумов сейчас. Discourse не установит нестабильную ветку в качестве версии по умолчанию.

Хм… что вы видите, когда переходите в /sidekiq на своём форуме?

Какую ветку вы планируете использовать для установки? Возможно, это руководство поможет?

3 лайка

Думаю, понадобятся детали вашей конфигурации VPS: CPU, RAM, место на диске и ZFS, а также версия ОС — Ubuntu LTS 24.

Когда вы говорите, что тестировали почту, вы использовали встроенную проверку Discourse и получили письмо?

По моему опыту, в файле app.yml у вас должно быть три основных параметра для настройки SMTP:

  • Имя пользователя:
  • Пароль
  • Порт

Судя по вашему сообщению, у вас это уже работало при предыдущей установке Discourse?

Как уже упоминалось, версия «Tests-Passed» является рекомендуемой для установки. Версия «Stable», насколько я понимаю, больше подходит для тех, кто использует кастомные плагины и темы, которые могут требовать более частых обновлений во избежание сбоев.

Можете поделиться логом сборки с ошибками? Не забудьте прокрутить лог вверх при сохранении, так как финальная ошибка часто просто указывает на неудачный результат. Вы всегда можете удалить конфиденциальные данные, такие как имя пользователя SMTP и пароль.

Также есть несколько тем на форуме, посвящённых проблемам с SMTP и почтой, где могут быть готовые решения.

1 лайк

Извините за поздний ответ. Как я уже писал в ответ на другой комментарий, я не могу предоставить подробности о моей последней неудачной попытке, поскольку я удалил большую часть программного обеспечения, чтобы попробовать снова. Я сообщу, как только смогу.

Спасибо за ваши подробные комментарии. Приношу извинения за медленный ответ.

Я пытаюсь выполнить установку заново, используя более ранние версии различных программ. Из-за этого мне сложно ответить на ваши вопросы о моей предыдущей неудачной попытке. Как только я смогу завершить следующую установку, я обязательно сообщу об этом.

1 лайк

Если потребуется, это может послужить дополнительным тестом. Создайте бесплатную учётную запись на https://www.brevo.com; у них есть бесплатный тариф, позволяющий отправлять до 300 писем в день. Я использую его в данный момент.

Если у вас возникают проблемы с отправкой писем, это поможет проверить, не связано ли это с вашим почтовым провайдером.

2 лайка

TL;DR не полагайтесь на ChatGPT, это всё ложные тревоги.

Просить о помощи — это хорошо, но полагаться на неё — плохая идея, как я покажу ниже.
Спасибо за заверение, что вскоре я не останусь без работы из-за ChatGPT. :wink:

beta4-dev столь же потенциально нестабилен, как и tests-passed.

Такого файла не существует.

Такой директории быть не должно.

Я в этом сомневаюсь.

Это ожидаемое поведение.

Это нормальное поведение, если вы используете git в директории, которой не владеете.

Это не имеет смысла. Кроме того, tests-passed новее, чем та версия, которую вы «ожидали», а не старше.

Это произошло потому, что вы пытались слишком много раз.

6 лайков

Хочу подчеркнуть это.
В большинстве случаев, если вы предлагаете ChatGPT найти проблемы, он их найдет, даже если их нет. Кроме того, это быстро приводит нас к бесконечному циклу «исправлений», которые он постоянно предлагает.

5 лайков

Огромное спасибо!

Что касается ИИ, очевидно, что ChatGPT не был надёжным помощником. С другой стороны, отладка оказалась для меня сложной задачей, поэтому искушение положиться на него для таких людей, как я, очень велико.

Я только что успешно завершил установку. ChatGPT (платная версия) не смог довести меня до цели, но Claude от Anthropic (тоже платная версия; я использую оба) в итоге справился. Он помог мне исправить проблемы, которые создал ChatGPT.

Позже я постараюсь написать подробнее о своём опыте. Спасибо за все ваши полезные комментарии!

2 лайка

Я согласен. По моему опыту, с Claude гораздо удобнее работать, и он обычно сразу даёт правильный ответ.

Рад, что у вас всё получилось!

5 лайков

Спасибо! Поразительно, насколько они могут отличаться в определённых задачах — почти как люди с разными характерами. Claude кажется более «вдумчивым», тогда как ChatGPT склонен делать поспешные выводы и немного опережать события. Хотя я сталкивался с ситуациями, где ChatGPT работал лучше. Я надеюсь, что оба они станут лучше. ИИ помог мне написать множество рабочих скриптов, несмотря на то, что я не являюсь разработчиком. У него есть потенциал стать отличным инструментом для людей, испытывающих трудности с технологиями, как я, но ему определённо нужно совершенствоваться. Очень расстраивает, когда тебя ведут по тупиковому пути. :frowning:

4 лайка

Вот краткий отчёт об успешной установке с вопросом о том, как двигаться дальше.

До сих пор не совсем понятно, почему в последних попытках возникали проблемы с SMTP. На самом деле моя первая попытка несколько недель назад прошла успешно, но я использовал сервер Vultr, который решил, что мне не нужен, а единственный способ перейти на меньший — это получить новый сервер меньшего размера, а затем удалить старый.

Согласно письму, которое я получил, версия Discourse, установленная несколько недель назад, была 3.4.0.beta4-dev. В письме рекомендовалось обновиться до версии 3.4.0.beta4.

Поскольку в версии 3.4.0.beta4-dev у меня возникли проблемы с SMTP, я решил попробовать установить более раннюю стабильную версию Discourse. В обсуждении с ChatGPT (ненадёжным, я знаю) мы решили попробовать установить версию 3.4.1. Мне казалось, что эта версия будет стабильной. Вот что в итоге мы установили:

• Версия Discourse: 3.5.0.beta2-dev
• Версия Docker: 23.0.6
• sidekiq: 6.5.12
• Версия PostgreSQL: PostgreSQL 15.12 (Debian 15.12-1.pgdg120+1)
• Версия Redis: 7.0.15
• NGINX: 1.26.2
• Версия Ubuntu: 22.04 LTS (Jammy Jellyfish)
• Версия Git: 2.39.5

Мне кажется, что независимо от наших намерений (то есть моих намерений при поддержке ИИ) установить более ранние стабильные версии, в итоге мы всё же установили Discourse 3.5.0.beta2-dev.

Это было непросто (много ложных стартов и использование команд, которые ИИ давал мне для исправления неработающих вещей), но мой Discourse наконец запущен и работает.

Вот несколько вопросов:

  1. Если я не ошибаюсь, текущим пользователям ещё не рекомендуется обновляться до версии 3.5.0, предположительно потому, что она ещё полностью не протестирована. Если это так, почему новичков вроде меня более-менее вынуждают устанавливать её?

  2. Мне кажется, что моя версия Docker устарела (снятa с поддержки). Стоит ли просто через терминал обновиться до последней версии? Discourse сейчас работает, и поскольку у меня было столько проблем с достижением этого этапа, я не хочу ничего делать, чтобы всё испортить.

  3. Мне кажется, что версии остального программного обеспечения довольно свежие. Если вы увидите что-то, что может быть проблемным или что требует обновления, пожалуйста, дайте мне знать.

  4. Есть ли страница или раздел этого сообщества, посвящённый техническим вопросам «ухода и обслуживания»? Я хочу поддерживать своё сообщество здоровым и работающим, быть готовым к любым проблемам, которые могут возникнуть, например, с резервными копиями и т.д.

2 лайка

Я только что завершил восстановление из резервной копии предыдущего сообщества Discourse. Всё прошло успешно, и, возможно, также было обновлено Docker (проблема, упомянутая выше):

Меня беспокоит сообщение, которое я получаю сразу после восстановления: «Исходящая почта отключена для пользователей, не являющихся сотрудниками».

Обратившись к другой теме здесь:

Я нашёл, где изменить этот параметр.

Теперь я полагаю, что всё в порядке, но, если возможно, буду признателен за подтверждение. Правильное значение — «no», верно? Я считаю, что обычные пользователи должны получать уведомления по электронной почте, поэтому меня немного сбивает с толку отключение этой функции. Интересно, в каких ситуациях требуется отключать отправку почты.

У меня была аналогичная проблема с отправкой писем на только что установленном Discourse, которую я подробно описал здесь:

Проблема заключалась в том, что адрес электронной почты notifications в файле app.yml не был аутентифицирован у моего SMTP-провайдера (SendGrid).

В основных логах Discourse, как и в логах SendGrid, ничего не отображалось. Ошибка была обнаружена при запуске discourse-doctor:

Причина: 550 Адрес отправителя не совпадает с подтвержденной идентичностью отправителя.

Если вы еще этого не сделали, рекомендую запустить discourse-doctor, так как это может дать больше информации о причинах неудачной отправки писем.

2 лайка

Огромное спасибо!!

Отличный совет. Я не знал о Discourse-doctor, но, думаю, это могло сэкономить мне много времени.

Я буду иметь это в виду, если столкнусь с другими проблемами. :slight_smile:

1 лайк