If you have a Dockerfile, you can package custom apps for deploying on Cloudron. No need to add/change nginx entries etc. Please see https://docs.cloudron.io/custom-apps/tutorial/

Thanks guys! Yeah it's a weird issue for sure and likely very rare, so it's probably not a big deal. If it helps for reproducing it, here's a few notes:

27 apps installed at the time of backup/restore Backup & Restore used tgz format with OVH Object Storage in BHS region Backup from a LunaNode m.8 model in Toronto region Restored onto OVH b2-7 model (though since upgraded to b2-15) in BHS3 region LunaNode instance (source) was running Ubuntu 18.04 at backup time, and OVH instance (target) was running Ubuntu 20.04 at the time of restore. When I restored, I very nearly ran out of disk space on the included disk, leaving only ~ 1.5 GB of space remaining. When restoring initially, it failed to restore because of the issue I reported earlier, though doubtful this is a root cause. Immediately moved the boxdata to external disk afterwards though, so plenty of space free soon after the restore was done once I moved boxdata off (20 GB in emails alone so it takes up a lot of space).

Hopefully those notes above help in some small way. No worries though if you can't reproduce it, I imagine it's a very rare scenario and could have even been completely unique to me somehow. Hopefully others can chime in though if they experienced anything similar where cron wouldn't run at all (whether a restore involved or not, as I'm still not 100% certain it had to do with the restore though I presume it did).

@kallados indeed it has to be adjusted to your own account name. cloudron here refers to our account at the docker hub. The chown is for the unix user named cloudron on your system. Nothing to do with the docker hub registry service.

@fossy As mugero said, you really have no reason to worry about the services. They use a negligible amount of resources when they are not actually used!

@atrilahiji idk, that was the thought about the reflexive connectivity, yet it should be able to use a fallback relay.

@girish Hi Girish. Just following up on this. Doesn't seem like it's been fixed yet. 😞

@infogulch said in Changing from wildcard to provider-based dns configuration left apps and my.example.com unassigned after wildcard was deleted:

That makes a lot of sense. Curious, does Cloudron log when it encounters an existing DNS record that it should not overwrite?

It will show the error in the UI. If you try to install an app into a subdomain that has a DNS entry, it will error and give you an option to "overwrite" the DNS record.

@svallory Accept self-signed certs and login to dashboard. Once logged in, I would first go to settings and check for updates/update all the way to Cloudron 6. This is because LE made a change in the last few months which makes cert renewal fail on Cloudron side. Once updated, Domains -> Renew all certs.

@d19dotca Thanks for the details analysis! So, after you report I decided to look into some of the Cloudrons I have access to and indeed logrotate configs for some apps are missing. Let me debug further, but there is definitely some bug.

@girish Will do

I was totally in the wrong here. I just looked at the wrong section it turned out 🤦 Sorry for taking up your time.

@nebulon said in Managing SSL certs via Cloudron CLI:

you have to "forget" the page in your browser

yes, or visit the site in an incognito session. Clearing these entries from the profile in Chrome is slightly more complicated, but doable as well.

https://msutexas.edu/library/clearhsts.php

We used to have owncloud as a package, but at some point it was impossible to update postgres due to owncloud dependency. So we dropped it.
There is however the new owncloud on the horizon which is essentially a rewrite and I am hopeful to be able to add that then.

@staypath Continuing my conversation with myself 🙂

Posting this here in case anyone else comes across this with the same question: I found that configuring fail2ban to use systemd was the trick:

[sshd] port = ssh #logpath = %(sshd_log)s #backend = %(sshd_backend)s backend = systemd enabled = true maxretry = 1 bantime = 14d

@girish Fantastic, I'll get right on this tomorrow! Cheers and thank you for the help, I will recontact in the event I struggle more. Very appreciated

@mastadamus If you use namecheap API, you don't need port 80. This is because Cloudron will use Let's encrypt DNS automation to get certs. Note that this will require you to sometimes type "https://" explicitly in some browsers because some browsers will default to connecting on port 80 and then the redirect will take it to the https site. In addition, Cloudron has HSTS, so future connects will directly be to 443 and no redirect dance.

Turns out the domain expired. 🤦
Nothing related to Cloudron.
Please mark this as resolved.

@girish Im tracking with what you saying but the API didn't create any A records. In fact i couldn't get to the dashboard at all until i created that * wild card. I still have no idea why its not redirecting to HTTPS if i put int http://www.mydomain.com. The only files the API created in dns were 2 txt records and a testcloudrondns at 127.0.0.1

@d19dotca OK, I have scheduled https://git.cloudron.io/cloudron/box/-/issues/737 for 6.2, let's see.