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?

@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!

I think this has started happening after I rebooted my cloudron after there were some ubuntu security updates installed. rssreader.<server> refers to the FreshRSS app, if that's of relevance. It is in stopped state on the dashboard.

@girish said in Several duplicate and recurring log messages in event log:

/home/yellowtent/platformdata/logs/box.log

I am seeing the following log messages repeat in that file:

2021-01-08T18:02:04.016Z box:server ==========================================
2021-01-08T18:02:04.016Z box:server            Cloudron 6.0.1
2021-01-08T18:02:04.020Z box:server ==========================================
2021-01-08T18:02:04.062Z box:settings initCache: pre-load settings
2021-01-08T18:02:04.076Z box:tasks stopTask: stopping all tasks
2021-01-08T18:02:04.077Z box:shell stopTask spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2021-01-08T18:02:04.130Z box:shell removeCollectdProfile spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/configurecollectd.sh remove cloudron-backup
2021-01-08T18:02:04.140Z box:shell removeCollectdProfile (stdout): Restarting collectd

2021-01-08T18:02:04.187Z box:shell removeCollectdProfile (stdout): Removing collectd stats of cloudron-backup

2021-01-08T18:02:04.190Z box:reverseproxy writeDashboardConfig: writing admin config for <server>
2021-01-08T18:02:04.237Z box:shell reload spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/reloadnginx.sh
2021-01-08T18:02:04.296Z box:platform initializing addon infrastructure
2021-01-08T18:02:04.297Z box:platform platform is uptodate at version 48.18.0
2021-01-08T18:02:04.297Z box:platform onPlatformReady: platform is ready. infra changed: false
2021-01-08T18:02:04.297Z box:apps schedulePendingTasks: scheduling app tasks
2021-01-08T18:02:04.298Z box:cron startJobs: starting cron jobs
2021-01-08T18:02:04.330Z box:cron backupConfigChanged: schedule 00 00 3 * * * (Asia/Kolkata)
2021-01-08T18:02:04.337Z box:cron autoupdatePatternChanged: pattern - 00 00 23 * * * (Asia/Kolkata)
2021-01-08T18:02:04.345Z box:cron Dynamic DNS setting changed to false
2021-01-08T18:02:04.354Z box:notifications alert: id=backupConfig title=Backup configuration is unsafe
2021-01-08T18:02:04.618Z box:dockerproxy startDockerProxy: started proxy on port 3003
Cloudron is up and running. Logs are at /home/yellowtent/platformdata/logs/box.log
2021-01-08T18:02:33.337Z box:apphealthmonitor app health: 22 alive / 10 dead.
2021-01-08T18:02:33.339Z box:apphealthmonitor app health: 22 alive / 10 dead.
2021-01-08T18:02:34.219Z box:apphealthmonitor app health: 22 alive / 10 dead.
2021-01-08T18:02:34.840Z box:reverseproxy writeDefaultConfig: writing configs for endpoint "ip"
2021-01-08T18:02:34.845Z box:shell reload spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/reloadnginx.sh
2021-01-08T18:03:00.014Z box:scheduler sync: adding jobs of 05fed728-cb8b-484d-8a12-a5c106b517cb (rssreader.<server>.in)
2021-01-08T18:04:00.019Z box:scheduler sync: adding jobs of 05fed728-cb8b-484d-8a12-a5c106b517cb (rssreader.<server>.in)
ERROR TypeError: Cannot read property 'id' of undefined
    at /home/yellowtent/box/src/scheduler.js:82:96
    at /home/yellowtent/box/src/docker.js:375:63
    at /home/yellowtent/box/node_modules/dockerode/lib/docker.js:73:23
    at /home/yellowtent/box/node_modules/docker-modem/lib/modem.js:265:7
    at getCause (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:287:7)
    at Modem.buildPayload (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:256:5)
    at IncomingMessage.<anonymous> (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:232:14)
    at IncomingMessage.emit (events.js:203:15)
    at endReadableNT (_stream_readable.js:1145:12)
    at process._tickCallback (internal/process/next_tick.js:63:19) [ /home/yellowtent/box/box.js:61:17 ]
2021-01-08T18:04:03.893Z box:server ==========================================
2021-01-08T18:04:03.894Z box:server            Cloudron 6.0.1
2021-01-08T18:04:03.898Z box:server ==========================================

I am getting several recurrent messages in the event log every couple of minutes with the following text:

"Cloudron started with version 6.0.1"
{
  "version": "6.0.1"
}

Which process could be raising these events so frequently and how can I debug the issue? Any pointers on this would be great. I am concerned that some service might be trying to start over and over again.

I had a question regarding the implementation of this app. I have currently put this behind the proxyAuth add-on but that prevents the app's APIs from being called by external applications, even if they use the API key. An alternative would be to use the app's inbuilt authentication which does not support LDAP and is limited to a single username/password combination. I have seen a similar issue with the transmission app as well, where the transmission's rpc api cannot be called by, say, the couchpotato app, due to the app being behind proxyApp.

What is the recommendation in such cases? Do we want to retain proxyAuth for a more secure and better integrated auth setup, or let users configure security using the in-app options available and allow them to retain access to the app's APIs.

Currently, I have put this behind proxyAuth, going by what was implemented for transmission, but more feedback might help make a better choice.

@girish Thanks Girish! One great value-add to me of cloudron is the simple setup of multiple apps and services with efficient utilization of the server resources. I am more of a hobbyist and lean towards using cloudron to self-host a lot of my digital footprint. From that point of view, a single server setup appears to make sense to me if it is feasible.

I did not consider that limitation of the nginx approach and completely agree that it's not great to bake in. I'll read the referred thread in more detail

@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?

@girish That makes sense. I guess I was really thinking inside the "box" on this one! While this would work, and would definitely be secure, doing it this way results in the following two issues to my mind:

1. It would need an extra machine on a VPS/cloud provider, and hence increased cost for the machine (and the potential cloudron license). Also, I am running on Hetzner, so not sure if they support VPC. Still, I'll try to see what I can do here. Using a proxy server, should work even if I cannot manage a VPC, if I can tell the hidden cloudron to blacklist all other public IPs other than the public IP of the VPS. Do you think that'd work too?

2. I would not be able to control what apps I expose publicly unless I put the public apps on a gateway cloudron, and the private apps on the hidden cloudron. If I do not use two cloudrons, this method would disable public access to all the apps, if I understood everything correctly and I would not, for example, be able to make connections to imap.server.com directly from my mail client unless it was hosted on the gateway cloudron.

Generally it makes sense for me to want to expose apps like surfer, wordpress, email endpoints for IMAP/SMTP etc. to the public internet, while keeping my webmail app and the control pages for internal services like my jupyter notebook secure behind a VPN to reduce attack surface area. Also, even if I go with the two cloudron approach, I'd have to synchronize data between the two cloudrons which would have it's own set of issues.

It'll likely work, but would not be that clean IMO. What I was mentioning is kind of similar to #1, save that the VPN server is an app on the cloudron, and instead of whitelisting the external IP for the whole cloudron, I'd be whitelisting the internal IP of the VPN app for the individual apps I want to protect. Not sure how feasible it is, but I feel it would be nicer to be able to label an app as "Private" or "Internal" vs "Public", and let the application nginx config block access to it to all save internal apps (including openvpn).