Currently, volume space usage appears to be getting rolled up into the "Everything else" bucket. Would be good to have on hand in System Info, the independent volume usage if possible.

The following packages work for the *arr family:

1. Sonarr: https://git.rohitja.in/rohit/sonarr-app
2. Radarr: https://git.rohitja.in/rohit/radarr-app
3. Lidarr: https://git.rohitja.in/rohit/lidarr-app
4. Bazarr: https://git.rohitja.in/rohit/bazarr-app
5. Jackett: https://git.rohitja.in/rohit/jackett-app

Readarr does not have a community docker image at this time, besides still being under development to my knowledge.

Of course, all these are very unpolished, and non-optimal and, imho, not ready for general use yet. Besides the servarrs being all beta v3, the docker image also does things like using mono instead of .net core. There are redundant steps in the recipe too, I am sure. The docker layers are also not handled optimally to increase layer re-use. Still, they might provide a starting point; and for anyone who wants to play around with the tools.

Okay, this might certainly be a bit out there, and a bit of an anti-pattern to what Cloudron apps seem to be about, but I was recently experimenting with bringing up an LXDE desktop environment on a cloudron container with tightvncserver installed and running. I could bring an app up for this, without the user having sudo access of course, and being limited at container creation time in the programs they can install and run on it. LXDE seems to work well even with a default container ram limit of 256 MB. The desktop can be made accessible on a VNC port.

In terms of use case, there might be some value for folks who want to setup a persistent, regularly backed-up remote development environment with emacs or eclipse, or say, for folks who are into photography and need a place to run RawTherapee or darktable.

@jodumont I cloned your repo, and spliced in some bits from the linuxserver Dockerfile with the net result that I could get Sonarr v3 (the beta version) to run on my cloudron. My code is here, if you want to review or play with.

SABnzbd is a binary newsgroup reader. See https://sabnzbd.org/. Seems to be actively developed:

It is somewhat similar in functionality to NZBGet which was requested earlier. I was able to get this to run as an app on my cloudron and the repo for that package is here. It will need some polish and review though if it is to be used more generally. I can help with that if there is broader interest.

@girish Yes, that'd work! I just think there should be some way to prevent a huge flood of requests hitting that app because some 3rd party found an open endpoint and decided to (ab)use it. The token strikes to me to be a better solution than the auth gateway too, since then it is easier for us to hit the endpoint as well from a script.

To further protect the apps running on a publicly accessible cloudron, I wanted to restrict the requests that a particular of set of apps would respond to by their originating IP address. In particular, I wanted this to be the IP address of the OpenVPN app. The idea is that to access say webmail.<server>.com, I would first have to connect to vpn.<server>.com using my VPN client, and only then would the webmail.<server>.com be visible or accessible. This would prevent indexing services, or possible hackers from even searching for what apps are hosted on the cloudron server.

Many apps provide whitelists in their configuration, so to start with, I am okay with configuring this inside the app itself. However, to do that, I need to know what the originating IP address internally would be for requests coming from the OpenVPN app. The OpenVPN app IP address externally is the same as the server IP address, but internally, I see that traffic coming from 172...* as prefix. Is this configured in box? Can we set static IPs internally for OpenVPN?

The code for a working (on one instance) package of Sonarr is here. This is Sonarr v3 which is currently in beta.

Also, this might not just be limited to OpenVPN IPs. I have seen use-cases where services could be using other service APIs like for eg. in case of vault, and it would be nice to restrict access to traffic from OpenVPN, and it's other calling apps.

@robi I am still reading through the linked thread. The idea to route traffic for an app through the VPN client is pretty cool! Still I believe from the first post that the incoming traffic to the app is not routed through the VPN client? My understanding is that the OpenVPN client would anonymise the traffic of an app, but I would still be able to login or hit its APIs from the open internet right?

Refreshing the UX a couple of times, got me an available 1.0.0 update. Looks like some weird bug. In any case, I'll make sure my package version is 1.0.0 and check again.

Update: This is working now. Tested with a few large images. Thanks!

@girish Platform version is 6.1.2. Regarding package version, I see it listed as 0.6.0 (Screenshot below)? An update seems be be available, but for some reason, the updated version seems to be 0.5.0, which cannot be "updated" to.

Clearly, this is not 1.0.0, but am not sure why I am not getting that app update. I updated this app a while ago successfully, but did not note the pkg version I was updating to then I'm afraid.

@msbt I am still getting this error for very large images now, while smaller images seem to get pushed without issues. Is there some associated parameter that controls the size of images that can be pushed?

@msbt Thanks! Looks like I missed the latest update. It's working fine now.

I am getting the following error when trying to push my docker image into this registry. Any suggestions on how to fix?

error parsing HTTP 413 response body: invalid character '<' looking for beginning of value: "<html>\r\n<head><title>413 Request Entity Too Large</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>413 Request Entity Too Large</h1></center>\r\n<hr><center>nginx/1.14.0 (Ubuntu)</center>\r\n</body>\r\n</html>\r\n"

@girish Sure, I'll make that change this weekend and update the app. I was under the impression that this would require a cloudron update

@girish I see that the WIP tag has been removed from this. Let me know if any blocker fixes are needed on this, or if there are any review comments on the package.

@robi @murgero This is a rather interesting approach with all sorts of interesting possibilities. I haven't tried sysbox yet, though I'd be happy to help in any way I can!

Okay, this might certainly be a bit out there, and a bit of an anti-pattern to what Cloudron apps seem to be about, but I was recently experimenting with bringing up an LXDE desktop environment on a cloudron container with tightvncserver installed and running. I could bring an app up for this, without the user having sudo access of course, and being limited at container creation time in the programs they can install and run on it. LXDE seems to work well even with a default container ram limit of 256 MB. The desktop can be made accessible on a VNC port.

In terms of use case, there might be some value for folks who want to setup a persistent, regularly backed-up remote development environment with emacs or eclipse, or say, for folks who are into photography and need a place to run RawTherapee or darktable.

@girish That fixed it. Thanks!