@girish Thanks for that command. It is indeed strange and I haven't seen it on other Cloudrons, so something must have got stuck with this one. Not a big deal, but it's nice to have that message not displaying any more.
Thing is some apps store the email (just like they store username) in the database. This means that when you change the email in Cloudron, it doesn't change in the app (depends on the app). So, just to keep things easier across apps, we decided to keep login username based as much as possible (since in Cloudron, you cannot change the username, we don't have a problem).
@d19dotca Sadly, they do match. I'm guessing it's something with my current setup that's acting funny. I'll ignore it for now since I plan on migrating either to the new Contabo server that I got or upgrading my current one at DO to Ubuntu 20.04. I just thought it was a wrong setting on my part.
Thank you for looking into this and for sharing the custom spam rules! I know you've put a lot of time into that 👍
@mastadamus right, the spamlists won't work if those lookups get blocked. Currently, if the lookups fail, the mail server will simply go ahead and try to detect spam via spamassassin. It's just one of the metrics for spam detection. I guess it's fine if it's working OK for you without it .
@d19dotca Yes, I think you're right, thank you.
I need to look into that.
Or move some long term storage files ("archive") into Minio.
That might just be moving the problem, but dividing the problem might be a partial solution.
@derin If email works, you can just click Reset password in the login page and you will get an email with the reset link. If email is wrong or does not work, you can SSH into the server and run cloudron-support --admin-login. This will give you a one time use password (will also print the username to use). You can then go to Profile and change the password. Note that you have to run the command again to get a new password when changing the password.
@garyhost did you get this sorted out ? I guess the box code is/was down. You can figure using systemctl status box. And if it is indeed down, please check /home/yellowtent/platformdata/logs/box.log. You can also check if you have enough disk space because this is a common source of the box code being down.
@rmdes yes, I am not sure why. It doesn't happen in any of our demo servers or managed services. Quite strange. It could also be that maybe others have hit it but have not noticed it (since it only causes a CPU spike..) but clearly it's a bug since it's been fixed upstream.