Just recheck... and I can do this. Was 100% it was not possible. Might have been an "between my ears" problem, sry

@wmlutz said in Outbound SMTP (Transactional Email) Stopped Working - Invalid login: 535 Authentication failed: @jdaviescoates got it! It was the IP allowlist. Glad to be of assistance @wmlutz said in Outbound SMTP (Transactional Email) Stopped Working - Invalid login: 535 Authentication failed: mailgun's transactional email cost which is cents/mo. I don't think I've ever paid anything yet as I've not yet gone over the 1000 free messages a month or whatever it is...

@girish No OOM errors seen. They often barely get close to the memory limit too. It's usually only about 15-30% usage for the memory for the redis containers. I looked at dmesg but do not see anything yet. I'll take a look when It happens again. Interestingly though, I do see a similar issue with the Graphite service too which I filed a separate report for in case they're different. The main difference to me is that it doesn't block the backup process so it's less of a blocker for me at the moment, but something that should still get resolved.

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

@ccfu said in Filtering emails to "Received" shows only "Saved" rather than "Received" status.: @girish As you have been tagged in this thread, could you perhaps also comment on the filter settings not been saved on page reload? This is a UI thing, the filters are reset on reload. I will fix the text to be consistent, it's confusing agreed.

@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

@joseph do you think this issue is from the Ubuntu OS? there are a lot off issues and why will your emails automatically stop sending. It gets disconnected entirely.

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

That is quite embarrassing... I am blocked at the setup process of fresh cloudron on a fresh ubuntu for a few hours... And that is all due to # Unbound is used primarily for RBL queries (host 2.0.0.127.zen.spamhaus.org) - which is not quite true / right anymore as well?

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

Applied this fix tonight and it worked for me to quiet the errors in the syslog file - thanks for finding and sharing the solution.

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