use garage s3 storage #7
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Most fediversity apps have options to use s3 storage as a backend.
Resources:
Current status:
Mastodon
Successfully uploads images into s3 storage, and tries to display that image from the correct URL. If I copy-paste the URL from the web inspector, the image shows up.
However, on mastodon itself the image does not show up. This might be a CORS issue, though changing those settings didn't help.
PeerTube
Works!
PixelFed
It seems to be storing the uploaded images correctly in s3, but then when it tries to display them it's using a different URL. Going to that url does not display the image. A couple possibilities
Mastodon update
It's not CORS. I solved the CORS problem already successfuly. Instead, it's security from the other end. Rather than garage refusing to serve the image, mastodon is refusing to display it because of Content-Security-Policy rules.
If I doctor the response headers for the page in the chromium devtools window to remove
Content-Security-Policy, it works. The images load.However, this doesn't immediately suggest a way to solve this in the NixOS configuration. Mastodon is supposed to set the CSP correctly automatically. The code for that is in content_security_policy.rb (among other places). I found a bunch of mastodon issues that had to do with CSP, but none seemed to correspond to this case.
I also tried doctoring the header in the
nginxreverse proxy config, but I couldn't get that working. It's not a great long-term solution anyways, so I don't want to put more effort into it.I'm working towards a minimal reproduction of the mastodon/garage issues using Nixos Tests taeer/simple-nixos-fediverse#9 (comment)
Minimal reproduction is done, and I've submitted an issue upstream with mastodon
https://github.com/mastodon/mastodon/issues/31145
Pixefled update:
There are two issues preventing us from seeing images posted.
Pixelfed update
Commit
553a03b971seems to feature a working Pixelfed+Garage setup. Here are some noteworthy comments:There exists a
DANGEROUSLY_SET_FILESYSTEM_DRIVERflag (formerly justFILESYSTEM_DRIVER) that one can put tos3and that makes all the storage rely on the S3 backend (Garage, in our case). It is not clear whether we actually want this.This flag differs from the
FILESYSTEM_CLOUDflag that specifies that medias (but not avatars, for instance) should be uploaded to the cloud (Garage, in our case). It seems to not have much effect when it iss3and so isDANGEROUSLY_SET_FILESYSTEM_DRIVER. If the later is not set, then the medias are first uploaded on the local storage and then copied to Garage. It is unclear if and when they are removed from the local storage.Pixelfed uses the
AWS_URLto which it appends the media's path and shows that on the client path. If requesting this file does not work, a piece of code on the client replaces thesrcby a “no preview” image. One should look in the developer tools to check the actual request that's being made.In the commit mentioned, we set
AWS_URLto"", meaning thesrcwill just be the media's path. This works in the presence of a proxy configuration for Nginx routing the request to the Garage web address internally.Images not showing up without
DANGEROUSLY_SET_FILESYSTEM_DRIVERseems to be a generic issue with pixelfed on nixpkgs. See https://github.com/NixOS/nixpkgs/issues/235147 for discussion.If we apply the patch someone there came up with, it works. See
1d8f514240for a working config withoutDANGEROUSLY_SET_ETC_ETCwe can also set
AWS_URLto the public web endpoint of garagehttp://pixelfed.web.garage.localhost:3902/. In this case we don't need to set any nginx proxy_pass. This is done in the next commite7ffd94c5e.Found this discussion which links to these two issues. Lots of confusing things, but in particular: