@warg said in The turn service ran out of memory: Could this be related to malicious clients, e. g. erros created by bots that try turn-specific exploits? It does seem to be like that. Is anyone else seeing such messages in the turn service logs?

There were a few bugs with the token display when we moved the dashboard over to OpenID. This is fixed now with https://git.cloudron.io/cloudron/box/-/commit/e9f3f135640f8ee60041a8797b32b62e032201af

Maybe you have dangling images around, which are not deleted, can you see if docker image prune -a removes some?

For others reading this: After looking at the WordPress instance, it appeared to have been hacked and someone placed suspicious includes in wp-config.php those made the app simply hang. Removing that brought it back, however in such situations, it is strongly advised to start fresh as we don't know what else may have been modified.

@imc67 yes, indeed, but the presence of the original DST Root CA is causing issues for Uptime Kuma. There is discussion in their Issues list, but no solution (some hack proposed but not interested in that). I've read elsewhere that the old DST Root CA can be deleted ... but no idea how. That might help Uptime Kuma not to report it. I might try that on non-Cloudron apps but wouldn't want to try that on a Cloudron app. Oh well, just some noise in Telegram that I can ignore.

Already fixed bugs are the best bugs

Thanks! I did not expect such a quick fix after your first response, but the change looks sensible.

@nebulon Thanks. Ohh, I was so close last night. Your post gave me the courage to plunge back in. The username I gave to the user who owns the policy was a really wierd choice several years ago. So when I went to the aws users page, I didn't think of exploring there. Also the ID and secret were in a file on my local machine, filed well with a good file name. Last night I just wasn't careful in looking for it. So I'm all good now.

I figured out the issue - posting here for anyone who encounters the same... I had not whitelisted my new server's IP address with my registrar (Namecheap). Once I did this, installs and uninstalls are now working. The error was actually an external error passed from Namecheap, not an internal Cloudron error message

That's the last thing I would have expected... thank you for finding this out!

The preserving of the file permissions is now also fixed for next release.

@ccfu right... if DNS is not mainained by Cloudron, we have to show some message/alert the user. This requires some work, this is why this feature is not done yet It seems like quite some work for very little value.

@BrutalBirdie how many subdomains/records are there in that domain ?

Thank you @girish - yes. that worked! I can sftp into the app And i am so glad you took the time to review and fix the issue.

Got it thanks.

We mostly rely on the spamd default settings, those are not easy to get right on a generic level. On my personal Cloudron I have tweaked those with great success, but mileage may vary. In my case I have raised the score for some bayes rules to give the learning more relevance. You can try this on your instance by putting the following content: score BAYES_999 2.0 score BAYES_99 4.5 into the file /app/data/spamd/custom.cf in your mail containers data folder, via SSH onto your host server the shell session is: docker exec -ti mail /bin/bash root@e05ce221283c:/app/code/haraka# cat /app/data/spamd/custom.cf score BAYES_999 2.0 score BAYES_99 4.5 root@e05ce221283c:/app/code/haraka# Then restart the mail container via the services view in your Cloudron dashboard. As said though this may also result in mails landing in spam which are legit for your cases.

alright, i have just tested the feature, and it works. thanks

Ahh yes! That makes perfect sense @nebulon ... and I feel rather silly for not taking that into consideration. It should have been the first place that I looked - because indeed the subdomains rocket-chat, and mastodon were pointing to the old server still. Therefore, there is nothing more to be assessed or figured out here, because you have helped me to solve the problem. I am taking the old server offline, and setting up the apps within the new host environment - as it seems this was much ado about nothing!

Fixed with https://git.cloudron.io/cloudron/box/-/commit/c3574614bc074750864b2e0424494a4cb58778e9 for next release.

@MooCloud_Matt I think you can just use "no-op" in your situation and also use a custom wildcard certificate. The proxy can then accept just that wildcard cert. no-op ignores DNS checks. The cert can be Let's Encrypt or not depending on if your proxy can carefully forward well-known HTTP requests.