AWS SDK 维护者破坏了兼容性。您的 S3 克隆提供商需要加快速度并实施更好的兼容性，以便您可以删除变通方法。
4 个赞
仅此而已，这只影响 assets 目录中的 JS/map/CSS 文件，不会影响上传，对吧？
我的意思是，它会影响清除孤立文件吗？
顺便提一下，我猜这个问题可能会影响从管理面板升级 Discourse？
实际上，我通过管理面板升级失败了，这也是我进行重建的原因。
是的，它仅用于 assets。
这个 rake 任务？不会。
但整个 AWS SDK 的更改也可能破坏了非兼容克隆上的人的功能。
1 个赞
我很确定那是错的。所以我们可能也需要关闭“清理上传”。但这只会导致你在运行时出错。它不会导致你无法重建。
听起来很可能。也许我们需要一个“skip_s3_delete”设置来解决这个问题，直到其他提供商赶上来？而且也许会自动为我们知道有问题的提供商设置它？
那个 rake 任务是过期资产被移除的唯一方式吗？
我只是想知道，为什么不添加一个选项将资源保留在 Discourse 核心服务器上（我的意思是，不将它们存储在 S3 上）？
只要不影响上传或清理孤立文件的过程，这似乎是一个可行的解决方案。
是的。这也不是什么大事。普通网站偶尔更新一下不会有什么大的区别。
如果有人关心这些事情，他们可以自己设置生命周期规则。
设置 clean up uploads = false 不是已经这样了吗？
哈哈，不行。Discourse 官方支持 S3。虽然我特意开始编写了整个为上传配置 S3 兼容对象存储提供商维基，并添加了一些开关以增加克隆兼容性，但我们今天没有任何计划投入更多时间。
如果社区想发送一些增加兼容性的 PR，并且默认关闭，那是 pr-welcome，但不要指望很快在核心中看到对每个克隆的官方支持。
4 个赞
FWIW，看起来 Digital Ocean 在删除备份和过期缺失资产方面没有遇到任何问题。
对于出现故障的服务商，不需要的资产在造成很大问题之前需要很长时间。如果需要付费存储，保留大量备份（包括巨大的数据库和所有上传内容）可能会带来很大问题。
1 个赞
您好 - 我是 Pat Patterson，Backblaze 的首席技术布道师；我之所以来到这个帖子，是因为我有一个自托管的 Discourse 论坛概念验证，并且在今天配置我的论坛使用 Backblaze B2 进行备份和上传时，恰好遇到了这个问题。
将 AWS_REQUEST_CHECKSUM_CALCULATION 和 AWS_RESPONSE_CHECKSUM_CALCULATION 设置为 WHEN_REQUIRED 是上传和下载文件的基本情况的一个有用的解决方法，但需要知道的是，它并不涵盖许多场景，包括：
- 删除文件 - Discourse 使用
DeleteObjectsS3 操作一次 API 调用删除多个文件，这是正确的做法。 - 上传对象锁定启用的存储桶中的文件。
问题在于，这些操作需要（而不仅仅是支持）一个校验和（Content-MD5 标头或新的校验和标头之一），这会导致当前的 AWS SDK 提供新的校验和标头。据我所知，没有办法覆盖这一点，让 SDK 提供像以前一样的 Content-MD5。
我们的工程师正在努力解决所有这些问题；在此期间，最好的缓解方法是使用 aws-sdk-s3 gem 的版本 1.177.0 或更早版本。
我尝试通过编辑 Gemfile 并将以下内容替换为：
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
替换为：
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
但我对 bundle 的掌握不够好，只成功地通过以下错误破坏了我的部署：
/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'
...
我猜我错过了一些重要的步骤。
我不希望给我们在 DO 的朋友泼冷水，他们是通过更新他们的服务来做到这一点的，即简单地忽略新的校验和标头，而不是因为不支持的校验和而拒绝 API 调用。
他们的事件报告 说：
请注意，Spaces 目前不验证 AWS CLI 和 AWS SDK 在上传请求中发送的数据完整性校验和。
我们认为简单地接受和存储可能与 API 客户端提供的校验和不匹配的数据是不好的。
9 个赞
感谢发帖！
2 个赞
是的，AWS SDK 的维护者对此不予理睬
2 个赞
很高兴看到 B2 团队也注意到了这个问题。
这是我的临时解决方案：
我注释掉了 app.yml 中所有与 S3 相关的配置，并成功重新构建了 Discourse。这不会影响我网站上先前上传文件的访问，在此期间上传的任何附件都将存储在本地，不会引起任何问题。
顺便说一句，我仍然想知道，为什么不添加一个选项将资产保留在 Discourse 核心服务器上（我的意思是，不将其存储在 S3 上）？
？？？
Discourse 开箱即用就是这样工作的，你需要明确选择将资源发送到对象存储服务。
我的意思是，将 Discourse 核心资产（JS、CSS 等）保留在本地服务器上可能是一个不错的选择。同时，只有用户上传的文件才会存储在 S3 中。
1 个赞
您可以通过不启用“use_s3”来做到这一点，但它们很小，我建议直接推送它们，不用担心浪费空间。
1 个赞
请帮我正确理解一下。
您的意思是将 app.yml 中的 DISCOURSE_USE_S3 设置为 false 吗？
我想这样做，因为我的 Discourse 服务器在亚洲，而 B2 只有美国的服务器。
另外，这次 AWS SDK 的问题与资产管理有关，对吗？
所以，如果我将资产存储在本地服务器上，也许可以避免这个问题（如果我理解得没错的话）。
问题与删除 S3 中的资产有关。如果您只删除尝试删除未使用的资产的那一行，它现在就可以工作。而且听起来问题很快就会得到解决。这是最简单的解决方案。我推荐它。这是我最好的免费答案。
1 个赞
谢谢，这对我很有帮助！
1 个赞
这是因为，在 S3 API 定义中，DeleteObjects 操作 的 httpChecksum.requestChecksumRequired 设置为 true，而 PutObject 则将其设置为 false。因此，SDK 遵守 WHEN_REQUIRED，因为校验和是必需的。
所有 AWS SDK 现在都从 API 定义生成，只有极少的额外代码来处理边缘情况。代码会看到 DeleteObjects 需要校验和，而现在执行此操作的方法是使用新的校验和之一，而不是 Content-MD5。
不幸的是，AWS 并未提供“像以前一样使用 Content-MD5”的配置。在进行此类更改时，他们通常不会考虑第三方对象存储生态系统，因为他们实际上不需要这样做。只有当这些更改意外地在某个角落案例中损坏了他们自己的服务时，才会修复这些问题。
3 个赞
这对亚洲的用户来说可能没什么帮助，但我们也在欧洲（荷兰阿姆斯特丹）以及今年年初在加拿大（多伦多）设有数据中心。
我无法做出任何承诺，但我们肯定在考虑在亚洲设立一个地点。
另外，如果您使用 CDN，源服务器的位置关系不大。
3 个赞
你说得对！
Backblaze 不支持 x-amz-checksum-crc32，而 Discourse 较新版本的 AWS SDK 可能默认启用了此功能。
所以我进入了应用：
./launcher enter app
并卸载了当前版本的 AWS SDK：
gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
然后安装了 Backblaze 技术人员说可以工作的版本：
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”
然后我重建了应用，它成功了！
2 个赞