Desde ontem, estou tentando instalar, mas não está funcionando. Já testei vários VPS e nenhum funcionou. Sempre o mesmo problema de SSL.
url: https://debatehosting.co/
SSL
Sinto que você pode copiar a mensagem de erro e enviá-la para o ChatGPT.
Eu não entendo essa mensagem de erro, mas o GPT pode resolvê-la rapidamente.
Olá, antes de mais nada, bem-vindo ao Meta!
Se você aceitar uma sugestão amigável, por favor, edite (ou da próxima vez) as postagens que contenham código para usar a formatação Markdown, resumindo a(s) linha(s) de erro que você acredita descreverem seu problema. Isso incentivará respostas e fará com que seu problema seja resolvido mais rapidamente.
Qual método de instalação você usou? Você está usando um proxy em seu VPS para o Discourse? Você pode compartilhar seu arquivo app/templates.yml?
Sim, é melhor postar texto em blocos de código.
provavelmente a sintaxe do arquivo app.yml está incorreta. por favor, poste o código de erro completo como texto pré-formatado no editor. capturas de tela do texto de erro são muito difíceis de depurar.
Minha impressão é que a emissão do Let’s Encrypt falhou por algum motivo.
Pode ser que você esteja sendo rejeitado.
Sim, verifique o app.yml e sua conectividade com o Let’s Encrypt:
docker exec app bash -lc '
curl -4 -v \
--connect-timeout 10 \
--max-time 20 \
https://acme-v02.api.letsencrypt.org/directory \
-o /dev/null
'
a partir de /var/discourse
templates:
- templates/postgres.template.yml
- templates/redis.template.yml
- templates/web.template.yml
- templates/web.ratelimited.template.yml
- templates/web.ssl.template.yml
- templates/web.letsencrypt.ssl.template.yml
expose:
- 80:80
- 443:443
params:
db_default_text_search_config: pg_catalog.english
db_shared_buffers: 256MB
env:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
DISCOURSE_HOSTNAME: debatehosting.co
DISCOURSE_DEVELOPER_EMAILS: pichopelis@gmail.com
LETSENCRYPT_ACCOUNT_EMAIL: 'pichopelis@gmail.com'
DISCOURSE_ENABLE_SSL: true
DISCOURSE_SKIP_EMAIL_SETUP: '1'
UNICORN_WORKERS: 4
volumes:
- volume:
host: "/var/discourse/shared/standalone"
guest: "/shared"
- volume:
host: "/var/discourse/shared/standalone/log/var-log"
guest: "/var/log"
hooks:
after_code:
- exec:
cd: "$home/plugins"
cmd:
- git clone https://github.com/discourse/docker_manager.git
run:
- exec: echo "Início dos comandos personalizados"
- exec: echo "Fim dos comandos personalizados"
Tente remover as aspas, elas são no mínimo redundantes (e também não são um tipo de aspa muito convencional).
ting: TRUSTED CERTIFICATE)
nginx: [emerg] cannot load certificate "/shared/ssl/debatehosting.co.cer": PEM_r ead_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expec ting: TRUSTED CERTIFICATE)
nginx: [emerg] cannot load certificate "/shared/ssl/debatehosting.co.cer": PEM_r ead_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expec ting: TRUSTED CERTIFICATE)
nginx: [emerg] cannot load certificate "/shared/ssl/debatehosting.co.cer": PEM_r ead_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expec ting: TRUSTED CERTIFICATE)
nginx: [emerg] cannot load certificate "/shared/ssl/debatehosting.co.cer": PEM_r ead_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expec ting: TRUSTED CERTIFICATE)
nginx: [emerg] cannot load certificate "/shared/ssl/debatehosting.co.cer": PEM_r ead_bio_X509_AUX() failed (SSL: error:0480006C:PEM routines::no start line:Expec ting: TRUSTED CERTIFICATE)
nginx: [emerg] cannot load certificate "/shared/ssl/debatehosting.co.cer": PEM_r
(postagem excluída pelo autor)
Sim, um certificado válido não foi emitido para você. Você precisa investigar o motivo.
Pode ser algo tão simples quanto fornecer um e-mail que eles não validam.
Confirmar a conectividade com o Let’s Encrypt também é útil. Verifique o log de compilação em busca de erros durante o processo de emissão.
Talvez você esteja sendo limitado por taxa pelo Let’s Encrypt? Lembro-me de que isso pode acontecer se você tiver muitas (5) reconstruções falhas.
sim, isso é bem possível.
isso deveria ficar bem claro no log, certo?
Não tenho certeza. Já faz muito tempo que não vejo esse problema.
Outro problema possível é que: acabei de ver que o domínio dele usa o Cloudflare. Talvez ele esteja tentando instalar o Discourse com a nuvem laranja?
Você veria algo como:
[Sat May 11 22:58:20 UTC 2019] Sign failed, finalize code is not 200.
[Sat May 11 22:58:20 UTC 2019] {
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "Error finalizing order :: too many certificates already issued for exact set of domains: example.com: see https://letsencrypt.org/docs/rate-limits/",
"status": 429
}
[Sat May 11 22:58:20 UTC 2019] Please check log file for more details: /shared/letsencrypt/acme.sh.log
Error loading file ca.cer
(retirado de aqui)
Acompanhe este arquivo: shared/letsencrypt/acme.sh.log
Será que estou me limitando? Vou tentar com outro domínio? O que você acha de eu comprar uma VPS de teste para verificar? Já testei com o mesmo domínio.
Sei lá, não. Estou usando, não sei se é o VPS
Neste caso, o que devo esperar?
O problema é quase certamente que debatehosting.co não está (ou talvez não estava) resolvendo para sua máquina virtual e/ou as portas 80/443 estão bloqueadas por algo no servidor ou em algum lugar a montante. Se você já fez isso várias vezes, é provável que você tenha atingido o limite de taxa do Let’s Encrypt e precisará tentar novamente. Mas você deve usar www em vez do domínio raiz, e se fizer isso, será uma nova solicitação e você não estará sujeito ao limite de taxa, já que ainda não solicitou nenhum certificado para esse nome de host.
O discourse-setup disse algo como “Não consigo acessar seu servidor pelo nome de domínio”? Você fez algo para que ele continuasse mesmo assim?
Você usou o discourse-setup ou fez tudo manualmente, do jeito antigo, então nenhuma verificação foi feita?
Elas não importam. O Let’s Encrypt não as usa mais e acho que o Discourse também não faz mais nada com elas.
Se você usar o Cloudflare, não use o nuvem laranja. Quando verifiquei há um minuto, ele resolve para um único endereço IP. Nada está respondendo nesse endereço nas portas 80 ou 443, mas acho que isso é porque o NGINX se recusa a iniciar.