Cloudron Forum

@ccfu said:

You need to set the reverse IP (PTR) in your VPS provider's network settings and make sure the IPv6 resolves to the mailserver address.

Thanks! It turns out that an IPv6 address is included with my VPS, but it wasn't assigned. Hosting support provided me an address, and now that it's added to Cloudron and a PTR record was set, I have all green checks under email status.

Hopefully this will resolve the DMARC rejections.

Thanks to all for your help.

@james said in Restore one app's backup to another existing app?:

Yes, you first have to either move the destination to a different location e.g. from www.DOMAIN.TLD to www-old.DOMAIN.TLD (save route) or just deleted the destination.

Thanks for that, I didn't consider just changing the subdomain of the main site to move it. I suspect that might leave me with Wordpress database errors, but I guess that wouldn't matter so much.

Ultimately I cloned Main to a new subdomain, and since that clone worked without any issues, I went ahead and deleted the original and cloned staging to the bare domain. I was hoping to minimize downtime by overwriting directly to Main, but honestly the deletion and cloning was so fast it wasn't an issue.

@robi said in Restore one app's backup to another existing app?:

Another option would be to export the WP site using a plugin, and import it into a fresh WP install w/o all the dev/staging cruft (unless you need it for some reason).

You can search the forum for "how to move wordpress" for more information.

I've certainly done it that way before, but I was hoping to avoid extra steps this time and let Cloudron do it. I'm happy to not have to find and replace "staging.domain.tld" with a plugin like I've done on past migrations.

I've used All-in-one WP Migration previously, and it was mostly fine other than the above issue with the database. It was fairly complete and I think any of my staging "cruft" would have been exported and imported. I'm curious to know what plugin you prefer? I'll put it on my list for next time.

I did search the forum of course, but most results are about migrating to a Cloudron app from elsewhere.

@Beardmancer said in Failed backups and email config issue since 8.0.3 upgrade:

I decided to go ahead and try adding this to /etc/systemd/resolved.conf since it's easy enough to comment out.

DNS=8.8.8.8 1.1.1.1

After doing that and restarting the service with systemctl restart systemd-resolved, things seem to be working correctly. The file /etc/resolv.conf lists nameservers now and a manually-initiated backup just completed successfully. Thanks for the hlep @nebulon !

In the future, is there anything I should look out for to avoid this? I don't know what caused it. Maybe it was the 8.0.3 upgrade, or maybe it was an Ubuntu update? I think I rebooted Cloudron for the latter recently. If there's a configuration I might have setup wrong, I'd love to correct it.

Description

My Cloudron server recently updated to 9.0.13, so I heeded the expected Ubuntu 22.04 notice and decided to upgrade. I've been successful with every step but one.

When I run the command systemctl status collectd, it shows that collectd is "inactive (dead)". This persists after a system reboot.

Everything is working as far as I can tell. Should I ignore this, or should I do something to make collectd active? Based on cloudron-support --troubleshoot results below, maybe it's an issue with IPv6? That is currently over my head.

Troubleshooting Already Performed

I've restarted the server a few times with no change in behavior. I'm not sure what else to do.

System Details

Cloudron Version

{
  "version": "9.0.13"
}

Ubuntu Version

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:      jammy

Cloudron installation method

Manual with ./cloudron-setup

Output of cloudron-support --troubleshoot

Vendor: Red Hat Product: KW
Linux: 5.15.0-161-generic
Ubuntu: Jemmy 22.04
Processor' Intel(R) Xeon(R) CPU E5-2695 v4 H 2.10GHz x 4
RAM: 4005200KB
Disk: /dev/vda2 59G
[OK] node version is correct
[FAIL] Server has an IPv6 address but api.cloudron.io is unreachable via IPv6 (ping6 -q -c 1 api.cloudron.io) Instead of disabling IPv6 globally, you can disable it at an interface level. sysctl -w net.ipv6.conf.ethO.disable_ipv6=1
For the above configuration to persist across reboots, you have to add below to /etc/syscti.conf net.ipv6.conf.ethO.disable_ipv6=1 

@necrevistonnezr @joseph Ah, got it, thank you for clarifying.

For what it's worth, I was following the upgrade guide for Ubuntu 22.04 (https://docs.cloudron.io/guides/upgrade-ubuntu-22/) which indicates that it should be active. Probably a decent number of people will follow the same trail I did: Cloudron updates to 9.x --> Notification about 20.04 EOL --> Follow 22.04 upgrade guide. If none of these folks need to worry about the collectd step, it might be worth adding a note in the 22.04 guide. The 24.04 guide also mentions collectd.

While it's fresh in my mind and I'm looking at it, is there any reason I should or shouldn't go ahead and upgrade to 24.04?

@james Also, I just used ip -f inet6 -br addr to check for IPv6 addresses and it provided eth0 and another entry starting with br- that has a longer name. I tried setting the IPv6 Setting to Network Interface > eth0, which does successfully detect the address. However, that leaves an error for the PTR6 record under Email status:

@james Thanks for showing me how to us mxtoolbox! I see that I needed to us :cloudron instead of the default :email in my search string.

Under Cloudron > Network, I tried changing IPv6 from "Disabled" to "Public IP" to match the IPv4 setting. However, it doesn't detect an address (see screenshot) and the IPv6 statuses under Email are now red alerts.

I've raised a ticket with my VPS provider (CloudFanatic) to see what they have to say, but is there anything else I can try in the mean time?