Правильно! Я по глупости применил конфигурацию в указанной выше странице, сравнил её с другими файлами конфигурации nginx и не мог понять, почему прокси не слушает порты 80 и 443 для Discourse…
Вот что я ожидал увидеть:
server {
listen 80;
server_name discourse.mydomain.com;
return 301 https://$host$request_uri; # перенаправление на https
}
server {
listen 443 ssl
listen [::]:443 ssl;
server_name discourse.mydomain.com;
ssl_certificate /etc/letsencrypt/live/discourse.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/discourse.mydomain.com/privkey.pem;
root /var/www/html;
# Добавьте index.php в список, если вы используете PHP
index index.html index.htm index.nginx-debian.html;
location / {
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:; # использование сокета
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
}
Извини, Стивен, за путаницу. Я просто использовал название инструмента, упомянутое в статье. Я понимаю, что NPM и nginx (как менеджер прокси) — это разные вещи, поэтому я использовал заглавные буквы…
Именно это я и пытаюсь сделать, и я понимаю, что вы не можете оказать поддержку в этом вопросе. Однако любая подсказка или ссылка будут очень кстати!
К сожалению, Джей, это невозможно: я помогаю другу развернуть приложение и не могу изменить конфигурацию его сервера. Именно поэтому мне приходится решать проблему с nginx…
Кстати, моё понимание таково:
Discourse слушает порты 80/443.
nginx выступает в роли коммутатора, распределяя запросы между различными приложениями на основе доменного имени:
netxcloud.mydomain.com, пытающийся обратиться к порту 80, → запрос направляется на server_IP:8000
crm.mydomain.com, пытающийся обратиться к порту 80, → запрос направляется на server_IP:9000
discourse.mydomain.com, пытающийся обратиться к порту 80, → запрос направляется на http://unix:/var/discourse/shared/standalone/nginx.http.sock: (надеюсь, двоеточие в конце не опечатка), так как скрипт настройки конфигурировал Discourse для прослушивания этого сокета.
Сегодня во второй половине дня я снова попробую настроить nginx. Может кто-нибудь подтвердить точный синтаксис для сокета: http://unix:/var/discourse/shared/standalone/nginx.http.sock:? Хочу убедиться, что двоеточие в конце — это не опечатка…
Действительно… Я внес в файл discourse.conf изменения, которые предложил в прошлую пятницу, и теперь Discourse работает исправно! По крайней мере, я могу открыть страницу приветствия, но письмо с активацией не приходит — это уже не связано с Discourse (я подозреваю, что мой друг не создал запрошенный почтовый аккаунт ).
От всей души благодарю вас за оказанную помощь и надеюсь, что мне не придётся возвращаться на этот форум слишком скоро!
Наконец-то, вернулся раньше, чем ожидал, но, скорее всего, вы сможете отправить меня в нокаут своими отличными предложениями!
Ситуация следующая:
Discourse запущен и работает, Docker (или Portainer) показывает, что контейнер исправен, и я могу открыть страницу приветствия по адресу forums.mydomain.com.
Я не получаю никаких писем с активацией, хотя технический почтовый аккаунт был создан правильно (провайдер хостинга — OVH).
Я проверил отправку письма с этого технического аккаунта (с конфигурацией ниже) — всё работает.
Первое, что я проверю: если forums@mydomain.com настроен на отправку от имени noreply-forums@mydomain.com, это нужно проверить у вашего поставщика услуг электронной почты.
========================================
Discourse 2.9.0.beta9
Версия Discourse на forums.mydomain.com: Discourse 2.9.0.beta9
Версия Discourse на localhost: НЕ НАЙДЕНО
==================== ПРОБЛЕМА С DNS ====================
Этот сервер сообщает «НЕ НАЙДЕНО», но forums.mydomain.com показывает версию Discourse 2.9.0.beta9.
Это указывает на проблему с DNS или на то, что виноват промежуточный прокси.
[...]
Проверка отправки на myprivatemail@yahoo.fr через ssl0.ovh.net:465, пользователь: forums@mydomain.com с обычной аутентификацией.
======================================== ОШИБКА ========================================
НЕОЖИДАННАЯ ОШИБКА
Net::ReadTimeout
====================================== РЕШЕНИЕ =======================================
Может ли проблема с почтой быть связана с предполагаемой проблемой DNS? У меня нет «промежуточного прокси», я просто использую nginx как веб-прокси-сервер…
Скорее всего, проблема именно в этом. Попробуйте использовать другой порт. Если ваш почтовый провайдер поддерживает порт 587, я рекомендую именно его — с ним результаты обычно лучше.
Если вы меняете порт на 587, вам нужно либо закомментировать эту настройку, либо установить её значение в true.
Нет, мой почтовый провайдер (тот же, что и хостинг-провайдер) разрешает только порт 465. Кстати, я прочитал, что для домена нужно настроить записи SPF и DKIM (речь о поддомене?), а я пока ничего из этого не настроил: может ли это как-то повлиять?
DNS управляется нашим хостинг-провайдером (для некоторых сервисов), предположим, на ServerA.
Discourse работает на другом сервере (ServerB), который размещён у другого провайдера.
Как я понимаю: Discourse на ServerB подключается к почтовому серверу на ServerA, аутентифицируясь по логину и паролю, чтобы использовать SMTP-сервис, предоставляемый хостинг-провайдером ServerA.
Является ли это нестандартной конфигурацией, или я всё ещё могу использовать обычную конфигурацию email в app.yml?
).
