Cloudron Forum

@osobo the power of the forum, thanks are due to @jdaviescoates and all those who went before on this issue.

@joseph said in Frequent Email is not configured properly notice: Maybe DNS is periodically failing on your servers. Do you know which DNS servers your server is using? You can use resolvectl to figure this. Thanks for the explanation! my DNS servers are : Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 9.9.9.9

@jdaviescoates said in Cloudron services are slow: @nebulon @KhalilZammeli said in Cloudron services are slow: update of the screenshot for our wordpress service, very high CPU usage, how can we investigate these ? Given the above and the fact WordPress uses mysql (and is very often attacked as it's so widely used, and malicious plugins are also quite common) that seem to me to be the obvious first app to investigate. Absolutely! Most of the time a WP plugin is the culprit. A WP plugin that's been acquired through a 'friend' which is not the original developer. Extremely, dangerous these are compromised in 99% of the times.

@senthilkumaran said in Cloudron Subdomain pointing to a different IP for Apps not on Cloudron: https://i.imgur.com/3gtJVw1.png - wildcard means that all the *.thinnal.org will point to the cloudron's ip. If you have *.domain.org and foo.domain.org entries in your DNS provider , then foo.domain.org being more specific wins. One crucial note: this is not a feature of DNS since DNS protocol itself no concept of wildcard. This feature comes from the DNS providers (I think this comes from bind9 configuration files). But interestingly, I have the root domain thinnal.org pointing to a different IP and it works fine. Yes! because *.domain.org does not include domain.org . It only includes subdomains of domain.org but not the bare domain itself. This is another important DNS quirk to know.

@SunDevil I'll keep sharing... I've tried Nextcloud on several different platforms, including JUST Nextcloud. It ALWAYS conks out on me. Always. So, my 2 cents, you'll have the same issue on Dokploy. EDIT: Have you even checked out Dokploy??? I just watched their intro video. They install their software on your VPS from their servers! What?? Sorry, I'm not letting some third party have that access to my data. You create your ssh key on their system!!! You have to create a db separate from your app!!! Good luck keeping track of all those deets. Holy smokes, the number of steps needed to get this thing running is exactly why most of us have come to Cloudron. This Dokploy is so at the opposite spectrum of Cloudron. I can't imagine anyone thinking it will be "better".

If the system runs out of disk space, a lot of side-effects can happen, so this could very well be the root cause then.

Ok, it seemed running the /home/yellowtent/box/setup/start.sh to trigger the migration after restoring the database (because of the ERROR 1046 (3D000) at line 22: No database selected i needed to add these two lines to the dump file: CREATE DATABASE box; USE box; Then it was able to backup the database and run the migration.

Thank you @nebulon ... it's awesome timing , thanks for the share! I guess that should be considered a solved problem for the future then.

Right so we have a bunch of similar topics referencing the same problem. https://forum.cloudron.io/topic/13162/unable-to-send-emails-to-gmail https://forum.cloudron.io/topic/13145/problems-with-sending-mail https://forum.cloudron.io/topic/13122/email-sending-broken-after-updating-to-8-2-x-due-to-ipv6-issues https://forum.cloudron.io/topic/13072/gmail-ipv6-anyone-else-with-this-experience Should they all be merged and/or marked as solved? The solution is provided by @girish (here) and @jdaviescoates (here) which I'll compile and summarise here again: Activate IPv6 on Cloudron via going to Network > IPv6 > Configure > Public IP Check your IPv6 address either via reading the IPv6 address detected by Cloudron when doing 1. or via running curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip on your server (via ssh). Set an IPv6 PTR record on your VPS/server provider (not your domain provider) for the above IPv6 address. The next Cloudron release will implement a check on IPv6 PTR record like it currently does for IPv4. If using Wildcard DNS then create a * AAAA record for the above IPv6 address. If things still don't work, you can go to Cloudron -> Domains -> hit Sync DNS If your VPS provider does not allow you to set IPv6 PTR, then disable IPv6 that way: disable IPv6 in Cloudron (Network -> IPv6 -> Disable) on your server via ssh run sysctl -w net.ipv6.conf.ens18.disable_ipv6=1 (replacing ens18 for your specific network interface, in my case eth0) make it persistent by adding net.ipv6.conf.ens18.disable_ipv6=1 to /etc/sysctl.conf (replacing ens18 for your specific network interface, in my case eth0) Update: I personally still faced issues with Gmail using IPv6 so I ended up disabling it persistently.

I followed the instructions, now the child sites work but the main network site isn't,

You have to install nginx and put those configs on the server where you deployed odoo . That is the correct place for putting those multiple port configs. Then nginx will then answer to a single port 80 which you can then put into cloudron.

Looks like this part does fix it (instructions for root server): [image: 1737492462373-9fbbe904-6e2e-4deb-8d7d-5d2812a54c83-image.png] Thanks to you both for the pointers!

I have added the provider by now https://git.cloudron.io/platform/box/-/blob/master/dashboard/public/js/setup.js?ref_type=heads#L71

Thanks for the information

A homemade problem. We have refactored our Ansible role. It has installed an MTA that was previously started as Cloudron's mail service. After uninstalling the MTA, everything works as expected.

Sorry, i should have checked that first. Downgrading CF proxy to DNS only does seem to fix the issue for me. Thanks @nebulon.

@luckow give postgresql more memory

Apologies, I continued investigating and going through logs with some Claude help and managed to work out that it was simply down to me adding a Private Docker Registry. It hadn't occurred to me that that would then override existing apps. This is now resolved.

Not sure which nameserver provider you are using, but I remember that back in the day it was possible to screw up the zonefile, rendering all DNS records broken. But generally try to put the TXT record back and then just try to resolve the dashboard domain using your nameserver explicitly (to avoid caching). This should work, if not, please contact your nameserver provider about that.

@firmansi said in Issue with New Installation with Cloudron 8.0.0: @girish I don't activate IPV 6, i have bad experience with this Just to say, it seems going forward you'll likely hit email deliverability issues without IPv6 stuff being configured (especially to M$/ Gmail accounts). See e.g. https://forum.cloudron.io/topic/13145/problems-with-sending-mail