Письмо активации администратора не отправлено при чистой установке с самохостингом (Ubuntu 20.04)

Поддержка Самостоятельное хостинг
1

Привет, сообщество,

У меня уже около года работает хорошо настроенная самохостинговая установка Discourse на VPS с Ubuntu 18.04. Поскольку форум вырос, я начал подготовку к переходу на более мощный VPS. Поэтому я взял минимальный образ Ubuntu 20.04, применил типичные меры по усилению безопасности и установил Discourse Docker, следуя руководству по установке за 30 минут. Я использовал те же значения, что и для рабочей установки. Однако: письмо с активацией не отправляется. Руководство Устранение неполадок с почтой при новой установке Discourse не помогло — я могу подключиться через telnet, но при запуске ./discourse-doctor получаю следующую ошибку:

>==================== ТЕСТ ПОЧТЫ ====================
Для надежного теста получите адрес на http //www mail-tester com/
Или просто отправьте тестовое сообщение себе.
Адрес электронной почты для теста? ('n' чтобы пропустить) [анонимизировано]: test-9ymkghbvc@srv1 mail-tester com
Отправка письма на test-9ymkghbvc@srv1.mail-tester com... . .
Тестирование отправки на test-9ymkghbvc@srv1.mail-tester com с использованием smtp mailbox org:587.
==================== ОШИБКА ======================
                                    НЕОЖИДАННАЯ ОШИБКА
>
>503 5.5.1 Ошибка: аутентификация не включена
>
>
>================== РЕШЕНИЕ =====================
>Это не распространенная ошибка. Нет рекомендованного решения!
>
>Пожалуйста, сообщите точное сообщение об ошибке выше на https //meta discourse org/
(И решение, если вы его найдете!)
=================================================

(пришлось удалить некоторые части URL выше, чтобы можно было опубликовать здесь)

Странная деталь: я получаю ту же ошибку при запуске ./discourse-doctor и на своей рабочей VPS, поэтому не знаю, актуальна ли эта ошибка.
Как видите, я использую mailbox.org как почтового провайдера, который работает отлично и является отличным выбором с точки зрения конфиденциальности и надежной настройки почтовой инфраструктуры. Я проверил хост и порт и использую их в Thunderbird, а также в другой установке Discourse уже несколько лет.

Есть ли какие-то идеи? Единственное различие, которое я вижу между двумя VPS, заключается в том, что рабочая работает на Ubuntu 18.08, а проблема возникает на VPS с Ubuntu 20.04.

Спасибо, cazee

2

Во время процесса ужесточения безопасности вы случайно не заблокировали порт 587?

Нет ли опечатки в вашем файле yaml.app?

smtp mailbox org:587

Разве это не должно быть

smtp.mailbox org:587

Обратите внимание на точку.

3

Спасибо за ваши идеи.

Порт 587 открыт, я могу подключиться к SMTP-серверу через telnet, как указано в руководстве по устранению неполадок.
Также протестировал с отключенным ufw — результат тот же.

Опечатки в YAML-файле нет — я намеренно убрал эти точки в своём сообщении (новая учётная запись на форуме — в одном посте разрешено только 2 URL).

Что ещё я могу проверить или сделать?

4

Выкладывайте код в виде правильных блоков кода — именно поэтому у вас возникли описанные проблемы.

5

Я наконец-то решил эту проблему.

Причиной был адрес электронной почты отправителя, который Discourse использует по умолчанию. Он формируется из имени хоста, указанного при настройке (в моём случае что-то вроде v220200xxxxxxxxxxxx.powersrv.de), что приводит к адресу отправителя noreply@v220200xxxxxxxxxxxx.powersrv.de, который отклоняется SMTP-сервером.

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

Как исправить проблему?
Найдите следующие строки в конце файла app.yml:

## Если вы хотите установить адрес электронной почты «От кого» для вашей первой регистрации, раскомментируйте и измените:
## После получения первого письма о регистрации снова закомментируйте эту строку. Она должна быть выполнена только один раз.

Раскомментируйте и измените последнюю строку на адрес, который ваш SMTP-сервер принимает как действительный адрес отправителя, например:
- exec: rails r "SiteSetting.notification_email='USER@DOMAIN.TLD'"

Теперь выполните ./launcher rebuild app, чтобы изменения вступили в силу, и готово — теперь письмо с активацией отправляется, и вы можете активировать учётную запись администратора и завершить настройку.

Как я это выяснил?
Я создал новую учётную запись электронной почты у моего провайдера веб-хостинга и снова запустил настройку Discourse с этими учётными данными SMTP — и получил письмо с активацией, как и ожидалось. Так что я понял, что проблема связана с настройками SMTP (а не с чем-то другим, связанным с настройками Ubuntu / Docker / Discourse).
После активации учётной записи администратора с помощью этого другого SMTP-сервера я перешёл в настройки > электронная почта > пропущено и нашёл неудачные попытки отправки письма с активацией: 553 5.7.1 <noreply@v220200xxxxxxxxxxxx.powersrv.de>: Sender address rejected: not owned by user USER@DOMAIN.TLD

Вывод
Я хотел бы обратить внимание команды разработчиков Discourse на запрос функции Предложение — разрешить опциональную настройку системного адреса «От кого» во время установки. Пожалуйста, рассмотрите возможность тестовых установок (например, как копию для проведения некоторых тестов перед фактическим обновлением экземпляра) без дружественного адреса хоста. Это сделало бы их настройку более плавной, без необходимости редактировать app.yaml. Кроме того, на мой взгляд, хорошо предоставить администратору возможность использовать адреса электронной почты, не привязанные к имени хоста Discourse.

Спасибо :slight_smile:

Также спасибо @codinghorror за то, что подсказали, как искать информацию о вставке блоков кода.

6

Я работаю над изменением в discourse-setup, которое потребует от вас указания notification_email в процессе настройки. Это должно решить подобные проблемы в будущем.

7

Это изменение уже объединено и будет запрашиваться при новых установках!