Instalação sem subdomínio não está funcionando

Olá, estou tentando instalar o Discourse em uma VM nova do Ubuntu 20.04 em um testbed (também tentei CentOS Stream 9 e Ubuntu 22.04 e openSUSE MicroOS). Tenho alguma experiência com o Discourse desde os primórdios do projeto e estou avaliando para uma migração. Nesse caso, seria para mydomain.tld (o domínio de produção é apenas um fórum e tem "fórum" em seu nome e é bem conhecido como tal, então eu definitivamente não quero discourse.mydomain.tld). Todas as minhas tentativas recentes de instalar o Discourse sem um subdomínio falharam. Sei que costumava ser possível porque executei um fórum Discourse assim há cerca de 6(?) anos sem um subdomínio. Agora a instalação parece ser concluída com sucesso, mas o site não carrega. No Ubuntu, ele muda automaticamente para https:// mesmo quando eu explicitamente coloco http://, e ele não carrega de forma alguma. E no CentOS e MicroOS, ele carrega a página de boas-vindas do Nginx http://, e nada carrega com https://.

Todas as minhas tentativas nos sistemas operacionais acima na mesma VM funcionam bem quando o Discourse é instalado em um subdomínio em discourse.mydomain.tld, incluindo a autoconfiguração do Let’s Encrypt. Pelo que pude apurar, meus registros DNS estão corretos no registrador de domínio e tenho resolução rDNS adequada. O nome do host do servidor em /etc/hosts mostra 127.0.1.1 mydomain.tld mydomain e o script discourse-install é bem-sucedido na verificação de resolução do nome de domínio.

Aqui está a saída do discourse-doctor, também tenho o log completo do discourse-install se alguém quiser:

DISCOURSE DOCTOR Dom, 9 de Out de 2022 13:32:47 UTC
SO: Linux mydomain 5.4.0-125-generic #141-Ubuntu SMP Qua, 10 de Ago 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux


Containers/app.yml encontrados

==================== CONFIGURAÇÕES DO YML ====================
DISCOURSE_HOSTNAME=mydomain.tld
SMTP_ADDRESS=mail.mydomain.tld
DEVELOPER_EMAILS=REMOVIDO 
SMTP_PASSWORD=REMOVIDO 
SMTP_PORT=587
SMTP_USER_NAME=admin@mydomain.tld
LETSENCRYPT_ACCOUNT_EMAIL=REMOVIDO 

==================== INFORMAÇÕES DO DOCKER ====================
VERSÃO DO DOCKER: Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1

PROCESSOS DO DOCKER (docker ps -a)

CONTAINER ID   IMAGE                 COMMAND        CRIADO          STATUS         PORTAS                                                                      NOMES
d6f7f53a81db   local_discourse/app   \"/sbin/boot\"   10 minutos atrás   Subindo há 4 minutos   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app


O container app do Discourse está em execução


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

Nenhum plugin não oficial detectado.

Veja https://github.com/discourse/discourse/blob/main/lib/plugin/metadata.rb para a lista oficial.

========================================
Versão do Discourse em mydomain.tld: NÃO ENCONTRADA
Versão do Discourse em localhost: NÃO ENCONTRADA


==================== INFORMAÇÕES DE MEMÓRIA ====================
SO: Linux
RAM (MB): 2029

              total        usado        livre      compartilhado  buff/cache   disponível
Mem:           1935         823         547          30         564         934
Swap:          2047           0        2047

==================== VERIFICAÇÃO DE ESPAÇO EM DISCO ====================
---------- Espaço em Disco do SO ----------
Filesystem      Tamanho  Usado  Disponível Uso% Montado em
/dev/sda1        38G    8.0G      28G    23% /

==================== INFORMAÇÕES DE DISCO ====================
Disco /dev/sda: 38.15 GiB, 40961572864 bytes, 80003072 setores
Modelo do disco: QEMU HARDDISK   
Unidades: setores de 1 * 512 = 512 bytes
Tamanho do setor (lógico/físico): 512 bytes / 512 bytes
Tamanho de E/S (mínimo/ótimo): 512 bytes / 512 bytes
Tipo de label do disco: gpt
Identificador do disco: 6643DB1B-E542-4DE1-A04C-C8EB4DAAD77E

Device      Start      End  Sectors  Size Tipo
/dev/sda1  528384 80003038 79474655 37.9G Sistema de arquivos Linux
/dev/sda14   2048     4095     2048    1M Boot BIOS
/dev/sda15   4096   528383   524288  256M Sistema EFI

As entradas da tabela de partição não estão na ordem do disco.

==================== FIM DAS INFORMAÇÕES DE DISCO ====================

==================== TESTE DE MAIL ===================
Para um teste robusto, obtenha um endereço de http://www.mail-tester.com/
Teste de mail pulado.

==================== PRONTO! ====================
1 curtida

Difícil ajudar sem saber o domínio. O que acontece quando você tenta um curl verboso de outra máquina na internet para o seu domínio.tld?

1 curtida

Olá, obrigado pela resposta. Ok, essa é uma boa ideia, parece que não está aceitando a conexão:

$ 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

