Good notes to follow up when we look into email in the next release. IIRC, whitelist setting is a bit dangerous because it allows "spoofed" emails as it pretty much bypasses all the SPF/DMARC/DKIM checks. Meaning, Cloudron does not reject mail if those checks do not pass because there are too many misconfigured mail servers out there. Instead we tag the failures and allow spamassassin to score the rules. whitelisting makes spamassassin bypass the checks altogether.

@americankulak Ah! thanks for the update.

Ok, I will mark this as solved but let's investigate further if this comes up again. FWIW, if you do docker exec -ti mysql /bin/bash then the details mysql logs are located at /tmp/mysqld.err .

This should work now.

@thetomester13 I came across this question after recently installing on Oracle Cloud, and thought I ought to put something in for the argument. I put in "OCI", saw it had been written to a file somewhere, but apart from that it all just worked so I forgot about it!

@msbt thanks! I will try to see if I can make this just "work" in the next release.

@qimmiq Great! Imma gonna uninstall that Discourse ram hog now!

@nebulon

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