@potemkin_ai said in can't install cloudron due to unbound issues: It seems like unbound is only used for SpamHause and during setup. If the setup issue will resorted, only SpamHause issue will remain. It's also used for DNS propagation checks (during app install, change location etc) and also verify validity of DNS records for Let's Encrypt. We cannot rely on caching resolvers because they would cache not found (NXDOMAIN) entries for very long periods of time. The recommendation is to keep all the outbound ports open - https://docs.cloudron.io/security/#outbound-ports .

@Kubernetes Yeah this is specific to the Nginx Ingress Controller which runs on Kubernetes. It won’t be related to Cloudron at all since Cloudron doesn’t use Kubernetes. Cloudron won’t be vulnerable to this.

It did not change earlier, but now hours later it seems to have. All my instances were fine, just the demo server seemed affected like it was possessed by someone

@nebulon I think it's important to highlight how impressive this actually is. A DB upgrade is no small feat for one app, let alone 60-80 apps and multiple DBs that many Cloudrons here run. Then to jump across two DB version upgrades, all while seamlessly restitching everything back up so apps function properly. Traditionally there would be a team of SREs doing this for a week. Yet it happens in a few hours if not minutes. So there will be some red timeout messages and UI glitches while the process is going on (the red messages were waiting for me this AM while the system upgrade happened over night as I left my dashboard tab open), however with some patience and understanding everything comes back up as if by self-healing magic. Sure it could be more polished (how about making a browser refresh after a successful upgrade to clear all the red messages?), but once you know, it's just more important to be in gratitude that it all just works and business continues as usual. I for one appreciate this magic and hence the makers of this wonderful self-hosting system from the time I first met them during a meetup in Silicon Valley, CA. Cloudron gives me TONS of time back, which is also why I can take the time to write about it, run fun experiments, and not have to be stuck troubleshooting standard app deployment woes. Thank you Cloudron & Team for another seamless upgrade and intangibly so much more.

@perelin the docker usage is reported searately (the second line in your screenshot). It's around 20GB. This seems reasonable. The graphs numbers from du are not accurate when it comes to docker . You have to use docker system df . Looks like the space is being used somewhere else. Did you happen to use another backup location previously ? I guess the only way to find out is to run du on each folder starting from root

@joseph You can go ahead and close this thread. Yes, I did install the same version as my backup, but unfortunately, that didn’t help. In the end, I had to reinstall the server completely and upgrade to 8.3.1 again. It’s clear that backups need to be properly saved. Thanks for your help anyway.

Maybe. But I think I'll just take the extra GB into account and see dynamically if and when issues arise. So far, nothing has been missed.

@jdaviescoates said in URGENT: In a post on an originally unrelated thread about IPv6 issues @Gengar posted this link https://www.spamhaus.com/resource-center/successfully-accessing-spamhauss-free-block-lists-using-a-public-dns/ which I think explains what's going on with all these false positive spamhaus issues people are having: The TL;DR seems to be: fill in this form https://www.spamhaus.com/free-trial/sign-up-for-a-free-data-query-service-account/

@nebulon I will build up real experience and report here

Setting default_client_limit = 1500 fixes the warning . I have put this for next release.

Turns out the mysql service wasn't starting, not too clear what the root cause was, but rebuilding it made it work again.

Thanks, Looks like IPv6 is not on by default on Hetzner.

@ekevu123 yes, the registry holds the images and enabling backups for it will keep the images. I think one issue might be though that because the order of apps is not defined/random , custom apps might fail to restore if the registry app restore after them. For this, the feature request you mentioned in another post will help. For the moment, workaround is just to click restore on custom apps again after the registry has restored.

@joseph Thank for the explanation

Here the issue was that the e-mails have been moved to the new cloudron server only partially, and the new folder wasn't created in this case, so when I tried to move this in Thunderbird, it failed. So, this is solved now

MetaMask the crypto wallet? Not sure why that could be causing problems, but maybe a question for the MetaMask people.

Apparently, this has resolved itself, except for other, more specific issues, but I will open new threads for these to resolve them separately.

It worked after I have reset my ssh keys and entered a new one during restoring.