Старые домены мультисайта продолжают отображать форум по умолчанию после отключения мультисайта

[Abdelrahman_MoHamed]

Ранее мы использовали настройку Discourse для нескольких сайтов с примерно 22 различными форумами. Недавно мы решили отказаться от конфигурации нескольких сайтов и оставить только сайт по умолчанию:

Сайт по умолчанию теперь: forum.mamapedia.com
Удален старый домен для нескольких сайтов: forum.employ.com (и еще 21 домен)

Проблема:

Даже после отключения настройки для нескольких сайтов старые домены все еще могут обслуживать форум по умолчанию (forum.mamapedia.com). Например:

• Переход на forum.mamapedia.com работает как ожидалось
• Но при переходе на forum.employ.com все еще загружается форум Mamapedia

Мы ожидали, что старые домены, такие как forum.employ.com, будут либо:

1. Показывать ошибку (поскольку они больше не настроены)
2. Корректно перенаправлять или быть полностью неактивными

Примечания по настройке:

• Мы используем SSL-сертификаты Cloudflare с включенной опцией прокси (трафик не идет напрямую на наш сервер).
• Мы можем удалить A-записи для старых доменов, но нам действительно нужно выявить и устранить коренную причину, а не полагаться на обходное решение на уровне DNS.

Выполненные шаги:

1. Удалили настройки для нескольких сайтов из discourse.conf и базы данных
2. Перезапустили Discourse и проверили настройки в app.yml
3. Очистили кэш и протестировали в режиме инкогнито

Ожидаемое поведение:

• forum.mamapedia.com должен продолжать работать
• forum.employ.com и другие старые домены не должны обслуживать форум Mamapedia

Вопросы:

1. Как правильно удалить старые домены, чтобы они не обслуживали форум по умолчанию?
2. Нужно ли нам изменить настройки Nginx/Traefik, Cloudflare или есть какая-то специфичная для Discourse конфигурация, которую мы упустили?

Конфигурация Nginx

[pfaffman (Jay Pfaffman)]

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

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

Единственная сложность заключается в том, что вам нужно перенаправить DNS на новый сервер во время восстановления, чтобы он мог получить сертификат. Убедитесь, что DNS Cloudflare настроен только как DNS.

[Abdelrahman_MoHamed]

Спасибо, @pfaffman! Мы попытались перейти с мультисайтовой конфигурации на стандартную установку, но проблема сохраняется.

Что мы сделали:

1. Удалили установку Discourse:

• Удалили весь каталог /var/discourse.

2. Переустановили Discourse:

• Снова клонировали репозиторий Discourse.
• Создали файл app.yml с необходимыми настройками.

3. Пересобрали приложение:

• Запустили команду ./launcher rebuild app.

4. Обновили DNS:

• Направили домен на новый сервер.
• Переключили Cloudflare в режим только DNS, чтобы обеспечить выпуск SSL-сертификата.

Дополнительная проблема с SSL:

• Когда мы включили SSL в app.yml и отключили прокси Cloudflare, возникла следующая проблема, даже после включения SSL:

Вопросы:

1. Может ли проблема быть связана с отсутствием восстановления резервной копии базы данных?
2. Требуются ли дополнительные шаги для очистки старых конфигураций мультисайта?
3. Как правильно включить SSL в этой конфигурации, чтобы избежать проблем?

Будем благодарны за любые советы от тех, кто уже сталкивался с этим!

[pfaffman (Jay Pfaffman)]

@Abdelrahman_MoHamed

Воссоздал app.yml с необходимыми настройками.

Вы запускали discourse-setup или настраивали вручную?

Есть ли у вас шаблоны для SSL и Let’s Encrypt?

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

[RGJ (Richard - Communiteq)]

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

@Abdelrahman_MoHamed

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

То, что старые записи указывают на ваш сайт, и есть коренная причина.
Очистка вашей старой конфигурации — это не обходное решение, это и есть правильное решение.

[pfaffman (Jay Pfaffman)]

Ого. Не помню, когда в последний раз я не соглашался с вами по факту. Как правило, когда я вижу ваш аватар в теме, в которой я комментировал, я знаю, что узнаю что-то новое!

@RGJ

Причина этого проста. Multisite выбирает форум на основе имени хоста.

Это правда. Однако они утверждают, что перешли на стандартную установку. Я им не верю.

@RGJ

Стандартная установка (не multisite) с радостью примет любое имя хоста, которое вы укажете.

Уже несколько лет (но, думаю, с момента появления Let’s Encrypt) в стандартной установке, если вы обращаетесь к ней через другое имя хоста, она выполняет редирект (это легко проверить, используя IP-адрес; я только что сделал это снова, добавив forum.bigmouth.bass в /etc/hosts для стандартной установки, и редирект сработал, как и ожидалось). Если вы обращаетесь к ней через HTTPS, что большинство браузеров делают по умолчанию сейчас, вы получите ошибку сертификата.

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

Думаю, вот в чём магия:

templates/web.ssl.template.yml

Мое предположение: в app.yml всё ещё что-то вроде этого:

@pfaffman

   # не перенаправлять все хосты обратно на основное доменное имя
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /if \(\$http_host[^\}]*\}/m
        to: ""
    - replace:
        filename: "/etc/nginx/conf.d/discourse.conf"
        from: /return 301.*$/
        to: "return 301 https://$host$request_uri;"

