Discourse установлен по официальному руководству на GitHub
Всё прошло хорошо, но при обращении к форуму возникает ошибка 502.
Я попытался проверить логи Rails production, но не нашёл записей production_error или логов Sidekiq.
При использовании tail увидел следующее:
Creating scope :open. Overwriting existing method Poll.open.
Creating scope :open. Overwriting existing method Poll.open.
Can’t reach ‘/images/welcome/discourse-edit-post-animated.gif’ to get its dimension.
Запуск команды discourse doctor показывает:
Discourse version at forum.abc.com.au: NOT FOUND
Я попробовал отключить SSL и пересобрать систему — после этого форум стал доступен.
Должна быть проблема с SSL, которую я не могу определить. При установке SSL разрешение IP-адреса прошло успешно.
После анализа всех логов выяснилось, что ошибка связана с выпуском сертификата Let’s Encrypt. Если у кого-то возникла похожая проблема, пожалуйста, поделитесь решением ниже.
forum.abc.com.au:Verify error:CAA record for forum.abc.com.au prevents issuance
Перед запуском скрипта установки Discourse для поддомена необходимо проверить, есть ли у основного домена записи CAA, и убедиться, что центр сертификации — не Let’s Encrypt (в моём случае запись CAA для основного домена указывает на comodoca.com). В такой ситуации сертификаты Let’s Encrypt для Discourse не будут выпущены.
Если вы знаете способ проверки этих записей, не требующий дополнительного программного обеспечения, я рассмотрю возможность добавления такой проверки в утилиту discourse-setup, но я никогда раньше этого не видел.
Можно с уверенностью предположить, что если вы владеете доменом и знаете, что такое CAA, и смогли его настроить, то вы понимаете последствия использования Let’s Encrypt.
@pfaffman
Команда dig caa {domain.tld} вернёт запись.
Сначала нужно проверить, возвращает ли она какие-либо записи.
Затем, если возвращает, убедиться, что выдающий орган отличается от letsencrypt.org.
Однако это очень редкий случай. Не уверен, стоит ли включать эту проверку.
Верно. Если я владею доменом, я знаю, что с ним делать.
Я помогал кому-то, и эта проблема может возникать у хостинг-провайдеров, использующих cPanel и предоставляющих автоматические SSL-сертификаты от других поставщиков, таких как Comodo. При создании сайта (например, WordPress) в cPanel они по умолчанию добавляют множество записей.
В любом случае, это очень редкий случай, я впервые с таким сталкиваюсь.
CAA здесь время от времени всплывает. Стандартный ответ, который мы получаем, когда указываем, что они ограничили выпуск сертификатов для всего своего домена, обычно выглядит так:
Если вы установите запись CAA для @ (домена), это будет применяться как к домену верхнего уровня, так и к поддоменам. Вы всё равно можете добавить специфичную запись CAA для subdomain.yourdomain.com для сервиса, такого как Let’s Encrypt, что ограничит область, в которой LE может выпускать сертификаты.
Вы также можете указать issuewild вместо issue, чтобы разрешить центру сертификации выпускать wildcard-сертификаты, а также использовать iodef для указания адреса электронной почты, на который будут отправляться уведомления о нарушениях политики.
Та же проблема. Команды не решили вопрос. Я переключился на DNS и прокси Cloudflare. Проблема для меня сохраняется.
Я делал это несколько раз, и такого раньше не случалось. Но я точно не программист, не эксперт и вообще ни в чём не разбираюсь. Просто обычный довольный пользователь. Но это раздражает.
Скорее всего, вы включили прокси Cloudflare и несколько раз пересобирали проект, из-за чего достигли лимитов Let’s Encrypt. Теперь вам придётся ждать неделю, чтобы получить сертификат.
Быстрое и простое решение — выбрать новое поддоменное имя, установить для Cloudflare режим «только DNS» и пересобрать проект. Если это сработает, значит, я прав насчёт ограничения частоты запросов. В таком случае вы можете либо смириться с новым поддоменом, либо подождать неделю, прежде чем попробовать снова.
Я как раз об этом же задумывался. Не уверен насчёт запроса, но если сертификат найден валидным, то новый не выдаётся (только что пересобрал песочницу).
