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

@jdaviescoates I am interesting to figure out the workaround if I could just define the new SMRP port in the server configuration. Alternatively, Is it possible to implement some kind of port forwarding rule that can circumvent the port 25 block?

It worked! Thanks!