If you rebuilt the app then the changes made in the container are gone. Perhaps the backblaze folks fixed things while you were doing that.
1 个赞
I just commented out the S3 and rebuilt. I guess I’ll stick to local storage from now on.
1 个赞
Local storage works fine. It’s just deleting that does not work.
Thanks for posting and confirming there is no current workaround without downgrading the aws SDKs. I ran into issues with the b2 s3 apis from another project using the golang aws sdk, trying to back up a VictoriaMetrics database.
Do you have any sense from your engineering team how or when they may choose to resolve this issue, or have any way to track/get updates on a supported workaround? I’m trying to decide if I should fork and recompile a project with a dependency change or just wait a little while for an update!
Thanks!
The following procedure worked for me to downgrade the AWS Gems:
# To get into the container:
./launcher enter app
# Apparently needed to unfreeze Gemfile.lock:
bundle config set frozen false
# Set an older version of the sdk-s3 gem:
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
# Downgrade the S3 gem to match what's now in the Gemfile:
bundle update aws-sdk-s3
# Also downgrade aws-sdk-core gem:
bundle add aws-sdk-core --version 3.215.
After making these changes, I was able to successfully save a backup to B2. I’m sure this is only a temporarily workaround that will be lost on the next Discourse update, so I’m hoping @PatPatterson and the Backblaze team can provide a more permanent compatibility fix soon.
2 个赞
Hopefully you won’t need to do this, but it’s possible to put that sed command in the app.yml so that it would happen automatically when you rebuild. I think just sticking it below where the plugins get cloned would do it. But it could be more complicated than I think.
1 个赞
Hi AntiMetaman,
I have spent the last week trying to get backups working with s3 storage and finally got the backup to work with this thread. Honestly, I am not sure which part worked.
I followed what you did with the gem uninstall and install but now I get an error trying to upload images. My error log shows this
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
Before I have to trash my whole server and start again (honestly, at this point I’m not even sure I want to continue) do you know how I can reverse the gem uninstall and install so I can try and see if that fixes the issue?
The behavior I’ve seen on our instance (which uses backblaze for backup) is that backups started failing, without notification, in February. I just happened to notice it today, since I check our backups from time-to-time. I would consider this quite a serious problem?
Would it be possible to downgrade the AWS-SDK until a workaround can be found for backblaze and other non-AWS providers?
But I did for a site that’s using Backblaze. I created a template I put in /root/aws-revert-template.yml with this:
# This template reverts aws-sdk-s3 to a version that works with 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
And then added it to my app.yml like this:
# IMPORTANT: SET A SECRET PASSWORD in Postgres for the Discourse User
# TODO: change SOME_SECRET in this template
templates:
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
- "templates/web.ssl.template.yml"
- "templates/web.letsencrypt.ssl.template.yml"
- "/root/aws-revert-template.yml"
And I ran an upgrade to stable and it seems to be working.
You could also just add what’s in the template to your app.yml
3 个赞