Se você reconstruiu o aplicativo, as alterações feitas no contêiner foram perdidas. Talvez o pessoal do Backblaze tenha consertado as coisas enquanto você fazia isso.
1 curtida
Eu apenas comentei o S3 e reconstruí. Acho que vou usar apenas armazenamento local a partir de agora.
1 curtida
O armazenamento local funciona bem. É apenas a exclusão que não funciona.
Obrigado por postar e confirmar que não há uma solução alternativa no momento sem fazer downgrade dos SDKs da AWS. Tive problemas com as APIs S3 do b2 de outro projeto usando o SDK Go da AWS, tentando fazer backup de um banco de dados VictoriaMetrics.
Você tem alguma ideia de sua equipe de engenharia sobre como ou quando eles podem optar por resolver esse problema, ou alguma maneira de rastrear/receber atualizações sobre uma solução alternativa suportada? Estou tentando decidir se devo fazer um fork e recompilar um projeto com uma alteração de dependência ou apenas esperar um pouco por uma atualização!
Obrigado!
O procedimento a seguir funcionou para mim fazer a redução da versão dos AWS Gems:
# Para entrar no container:
./launcher enter app
# Aparentemente necessário para desbloquear o Gemfile.lock:
bundle config set frozen false
# Definir uma versão mais antiga do gem sdk-s3:
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
# Rebaixar o gem aws-sdk-s3 para coincidir com o que está agora no Gemfile:
bundle update aws-sdk-s3
# Também rebaixar o gem aws-sdk-core:
bundle add aws-sdk-core --version 3.215.
Depois de fazer essas alterações, consegui salvar com sucesso um backup no B2. Tenho certeza de que isso é apenas uma solução temporária que será perdida na próxima atualização do Discourse, então espero que o @PatPatterson e a equipe Backblaze possam fornecer uma correção de compatibilidade mais permanente em breve.
2 curtidas
Espero que você não precise fazer isso, mas é possível colocar esse comando sed em app.yml para que ele aconteça automaticamente quando você reconstruir. Acho que apenas colocá-lo abaixo de onde os plugins são clonados seria suficiente. Mas pode ser mais complicado do que eu penso.
1 curtida
Olá AntiMetaman,
Passei a última semana tentando fazer os backups funcionarem com o armazenamento S3 e finalmente consegui fazer o backup funcionar com este tópico. Honestamente, não tenho certeza de qual parte funcionou.
Segui o que você fez com o gem uninstall e install, mas agora recebo um erro ao tentar fazer upload de imagens. Meu log de erros mostra isto:
not entitled /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.219.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call’ /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aw
Antes que eu tenha que jogar meu servidor inteiro fora e começar de novo (honestamente, a esta altura nem tenho certeza se quero continuar), você sabe como posso reverter o gem uninstall e install para que eu possa tentar ver se isso resolve o problema?
O comportamento que observei em nossa instância (que usa Backblaze para backup) é que as cópias de segurança começaram a falhar, sem aviso prévio, em fevereiro. Eu percebi isso por acaso hoje, pois verifico nossos backups de vez em quando. Considero isso um problema bastante sério.
Seria possível fazer um downgrade do AWS-SDK até que uma solução alternativa seja encontrada para o Backblaze e outros provedores que não sejam AWS?
Mas eu precisei para um site que está usando Backblaze. Criei um template que coloquei em /root/aws-revert-template.yml com isto:
# Este template reverte aws-sdk-s3 para uma versão que funciona com backblaze
params:
home: /var/www/discourse
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- bundle config set frozen false
- "sed -i 's/gem \\\"aws-sdk-s3\\\", require: false/gem \\\"aws-sdk-s3\\\", \\\"1.177.0\\\", require: false/' Gemfile"
- bundle update aws-sdk-s3
- bundle add aws-sdk-core --version 3.215
E então o adicionei ao meu app.yml assim:
# IMPORTANTE: DEFINA UMA SENHA SECRETA no Postgres para o Usuário Discourse
# TODO: mude ALGUMA_SENHA SECRETA neste template
templates:
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Descomente estas duas linhas se desejar adicionar Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "/root/aws-revert-template.yml"
E eu executei um upgrade para stable e parece que está funcionando.
Você também poderia apenas adicionar o que está no template ao seu app.yml
3 curtidas
Notei que esta página - S3-Compatible API - não lista mais os vários cabeçalhos checksum-* como não suportados.
@PatPatterson não sei se você ainda está neste tópico ou não - mas o suporte oficial foi adicionado para eles?
2 curtidas
Você pode confirmar que seu backblaze b2 está funcionando sem a correção que sugiro?
Obrigado pela resposta rápida e desculpe - eu deveria ter adicionado mais detalhes. Em outro pacote de código aberto (Mastodon), acabamos também bloqueando o gem aws-sdk-core para ser < 3.216.0 para lidar com essa questão exata para pessoas que estão usando Backblaze (e suspeito que outros, mas foi aí que surgiu).
Mas então, nas últimas semanas, notei:
- Que a página no site da Backblaze não lista mais esses cabeçalhos como não suportados
- Um lançamento recente do gem
awsmenciona a correção do problema em quewhen_requirednão era totalmente honrado anteriormente
Em pesquisas anteriores, eu tinha visto este tópico com mais ou menos o mesmo problema e estava tentando entender se podemos atualizar o gem com segurança agora, se de fato a Backblaze adicionou esse suporte e/ou se o gem agora contorna totalmente o problema.
2 curtidas
Olá - sim, o Backblaze B2 adicionou suporte oficial aos cabeçalhos de checksum no início deste ano.
2 curtidas
Excelente! Obrigado pela confirmação.