Установка без поддомена не работает

Привет! Я пытаюсь установить Discourse на свежую тестовую виртуальную машину с Ubuntu 20.04 (также пробовал CentOS Stream 9, Ubuntu 22.04 и openSUSE MicroOS). У меня есть опыт работы с Discourse с самых ранних дней проекта, и сейчас я оцениваю его для миграции. В данном случае речь идет о домене mydomain.tld (производственная доменная зона — это только форум, в её названии есть слово «forum», и она хорошо известна именно как форум, поэтому я категорически не хочу использовать discourse.mydomain.tld). Все мои недавние попытки установить Discourse без поддомена заканчивались неудачей. Я знаю, что раньше это было возможно, так как около 6 (?) лет назад я запускал форум Discourse именно так, без поддомена. Сейчас установка, кажется, завершается успешно, но сайт не загружается. В Ubuntu он автоматически переключается на https://, даже если я явно указываю http://, и вообще не загружается. А в CentOS и MicroOS загружается приветственная страница Nginx для http://, а при использовании https:// ничего не открывается.

Все мои попытки на вышеупомянутых операционных системах в рамках одной и той же ВМ проходят успешно, когда Discourse устанавливается на поддомен discourse.mydomain.tld, включая автоматическую настройку Let’s Encrypt. Насколько я могу судить, мои DNS-записи у регистратора домена корректны, и у меня настроено правильное обратное разрешение DNS (rDNS). Имя хоста сервера в файле /etc/hosts указано как 127.0.1.1 mydomain.tld mydomain, а скрипт discourse-install успешно проходит проверку разрешения доменного имени.

Вот вывод команды discourse-doctor. Полный лог discourse-install у меня тоже есть, если кому-то он понадобится:

DISCOURSE DOCTOR Sun Oct 9 13:32:47 UTC 2022
OS: Linux mydomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux


Found containers/app.yml

==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=mydomain.tld
SMTP_ADDRESS=mail.mydomain.tld
DEVELOPER_EMAILS=REDACTED 
SMTP_PASSWORD=REDACTED 
SMTP_PORT=587
SMTP_USER_NAME=admin@mydomain.tld
LETSENCRYPT_ACCOUNT_EMAIL=REDACTED 

==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1

DOCKER PROCESSES (docker ps -a)

CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS         PORTS                                                                      NAMES
d6f7f53a81db   local_discourse/app   "/sbin/boot"   10 minutes ago   Up 4 minutes   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   app


Discourse container app is running


==================== PLUGINS ====================
          - git clone https://github.com/discourse/docker_manager.git

No non-official plugins detected.

See https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb for the official list.

========================================
Discourse version at mydomain.tld: NOT FOUND
Discourse version at localhost: NOT FOUND


==================== MEMORY INFORMATION ====================
OS: Linux
RAM (MB): 2029

              total        used        free      shared  buff/cache   available
Mem:           1935         823         547          30         564         934
Swap:          2047           0        2047

==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        38G  8.0G   28G  23% /

==================== DISK INFORMATION ====================
Disk /dev/sda: 38.15 GiB, 40961572864 bytes, 80003072 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6643DB1B-E542-4DE1-A04C-C8EB4DAAD77E

Device      Start      End  Sectors  Size Type
/dev/sda1  528384 80003038 79474655 37.9G Linux filesystem
/dev/sda14   2048     4095     2048    1M BIOS boot
/dev/sda15   4096   528383   524288  256M EFI System

Partition table entries are not in disk order.

==================== END DISK INFORMATION ====================

==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Mail test skipped.

==================== DONE! ===================="} 

Сложно помочь, не зная предметной области. Что происходит, когда вы пытаетесь выполнить подробный запрос curl с другой машины в интернете к вашему domain.tld?

Привет, спасибо за ответ. Хорошо, это хорошая идея, похоже, что соединение не принимается:

$ curl -v mydomain.tld
*   Trying 1.2.3.4:80...
* connect to 1.2.3.4 port 80 failed: Connection refused
* Failed to connect to mydomain.tld port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 80: Connection refused

$ curl -v https://mydomain.tld
*   Trying 1.2.3.4:443...
* connect to 1.2.3.4 port 443 failed: Connection refused
* Failed to connect to mydomain.tld port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to mydomain.tld port 443: Connection refused

Возможно, это связано с каким-то ограничением в логике настройки Discourse, где ожидается, что .tld будет чем-то распространённым, например .com или .org? У меня просто домен .tech за 5 долларов, который я создал для тестирования.

Это маловероятно.

Где размещён сервер? Что находится между ним и клиентом?

Предоставление нам полного доменного имени (FQDN) поможет нам провести диагностику. В текущем виде вы просите нас помочь с выявлением проблемы, будучи завязанными на глаза, поэтому может потребоваться время, чтобы точно определить причину.