[RGJ (Richard - Communiteq)]

@Jay Pfaffman

Я знаю, что узнаю что-то новое!

Что ж, теперь я узнал, что мне стоит чаще обновлять свои знания! Этот код существует с 2014 года, так что, видимо, я жил очень далеко в прошлом.

Вы абсолютно правы, это перенаправит.

[Abdelrahman_MoHamed]

Спасибо @RGJ, @pfaffman,

Мы проверили app.yml, и в нём нет пользовательских конфигураций или переопределений перенаправлений. Однако наш экземпляр по-прежнему не перенаправляет неизвестные имена хостов на основной домен.

1. Конфигурация Nginx: Можно ли проверить, применяется ли логика перенаправления из templates/web.ssl.template.yml? Нужно ли нам вручную проверять сгенерированный конфиг Nginx внутри контейнера?

2. Отладка Discourse: Есть ли какие-либо логи или команды, которые можно выполнить внутри контейнера, чтобы подтвердить, что Discourse корректно обрабатывает имена хостов?

3. Другие возможные причины: Если app.yml чист, что ещё может препятствовать ожидаемому поведению перенаправления? Не мешает ли Cloudflare или какой-то другой параметр?

Будем признательны за любые подсказки, как углубиться в это!

[RGJ (Richard - Communiteq)]

@RGJ

Очистка вашей старой конфигурации — это не временное решение, это само решение.

Вот указатель.

[pfaffman (Jay Pfaffman)]

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

Но если использование Cloudflare позволяет злоумышленнику (в данном случае вам) обслуживать чужой сайт на его домене, это кажется проблемой.

[Abdelrahman_MoHamed]

Хорошо, нужно ли мне запускать

./discourse-setup

после загрузки Discourse или мне следует вставить свой старый app.yml после загрузки, а затем запустить

./launcher rebuild app

Какой путь выбрать?

[Abdelrahman_MoHamed]

Мы уже удалили старые домены, но да, у них была включена оранжевая кнопка. Сейчас проблема в том, что если кто-то узнает IP нашего сервера и создаст там запись с включённой опцией прокси, наш сайт будет обслуживаться через их домен.

[pfaffman (Jay Pfaffman)]

Вам следует запустить discourse-setup, чтобы убедиться, что у вас действительно стандартная установка. Если вы вставите свой старый app.yml, там может оказаться что-то лишнее. Я до сих пор не совсем убеждён, что у вас стандартная настройка.

@Abdelrahman_MoHamed

теперь проблема в том, что если кто-то узнает IP-адрес нашего сервера и создаст там запись с включённой опцией прокси, он будет обслуживать наш сайт под своим доменом

Я до сих пор не уверен, что это так, но даже если это правда, вы ничего не сможете с этим поделать.

[Jagster (Jakke Flemming)]

@Abdelrahman_MoHamed

если у кого-то есть IP нашего сервера

Большинство IP-адресов серверов по всему миру являются публичными. В этом и заключается суть IP-системы.

[Abdelrahman_MoHamed]

Я очень хочу поблагодарить вас, @pfaffman и @RGJ, теперь всё чисто и почти в порядке.

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

Данные брендинга в порядке — я могу загрузить их со старого сервера, но что насчёт изображений пользователей? Все изображения сайта также отсутствуют.

Новый сервер

Старый сервер

ПРИМЕЧАНИЯ:

• Мы выполнили шаги миграции, запустив discourse remap для того же домена и rake posts:rebake.
• Возможно, это связано с историей мульти-сайтов, и нам требуется специальная перенастройка в соответствии с этой ссылкой:
  Serve Discourse from a subfolder (path prefix) instead of a subdomain - #101 by jtraulle ?

[pfaffman (Jay Pfaffman)]

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

[Jacob_Peebles]

При просмотре отсутствующих изображений видно, что у них вложенный URL, вот один из них:

(https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png)

И @pfaffman, это действительно был основной сайт в настройке мультисайта.

CC: @Abdelrahman_MoHamed

[pfaffman (Jay Pfaffman)]

@Jacob Peebles

/user_avatar/forum.mamapedia.com/

Хм. Ну, если бы это был основной сайт, я бы ожидал, что путь будет https://forum.mamapedia.com/user_avatar/forum.mamapedia.com/jakeatgetit/24/5872_2.png, но это тоже не работает.

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

[Abdelrahman_MoHamed]

Спасибо, @pfaffman, то, что я сделал до сих пор, кажется, работает.

Я зашел на старый сервер, переместил данные из /var/discourse/shared/standalone/uploads/default в тот же путь на новом сервере, и все аватары пользователей и сообщения восстановились.

Новая проблема в том, что брендинг сайта не работает, даже если я пытаюсь его обновить.

Вот минутная запись экрана:
https://www.veed.io/view/89c9e122-57bd-40b3-a5c5-d510a56973e4?panel=share

[Jacob_Peebles]

Проверяю здесь, нет ли у кого-нибудь идей. Мы очень близки к завершению этого вопроса с нашей стороны, нам нужна лишь помощь в устранении неполадок с проблемой сохранения «без логотипа». Заранее спасибо за любые предложения по решению этой проблемы!