Les mainteneurs du SDK AWS ont rompu la compatibilité. Il appartient à votre fournisseur de clonage S3 de se mettre à jour et d’implémenter une meilleure compatibilité afin que vous puissiez supprimer les solutions de contournement.
4 « J'aime »
Juste pour clarifier, cela n’affecte que les fichiers JS/map/CSS dans assets, et n’affectera pas les téléchargements, n’est-ce pas?
Je veux dire, cela impactera-t-il la suppression des fichiers orphelins?
Au fait, je suppose que ce problème pourrait affecter la mise à jour de Discourse depuis le panneau d’administration?
En réalité, la mise à jour via le panneau d’administration a échoué pour moi, c’est pourquoi j’ai effectué une reconstruction.
Oui, c’est uniquement pour les assets.
Cette tâche rake ? Non.
Mais le changement complet du SDK AWS peut également avoir cassé cela pour les personnes ayant des clones non compatibles.
1 « J'aime »
Je suis à peu près sûr que c’est faux. Nous devrons donc probablement désactiver également le nettoyage des téléchargements. Cela provoquera des erreurs lorsque vous exécuterez, cependant. Cela ne vous empêchera pas de pouvoir reconstruire.
Cela semble probable. Avons-nous besoin d’un paramètre “skip_s3_delete” pour résoudre ce problème jusqu’à ce que les autres fournisseurs rattrapent leur retard ? Et peut-être le définir automatiquement pour les fournisseurs que nous savons être défectueux ?
Cette tâche rake est-elle le seul moyen de supprimer les actifs expirés ?
Je me demande juste, pourquoi ne pas ajouter une option pour conserver les ressources sur le serveur principal de Discourse (je veux dire, sans les stocker sur S3) ?
Tant que cela n’affecte pas les téléchargements ou le processus de suppression des fichiers orphelins, cela semble être une solution viable.
Oui. Ce n’est pas comme si c’était un gros problème. Les sites normaux qui se mettent à jour de temps en temps ne verront pas beaucoup de différence.
Les gens peuvent définir leurs propres règles de cycle de vie s’ils se soucient de ces choses.
N’est-ce pas déjà le cas avec le réglage clean up uploads = false ?
Lol non. Discourse prend officiellement en charge S3. Bien que je me sois donné beaucoup de mal pour lancer le wiki Configurer un fournisseur de stockage d’objets compatible S3 pour les téléchargements et ajouter quelques options pour augmenter la compatibilité des clones, nous n’avons absolument aucun projet d’y investir plus de temps aujourd’hui.
Si la communauté souhaite envoyer quelques PR qui augmentent la compatibilité et qui sont désactivées par défaut, c’est pr-welcome, mais ne vous attendez pas à voir un support officiel dans le cœur pour chaque clone de sitôt.
4 « J'aime »
Soit dit en passant, il semble que Digital Ocean n’ait aucun problème à supprimer les sauvegardes ni à expirer les actifs manquants.
Pour les fournisseurs défectueux, il faudrait beaucoup de temps avant que les actifs inutiles ne posent de problème. Conserver une tonne de sauvegardes, y compris une énorme base de données et toutes les téléversements, pourrait être un problème si vous payez pour le stockage.
1 « J'aime »
Salut, je suis Pat Patterson, évangéliste technique en chef chez Backblaze ; je suis tombé sur ce fil de discussion car j’ai un forum Discourse auto-hébergé en preuve de concept, et je suis tombé sur ce problème exact aujourd’hui en configurant mon forum pour utiliser Backblaze B2 pour les sauvegardes et les téléchargements.
Définir AWS_REQUEST_CHECKSUM_CALCULATION et AWS_RESPONSE_CHECKSUM_CALCULATION sur WHEN_REQUIRED est une solution de contournement utile pour les cas de base de téléchargement et de téléversement de fichiers, mais il est utile de savoir que cela ne couvre pas un certain nombre de scénarios, notamment :
- Suppression de fichiers - Discourse utilise l’opération S3
DeleteObjectspour supprimer plusieurs fichiers en un seul appel API, comme il se doit. - Téléversement de fichiers vers des compartiments avec verrouillage d’objets activé.
Le problème est qu’une somme de contrôle (soit l’en-tête Content-MD5, soit l’un des nouveaux en-têtes de somme de contrôle) est requise (plutôt que simplement prise en charge) pour ces opérations, et cela amène les SDK AWS actuels à fournir le nouvel en-tête de somme de contrôle. Autant que je sache, il n’y a aucun moyen de contourner cela et de faire en sorte que le SDK fournisse Content-MD5 comme il le faisait auparavant.
Nos ingénieurs travaillent à résoudre tout cela ; en attendant, la meilleure mesure d’atténuation est d’utiliser la version 1.177.0 ou antérieure de la gemme aws-sdk-s3.
J’ai essayé de rétrograder les versions de la gemme AWS SDK dans mon déploiement PoC en modifiant le Gemfile et en remplaçant
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
par
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
mais mon bundle-fu n’est pas assez fort, et je n’ai réussi qu’à casser mon déploiement avec l’erreur :
/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'
...
Je suppose que j’ai manqué une étape vitale.
Sans vouloir jeter l’ombre sur nos amis de DO, ils l’ont fait en mettant à jour leur service pour ignorer simplement les nouveaux en-têtes de somme de contrôle plutôt que de rejeter l’appel API en raison de la somme de contrôle non prise en charge.
Leur rapport d’incident indique :
Notez que Spaces ne vérifie actuellement pas les sommes de contrôle d’intégrité des données envoyées par l’AWS CLI et les SDK AWS dans le cadre des demandes de téléchargement.
Nous avons décidé qu’accepter et stocker des données qui pourraient ne pas correspondre à la somme de contrôle fournie par le client API était une mauvaise chose.
9 « J'aime »
Merci d’avoir posté !
2 « J'aime »
Ouais, et les mainteneurs du SDK AWS nous ignorent royalement à ce sujet
2 « J'aime »
Je suis heureux de constater que l’équipe B2 a également remarqué ce problème.
Voici ma solution temporaire :
J’ai mis en commentaire toutes les configurations relatives à S3 dans app.yml et j’ai réussi à reconstruire Discourse. Cela n’affecte pas l’accès aux fichiers précédemment téléchargés sur mon site, et toutes les pièces jointes téléchargées pendant cette période seront stockées localement sans causer de problèmes.
Au fait, je me demande toujours pourquoi ne pas ajouter une option pour conserver les ressources sur le serveur principal de Discourse (je veux dire, sans les stocker sur S3 ?
???
C’est ainsi que Discourse fonctionne par défaut, vous devez explicitement choisir d’expédier les ressources vers un service de stockage d’objets.
Je veux dire, il pourrait être bon d’avoir une option pour conserver les ressources principales de Discourse (JS, CSS, etc.) sur le serveur local. Dans le même temps, seuls les fichiers téléchargés par l’utilisateur seraient stockés dans S3.
1 « J'aime »
Vous pouvez le faire en ne permettant pas « use_s3 », mais ils sont petits, je les pousserais et ne me soucierais pas de l’espace perdu.
1 « J'aime »
Veuillez m’aider à comprendre correctement.
Voulez-vous dire que je dois définir DISCOURSE_USE_S3: false dans app.yml ?
Je voudrais faire cela car mon serveur Discourse est en Asie et B2 n’a que des serveurs aux États-Unis.
De plus, cette fois, le problème du SDK AWS est lié à la gestion des actifs, n’est-ce pas ?
Donc, si je stocke les actifs sur le serveur local, cela pourrait éviter le problème (si je comprends bien la situation).
Le problème est lié à la suppression d’éléments de S3. Si vous supprimez simplement la ligne qui tente de supprimer les éléments inutilisés, cela fonctionnera immédiatement. Et il semble que le problème sera résolu bientôt. C’est la solution la plus simple. C’est ce que je recommande. C’est ma meilleure réponse gratuite.
1 « J'aime »
Merci, c’est très utile pour moi !
1 « J'aime »
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 genre de changements, car ils n’en ont pas vraiment besoin. La seule fois où ce genre de choses est corrigé, c’est lorsqu’ils nuisent accidentellement à l’un de leurs propres services dans un cas particulier.
3 « J'aime »
Non pas que cela aide particulièrement si vous êtes en Asie, mais, pour mémoire, nous avons également des centres de données en Europe (Amsterdam, Pays-Bas) et, depuis le début de cette année, au Canada (Toronto).
Je ne peux rien promettre, mais nous envisageons définitivement un emplacement en Asie.
De plus, si vous utilisez un CDN, peu importe où se trouve le serveur d’origine.
3 « J'aime »
Vous avez raison !
Backblaze ne prend pas en charge x-amz-checksum-crc32, et la version plus récente du SDK AWS de Discourse peut l’avoir activé par défaut.
Je suis donc allé dans l’application :
./launcher enter app
et j’ai désinstallé la version actuelle du SDK AWS :
gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
et j’ai installé celle que le gars de Backblaze a dit qui fonctionnerait :
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”
Ensuite, j’ai reconstruit l’application et cela a fonctionné !
2 « J'aime »