Cloudron Forum

@joseph No idea how, all I did was to take a break from this to cook dinner, but now it works.

Yes, and since Cloudron pass that test I thought I had manage to do that the right way.

But when I used MX Toolsbox to double-check, I realized that Cloudron asked to enter my.domain.tld. Should it be just domain.tld?

Ah, I see. Can't find a way to disable IPv6 for the server, so tried to other route: Getting IPv6 configured instead.

The PTR6 passes the test now, but still SPF failure for the IPv6 address.

I'm using wildcard dns and have added AAAA records for *.domain.tld and domain.tld using the identified IPV6 address.

Hi!

This goes beyond my comprehension. I switch from an external SMTP server to use Cloudrons internal. All checks pass, and as you can see, IPv6 is disabled in Cloudron.

Yet the server I try to send a testmail to rejects, saying that the SPF check for my VPS' IPv6 address didn't pass.

What is happening here? And how can it be solved?

@joseph That's right! I thought that was the easiest way to increase the deliverability of emails sent from my Cloudron server. But apparently my understanding of DNS is lacking.

I checked my VPS' ip address and it's not in any blacklists, so switching to the internal SMTP server.

That is where I expected it, but they are not to be found there.

Hi!

Where do I find the DKIM and SPF settings when using Wildcard DNS?

Thanks!

Hi!

Would it be possible to add the AI starter pack as a Cloudron app?

Hmm. I understood the docs like it was a thing in the hosting firms routers. That makes it even more strange, since my router is the same before, during, and after I had this problem.

Hi!

For a couple of hours now, both the Cloudron admin interface and the email services have been unavailable for me, but all apps seems to be running just fine.

Just before this happened, I was trying to add some changes to the DNS for the same domain name as I use for my Cloudron to solve some mail delivery problems.

When I ran

cloudron-support --troubleshoot

and got an error message about Hairpin NAT not working and that the admin domain could not be loaded.

So I went into my registrars DNS configuration and removed the TXT entry I had added for my.<cloudron.domain>, even though I couldn't understand why that would have an impact on the admin interface or email services.

But when I did, both admin interface and email became accessible again. Good. But I still get the Hairpin DNS error and FAIL for loading dashboard admin when troubleshooting from my servers terminal.

Can someone explain what's going on here?

1. How could SPF records have an impact on the services?
2. And how could they become available again, yet cloudron-support claming there is a problem with Hairpin NAT?

So it's IPv6 entries that are handled by Oderland, but Cloudron takes care of the IPv4?

Ah, I see! Thanks!

But I also noticed that it worked if I disabled IPv6 even for the primary domain. Why is that?

Hmm, your terminal command got me thinking: I'm trying to install apps under my Cloudron's primary domain. For primary.tld I've AAAA records configured at my registrar. I thought that Cloudron managed the AAAA records for any subdomains thanks to this setup? But should I add the AAAA record for linkwarden.primary.tld at my registrar as well?

I haven't done that for any of the already working apps, and they run as expected.

It's a Swedish one, Oderland, configured using the Wildcard option. And yes, dns1/2/3.oderland.com all have the AAAA record.

Hi!

I recently moved my Cloudron-installation to a new VPS at Netcup, and after the migration new apps can't be installed anymore.

I get this error for all apps I try:

But as far as I can tell, I've the AAAA record for the domain configured the right way at my registrar:

The IPv6 address is copied from the Network Settings in Cloudron.

What's causing this problem?

Switched to tarball, and it made a huge difference!

I use Netcup as my host, in one of their datacenters in Germany, and do my backups to Wasabi, also in Germany, using rsync. Even though my Cloudron installation is only 40 GB, backups take at least 6 hours. Six apps installed: Mastodon, Ghost, Adguard, FreshRSS, Uptime Kuma, and Umami. Guess the reason is a bunch of small files.

I went with rsync for incremental backups at less storage space. But I am starting to reconsider that, and perhaps switch to tarball.

What backup strategies do everyone else have?

Ah, that make sense. So then I better select Dry run to not have any internal checks fail, change DNS manually, and after that are good to go? The Sync DNS wont work either for Wildcard DNS?

Hi!

I'm in the process of migrating from one VPS to another, and while waiting for the backup of my old installation finish I read through the docs once more and realized that there is one thing I don't understand: What does "Dry run" do?

I get that this is a feature that let me test my Cloudron on the new server before pointing the DNS to it. What I wonder is more like how Cloudron can make those changes in the first place?

I'm using the Wildcard configuration, and in the settings at my registrar point the A records to the IP address of my current VPS. How could Cloudron change those settings if I don't check the Dry run option?

What am I missing?

Hi!

The media cache of my Mastodon installation is growing to big for my VPS. I'm considering moving the media storage to S3 instead of upgrading to a larger VPS. But I can't find any instructions on how to migrate the existing local files (that is the ones me and the other users on my instance has uploaded) to S3. Anyone who has made this and can share how?