d.ourdomain.com (nosso Discourse está sob um subdomínio)
○ Com ele configurado tanto em DO CP > Networking > Domains quanto no Cloudflare como um alias para ours.nyc3.digitaloceanspaces.com.
○ Erro ao carregar uma imagem… Falha ao abrir conexão TCP para uploads.d.ourdomain.com:443 (getaddrinfo: Name or service not known)
Mas minhas configurações não aparecem na interface de administração, então acho que isso pode não estar desatualizado e é apenas uma questão de acertar minha configuração de configurações.
Eu vi isso…
…mas a área de administração não me permite deixar “s3 upload bucket” vazio, então não tinha certeza se isso era relevante. Isso também parecia ser apenas se você estiver usando AWS S3 também. Tentei criar uma pasta no meu DO Space e usar esse nome de pasta. Tentei usar um nome diferente de uma pasta que não estava lá, caso precise criar a sua própria. Nada disso funcionou.
Eu vi isso…
…mas estou longe de ser um especialista, então evitei isso.
Neste ponto, estou sem ideias para tentar e não tenho certeza se estou perto e só preciso da configuração correta ou se estou completamente perdendo algo e nem perto.
Não, elas não aparecem. Embora você possa configurar os endpoints S3 na interface do usuário, nós apenas testamos e validamos o uso de clones S3, como a oferta da Digital Ocean, ao configurá-lo no arquivo app.yml.
Não vejo uma seção em app.yml para configurações DISCOURSE_S3. Devo apenas criar uma linha para cada uma? Ou é isso que os comandos sudo fazem?
Não está totalmente claro onde executar ou colocar esses comandos sudo. Não está claro se é um item de linha de comando único para adicioná-lo ou se é algo que precisa ir para app.yml para que seja sempre contabilizado.
Os comandos sudo vão na área app.yml ou apenas as linhas de configuração DISCOURSE_S3?
Devo apenas deixar isso em branco com DO Spaces? DISCOURSE_S3_REGION:
Preciso ter um CDN? Temos tráfego muito baixo. Grupo pequeno. Estou realmente tentando limitar as partes móveis, se possível.
Existe alguma solução para este problema? Recebi o mesmo erro ao tentar usar o Oracle Cloud Storage.
Segui a wiki configurando em app.yml. Tentei usar o s3cmd manualmente, com certeza para uma conexão correta. Mas ao fazer upload de uma imagem em uma postagem, recebi a mesma mensagem de erro.
Então obtive a mensagem de erro exata na ferramenta s3cmd como o Discourse mostra:
Aguarde, tentando listar todos os buckets...
ERRO: Teste falhou: [SSL: CERTIFICATE_VERIFY_FAILED] falha na verificação do certificado: incompatibilidade de nome do host, o certificado não é válido para 'objectstorage.ap-singapore-1.oci.oraclecloud.com'. (_ssl.c:1007)
Após muitas tentativas, ainda recebo a mesma mensagem de erro. Verifiquei manualmente o certificado e o nome do host, usei o formato correto para obter o certificado certo visualmente, mas sem sucesso.
Meu endpoint: .<região>.compat.objectstorage.oraclecloud.com
O CN do certificado: *.compat.objectstorage.<região>.oraclecloud.com
Eu consegui me conectar com a ferramenta s3cmd. Mas não consegui configurar o upload S3 para o Discourse com a mesma configuração.
A mensagem de erro: SSL_connect returned=1 errno=0 peeraddr=134.70.128.1:443 state=error: certificate verify failed (Hostname mismatch)
Quero tentar outra maneira definindo no ambiente ruby (depois de procurar em todo lugar):
Esta é uma má ideia, pois minará muitas proteções que os certificados X509 fornecem.
Você pode mostrar quais são suas configurações não secretas aqui? Por favor, note que o Oracle Cloud não é suportado, mas ainda daremos uma olhada rápida para ver se algo está obviamente errado.
O Oracle Cloud Storage tem um formato para o endereço do endpoint. Mas qualquer que seja o formato que eu tentei, a mesma mensagem de erro que mostrei acima.
OK, adicionei um binding.pry no início de ssl_socket_connect e o que vejo ao tentar usar essas configurações é:
→ DISCOURSE_USE_S3=true DISCOURSE_S3_REGION=ap-singapore-1 DISCOURSE_S3_ENDPOINT=https://axhjdarc4cuy.compat.objectstorage.ap-singapore-1.oraclecloud.com DISCOURSE_S3_ACCESS_KEY_ID=foo DISCOURSE_S3_SECRET_ACCESS_KEY=bar DISCOURSE_S3_BUCKET=bucketname bin/rails c
Loading development environment (Rails 7.0.7)
[1] pry(main)> s3 = S3Helper.build_from_config; s3.list
From: /home/michael/.rvm/gems/ruby-3.2.2@discourse/gems/net-protocol-0.2.2/lib/net/protocol.rb:42 Net::Protocol#ssl_socket_connect:
40: def ssl_socket_connect(s, timeout)
41: binding.pry
=> 42: if timeout
43: while true
44: raise Net::OpenTimeout if timeout <= 0
45: start = Process.clock_gettime Process::CLOCK_MONOTONIC
46: # to_io is required because SSLSocket doesn't have wait_readable yet
47: case s.connect_nonblock(exception: false)
48: when :wait_readable; s.to_io.wait_readable(timeout)
49: when :wait_writable; s.to_io.wait_writable(timeout)
50: else; break
51: end
52: timeout -= Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
53: end
54: else
55: s.connect
56: end
57: end
[1] pry(#<Net::HTTP>> s.hostname
=> "bucketname.axhjdarc4cuy.compat.objectstorage.ap-singapore-1.oraclecloud.com"
portanto, o hostname real para o qual a conexão está sendo feita é bucketname.axhjdarc4cuy.compat.objectstorage.ap-singapore-1.oraclecloud.com, que não corresponde a *.compat.objectstorage.ap-singapore-1.oraclecloud.com, então o erro está correto.
Use o acesso baseado em caminho em seu aplicativo. O acesso no estilo de host virtual (acessando um bucket como {bucketnamespace}.compat.objectstorage.{region}.oraclecloud.com [sic]) não é suportado.
Por outro lado, o Discourse só suporta acesso no estilo de host virtual ({bucketname}.{namespace}.compat.objectstorage.{region}.oraclecloud.com.).
Nós removemos a configuração que poderia ter feito funcionar há algum tempo, pois não era bem suportada (veja a mensagem do commit).
Fazer isso funcionar não será simples e exigirá desenvolvimento e testes complexos para adicionar esse suporte.
Encontrei o que ele estava se referindo, mas quando copio e colo texto, ele inverte o caso. Desisto e não voltei a isso. Talvez tente novamente no ano que vem.
Eu esperava que alguém descobrisse nesse meio tempo e documentasse melhor a configuração para corresponder aos meus planos.
Eu estava tendo esse problema e o corrigi. Minha solução foi que, quando configurei, meu servidor de e-mail não era verificado por SSL, mas meu provedor de domínio me deu um servidor de e-mail verificado por SSL, então eu os substituí.
