Impossible de reconstruire en raison de la mise à jour de la gem AWS SDK et des nouvelles protections d'intégrité des données AWS

[pfaffman (Jay Pfaffman)]

@AntiMetaman

J’ai reconstruit l’application et ça a fonctionné !

Si vous avez reconstruit l’application, les modifications apportées dans le conteneur ont disparu. Peut-être que les gens de Backblaze ont résolu les problèmes pendant que vous faisiez cela.

[AntiMetaman]

Je viens de commenter S3 et de reconstruire. Je suppose que je m’en tiendrai au stockage local à partir de maintenant.

[pfaffman (Jay Pfaffman)]

Le stockage local fonctionne bien. C’est juste la suppression qui ne fonctionne pas.

[tedpearson]

@PatPatterson

C’est parce que, dans la définition de l’API S3, l’opération DeleteObjects a httpChecksum.requestChecksumRequired défini sur true, contrairement à, par exemple, PutObject, qui le définit sur false. Le SDK respecte donc WHEN_REQUIRED, car la somme de contrôle est requise.

Tous les SDK AWS sont désormais générés à partir de la définition de l’API, avec un minimum de code supplémentaire pour couvrir les situations limites. Le code constate que DeleteObjects nécessite une somme de contrôle, et la manière de le faire maintenant est d’utiliser l’une des nouvelles sommes de contrôle, plutôt que Content-MD5.

Malheureusement, AWS n’a pas jugé utile de fournir une configuration du type « utiliser Content-MD5 comme avant ». Ils ne tiennent généralement pas compte de l’écosystème de stockage d’objets tiers lorsqu’ils apportent ce type de modifications, car ils n’en ont pas vraiment besoin. La seule fois où ce genre de choses est corrigé, c’est lorsqu’il affecte accidentellement l’un de leurs propres services dans un cas particulier.

Merci d’avoir posté et confirmé qu’il n’existe actuellement aucune solution de contournement sans rétrograder les SDK AWS. J’ai rencontré des problèmes avec les API S3 B2 d’un autre projet utilisant le SDK AWS golang, en essayant de sauvegarder une base de données VictoriaMetrics.

Avez-vous une idée de la part de votre équipe d’ingénierie sur la façon dont ou quand ils pourraient choisir de résoudre ce problème, ou avez-vous un moyen de suivre/obtenir des mises à jour sur une solution de contournement prise en charge ? J’essaie de décider si je dois forker et recompiler un projet avec un changement de dépendance ou simplement attendre un peu une mise à jour !

Merci !

[bjmc (Brendan)]

La procédure suivante a fonctionné pour moi afin de rétrograder les Gems AWS :

 # Pour accéder au conteneur :
./launcher enter app
# Apparemment nécessaire pour déverrouiller le Gemfile.lock :
bundle config set frozen false
# Définir une version plus ancienne du gem sdk-s3 :
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
# Rétrograder le gem S3 pour qu'il corresponde à la version dans le Gemfile :
bundle update aws-sdk-s3
# Rétrograder également le gem aws-sdk-core :
bundle add aws-sdk-core --version 3.215

Après avoir effectué ces modifications, j’ai pu sauvegarder avec succès une sauvegarde sur B2. Je suis sûr que ce n’est qu’une solution temporaire qui sera perdue lors de la prochaine mise à jour de Discourse, donc j’espère que @PatPatterson et l’équipe Backblaze pourront bientôt fournir une correction de compatibilité plus permanente.

[pfaffman (Jay Pfaffman)]

Vous n’aurez peut-être pas besoin de le faire, mais il est possible de placer cette commande sed dans app.yml afin qu’elle s’exécute automatiquement lors de la reconstruction. Je pense que la placer juste en dessous de l’endroit où les plugins sont clonés suffirait. Mais cela pourrait être plus compliqué que je ne le pense.

[becl]

Salut AntiMetaman,

