Sem conexão segura para Discourse auto-hospedado após a última atualização

Instalação
1

Olá. Atualizei o Discourse Image e o Discourse há algumas horas usando ./launcher rebuild app. No processo, tive alguns erros que foram corrigidos removendo linhas de instalação de plugins obsoletas do app.yml. Nenhuma outra alteração de configuração foi feita. Agora tenho um contêiner Docker em execução escutando nas portas TCP 80 e 443, mas o nginx no contêiner se recusa a aceitar conexões SSL/TLS. O error.log dentro do contêiner não mostra erros com certificados, o access.log não mostra nenhuma solicitação, o telnet para a porta 443 mostra recusa de conexão, o acesso HTTP na porta TCP 80 funciona, mas temos problemas de autenticação SSO (provavelmente é um problema com cookies seguros). Reiniciar o launcher e o discourse-doctor não ajudam. Reiniciar o nginx dentro do contêiner também não ajuda. Onde devo procurar agora e o que fazer?

2 curtidas
2

isso acontecerá se o ufw estiver ativado e não configurado para permitir conexões na porta 443 do https

Editar: você precisará que esta porta esteja aberta para que o mail-receiver funcione corretamente

3

Eu não fiz nada com a configuração do ufw, iptables, etc. A porta estava exatamente aberta antes da atualização. A configuração poderia ter sido alterada com o processo de atualização do Discourse?

4

absolutamente poderia, o contêiner Docker do Discourse deveria ficar na frente do ufw. No entanto, não ter a porta 443 aberta causa problemas na comunicação entre diferentes contêineres ou problemas com telnet

o que .\launcher logs app retorna? (você pode usar o MS Word para redigir o nome do seu domínio, etc.)

você acessa seu servidor através do PuTTy ou outro cliente SSH? abrindo a porta 22?

5

Também estou vendo esse problema em uma instância auto-hospedada após uma reconstrução recente. Nenhuma alteração na configuração, exceto a própria reconstrução. Posso acessar o servidor via SSH e esta é a saída de ./launcher logs app.


run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/install-ssl
Started runsvdir, PID is 45
ok: run: redis: (pid 55) 0s
supervisor pid: 53 unicorn pid: 76

O contêiner Docker está em execução, como evidenciado pela minha saída de docker ps. (ID do contêiner omitido)

local_discourse/app “/sbin/boot” 16 minutes ago Up 16 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp app

Uma nota importante a destacar é que não usamos openSSL para nossos certificados, devido à exigência de um emissor específico. No entanto, este certificado não mudou e estava funcionando bem antes da reconstrução.

Parece haver uma incompatibilidade entre o IP que o nginx espera (IP local) e o que é encontrado atribuído ao contêiner. Parece que o contêiner pode estar rodando em modo bridge? Aqui estão as configurações de rede do contêiner.

"Labels": {
    "org.opencontainers.image.created": "2025-07-25T21:40:36+00:00"
},
"NetworkSettings": {
    "Bridge": "",
    "SandboxID": "[REDACTED]",
    "SandboxKey": "[REDACTED]",
    "Ports": {
        "443/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "443"
            },
            {
                "HostIp": "::",
                "HostPort": "443"
            }
        ],
        "5432/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "5432"
            },
            {
                "HostIp": "::",
                "HostPort": "5432"
            }
        ],
        "80/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "80"
            },
            {
                "HostIp": "::",
                "HostPort": "80"
            }
        ]
    },
    "HairpinMode": false,
    "LinkLocalIPv6Address": "",
    "LinkLocalIPv6PrefixLen": 0,
    "SecondaryIPAddresses": null,
    "SecondaryIPv6Addresses": null,
    "EndpointID": "[REDACTED]",
    "Gateway": "172.17.0.1",
    "GlobalIPv6Address": "",
    "GlobalIPv6PrefixLen": 0,
    "IPAddress": "172.17.0.2",
    "IPPrefixLen": 16,
    "IPv6Gateway": "",
    "MacAddress": "[REDACTED]",
    "Networks": {
        "bridge": {
            "IPAMConfig": null,
            "Links": null,
            "Aliases": null,
            "MacAddress": "[REDACTED]",
            "DriverOpts": null,
            "GwPriority": 0,
            "NetworkID": "[REDACTED]",
            "EndpointID": "[REDACTED]",
            "Gateway": "172.17.0.1",
            "IPAddress": "172.17.0.2",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "DNSNames": null
        }
    }
}
6

Parece haver um novo PR que introduziu um novo requisito de variável no app.yml. Isso ainda não parece estar documentado, mas você precisa adicionar ENABLE_SSL: true ao seu arquivo app.yml.

7

Isso parece um bug. SSL está ativado por padrão há alguns anos. Você pode vincular ao commit?

Eu o vejo no código no template SSL. Posso estar perdendo alguma coisa, já que estou no meu celular e o GitHub está com problemas, mas parece que isso quebrará todos os sites auto-hospedados.

1 curtida
8

É este aqui, definitivamente um bug não intencional ao mesclar a configuração ssl-on-boot:

Atualizei o ENABLE_SSL para ser 1 por padrão aqui:

Obrigado pela observação, @tanya_byrne

3 curtidas
9

Bom salvamento, Jeff! Obrigado!

1 curtida
10

Obrigado pela correção @featheredtoast

2 curtidas
11

Obrigado, pessoal. Nós também resolvemos o problema.

2 curtidas
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.