Здравствуйте,
bash-скрипт ./discourse-setup не заполняет DISCOURSE_SMTP_DOMAIN в файле конфигурации PUPS.
Я использовал команду rake admin:create внутри контейнера, чтобы обнаружить следующее влияние на графический интерфейс;
В какой-то момент оно, кажется, заполнялось именем хоста. Но в большинстве случаев это не имеет значения.
Можно ли использовать какое-то регулярное выражение для извлечения домена электронной почты после символа @ в переменной DISCOURSE_NOTIFICATION_EMAIL?
Речь идет о случаях развертывания, когда домен электронной почты отличается от домена веб-сайта.
Например:
DISCOURSE_SMTP_DOMAIN=$(echo "$DISCOURSE_NOTIFICATION_EMAIL" | sed -E 's/^[^@]+@(.+)$/\1/')
Эта переменная задаёт имя хоста EHLO, используемое клиентом во время SMTP-диалога.
Почти никому это не нужно, и практически никогда не имеет значения, какое значение ей присвоено.
(Я не встречал ни одной ситуации, где это имело бы значение).
Скорее всего, по умолчанию следует использовать порт 2525 или предложить пользователям, что большинство виртуальных машин блокируют порты SMTP, а большинство SMTP-сервисов работают на порту 2525 (хотя это уже довольно много слов).
Тот факт, что Digital Ocean блокирует порт 587, является ужасным и необоснованным решением, не имеющим под собой оснований в виде передовой практики.
Удивительно, что они ещё не начали блокировать порт 2525 по умолчанию по той же причине.
Я не спорю. Я почти уверен, что они не единственные, кто так поступает (хотя мне трудно это подтвердить). Странно то, что они вроде бы всегда так делали, но в прошлом апреле (?) они начали применять это ко всем. Но «все» в данном случае означает скорее «все после следующей перезагрузки» (возможно, это зависит от чего-то ещё, что требует перезагрузки), поэтому может пройти несколько месяцев, прежде чем вы перезагрузите сервер (или измените размер своего droplet или что-то в этом роде), и только тогда это начнёт происходить.
При этом они даже не предлагают SMTP-сервис, поэтому, как только они заблокируют порт 2525, отправки почты не останется никакой возможности. У меня много пользователей на DO, так как CDCK рекомендовал их с самого начала (или, по крайней мере, с того момента, как я начал этим заниматься).
Как вы это обнаружили? Пробовали ли вы задачу emails:test в Rake? Если да, то была ли она полезной? Вы знали о её существовании?
Спасибо, Майкл. Вот что на самом деле произошло при сегодняшней установке и как я понял, что порт 587 был корнем проблемы.
Когда я впервые запустил ./discourse-doctor в 50:30, он явно показал, что исходящий SMTP на порту 587 не работает. В этой части процесса не было ни одного успешного тестового письма. Из-за этого в 51:38 я изменил порт SMTP на 2525 и пересобрал контейнер. Как только приложение снова запустилось, первое тестовое письмо в 57:46 сразу же прошло успешно.
В 57:58 я отметил, что мой аккаунт Mailgun всё ещё не активирован — значит, утилита doctor была права: сбой SMTP был вызван не учётными данными, а блокировкой порта провайдером DigitalOcean.
Поскольку Brevo запускается быстрее, я сменил провайдера: начал настройку в 58:40, выбрал бесплатный тариф в 1:01:12, изменил DNS-записи в 1:02:29 и обновил настройки SMTP в файле app.yml в 1:04:37. В 1:06:08 я указал, что GUI отображает DISCOURSE_SMTP_DOMAIN даже тогда, когда переменная не заполнена через ./discourse-setup, поэтому пустое поле сначала заставило меня подумать, что что-то настроено неверно.
После завершения настройки Brevo я снова запустил ./discourse-doctor в 1:42:10, и в 1:42:25 он подтвердил успешную отправку исходящего письма — снова через порт 2525.
Отвечая на ваши конкретные вопросы:
- Как я обнаружил, что DigitalOcean блокирует порт 587?
Утилита ./discourse-doctor сразу сообщила о сбое на порту 587, а переключение на порт 2525 мгновенно всё исправило. В видео эта последовательность действий показана чётко. - Использовал ли я команду rake emails:test?
На тот момент — нет. Я полагался на ./discourse-doctor и тестовое письмо из административного интерфейса. Я не знал о существовании emails:test, пока вы не упомянули об этом. В дальнейшем я обязательно буду использовать её, так как она даёт более понятную диагностику внутри контейнера. - Была ли проблема с отсутствующим DISCOURSE_SMTP_DOMAIN связана с этим?
Нет — пустое поле в GUI было ложным следом. Реальная проблема заключалась в блокировке порта 587 провайдером DigitalOcean; как только я перешёл на порт 2525, работали как Mailgun (после активации), так и Brevo.
Ещё раз спасибо — ваше объяснение того, на что именно влияет DISCOURSE_SMTP_DOMAIN (только EHLO), помогло прояснить, почему отсутствие значения не имело значения.