@subven wordwrap!!! the problem was staring me in the face! But I could not see it because i did not scroll to the right... Thanks for the help!!!! I took a cert and key file from another server, and renamed the default cert to be whatever the error wanted. first thedomain.com.cert, then thedomain.com.key. and so-forth until it loaded. It is working now! .

@perler Have you seen https://docs.cloudron.io/apps/#cron already? This will run the job in the context of a container. I am happy to add other "meta" patterns, if none of those fit your use case

@CBCUN any decent hoster can upload with a speed of 10MB/s so for a 600GB backup it should take 16-18 hours. My Cloudron backup is ~80GB TGZ and it takes 35-45 minutes to backup from a Netcup RS to a Hetzner storage box. Either your source/target system is slow as hell or something else is bottlenecking. What method do you use? I found TGZ to be way faster because of the many many small files. If you have larger files, maybe RSYNC is the way to go. A good solution would be a (maybe self hosted) S3 Storage together with RSYNC. I use Minio for one of my backup instances and the backup from Cloudron is blazing fast as most of the work is done by the target machine.

@Linda-Mendez Not easily. I guess you can hack on the dashboard code to come up with something but this will get overwritten during updates.

@girish Thanks for getting back. Yea I was able to sort this out. It appears it might have been related to the route I had established for internet traffic. Strange that it would only effect gmail, but this new route is simpler, and testing shows all mails being delivered without issue.

What you can do is install Cloudron anew, have it manage your domain, then migrate your 2 subdomains over to Cloudron apps. Since they appear to be simple static websites, you can use the Surfer Cloudron app to copy over and serve those website files via the convenient app File Manager. Check out the docs and play with the demo to get a feel for it.

@krumel thanks!

Hmmm Rebooted the box using button in System Info Eventually postgresql started again "by itself" (although I did push the memory limit up a bit) That seems to have allowed most apps to restart by themselves. Apart from Vikunja - it's always Vikunja. Nice app but forever having to restart it (or so it feels).

@eddowding said in Updating Cloudron to a stable version: I was migrating servers when I noticed that I'm on 7.2.5, but the latest is 7.3.2. When moving to the new server, you can install it as ./cloudron-setup --version 7.2.5 . 7.3 was out last week, just ironing out some regressions. We expect to start rolling it out next week.

@necrevistonnezr I wasn't aware of the setting, good to know.

@girish Great. Yes, thanks for asking, it was a painful several hours during the wee hours of the night figuring out how to generate a set of new certs that would bring the UI back enough to regenerate them all. I ended up using one of the 3rd party CLI tools for LE called getssl.

Currently Cloudron is single-server only, however you can of course have multiple Cloudron and thus servers. You can also connect those Cloudrons with regards to the users, by using the external user directory on one Cloudron connecting to the user directory server on the other.

Whoops, apologies. It seems you already wrote to support@cloudron.io and the issue is already resolved.

@subven said in out of space error leading to missing certs: @girish there is no way to trigger certificate renewal over the (SSH) console? I'd like an answer to this question.. as I just ran into the missing cert problem too. Having deleted all the conf/cert files, and gotten nginx started, the UI is still not accessible after box restart. All apps are inaccessible too. box restart seems to recreate the /etc/nginx/applications/my.domain.conf BUT doesn't check if the /home/yellowtent/platformdata/nginx/certs/my.domain.host.cert is there. How are they regenerated from the CLI?

@nebulon Awesome! Muchas Gracias!

That's great! Thank you very much.

@mrchrisjones I don't think the reddit thread is related to this directly, but it seems our latest version has some install regression. We are investigating. Until that you can run cloudron-setup --version 7.2.5 on a fresh Ubuntu which should not have the issue. And to confirm, Cloudron does support running at home as long as you can portforward the relevant ports from your router to the server. Sorry for that hickup on our side.

@nebulon ohh yes that could be it.