@nebulon Thanks, this was the reason for my problem. After I uncheck "mounted filesystem" Cloudron was updated to 5.4.1

@imc67 I made https://git.cloudron.io/cloudron/box/-/issues/717 for keeping mail backups separately from the box backups.

@marcusquinn Thanks for the info!

Correct. We don't need to re-create container to change the memory limit. But we still need to restart it after adjusting memory limit because of the limitations in our packaging. I think over time we have learnt that it is not a good idea to setup apache to auto-scale based on container memory limit. Those things are very dependent on the app/plugin use. I think java apps require a restart at this point since the JVM gets passed in the heap memory as a flag on startup, maybe there is a workaround for this as well, have to investigate. But at that point, we can atleast make the memory limit code not re-create container which I think is where bulk of the slowness is.

As @scooke and @mehdi already mentioned, the sole reason to support only one distribution is the reduced complexity by having to deal with only a single well known system. Even different ubuntu versions require quite a lot of testing and different code. Sometimes package names change for example. We essentially just settled on Ubuntu 16.04 initially since that was available on basically every VPS provider. Really that is the main concern for us. Naturally for security updates we then progressed to 18.04 and will soon hopefully support 20.04. Other distros with even other package managers are simply just overhead and cause trouble to users. In the end from what Cloudron requires, there will hardly be any noticeable difference in speed or resources use between any of the distros, so we lean towards stability here.

Thank you everyone for the clear explanations as always.

@ultraviolet Glad I could help...

@HulaCloud We don't have plans to support netdata out of the box but I think it's a good idea to atleast have some interoperability instructions. Let me give this a try and get back.

Yes that should work.

Thanks, Girish, That patch worked. I've successfully setup things. cheers Mark

Thanks for the response, @girish. I'm going to email B2 and see what they say, I'll report back with results!

This appears to be someone/bot trying out common usernames in one of your apps. Unfortunately this is not too uncommon, but also not an a real issue if you have strong passwords. The requests will be rate-limited as well to prevent proper brute-force attacks. The internal IP is associated to an app, it may or may not change when an app is restarted. However the ldap logs might indicate there are multiple apps configured to use LDAP. The port is actually dynamic per request, so that is the reason why it does not show in docker ps/inspect

Ok I gotcha myself because anyway I create my own pain so from what I understand to being able to restore Cloudron verify the DNS first than app/data I forgot to authorize my new IP in my Cloudflare API code 9109 is probably related to the fact it was unable to edit the DNS.

@girish This is an interesting observation. I was just looking to see if this was a real security threat or not, and I suppose it isn't but can offer a bit more privacy using the wildcard approach. Any particular reason why the Let's Encrypt wildcard support can't be done through the actual Cloudron wildcard DNS approach? Is there a way to support this? I'd really like to take advantage of a smaller DNS provider which has some great monitoring features included, but it isn't supported via any API by Cloudron yet, so if I go that route I can only use the Wildcard option, but those don't actually allow for the wildcard certificates. Edit: Nevermind, I see why in the docs: "Let's Encrypt only allows obtaining wildcard certificates using DNS automation. Cloudron will default to obtaining wildcard certificates when using one of the programmatic DNS API providers."

Cloudron won't refresh DNS entries automatically unless some action is performed like app configure etc or the Dynamic DNS feature is enabled. Generally, if you go to network view and put in the local IP, you don't have to worry about those automatic actions as well.

@woke If you don't mind, I would like to debug further if possible and fix up the docs as needed. Can you enable SSH support and send a mail to support@cloudron.io with the IP address? Thanks

@d19dotca So far things seem to be fine, didn't get the issue yesterday at all, and so far nothing today neither.

@mario no problem

@nebulon Sounds good. It's just that eventually I'm going to register a domain on infomaniak and use their web mail services. My current email address is temporary. I just want to make sure I have that option, before I build my castle.