Garage packaging status, next steps
-
Hi @scooke ,
To your question, I followed the instructions on the Garage website, and I added a near-copy of that documentation to the README in the package I've developed. This is all documented in the git repository for the package that I linked to. I have Garage running on my Cloudron instance, and was able to create buckets, add content, and even serve static web content from within those buckets. I'm sorry your prior experience with this did not work for you.
I am now trying to do that in a way that it would be considered for inclusion as a standard package, if the Cloudron team thinks it is worthwhile. If they don't, perhaps I'll do it for myself.

-
J jadudm referenced this topic on
-
Hi @scooke ,
To your question, I followed the instructions on the Garage website, and I added a near-copy of that documentation to the README in the package I've developed. This is all documented in the git repository for the package that I linked to. I have Garage running on my Cloudron instance, and was able to create buckets, add content, and even serve static web content from within those buckets. I'm sorry your prior experience with this did not work for you.
I am now trying to do that in a way that it would be considered for inclusion as a standard package, if the Cloudron team thinks it is worthwhile. If they don't, perhaps I'll do it for myself.

-
Hi @timconsidine ,
Good question. I didn't push further, given that @girish suggested this might be positioned to be an addon.
https://forum.cloudron.io/post/116655
@girish , do you think I should finish this as an app package, or do you think this is something that will land in the roadmap? Or, as we say, "two things can be true?"
@timconsidine , I'm happy to bring this app to completion. Or, perhaps, contribute work to the core. I guess I'd look to the product team to provide some guidance.
-
Hi @timconsidine ,
Good question. I didn't push further, given that @girish suggested this might be positioned to be an addon.
https://forum.cloudron.io/post/116655
@girish , do you think I should finish this as an app package, or do you think this is something that will land in the roadmap? Or, as we say, "two things can be true?"
@timconsidine , I'm happy to bring this app to completion. Or, perhaps, contribute work to the core. I guess I'd look to the product team to provide some guidance.
-
@robi said in Garage packaging status, next steps:
More options is better than less IMHO
In that spirit, I made my own package, principally so I could learn about Garage :
https://forum.cloudron.io/post/117911 -
@robi said in Garage packaging status, next steps:
More options is better than less IMHO
In that spirit, I made my own package, principally so I could learn about Garage :
https://forum.cloudron.io/post/117911@timconsidine hi Tim,
I tried to use the community app but I get a 413 response code (which suggests the payload is too large). It happens at the very first backup attempt.
Any suggestions? Is there anything I may have missed, or anything you had to do after deploying the app? Did you ever run into the 413?
I’m using tarball and encryption in case that matters at all.
-
There's a good chance this is an Nginx error; we've seen this before on other packages. There's a limit on the front-side as to how large a file can be passed through an Nginx proxy. For example:
It might be a similar problem here. Fixable, but it will require an update on the package.
-
There's a good chance this is an Nginx error; we've seen this before on other packages. There's a limit on the front-side as to how large a file can be passed through an Nginx proxy. For example:
It might be a similar problem here. Fixable, but it will require an update on the package.
@jadudm Agreed.
But isn’t that something configurable in the package? Looks like it isn’t a user-facing setting, but I assume this can be taken care of in the code part of the package? I’m not super familiar with packing apps just yet so correct me if I’m wrong.Probably worth setting the client max body size to 0 for unlimited since there will be all sorts of sizes to an app that’s used for backups. I’m just surprised nobody else has run into this issue, it happens immediately upon backup.
-
@timconsidine hi Tim,
I tried to use the community app but I get a 413 response code (which suggests the payload is too large). It happens at the very first backup attempt.
Any suggestions? Is there anything I may have missed, or anything you had to do after deploying the app? Did you ever run into the 413?
I’m using tarball and encryption in case that matters at all.
@d19dotca errr...
No I have not experienced that.
Personally I use rsync not tarball.
I will try a tarball backup later.If it's a backup issue, is it an app issue ?
I don't understand this.EDIT : that's meant as unhelpful, just not sure where to start looking - will ask AI
But did you see that an official version is close ? -
I just saw that @girish is looking at this, so it sounds like there might be an official packing in the pipeline:
The garage app is packaged, just reviewing it and have to a get an initial package out.
Edit: heh, and also just realised that @timconsidine just linked to that too!

-
@d19dotca errr...
No I have not experienced that.
Personally I use rsync not tarball.
I will try a tarball backup later.If it's a backup issue, is it an app issue ?
I don't understand this.EDIT : that's meant as unhelpful, just not sure where to start looking - will ask AI
But did you see that an official version is close ?@timconsidine Serving as your meat-based AI...

In theory, it would be an app issue. Because Nginx is serving as a proxy in front of Garage---it is handling the HTTPS and some domain routing to the app itself---the behavior of that HTTP server becomes "a thing." In this case, Nginx has a maximum client body size:
https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
For many apps, this is never an issue; for apps that involve uploading files (Immich, Garage, etc.), clients routinely send large files. While I might think I'm connected to my Garage instance, what I'm actually connected to is Nginx, which is proxying my connection through to Garage in the backend. Therefore, the behavior of the proxy matters, and in this case, it has to do with the filesize limits of the proxy. When doing file uploads, we can easily exceed the per-request filesize limit on the proxy, and Nginx returns a 413 as a result.
You wouldn't see it if you're using
rsyncbackups and dealing with small files. However, a tarball backup can easily generate a request that comes in at gigabytes in size; as a result, Nginx says "no" and returns a 413.Hence, @d19dotca thinking that setting that value in the Nginx config to 0 would likely eliminate the error.
All of that said, there's also the possible arrival of an officially maintained Garage package, which we might want to move to anyway. However, it is good to have options to experiment with!
-
@timconsidine Serving as your meat-based AI...

In theory, it would be an app issue. Because Nginx is serving as a proxy in front of Garage---it is handling the HTTPS and some domain routing to the app itself---the behavior of that HTTP server becomes "a thing." In this case, Nginx has a maximum client body size:
https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
For many apps, this is never an issue; for apps that involve uploading files (Immich, Garage, etc.), clients routinely send large files. While I might think I'm connected to my Garage instance, what I'm actually connected to is Nginx, which is proxying my connection through to Garage in the backend. Therefore, the behavior of the proxy matters, and in this case, it has to do with the filesize limits of the proxy. When doing file uploads, we can easily exceed the per-request filesize limit on the proxy, and Nginx returns a 413 as a result.
You wouldn't see it if you're using
rsyncbackups and dealing with small files. However, a tarball backup can easily generate a request that comes in at gigabytes in size; as a result, Nginx says "no" and returns a 413.Hence, @d19dotca thinking that setting that value in the Nginx config to 0 would likely eliminate the error.
All of that said, there's also the possible arrival of an officially maintained Garage package, which we might want to move to anyway. However, it is good to have options to experiment with!
@jadudm thanks for the clarification
will certainly bear that in mind for future issuesfor this one on my Garage app, I'm not sure what to do. If an App Store version is coming, even unstable, that might be better for this wanting Garage.
I will try find time to check out my Garage packaging code with this issue in mind.
-
It might be in the
locationblock that you would need to add it:Which would parallel the fix described here:
It might even be that @d19dotca can make that change to his own config for local testing. But, I agree, an officially packaged version will likely address this, and be integrated fully with backups, etc.
-
Still a little unsure about this.
If the Garage app is storing large volumes, say 5Gb, is backup by tarball appropriate, do we want to be facilitating that ?
That said, I guess it still needs fixing for smaller tarballs.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login