Será que é possivelmente devido a alguma limitação na lógica de configuração do Discourse, onde ele espera que .tld seja algo comum como .com ou .org? O meu é apenas um domínio $5 .tech que criei para testes.

É improvável.

Onde o servidor está hospedado? O que fica entre ele e o cliente?

Fornecer o FQDN nos ajuda a solucionar alguns problemas. Do jeito que está, você está nos pedindo para ajudar a diagnosticar isso de olhos vendados, então pode levar um tempo para identificar.

2 curtidas

Esta instância foi instalada usando discourse-setup ou você criou o arquivo YML manualmente?

Você verificou se 80/443 estão abertos no Hetzner?

Let’s encrypt está habilitado como padrão atualmente, daí o redirecionamento para uma porta segura.

Eu usei o discourse-setup. Sim, as portas estão abertas. A instalação em um subdomínio funciona bem, e eu também configurei uma instalação Docker de um servidor de e-mail com uma interface web nesta mesma VM (mas depois a reformatei).

Você já leu:

Ainda?

Hmm não. O registrador é Hover, eles normalmente são muito bons. Isso é bizarro, em 20 anos configurando servidores eu nunca tive problemas com sites na raiz de um domínio…

Não me lembro de ter funcionado para o único domínio que tive na Hover, mas isso foi há algum tempo.

Você poderia tentar trocar seus NS para o CloudFlare e testar se o DNS é o problema a partir daí, sem custo.

Muito obrigado por me indicar isso.

Você poderia tentar trocar seu NS para CloudFlare e testar se o problema é o DNS a partir daí, sem custo.

Desculpe pela pergunta idiota, você quer dizer configurar meu DNS local para o Cloudflare? (Estou usando 8.8.8.8 no momento) Ou usar um serviço de DNS diferente para o meu domínio?

Perguntei à Hover sobre isso, e eles me indicaram isto:

O que você poderia fazer é tentar usar um registro Glue. Isso fará com que seu servidor seja o gerenciador de DNS e roteará o nome de domínio para um servidor de nomes que você pode configurar usando registros Glue. Basicamente, seu servidor se torna o servidor de nomes.

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

Isso ainda parece uma pista falsa para mim. Não entendo por que o Discourse não funcionaria na raiz do domínio na mesma situação em que o WordPress ou o Drupal funcionariam?

Não, quero dizer que você não precisa mover seu domínio entre registradores, mas precisará atualizar os registros NS no Hover para que seu domínio aponte para o DNS de um provedor diferente para testar essa teoria. Atualmente, eles estão definidos como ns1.hover.com e ns2.hover.com

É um processo muito rápido e bastante indolor. Se você se inscrever no CloudFlare e tentar adicionar o domínio lá, eles lhe darão dois novos servidores de nomes que precisam ser inseridos no Hover. Há um guia para o lado do Hover aqui:

1 curtida

Faz um tempo que não uso o apex com outra coisa além do CloudFlare. Vou testar isso em breve para ver se consigo identificar outros problemas. A maioria dos problemas com o apex se aplicam a cnames, mas agora vejo que você está usando um registro A.

1 curtida

Minha melhor suposição é que você fez várias reconstruções com algo mal configurado e agora o Let’s Encrypt não emitirá um certificado por causa da limitação de taxa.

Se for esse o caso, você pode esperar uma semana ou tentar usar www como subdomínio, o que é realmente uma boa ideia nos dias de hoje.

Você pode verificar os logs em /var/discourse/shared/log/var-log/nginx/access.log ou talvez

docker logs app

Espero que você veja problemas com o certificado não existente ou inválido.

1 curtida

Por enquanto, desabilitei o SSL em app.yml e fiz uma reconstrução, e o Discourse agora está carregando na porta 80 sem um subdomínio.

Também estou usando o DNS da Hetzner como autoritativo. Não tenho certeza se isso fez a diferença ou se foi o problema de certificado Let’s Encrypt falho. Voltarei a relatar após outra reconstrução, assim que puder criar certificados Let’s Encrypt novamente e reativar o SSL.

Se você tentou reconstruir mais de duas vezes, provavelmente está sendo limitado pelo letsencrypt. Você pode contornar isso adicionando outro nome de host ao seu certificado.

1 curtida

Sim, mas acredito que essas instruções não funcionam mais.

O motivo pelo qual você não está se conectando à Porta 443 é que o certificado está corrompido e causa um erro no nginx.

3 curtidas

Obrigado a todos pelas respostas rápidas. Parece que foi realmente apenas uma questão do limite de taxa do Let’s Encrypt. Criei um novo domínio no Hover e desta vez a instalação do Discourse funcionou bem sem um subdomínio.

1 curtida

Olá novamente @pfaffman ou qualquer outra pessoa, pergunta idiota: O certificado Let’s Encrypt é atualizado toda vez que eu executo ./launcher rebuild app? Em outras palavras, vou ter algum problema com mais limitação de taxa se eu fizer um pouco de tentativa e erro e reconstruir (mas não começar completamente do zero) minha instância Discourse várias vezes seguidas? Muito obrigado.

Tenho quase certeza de que, se você tiver certificados válidos, eles não serão solicitados em cada reconstrução.

2 curtidas