Porkbun issue is fixed in 8.1

The porkbun issue is fixed in 8.1

@timka thanks for verifying

@joseph ah, there you go. I have indeed updated to 24.04, and presumably it was before this instruction was added. Thank you all for the help, guys, all is well now

Mm, ok thanks, but I think we need more information to debug. Hopefully, it doesn't happen again!

We can not help you. You have your answer. Look for VPSes which unblock port 25. I frequent lowendtalk and lowendbox for this.

Thanks for sharing that and glad it worked out in the end.

Ah this is good information and indeed a likely a problem for rsync backups with a lot of files (not sure how the rate-limit turns out in the end though)

It seems this worked out? Atleast, I see a login screen here. [image: 1731514135008-94c957b3-6fc7-481a-9dd2-96d7c87aa228-image-resized.png]

It looks like the problem is indeed gone with 8.1 Thank you!

Indeed those leftovers should have been purged. Maybe some bug somewhere then. Do you have a way to reproduce this?

Should be fixed now. A new weblate package is also out with probably a fix to the root cause.

8.1 is in unstable now, these issues are fixed there.

@ekevu123 Previously, we used something called "CPU Shares" (--cpu-shares in docker) . This option was a bit hard to understand since it comes to picture only when there is CPU contention between various apps (i.e when a server is overloaded to start with). We removed this and replaced it with an easier to explain "CPU Limit" (--cpu-quota in docker). This corresponds to how many cycles your app should be given. Like, you can say, give only 2 cores max to this app (in any situation). By default, apps have access to all your CPUs. However, isn't the point that the default should be less than that so that one app cannot take down the whole server? We couldn't think of a good default. Otherwise, apps will start out "crippled" and we thought it's better this way. I think if you have apps that are causing problems, only then should you look into tweaking this. This would be a stop gap measure before you try to report the issue and get the app fixed...

Sorry I did say the wrong currency. Thanks that does answer my question. Now I just have to decide if my small home server NUC is worth an extra $200 USD a year.

@jdaviescoates thank you - I've got mail restored using backup, which required a few hours, but the data is there. But I can't really can't see any reason keeping it enabled by default. How many modern mail clients can't handle search across all folders? I understand that you can't satisfy everyone with changes - just wanted to let you know that I'm on the side that is shall not be a default; unless I'm missing something, people lived happily up till 7.5.1

Updates cannot be skipped. This is how all the app packages are tested by us and by (most) upstream projects.

OK, instead of increasing the disk space or trying to hunt down files to delete, I decided to set up the new server on a temporary domain to test everything out (and might just migrate to that domain permanently). One issue I ran into was Cloudron wouldn't recognize the DNS in the domain settings when changing the dashboard domain. Since I set up the server with IPv6 I had to enter both the IPv4 and 6 addresses into the DNS config for my domain (I'm doing it manually since Godaddy and NameCheap won't let you use their API unless you have a LOT of domains and/or pay a premium). I'll have to do that for every app individually. I'll have to think ahead as far as disk space is concerned so I don't run into the Postgresql problem again. Thanks for your help!

@hpz24 said in Best practice for migrating apps from one Cloudron to another?: Now I'm curious: does an app actually survive the move to another cloudron instance with a different domain? In most apps, yes. The federated apps like mastodon and matrix are a special case. They don't support changing the domain . Even though the app itself will work after changing the domain, expect bad things to happen (tm) after domain change. For example, not seeing proper history of old message etc. I haven't tried this much, so this is just a warning really.

Not sure what we can do here I mean wget is pretty very basic and part of standard ubuntu. I am not sure who they are trying to reach stripping basic tooling on a server. I will mark this as solved but if you have idea on what we can do, I am open for suggestions. Apart from putting a note saying, "make sure you have wget installed"