This is marked as solved but doesn't actually appear to be @girish @nebulon

@austinsonger Is the server also hosted in Azure? PTR records are not part of your DNS zone. They should instead be set from wherever your server is hosted (i.e whoever owns the IP address of the server) It seem Azure does not have a UI to set PTR records but you have to use the CLI - https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services . What you are trying to do is https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-hosting I think, this is not what we want. Quite confusing from Azure. Tagging @derek since he knows Azure stuff.

@girish That would be ideal! In fact if that can come in the next couple of months, I'll hold off my own DNS change until that's there. Because the whole "my." doesn't really conform to the standards that people expect when they need to enter in their server names for a mail server. I'd definitely love if Cloudron could use it's own "mail" subdomain and it's own certificate for the mail server portion so that I can still have clients connect to mail.<domain>.<tld> without impact since that's what I have told a dozen or so to do already over the last 1.5 years. And no, the decision wasn't anything to do with Cloudron or DigitalOcean really. My main reason for the move away from DigitalOcean isn't anything to do with Cloudron or DigitalOcean. If you're curious... the decision was mostly for two reasons: A movement from both myself and my clients to keep everything (as much as possible) in Canada. And my current DNS provider (LunaNode) has their infrastructure in Canada only (well France too, I believe). It's one of those "shop local" sort of things. The DNS provider I currently use has a great feature that I can take advantage of in the future when running a secondary Cloudron server as a mirror image of the first one (waiting for that clustering capabilities in the future, hint hint haha). The advantage is that they have monitoring tools I can use, and based on those monitoring tools they can automatically update DNS records to the other IP address if monitoring detects one of the servers as "down" for whatever reason. To me this is like the health checks in load balancing, but I don't have to pay for load balancing with this solution. I see this as a further advantage to using LunaNode for the DNS management. So yeah, nothing to do with Cloudron or DigitalOcean really, so no worries there. Just a decision made for various reasons (the biggest two above, but also a bit of my own OCD and others haha). I will keep my primary domain on DigitalOcean then for now if you think the SSL cert for the mail subdomain would arrive in the next couple of months. Because I think that's a fantastic idea, and I think that was something I mentioned or questioned back when I started using Cloudron because I was so surprised that it had to be "my." as that's not something that conforms to the standards of mail server hostnames, and I wanted to keep things more standard for my clients to avoid having to explain non-standard implementations. I say standard loosely here as I realize there's no official standard, but it's more a de-facto one that mail. is the subdomain to use, or imap., etc. Hope that helps.

@girish This is intentional because the root domain record can be in use on another server/app/website. Right, that makes sense. I added a redirect from the root domain and it solved all my problems. Thanks for the quick help.

@nebulon Big fan of Dark Mode, thanks for your work to add it!

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