Этот инстанс был установлен с помощью discourse-setup или вы вручную создали файл YML?

Проверили ли вы, что порты 80/443 открыты в Hetzner?

В наше время Let’s Encrypt подключается по умолчанию, поэтому происходит перенаправление на безопасный порт.

Я использовал discourse-setup. Да, порты открыты. Установка на поддомен работает нормально, и я также настроил установку почтового сервера в Docker с веб-интерфейсом на этой же виртуальной машине (но позже я отформатировал её).

Вы уже читали:

?

Хм, нет. Регистратор — Hover, обычно они работают отлично. Это странно: за 20 лет настройки серверов у меня никогда не возникало проблем с веб-сайтами, размещёнными в корне домена…

Я не помню, чтобы это работало для того домена, который у меня был в Hover, но это было довольно давно.

Вы можете попробовать переключить свои NS-серверы на CloudFlare и проверить, является ли DNS проблемой, бесплатно.

Спасибо большое за подсказку.

Вы можете попробовать сменить NS-серверы на CloudFlare и проверить, является ли проблема в DNS, это бесплатно.

Извините за глупый вопрос, вы имеете в виду настройку моего локального DNS-сервера на Cloudflare? (Сейчас я использую 8.8.8.8) Или использование другого DNS-сервиса для моего домена?

Я спрашивал об этом в Hover, и они указали мне на это:

Вы можете попробовать использовать Glue-запись. Это сделает ваш сервер менеджером DNS и перенаправит доменное имя на сервер имён, который вы можете настроить с помощью Glue-записей. По сути, ваш сервер станет сервером имён.

Connecting your domain using private nameservers (Glue records) : Hover Customer Support

Мне всё ещё кажется, что это ложная подсказка. Я не понимаю, почему Discourse не будет работать в корне домена в той же ситуации, когда WordPress или Drupal работают?

Нет, я имею в виду, что вам не нужно переносить домен между регистраторами, но вам нужно будет обновить NS-записи в Hover, чтобы указать ваш домен на DNS другого провайдера для проверки этой теории. В настоящее время они установлены как ns1.hover.com и ns2.hover.com.

Это очень быстрый и практически безболезненный процесс. Если вы зарегистрируетесь в CloudFlare и попытаетесь добавить туда домен, они предоставят вам два новых имени сервера, которые нужно будет ввести в Hover. Руководство по настройке на стороне Hover можно найти здесь:

Прошло уже много времени с тех пор, как я использовал apex с чем-либо, кроме CloudFlare. Я сейчас сам проведу тест, чтобы посмотреть, смогу ли я выявить какие-либо другие подводные камни. Большинство проблем с apex касаются CNAME, но теперь я вижу, что вы используете A-запись.

Мой лучший предположение — вы выполнили множество пересборок с ошибочной конфигурацией, и теперь Let’s Encrypt не выдаёт сертификат из-за ограничения частоты запросов.

Если это так, вы можете подождать неделю или попробовать использовать www в качестве поддомена — что, впрочем, и так является хорошей практикой в наши дни.

Вы можете посмотреть логи в /var/discourse/shared/log/var-log/nginx/access.log или, возможно,

docker logs app

Я ожидаю, что вы увидите ошибки, связанные с несуществующим или недействительным сертификатом.

На данный момент я отключил SSL в app.yml и выполнил повторную сборку, и теперь Discourse загружается на порту 80 без поддомена.

Также я теперь использую Hetzner DNS в качестве авторитетного. Не уверен, повлияло ли это или проблема была в неудачной попытке получения сертификата Let’s Encrypt. Сообщу снова после следующей пересборки, как только смогу создать сертификаты Let’s Encrypt и снова включить SSL.

Если вы пытались восстановить сертификат более пары раз, возможно, вы уперлись в ограничение скорости от Let’s Encrypt. Вы можете обойти это, добавив еще одно имя хоста в ваш сертификат.

Да, но я считаю, что эти инструкции больше не работают.

Причина, по которой вы не подключаетесь к порту 443, в том, что сертификат повреждён, и это вызывает ошибку в nginx n

Спасибо всем за быстрые ответы. Похоже, это действительно была проблема с лимитом запросов Let’s Encrypt. Я создал новый домен на Hover, и на этот раз установка Discourse прошла успешно без использования поддомена.

Привет снова, @pfaffman, или любой другой, глупый вопрос: Обновляется ли сертификат Let’s Encrypt каждый раз, когда я запускаю ./launcher rebuild app? Иными словами, столкнусь ли я с дальнейшими ограничениями скорости, если буду немного экспериментировать и несколько раз подряд пересобирать (но не начинать заново с нуля) свой экземпляр Discourse? Большое спасибо.

Я довольно уверен, что если у вас есть действительные сертификаты, система не будет запрашивать их при каждой пересборке.