@Falco - Il pourrait être bon d’ajouter un avertissement pour Scaleway, indiquant qu’il ne prend en charge que 1 000 parties pour le téléchargement multipart, tandis qu’AWS en prend en charge 10 000. Ce n’est pas un problème pour les téléchargements réguliers, mais c’est un problème pour les téléchargements de sauvegarde au-delà d’une certaine taille, car le SDK S3 utilisera 10 000 parties à moins d’être modifié manuellement et échouera.
4 « J'aime »
Excellente découverte ! Veuillez l’ajouter au wiki de l’OP si vous le pouvez.
4 « J'aime »
Merci, j’ajouterais également que vous pouvez utiliser n’importe lequel de ces outils pour copier de cloud à cloud, en particulier vers/depuis un stockage d’objets compatible S3, par exemple, Rclone, Shargate, Gs Richcopy360 et GoodSync. Tous ces outils sont compatibles avec des clouds similaires.
1 « J'aime »
Nous venons de découvrir un problème, Cloudflare R2 ne permet pas la lecture publique à partir de l’URL du point de terminaison S3, mais uniquement le domaine personnalisé ou un domaine aléatoire r2.dev.
(Les téléchargements pré-signés fonctionnent, mais aucun accès public direct n’est pris en charge.)
Mais Discourse n’utilise l’URL CDN que pour les images intégrées, et non pour les téléchargements directs, qui utilisent l’URL du point de terminaison S3.
Existe-t-il un moyen de le faire utiliser l’URL CDN pour tous les fichiers, ou de forcer l’utilisation d’une URL pré-signée ?
Connexe :
La solution de contournement mentionnée dans cet article fonctionne, ajouter ?dl=1 corrige le problème, car cela force Discourse à utiliser une URL S3 pré-signée.
1 « J'aime »
Corrigé dans 2023-03-16, R2 fonctionne maintenant avec Discourse à merveille avec le plan gratuit.
3 « J'aime »
Je vois aussi cela avec une certaine fréquence (tous les quelques mois) même si mon Discourse fonctionne sur AWS Lightsail et que j’envoie des fichiers sur AWS S3. Je ne suis donc pas sûr que ce soit la faute de wasabi.
Serait-il possible de détecter cette erreur et d’alerter l’administrateur ? Je vérifie l’espace disque et supprime les anciennes sauvegardes lors des mises à niveau, mais parfois il est trop tard et le forum tombe en panne par manque d’espace disque.
1 « J'aime »
Je suis à peu près certain que le problème était que les redémarrages automatiques du système d’exploitation pour les mises à jour de sécurité se produisaient pendant l’exécution de la sauvegarde. Assurez-vous de planifier vos redémarrages du système d’exploitation et vos sauvegardes à des moments différents. C’est après avoir déplacé ce site de wasabi que j’ai trouvé cette explication, mais je suis à peu près sûr que c’est ce que c’était.
2 « J'aime »
uptime indique qu’il est en ligne depuis 300 jours, donc je ne pense pas que ce soit le problème. Mais dans le même ordre d’idées, j’avais des sauvegardes Discourse prévues à 2h00 et des instantanés Lightsail à 2h30, donc peut-être que le téléchargement n’est parfois pas complet et que l’instantané interfère avec. J’ai séparé les deux opérations d’une heure ; nous verrons si cela fait une différence.
Quoi qu’il en soit, je pense qu’il est raisonnable d’avertir les administrateurs en cas d’échec du téléchargement, quelle qu’en soit la raison.
2 « J'aime »
Je pense qu’il est temps de faire des mises à niveau du noyau et de redémarrer. 
Pourriez-vous manquer de RAM ?
Après avoir implémenté les sauvegardes distantes Backblaze, je vois cette erreur dans mon tableau de bord :
Le serveur est configuré pour téléverser des fichiers vers S3, mais aucun CDN S3 n’est configuré. Cela peut entraîner des coûts S3 élevés et des performances de site plus lentes. Consultez « Utilisation du stockage d’objets pour les téléversements » pour en savoir plus.
Je n’ai pas configuré le téléversement de fichiers, j’ai seulement configuré les sauvegardes via cette configuration :
DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3
Ai-je fait quelque chose de mal ?
Quelque chose semble mal configuré, je remarque que lorsque j’essaie de téléverser un fichier dans un message, j’ai reçu cette erreur :
Valeur non prise en charge pour canned acl ‘public-read’
Toute aide serait appréciée.
2 « J'aime »
Supprimez ceci si vous ne voulez pas que les téléchargements aillent vers s3.
4 « J'aime »
Tu as sauvé la situation, mon frère. 
Merci beaucoup !
2 « J'aime »
Est-ce que cela a semblé fonctionner ?
1 « J'aime »
C’est arrivé une fois le mois dernier depuis que j’ai séparé les deux processus d’une heure, donc ça ne l’a pas “réglé”, et ça n’arrive pas assez souvent pour dire si ça a aidé.
Du côté positif, j’ai remarqué qu’il y a une section d’état de sauvegarde sur la page d’administration qui affiche l’espace disque disponible, ce qui m’évite d’ouvrir constamment un terminal et de faire un df juste pour vérifier les sauvegardes bloquées. J’ai personnalisé le texte pour me rappeler que j’attends environ 80 Go libres.
1 « J'aime »
C’est une bonne idée.
J’ai vu l’image avant de lire que vous aviez personnalisé le texte et je me demandais quelle logique était en jeu pour déterminer que c’était “bon” !
1 « J'aime »
Je n’arrivais pas à faire fonctionner cela avec Scaleway en utilisant l’image Bitnami Discourse.
Les variables d’environnement étaient définies mais n’étaient clairement pas lues/appliquées correctement (ou pas du tout ?).
J’ai donc défini les variables S3 dans le panneau d’administration et défini la région directement dans la console Rails (en espérant toujours que cela devienne juste un champ de texte) :
SiteSetting.s3_region="fr-par"
Cela m’a donné une erreur de validation, mais j’ai simplement commenté la vérification de validation avant de mettre à jour le paramètre, puis je l’ai remise.
1 « J'aime »
L’image Bitnami n’est pas empaquetée par nous et ne suit pas nos recommandations. Tout ce qui est documenté ici n’est testé qu’avec l’installation officielle.
4 « J'aime »
Cela a été résolu en activant « s3 use cdn url for all uploads », une option récemment ajoutée par Discourse.
Comme nous utilisions R2 auparavant, nous avons dû utiliser discourse remap pour remplacer manuellement les liens brisés, synchroniser les fichiers s3 par mesure de sécurité, puis nous avons ré-encodé tous les messages.
1 « J'aime »
J’essaie de configurer cela avec idrive e2, qui est compatible s3. Cependant, j’obtiens une erreur/trace de pile peu utile à la fin de ./launcher rebuild app :
I, [2023-10-14T15:08:08.026184 #1] INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: Nous avons rencontré une erreur interne, veuillez réessayer.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1] INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js
C’est la configuration que j’ai utilisée, mais j’ai aussi essayé avec DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY et DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: Dallas
DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
DISCOURSE_S3_ACCESS_KEY_ID: <snip>
DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
DISCOURSE_S3_BUCKET: discourse
DISCOURSE_S3_INSTALL_CORS_RULE: false
Notez que je ne l’utilise pas pour les sauvegardes (cela est déjà configuré dans l’interface utilisateur avec backblaze) ni pour DISCOURSE_CDN_URL car je ne suis pas sûr qu’idrive prenne en charge cela - j’avais prévu d’expérimenter avec cela une fois que j’aurais mis des fichiers réels dans le bucket.
1 « J'aime »
Il semble qu’il ne soit pas assez compatible avec S3 pour les besoins de Discourse.
Si vous souhaitez approfondir, la prochaine étape serait de reproduire cela dans une installation de développement et d’obtenir l’appel API exact qui échoue.
2 « J'aime »