Cloudron Forum

esawtooth

@girish Yes, semi-regularly, though I haven't actually kept them updated considering that the older versions I had created still work fairly well for me.

esawtooth

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!

esawtooth

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

esawtooth

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

esawtooth

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

esawtooth

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"

esawtooth

@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

esawtooth

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

esawtooth

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

esawtooth

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.

esawtooth

@girish That fixed it. Thanks!

esawtooth

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.

esawtooth

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

esawtooth

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.

esawtooth

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.

esawtooth

@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

esawtooth

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

esawtooth

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

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?
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).

esawtooth

I think based on this, the Nginx reverse proxy can limit access to IPs or subnets as required. Being able to configure this in a persistent way should work. Is there a way to configure nginx persistently? I am guessing that my changes in /etc/nginx/conf/applications would probably not be persistent?

I believe docker by default puts all IPs in the 172.17 range, so we could limit app access on HTTP, or even tcp/udp to those IPs for apps we want to further protect. They should then be accessible by OpenVPN users.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

esawtooth

Posts