@lg2_soft ah, it could be you are in a pretty old version of cloudron. The current version is 6.3

Just had a read over this support ticket: https://forum.cloudron.io/topic/5272/backup-size-growing/ should have added to this rather then create a new topic. I'm assuming once changing the lifecycle setting, an almost full reset of the bucket will be required as the 'Delete' function of Cloudron won't run correctly?

@d19dotca Also, it's probably not clear from the UI because the UI is not optimized for the early upgraders. You can see https://git.cloudron.io/cloudron/box/-/blob/master/CHANGES for what exactly is the fix in the patch release.

@girish I would avoid deleting them, but instead migrate them to the deactivated directory.

Thanks that was it!

@ritesh What PHP version are you looking for? Usually, we make a new version of the LAMP stack as new versions come out. I guess maybe it's time for PHP 8 (if that's what you are looking for).

@girish UPDATE: Finally found the culprit the was a huge backup file in /var/backups/snapshot# Did the internal DNS restart steps, restarted docker and my sites are working again. Still having trouble accessing the cloudron admin page, complaint about certificates etc. will wait and see if this resolves itself. Dimitri UPDATE: /home/yellowtent/box/setup/start.sh did the trick cloudron dashboard also available again

The CLI has indeed no way to edit domains. What you did is the correct approach - make the dashboard available via the browser and then edit from the Domains view. (As for the CLI warnings, looks like we have to replace request module with superagent. Sigh, we actually used to use superagent before...)

@nebulon Oh sorry, yes that was a command I found online which I thought was neat, haha. It just combines processes with the same name which I think is useful at times, so it's basically a summary of all MySQL services, all Node servers, etc. Thanks for the assistance by the way - I know I'm deviating a bit from the original concern so that's okay - we can probably mark this resolved now since limiting the backup task memory was sufficient for now. It just has me wondering about memory usage overall on my system now. haha. I'll maybe file a new post if I need a bit more insight later to memory stuff. Thanks again for the help! For reference, here is the current status of those commands: ubuntu@my:~$ free -h total used free shared buff/cache available Mem: 14Gi 5.3Gi 797Mi 925Mi 8.2Gi 7.8Gi Swap: 4.0Gi 3.0Mi 4.0Gi (there was 2.2 GB free when I woke up this morning but little left now because it just completed a backup, so hoping that memory gets put back - but wondering if maybe this is why it's going to low in "free" memory (even though plenty left in "available" memory). ubuntu@my:~$ ps axo rss,comm,pid | awk '{ proc_list[$2] += $1; } END \ > { for (proc in proc_list) { printf("%d\t%s\n", proc_list[proc],proc); }}' | sort -n | tail -n 20 | sort -rn | awk '{$1/=1024;printf "%.0fMB\t",$1}{print $2}' 5793MB /usr/sbin/apach 1958MB node 1070MB ruby2.7 903MB mysqld 716MB supervisord 476MB containerd-shim 327MB spamd 236MB redis-server 179MB postmaster 170MB nginx 139MB mongod 133MB dockerd 121MB uwsgi 81MB imap 65MB systemd-udevd 61MB containerd 59MB imap-login 44MB radicale 39MB carbon-cache 36MB snapd Definitely a lot more Apache-related memory usage (which I guess is just all the containers running Apache like all the WordPress sites for example and makes sense as most of the apps running are WordPress apps in Cloudron). MySQL memory also almost doubled, but since so many are WordPress sites and if they're getting busier I suspect that means more MySQL usage which means MySQL will use more memory, so I think that all checks out still. One thing I'm not sure I fully understand yet (but maybe this is a bit outside the scope of Cloudron) is the memory part... so last night I had 4.0 GB used and 4.8 GB in the free column, now it's 5.3 GB used but the free memory dropped by about 4 GB to 797 MB from 4.8 GB last night. That's where I get a bit confused and unsure why that goes so low when the memory usage only went up a bit. I believe it basically becomes "reserved" and then used in the "buff/cache" and when no longer used it's still reserved so becomes "available", is that right do you think?

Sorry, this can be closed I guess. Turns out it was because of how I edited /etc/netplan/50-cloud-init.yaml on my server where I accidentally added both IPs when it should have only contained the failover IP. Now it's working again. Was my own mistake.

@alexsunny123 ok there are quite a few variables in the mix here it seems. For a start, can you connect to the Cloudron setup view using the public IP address from your ISP on port 80 and 443? To rule out some other maybe interfering parts, disable the Cloudflare proxying. Since you mentioned email, on a residential connection you will most likely require a mail relay to work properly, anyways port 25 will most likely be blocked by your ISP. Cloudron as mail relay support for various providers though. Lastly for Cloudron it doesn't really matter if bare-metal or VM, so there are no special docs about this. You should be fine as long as you have vanilla Ubuntu 20.04 server installed.

@girish I think that might be an improvement worth considering, no? Making the necessary changes would (I think)... Make it clear to monitoring tools and manual checks by users which processes being run are local to the host and which are from containers, particularly useful when multiple instances of a service are being run both on the host and container. Follow what appears to be "best practices" when running containers. Improve security in certain situations. Admittedly these may be minor and not worth the overhead, but now that I'm aware of the behaviour, I'm a bit irked by it as it currently prevents me from easily identifying which services are container-run and which are local to the host, as well as making it confusing to which user is actually running the process listed.

@eddowding ah, great you managed to figure this out. indeed, cloudflare can only proxy http(s) and not email.

To close this, turned out that "libpython3.8" was missing on my newly upgraded 20.04 Hetzner system...therefore I was getting the message "dependency problems prevent configuration of collectd"

@girish Thank you for those commands. I think I'll just use the cloudron push after I run cloudron install on my image server. Also, not sure if there is a specific way to go about this but I could strip this down a bit to have a base install for the app if it's of use to the Cloudron community. I'm sure it would have to be polished by the devs but it is an install for Timetrex CE which is a timeclock software that our company uses.

@vladimir-d This is already fixed in the coming release - https://git.cloudron.io/cloudron/box/-/commit/6d044bfbf384b8ae98f1beac0f9d1c50005e8d34 . For now, you can ignore the warning, it's harmless.

@marcusquinn I understand your time constraints, unfortunately I am not able to trigger the behavior you are describing, so this is hard to find a fix for it. Maybe if you have some time, can you describe how one of those apps was setup initially before you adjusted the access control from the groups panel?

@nebulon Yeah fair enough. I figured it was a decision based on app compatability. Thankfully I only had 40 apps to go through