Я не думаю, что это так сейчас.
Точно, @jomaxro. Вот почему я сказал:
Ох. Извините, я упустил это изменение.
Итак, если пользователь не указывает адрес электронной почты для уведомлений Let’s Encrypt, discourse-setup теперь без проверки включает Let’s Encrypt, не проверяя, что домен указывает на текущий сервер. Однако, если адрес электронной почты указан, проверка выполняется. Это кажется не очень хорошей идеей.
Зачем принуждать к использованию HTTPS, если у них нет действительного доменного имени? Если план состоит в том, чтобы заставить всех всегда использовать HTTPS, то мы должны проверять действительность доменного имени и в случае неудачи отказываться от запуска, а не предоставлять нерабочую установку.
В текущей реализации, если вы не указываете адрес электронной почты для Let’s Encrypt и домен не указывает на сервер, discourse-setup кажется успешным, но он запускает веб-сервер, который не принимает подключения, поскольку nginx не может найти сертификат. Я считаю, что лучше не запрашивать адрес электронной почты для Let’s Encrypt, использовать (первый?) адрес электронной почты разработчика для Let’s Encrypt и при этом проводить проверку DNS, но теперь это не должно обсуждаться в этой теме.
Нет, это не так работает Let’s Encrypt. Адрес электронной почты не имеет никакого отношения к проверке домена. Он используется для уведомления пользователя, если срок действия его сертификата истекает и его нельзя продлить. Проверка всегда выполняется через DNS.
Let’s Encrypt не может выдать сертификат для адреса, который не соответствует требованиям проверки. Если бы это было возможно, вся схема LE рухнула бы в одночасье.
Нет. Так работает (или работал) discourse-setup. Раньше он защищал пользователей от запроса сертификата, когда было почти наверняка известно, что он не сработает. Теперь же он продолжает работу, запрашивает сертификат даже тогда, когда успех невозможен, и не имеет способа сообщить пользователю о неудаче. В результате теперь он беззвучно завершается с ошибкой, не выдавая никаких предупреждений.
Повторяю, почему это должно завершиться неудачей? Электронная почта не является обязательной для проверки домена.
При неудаче письмо также никогда не отправлялось.
Электронная почта нужна только для того, чтобы позже уведомить пользователя, если Let’s Encrypt не сможет выполнить продление и сертификат вот-вот истечёт. Если сертификат будет успешно продлён, пользователь никогда не получит письмо.
Я не думаю, что это было целью изменения. Цель состояла в том, чтобы включить SSL независимо от того, предоставлен ли адрес электронной почты. Мы всё равно должны проверять разрешение домена, cc @Falco
Это произойдет, если доменное имя не будет разрешено на хост. Адрес электронной почты не имеет значения, но если он указан, настройка Discourse предупредит пользователя, если адрес не будет разрешен.
Разрешение домена обязательно должно проходить через @falco, иначе настройка должна быть остановлена. Это плохое изменение.
Итак, я внес некоторые изменения в ветку. Вот как это будет работать:
Использование неверного имени хоста:
root@droplet:/var/discourse# ./discourse-setup
Имя хоста для вашего Discourse?: bad-domain.com
Проверка имени домена . . .
ПРЕДУПРЕЖДЕНИЕ:: Похоже, что этот сервер недоступен по адресу bad-domain.com:443.
Подключение к http://bad-domain.com (порт 80) также не удалось.
Это указывает на то, что bad-domain.com разрешается в неправильный IP-адрес
или что трафик не маршрутизируется на ваш сервер.
Google: "открытые порты ВАШЕ ОБЛАЧНОЕ ОБСЛУЖИВАНИЕ" для получения информации о решении этой проблемы.
Если вы хотите продолжить в любом случае, вам нужно будет выполнить команду cp samples/standalone.yml containers/app.yml
и вручную отредактировать файл containers/app.yml.
Использование правильного имени хоста:
root@droplet:/var/discourse# ./discourse-setup
Имя хоста для вашего Discourse?: good-domain.com
Проверка имени домена . . .
Подключение к good-domain.com успешно.
Адрес электронной почты для учетной записи администратора(ов)? :
Изменения находятся в ожидании по адресу:
Выглядит ли это хорошо, @pfaffman @codinghorror?
Комментарий о том, почему это изменение вообще потребовалось
Во-первых, меня удивляет, что за почти три месяца, прошедших с момента введения этого изменения, не поступило множества жалоб. Более того, тема, которая привлекла моё внимание к этой проблеме, не испытывала трудностей из-за этого изменения, так что, возможно, это не так важно, как я думаю.
Первое, чего я действительно не понимаю: вы действительно хотите сделать так, чтобы с помощью discourse-setup было невозможно настроить сайт только на HTTP? Допустим, они уже выполнили множество действий с DNS для настройки почты, поэтому, возможно, создание записи A не станет для них большой проблемой.
Отзывы об изменении
Если вы не внесли изменений, которые я не заметил, то скрипт создаёт файл app.yml ещё до того, как начинает задавать вопросы. Поэтому можно просто вывести сообщение вроде: «Установка Discourse без конфигурации DNS не поддерживается. Чтобы продолжить без настройки DNS, отредактируйте app.yml в соответствии с вашими потребностями и выполните ./launcher rebuild app», а затем завершить работу без начальной настройки.
Кроме того, если вы собираетесь обязать всех использовать Let’s Encrypt и HTTPS, то имеет смысл соответственно изменить файлы standalone.yml и web_only.yml, после чего можно будет убрать эти капризные команды sed.
Дополнительные размышления
Из раздела «это моя проблема»: мой текущий скрипт установки запускается до того, как пользователи успевают настроить DNS. Я создаю для них droplet, настраиваю Discourse, отправляю им письмо с инструкциями по DNS, жду, пока DNS будет настроен, а затем изменяю app.yml, чтобы включить шаблоны и указать адрес Let’s Encrypt. Но, полагаю, это лишь по историческим причинам. Вместо этого мне следовало бы создать droplet, настроить Mailgun, дождаться настройки DNS, а затем выполнить установку. Это всё равно позволило бы моему скрипту использовать discourse-setup, что мне нравится делать как частный тест на работоспособность (вы, ребята, не проводите ли автоматическое тестирование discourse-setup?)
Да.
Я не получил ни одной жалобы на это изменение. С момента его внедрения у меня больше нет множества экземпляров Discourse, работающих только на HTTP, потому что, когда вы говорите, что что-то является ОПЦИОНАЛЬНЫМ, все пропускают это без раздумий. На мой взгляд, это отличное изменение, обеспечивающее безопасные настройки по умолчанию для Discourse, что полностью соответствует нашей цели в руководстве за 30 минут.
О, это ещё лучше, нужно меньше инструкций!
Теперь я понимаю вашу резкую реакцию на это изменение, так как оно нарушило вашу схему работы. Приношу извинения за это.
Я настоятельно рекомендую использовать прямой файл yml для любых автоматизированных задач вместо ориентации на интерактивный скрипт.
tl;dr: Да, с небольшой правкой формулировки, которую я рекомендовал, всё выглядит хорошо.
Согласен. Ни одной жалобы! Звучит как победа.
Нет! Оно не нарушило. (!) Я лишь отчасти заметил, что сайты не загружаются, прежде чем выполнил второй этап установки, который включает HTTPS. И моя настройка — не ваша ответственность. (О, ТЕПЕРЬ это сломает мой скрипт, но всё равно лучше не проводить установку до настройки DNS. Я не делал установку без HTTPS уже как минимум год.)
Причина, по которой мне нравилось использовать discourse-setup в моём скрипте, заключалась в том, что это гарантировало, что клиенты, использующие мой скрипт, получают стандартную установку. И когда кто-то говорит: «Я сделал установку, но она не работает», я могу запустить свой скрипт, выполнить ровно то, что они должны были сделать, и сказать: «Ну, я только что сделал установку, и она работает». Но я не припомню ни одного случая за последние три года, когда я находил проблему, так что, возможно, моё «тестирование» никому не приносит пользы.
Круто, спасибо за анализ и обзор!
Объединил PR, поэтому теперь мы всегда будем проверять DNS.