J’ai passé la semaine dernière à essayer de faire fonctionner les sauvegardes avec le stockage S3 et j’ai finalement réussi la sauvegarde grâce à ce fil de discussion. Honnêtement, je ne suis pas sûr de ce qui a fonctionné.

J’ai suivi ce que vous avez fait avec la désinstallation et l’installation du gem, mais maintenant j’obtiens une erreur en essayant de télécharger des images. Mon journal d’erreurs montre ceci :

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

Avant de devoir jeter mon serveur entier et recommencer (honnêtement, à ce stade, je ne suis même pas sûr de vouloir continuer), savez-vous comment je peux annuler la désinstallation et l’installation du gem pour essayer de voir si cela résout le problème ?

[Stéfan_van_der_Walt]

Le comportement que j’ai observé sur notre instance (qui utilise Backblaze pour la sauvegarde) est que les sauvegardes ont commencé à échouer, sans notification, en février. Je l’ai remarqué aujourd’hui, car je vérifie nos sauvegardes de temps en temps. Je considérerais cela comme un problème assez grave.

Serait-il possible de revenir à une version antérieure de l’AWS-SDK jusqu’à ce qu’une solution de contournement soit trouvée pour Backblaze et d’autres fournisseurs non-AWS ?

[pfaffman (Jay Pfaffman)]

@pfaffman

J’espère que vous n’aurez pas besoin de faire cela,

Mais je l’ai fait pour un site qui utilise Backblaze. J’ai créé un modèle que j’ai placé dans /root/aws-revert-template.yml avec ceci :

# Ce modèle remplace aws-sdk-s3 par une version qui fonctionne avec 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

Et je l’ai ajouté à mon app.yml comme ceci :

# IMPORTANT : DÉFINISSEZ UN MOT DE PASSE SECRET dans Postgres pour l'utilisateur Discourse
# TODO : changez SOME_SECRET dans ce modèle

templates:
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Décommentez ces deux lignes si vous souhaitez ajouter Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
  - "templates/web.letsencrypt.ssl.template.yml"
  - "/root/aws-revert-template.yml"

Et j’ai exécuté une mise à niveau vers stable et cela semble fonctionner.

Vous pourriez également simplement ajouter ce qui se trouve dans le modèle à votre app.yml

[MattJankowski]

J’ai remarqué que cette page - S3-Compatible API - ne liste plus les divers en-têtes checksum-* comme étant non pris en charge.

@PatPatterson Je ne sais pas si vous êtes toujours dans ce fil de discussion ou non - mais un support officiel a-t-il été ajouté pour ceux-ci ?

[pfaffman (Jay Pfaffman)]

Pouvez-vous confirmer que votre backblaze b2 fonctionne sans la correction que je suggère ?

[MattJankowski]

Merci pour votre réponse rapide, et désolé - j’aurais dû ajouter plus de détails. Dans un autre package open source (Mastodon), nous avons également bloqué le gem aws-sdk-core à < 3.216.0 pour gérer exactement ce problème pour les personnes qui utilisent Backblaze (et je soupçonne d’autres, mais c’est là que le problème s’est posé).

Mais ces dernières semaines, j’ai remarqué :

• Que la page du site Backblaze ne liste plus ces en-têtes comme non pris en charge
• Une récente version du gem AWS mentionne la résolution du problème où when_required n’était pas entièrement respecté auparavant

Dans mes recherches précédentes, j’avais vu ce fil de discussion avec plus ou moins le même problème et j’essayais de comprendre si nous pouvions mettre à jour le gem en toute sécurité maintenant si Backblaze a ajouté cette prise en charge, et/ou si le gem contourne maintenant entièrement le problème.

[PatPatterson (metadaddy)]

Salut - oui, Backblaze B2 a ajouté la prise en charge officielle des en-têtes de somme de contrôle plus tôt cette année.

[MattJankowski]

Excellent ! Merci de votre confirmation.