@Falco - Scaleway には、マルチパートアップロードで 1,000 個のパートしかサポートしていないという警告を追加すると良いかもしれません。AWS は 10,000 個をサポートしています。これは通常のアップロードでは問題ありませんが、S3 SDK は手動で変更しない限り 10,000 個のパートを使用し、失敗するため、特定のサイズを超えるバックアップアップロードでは問題となります。
「いいね！」 4
素晴らしい発見ですね！もし可能であれば、OPのwikiに追加してください。
「いいね！」 4
ありがとうございます。また、これらのツールのいずれかを使用して、クラウドからクラウドへ、特にS3互換オブジェクトストレージとの間でコピーできることも付け加えておきます。例えば、Rclone、Shargate、Gs Richcopy360、GoodSyncなどです。これらはすべて類似のクラウドと互換性があります。
「いいね！」 1
問題を発見しました。Cloudflare R2は、S3エンドポイントURLからのパブリック読み取りを許可せず、カスタムドメインまたはランダムなr2.devドメインのみを許可します。
（事前署名付きダウンロードは機能しますが、直接のパブリックアクセスはサポートされていません。）
しかし、Discourseは埋め込み画像にはCDN URLのみを使用し、S3エンドポイントURLを使用する直接ダウンロードは使用しません。
すべてのファイルにCDN URLを使用させるか、事前署名付きURLの使用を強制する方法はありますか？
関連情報:
その投稿で言及されている回避策は機能します。?dl=1を追加すると、Discourseが事前署名付きS3 URLを使用するように強制されるため、問題が解決します。
「いいね！」 1
2023-03-16で修正され、現在R2はDiscourseと連携して、無料プランでスムーズに動作します。
「いいね！」 3
私もこれは（数ヶ月に一度ですが）頻繁に発生しています。DiscourseはAWS Lightsailで実行しており、AWS S3にアップロードしていますが、Wasabiのせいではないようです。
このエラーをキャッチして管理者に通知することは可能でしょうか？ディスク容量は確認し、アップグレード時に古いバックアップを削除しますが、時には手遅れになり、ディスク容量不足でフォーラムがダウンすることがあります。
「いいね！」 1
この問題は、セキュリティアップデートのためのOSの自動再起動がバックアップ実行中に発生していたことが原因だとほぼ確信しています。OSの再起動とバックアップのスケジュールを異なる時間帯に設定してください。この説明に至ったのはWasabiからそのサイトを移動した後ですが、それが原因だったと確信しています。
「いいね！」 2
uptimeによると300日間稼働しているので、それが問題だとは思いません。しかし、似たようなことですが、午前2時にDiscourseのバックアップをスケジュールし、午前2時30分にLightsailのスナップショットをスケジュールしていたので、アップロードが完了しないことがあり、スナップショットがそれを台無しにしているのかもしれません。両方の操作を1時間ずらしました。違いが出るかどうか見てみましょう。
いずれにしても、何らかの理由でアップロードが失敗した場合、管理者に警告するのは妥当だと思います。
「いいね！」 2
カーネルのアップグレードと再起動を行う時期だと思います。
RAMが不足している可能性がありますか？
リモートのBackblazeバックアップを実装した後、ダッシュボードに次のエラーが表示されます。
サーバーはS3にファイルをアップロードするように構成されていますが、S3 CDNが構成されていません。これにより、高額なS3コストとサイトパフォーマンスの低下につながる可能性があります。「アップロードにオブジェクトストレージを使用する」を参照して詳細を確認してください。
ファイルをアップロードするように構成したわけではありません。設定したのは次の設定によるバックアップのみです。
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
何か間違ったことをしましたか？
設定に誤りがあるようです。投稿にファイルをアップロードしようとすると、次のエラーが発生しました。
canned acl ‘public-read’ のサポートされていない値
何かお手伝いいただければ幸いです。
「いいね！」 2
S3へのアップロードを避けたい場合は、これを削除してください。
「いいね！」 4
兄弟、君が救ってくれた。
本当にありがとう！
「いいね！」 2
それでうまくいきましたか？
「いいね！」 1
過去1か月の間に、2つのプロセスを1時間ずつ分離しましたが、それでも発生しました。「修正」されたわけではなく、頻繁に発生しないため、役立ったかどうかは判断できません。
明るい面としては、管理ページにバックアップステータスセクションがあり、利用可能なディスク容量が表示されることに気づきました。これにより、バックアップがスタックしているかどうかを確認するために、常にターミナルを開いてdfを実行する必要がなくなりました。約80GBの空き容量を期待していることを自分に思い出させるために、テキストをカスタマイズしました。
「いいね！」 1
それは良い考えですね。
テキストをカスタマイズしたことを読む前に画像を見て、それが「良い」と判断されたロジックは何だろうと思っていました！
「いいね！」 1
Scaleway で Bitnami Discourse イメージを使用しても、これが機能しませんでした。
環境変数は設定されていましたが、明らかに正しく（またはまったく？）読み取られていませんでした。
そのため、管理パネルで S3 変数を設定し、rails コンソールで直接リージョンを設定しました（これが単なるテキストフィールドになることをまだ期待しています）。
SiteSetting.s3_region="fr-par"
検証エラーが発生しましたが、設定を更新する前に検証チェックをコメントアウトし、その後元に戻しました。
「いいね！」 1
Bitnamiイメージは弊社がパッケージ化したものではなく、弊社の推奨事項に従っていません。ここに文書化されているすべては、公式のインストールに対してのみテストされています。
「いいね！」 4
これは、Discourse によって最近追加されたオプションである「s3 use cdn url for all uploads」を有効にすることで解決されました。
以前は R2 を使用していたため、壊れたリンクを手動で置き換えるために discourse remap を使用し、念のため S3 ファイルを同期してから、すべての投稿を再ベイクしました。
「いいね！」 1
idrive e2 と S3 互換でこれを設定しようとしていますが、./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: 内部エラーが発生しました。もう一度お試しください。
/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 -- : CORS ルールをインストール中...
スキップ
アップロード中: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js
これは、DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY や 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
バックアップ用ではない（UIでbackblaze用に既に設定済み） nor DISCOURSE_CDN_URL ではないことに注意してください。idrive がそれをサポートしているかどうかわかりません。実際のファイルをバケットに配置できたら、それを使って実験するつもりでした。
「いいね！」 1
Discourse のニーズに対して S3 との互換性が十分ではないようです。
さらに詳しく知りたい場合は、次のステップとして、開発環境にこれを再現し、失敗する正確な API 呼び出しを取得することになります。
「いいね！」 2