Прежде всего, выражаю благодарность там, где она уместна: новый установщик — это большое улучшение. Когда он работает, а это происходит в большинстве случаев, он предлагает гораздо более дружелюбный путь по сравнению со старым ручным процессом, и я могу с его помощью выполнить чистую установку. Запускаешь установщик, завершаешь регистрацию/активацию как обычно, а затем приступает к настройке app.yml под свои требования. Легко и просто. Огромная благодарность @Falco и команде! Какое огромное отличие от старых времен установки Discourse.
Я пишу это, потому что также столкнулся с одним именем хоста, которое вызывало у меня проблемы, и мне кажется, что этот опыт может указать на несколько мест, где установщик мог бы предоставлять более понятную информацию для самостоятельных хостеров.
Что сработало
Я успешно установил Discourse на новом сервере, используя:
- собственное доменное имя: да
- SMTP: да
- текущий процесс установки
Установка завершилась сообщением:
Tallyho!
Congratulations, you installed Discourse!
Register a new account to get started.
Так что это не пост в стиле «новый установщик сломан». Установщик может работать очень хорошо.
Сложное имя хоста
При другой установке, используя тот же общий путь, целевое имя хоста было:
forum.domain.tld
Команда установщика была:
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
Выборы были примерно такими:
- создать файл подкачки 2 ГБ: да
- использовать свое доменное имя: да
- имя хоста:
forum.domain.tld - настроить SMTP: да
- SMTP-провайдер: SendGrid
- SMTP-порт: 587
Установщик достиг этапа:
[4/5] Проверка конфигурации домена
? Проверка вашего доменного имени...
? Подключение к forum.domain.tld успешно.
Затем он записал конфигурацию и пересобрал приложение.
Но сайт не открылся корректно в браузере. Симптом в итоге стал:
forum.domain.tld отказался от подключения
Повторные попытки пересборки и повторного запуска не помогли.
Результат Discourse Doctor
./discourse-doctor нашел контейнер приложения и ожидаемые значения конфигурации. Контейнер работал, и порты 80/443 казались связанными.
Но он сообщил:
Версия Discourse на forum.domain.tld: НЕ НАЙДЕНА
и позже:
Версия Discourse на localhost: НЕ НАЙДЕНА
Это заставило проблему казаться отличной от обычного распространения публичных DNS.
Лимит скорости ACME
Ранее в процессе устранения неполадок я также попытался выполнить установки, используя пути, assistированные службой Discourse:
- DiscourseID
- поток
yoursite.discourse.diy
Именно там происходило поведение многократных попыток/перезапусков сервера, и в журнале ACME был показан лимит скорости Let’s Encrypt:
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: too many certificates (5) already issued for this exact set of identifiers...
Полезный путь к журналу был:
/shared/letsencrypt/acme.sh.log
Это был большой урок. Из браузера сбой выглядел как общая проблема доступности. Но реальным препятствием в тот момент была выдача сертификата.
Самой запутанной частью было то, что блок статуса завершения установки не вывел это как исправимую ошибку. Конечный симптом для пользователя был просто в том, что сайт отказывал в подключении браузера.
Поздняя проверка показала цепочку сбоев более четко:
Лимит скорости ACME 429
-> файлы .cer нулевого размера в /shared/ssl
-> nginx пытается загрузить сертификат нулевого размера
-> nginx не запускается
-> порты 80/443 отказывают
-> браузер говорит "подключение отклонено"
Запрос на функцию, скрытый в опыте:
Было бы очень полезно, если бы установщик/процедура пересборки проверял /shared/letsencrypt/acme.sh.log после шага сертификата и выводил ошибки лимита скорости, такие как:
rateLimited
too many certificates
status: 429
Например:
Достигнут лимит скорости Let's Encrypt для этого имени хоста.
Подождите до времени retry-after, указанного в /shared/letsencrypt/acme.sh.log, перед повторной попыткой.
Повторные пересборки могут не помочь.
Это спасло бы пользователей от погони за проблемами DNS, SMTP, кавычками в app.yml, Docker или фаерволом, когда реальная проблема — ACME.
После снятия лимита скорости
После того как окно лимита скорости Let’s Encrypt прошло, я все еще видел запутанную ситуацию с проверкой домена.
Установщик сообщил:
[4/5] Проверка конфигурации домена
? Проверка вашего доменного имени...
? Подключение к forum.domain.tld успешно.
Но локальный DNS-запрос все еще показывал:
Resolve-DnsName -Name "forum.domain.tld"
с:
Resolve-DnsName: forum.domain.tld : DNS name does not exist.
Как могут сосуществовать эти две вещи?
Я могу представить несколько возможностей:
- сервер и рабочая станция использовали разные рекурсивные резолверы
- один резолвер имел устаревший кеш NXDOMAIN
- распространение DNS было частичным в тот момент
- установщик проверяет что-то другое, кроме простого DNS-запроса
- установщик или связанная служба имели кэшированное состояние проверки
Я не утверждаю, какая из них верна. Я просто отмечаю, что с точки зрения пользователя сообщение установщика “подключение успешно” может сделать последующие ошибки DNS или доступности более трудными для интерпретации.
Проверка изоляции DNS
Чтобы проверить, было ли это просто медленным распространением Cloudflare, я добавил другую запись в той же зоне:
test.domain.tld
В течение нескольких минут результаты публичных DNS-проверщиков стали зелеными.
Это заставило меня меньше доверять тому, что общее распространение Cloudflare было всей проблемой. Это выглядело так, будто проблема была специфична для forum.domain.tld.
Сравнительные установки
У меня также была успешная установка на другом имени хоста:
discourse.domain2.tld
используя тот же общий путь установщика.
Другое тестовое имя хоста, для диагностики DNS, было:
forum.domain3.tld
Сравнительные установки заставили меня отойти от мысли “новый установщик сломан” в сторону “здесь произошло что-то специфичное для имени хоста”.
Текущая теория
Моя текущая теория, не доказанная, заключается в том, что forum.domain.tld мог иметь какое-то специфичное для имени хоста кэшированное/зарезервированное/запомненное состояние где-то вне самого сервера.
Места, которые я обдумывал:
- DiscourseID
- поток
yoursite.discourse.diy - проверка домена на стороне установщика
- какое-то кэшированное соотношение между предыдущей попыткой настройки и именем хоста
Причина, по которой я обдумываю эти пути, assistированные службой, заключается в том, что я ранее пробовал их с тем же проблемным именем хоста, и это был также путь, где многократные попытки в конечном итоге уперлись в лимит скорости Let’s Encrypt.
Снова, это гипотеза, а не вывод.
Вопросы
- Обращается ли новый установщик к службе, контролируемой Discourse, во время установок с собственным доменом?
- Резервирует, запоминает или кэширует ли DiscourseID или поток
discourse.diyимена хостов? - Существует ли какой-либо путь сброса/освобождения для имени хоста, которое ранее использовалось или пытались использовать во время настройки?
- Что именно проверяет шаг
[4/5] Проверка конфигурации домена? - Может ли установщик более четко выводить сбои лимита скорости ACME перед финальным блоком статуса/результата?
Что помогло бы
Три вещи сделали бы путь устранения неполадок гораздо яснее:
- Четкое предупреждение установщика, когда
/shared/letsencrypt/acme.sh.logсодержит сбой лимита скорости. - Краткое объяснение того, что именно проверяет шаг проверки домена.
- Если существует какой-либо кэш или резервирование имен хостов на стороне DiscourseID /
discourse.diy/ установщика, видимый способ просмотра или освобождения этого состояния.
Спасибо еще раз за работу над новым установщиком. Он действительно ощущается как правильное направление. Я пишу это в этом духе: он работал прекрасно, когда работал, и шероховатость здесь кажется тем, что лучшая коммуникация установщика могла бы сделать гораздо более легкой для диагностики.
Написано с моими вводами моим новым лучшим другом Codex.
