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"

You may have to create the /home/yellowtent/boxdata/custom_pages directory if it doesn't exist.

Quick update - The issue had nothing to do with Cloudron server and everything to do with the Nginx Proxy Manager host sitting in front of the Cloudron server. Good time to mention that NPM in front of a Cloudron server is not an officially supported Cloudron setup. Yet, with this being said, once Websockets relay was enabled on NPM proxy host, everything fell into places. Many many thanks for @nebulon and the cloudron team for their support as always.

Sorry for this delayed response. Just wanted to confirm that everything worked right after contacting you. Thank your very much for this quick reply and for your great support. Appreciate it.

The issue here was server DNS related . The upgrade to Cloudron 8 left the system in a broken state where DNS was not working. Fixing up /etc/systemd/resolved.conf to have DNS servers resolved the problem.

Just purge contents of the folder or delete the folder and recreate it with the same permissions. Other bits of Linux sometimes put logs there.

node.js has a "happy eyeballs" quirk. This causes premature network errors when there is no ipv6 and ipv4 is slow. I have fixed this in https://git.cloudron.io/cloudron/box/-/commit/aefa481c43603d284346d58497b6ff5b462efd88

Hello and thank you for your feedback. I put this idea on hold for the time being after learning that Okta has had several security breaches in the past. I am reconsidering which solution I want to use at all. Thanks anyway

Thanks!

There is currently no generic way to do this from Cloudron side. Depending on your backup storage you are using, you probably can download directly from there.

@jdaviescoates said in OnlyOffice is unresponsive after update to 1.18: @imc67 said in OnlyOffice is unresponsive after update to 1.18: config key config key? Secret (key) in the Config folder

thanks, made a snapshot and got rid of the most important/obvious logs, cheers Unsure about the 90 days though, many of my servers have logs until the day they were created.

As far as I understand those CVEs they are not relevant in that context. For the first, we don't use those affected configs and the second is for the ssh-agent. Given that the Ubuntu team usually knows what they do and are working closely together with upstream projects, there seems no need here to go beyond their recommendations of versions they push out via security updates.