Os mantenedores do AWS SDK quebraram a compatibilidade. Cabe ao seu provedor de clone S3 se atualizar e implementar melhor compatibilidade para que você possa remover as soluções alternativas.
4 curtidas
Só para esclarecer, isso afeta apenas arquivos JS/map/CSS em assets, e não afetará os uploads, certo?
Quero dizer, afetará a remoção de arquivos órfãos?
A propósito, presumo que esse problema possa impactar a atualização do Discourse pelo painel de administração?
Na verdade, a atualização pelo painel de administração falhou para mim, por isso fiz uma reconstrução.
Sim, é apenas para assets.
Esta tarefa do rake? Não.
Mas toda a mudança no SDK da AWS pode também ter quebrado isso para pessoas em clones não compatíveis.
1 curtida
Tenho quase certeza de que isso está errado. Portanto, provavelmente também precisamos desativar clean up uploads. Isso apenas causará erros quando você estiver executando, no entanto. Não o impedirá de conseguir reconstruir.
Parece provável. Talvez precisemos de alguma configuração “skip_s3_delete” para resolver isso até que os outros provedores se atualizem? E talvez defini-la automaticamente para provedores que sabemos que estão quebrados?
Essa tarefa do rake é a única maneira de os ativos expirados serem removidos?
Estou apenas imaginando, por que não adicionar uma opção para manter os ativos no servidor principal do Discourse (quero dizer, sem armazená-los no S3)?
Desde que não afete os uploads ou o processo de limpeza de arquivos órfãos, parece uma solução viável.
Sim. Não é como se isso fosse um grande problema. Sites normais que atualizam de vez em quando não verão muita diferença.
As pessoas podem configurar suas próprias regras de ciclo de vida se se importarem com essas coisas.
Configurar clean up uploads = false já não é isso?
Lol, não. O Discourse oferece suporte oficial ao S3. Embora eu tenha feito um esforço para iniciar toda a wiki Configurar um provedor de armazenamento de objetos compatível com S3 para uploads e adicionado alguns alternadores para aumentar a compatibilidade de clones, não temos planos de investir mais tempo nisso hoje.
Se a comunidade quiser enviar alguns PRs que aumentem a compatibilidade e estejam desativados por padrão, isso é pr-welcome, mas não espere ver suporte oficial no core para todos os clones tão cedo.
4 curtidas
Para constar, parece que a Digital Ocean não tem problemas em excluir backups nem em expirar ativos ausentes.
Para provedores que estão com problemas, levaria muito tempo até que ativos desnecessários causassem muitos problemas. Manter um monte de backups, incluindo um banco de dados enorme e todos os uploads, pode ser um grande problema se você estiver pagando pelo armazenamento.
1 curtida
Olá, sou Pat Patterson, Evangelista Técnico Chefe da Backblaze; cheguei a este tópico porque tenho um fórum Discourse de prova de conceito auto-hospedado e, por acaso, me deparei com exatamente este problema hoje ao configurar meu fórum para usar o Backblaze B2 para backups e uploads.
Definir AWS_REQUEST_CHECKSUM_CALCULATION e AWS_RESPONSE_CHECKSUM_CALCULATION como WHEN_REQUIRED é uma solução alternativa útil para casos básicos de upload e download de arquivos, mas é útil saber que isso não cobre uma série de cenários, incluindo:
- Exclusão de arquivos - O Discourse está usando a operação S3
DeleteObjectspara excluir vários arquivos em uma única chamada de API, como deveria. - Upload de arquivos para buckets com bloqueio de objetos ativado.
O problema é que um checksum (seja o cabeçalho Content-MD5 ou um dos novos cabeçalhos de checksum) é exigido (em vez de apenas suportado) para essas operações, e isso faz com que os SDKs AWS atuais forneçam o novo cabeçalho de checksum. Pelo que sei, não há como substituir isso e fazer com que o SDK forneça Content-MD5 como fazia antes.
Nossos engenheiros estão trabalhando para resolver tudo isso; enquanto isso, a melhor mitigação é usar a versão 1.177.0 ou anterior do gem aws-sdk-s3.
Eu tentei fazer o downgrade das versões do gem AWS SDK em minha implantação de PoC editando o Gemfile e substituindo
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
por
gem "aws-sdk-core", "~> 3.215.1", require: false
gem "aws-sdk-kms", "~> 1.96.0", require: false
gem "aws-sdk-s3", "~> 1.177.0", require: false
gem "aws-sdk-sns", "~> 1.92.0", require: false
mas meu bundle-fu não é forte, e só consegui quebrar minha implantação com o erro:
/var/www/discourse/config/initializers/100-sidekiq.rb:69:in `<main>': undefined method `logger=' for module Sidekiq (NoMethodError)
Sidekiq.logger = Logger.new(nil)
^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `block in load_config_initializer'
...
Acho que perdi alguma etapa vital.
Sem querer lançar sombra sobre nossos amigos da DO, eles fizeram isso atualizando seu serviço para simplesmente ignorar os novos cabeçalhos de checksum em vez de rejeitar a chamada de API devido ao checksum não suportado.
O relatório de incidente deles diz:
Observe que o Spaces atualmente não verifica checksums de integridade de dados enviados pelo AWS CLI e SDKs AWS como parte das solicitações de upload
Decidimos que simplesmente aceitar e armazenar dados que podem não corresponder ao checksum fornecido pelo cliente da API era uma coisa ruim.
9 curtidas
Obrigado por postar!
2 curtidas
Sim, e os mantenedores do AWS SDK estão apenas nos ignorando nisso
2 curtidas
Fico feliz em ver que a equipe B2 também notou este problema.
Aqui está minha solução temporária:
Comentei todas as configurações relacionadas ao S3 em app.yml e reconstruí o Discourse com sucesso. Isso não afeta o acesso a arquivos previamente carregados no meu site, e quaisquer anexos carregados durante este período serão armazenados localmente sem causar problemas.
Aliás, ainda me pergunto, por que não adicionar uma opção para manter os ativos no servidor principal do Discourse (quero dizer, sem armazená-los no S3?
???
É assim que o Discourse funciona pronto para uso, você precisa optar explicitamente por enviar os assets para um serviço de armazenamento de objetos.
Quer dizer, pode ser bom ter uma opção para manter os assets principais do Discourse (JS, CSS, etc.) no servidor local. Ao mesmo tempo, apenas os arquivos enviados pelo usuário seriam armazenados no S3.
1 curtida
Você pode fazer isso não habilitando “use_s3”, mas eles são pequenos, eu apenas os enviaria e não me preocuparia com o espaço desperdiçado.
1 curtida
Por favor, ajude-me a entender corretamente.
Você quer definir DISCOURSE_USE_S3: false em app.yml?
Eu gostaria de fazer isso porque meu servidor Discourse fica na Ásia, e o B2 só tem servidores nos EUA.
Além disso, desta vez, o problema do SDK da AWS está relacionado ao gerenciamento de ativos, certo?
Então, se eu armazenar os ativos no servidor local, isso pode evitar o problema (se eu entendi a situação corretamente).
O problema está relacionado à remoção de ativos do S3. Se você remover apenas a linha que tenta remover os ativos não utilizados, isso funcionará no momento. E parece que em breve o problema será resolvido. Esta é a solução mais fácil. É o que eu recomendo. Essa é a minha melhor resposta gratuita.
1 curtida
Obrigado, isso é muito útil para mim!
1 curtida
Isso ocorre porque, na definição da API do S3, a operação DeleteObjects tem httpChecksum.requestChecksumRequired definido como true, em contraste com, por exemplo, PutObject, que o define como false. Portanto, o SDK está honrando WHEN_REQUIRED, porque o checksum é necessário.
Todos os SDKs da AWS agora são gerados a partir da definição da API, com código adicional mínimo para cobrir situações de exceção. O código vê que DeleteObjects requer um checksum, e a maneira de fazer isso agora é usar um dos novos checksums, em vez de Content-MD5.
Infelizmente, a AWS não achou adequado fornecer uma configuração de ‘usar Content-MD5 como antes’. Eles não costumam considerar o ecossistema de armazenamento de objetos de terceiros quando fazem esse tipo de alteração, pois realmente não precisam. A única vez que coisas como essa são corrigidas é quando acidentalmente prejudicam um de seus próprios serviços em algum caso extremo.
3 curtidas
O que não ajuda muito se você estiver na Ásia, mas, para constar, também temos data centers na Europa (Amsterdã, Holanda) e, desde o início deste ano, no Canadá (Toronto).
Não posso fazer promessas, mas definitivamente estamos considerando uma localização na Ásia.
Além disso, se você usar uma CDN, não importa muito onde o servidor de origem esteja.
3 curtidas
Você está certo!
O Backblaze não suporta x-amz-checksum-crc32, e a versão mais recente do SDK da AWS do Discourse pode ter habilitado isso por padrão.
Então, eu entrei no aplicativo:
./launcher enter app
e desinstalei a versão atual do SDK da AWS:
gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
e instalei aquela que o cara do Backblaze disse que funcionaria:
gem install aws-sdk-core -v “~> 3.215.1”
gem install aws-sdk-kms -v “~> 1.96.0”
gem install aws-sdk-s3 -v “~> 1.177.0”
Então, reconstruí o aplicativo e funcionou!
2 curtidas