Cloudron Forum

I've been having the same issue with S3, switched to DO Spaces now because it's easier to monitor. I had terabytes of data in my S3 bucket and only noticed it once I got my bill. With DO Spaces it's now the same issue, there's still backups from three days in there despite a 2 day retention policy.

@jdaviescoates Thank you! Apparently it was one of my plugins, but they needed to be deactivated manually, simply renaming the folder didn't work. I guess I'm gonna do that with my other installs now and see which one it is there that breaks the site.

I tried updating two of my Wordpress installs to the latest package (v3.0.0), and it results in a critical, not very verbose, error message.

"There has been a critical error on this website.

Learn more about troubleshooting WordPress."

I tried renaming the entire plugins folder while in recovery mode, in order to find out whether it's a specific plugin, but the result is the same.

Any ideas what might be going on here?

I second this. Would be great to use this as a Goodreads alternative.

@girish said in IPv6 for Mastodon - how?:

@stormgrass This one - https://docs.digitalocean.com/products/networking/ipv6/how-to/enable/#on-existing-droplets . Did you do this?

Ah, no, that point I missed. Am trying to fix it now, but the yaml indicated in the doc doesn't exist. So, I've created it and get hit with a syntax error, even though it's a copy of the contents specified.

Anyway, I'll keep investigating, but I think you can mark this as resolved now. Thank you!

@girish I actually tried using "Public IP" first, but I always get this error message when I do that:

Unable to detect IPv6. API server (ipv6.api.cloudron.io) unreachable

One thing is, can you check if you can curl -6 https://my.domain.com works? If that doesn't work, there is some other issue at the server/network level.

That actually produces an error message as well:

curl: (7) Failed to connect to my.stormgrass.com port 443: Network is unreachable

You can also check curl --connect-timeout 10 -v6 https://social.cloudron.io/@cloudron which our mastodon instance with IPv6.

This too:

Trying 2001:19f0:5001:64e:5400:2ff:fee8:d17b:443...
* connect to 2001:19f0:5001:64e:5400:2ff:fee8:d17b port 443 failed: Network is unreachable
* Failed to connect to social.cloudron.io port 443: Network is unreachable
* Closing connection 0
curl: (7) Failed to connect to social.cloudron.io port 443: Network is unreachable

So, does that mean I have both a misconfigured Cloudron droplet AND my machine doesn't have proper IPv6 connectivity (as @mehdi suggested)?

Not even sure any more where all the potential fault-lines are haha

(Also: @mehdi: yeah, trying to obfuscate something that's easily found out via the exact same command I pasted wasn't exactly my proudest moment haha)

The issue

I'm trying to make my Mastodon instance reachable via IPv6 (and, but that might be a Mastodon and not Cloudron-related issue, allow it to add accounts on IPv6-only servers).

What did I do?

I've created an IPv6 address for my Cloudron droplet on Digital Ocean, added that address as a static IP to Cloudron via the Networking section, and then ran a full DNS sync, letting Cloudron write the AAAA records to my Digital Ocean DNS records.

I then tried connecting to my instance via curl, like so:

curl --connect-timeout 10 -v6 https://hemmer.land/@GeschichteFM

But receive this error message (address is obfuscated):

connect to X::X::X::X::X port 443 failed: Network is unreachable
* Failed to connect to hemmer.land port 443: Network is unreachable
* Closing connection 0
curl: (7) Failed to connect to hemmer.land port 443: Network is unreachable

I've also tried adding an IPv6 to Cloudron by using the Network Interface option, which generated another address than the one I got from Digital Ocean via their interface. I then tested via curl again, which generated a different error message:

Immediate connect fail for X::X::X::X::X Invalid argument
* Closing connection 0

The questions

• Seeing how both produce different results in my DNS records: is adding the DO-issued address into Cloudron as a static IP the correct course of action, or should I be using the Network Interface instead?
• Once the correct address is in my DNS records, do I need to do anything else, like change any settings in the Mastodon .env settings?

Thanks in advance,
Richard

@girish Thank you, that did the trick! Not entirely sure how and why my install looked the way it did. I think I installed it first thing once it showed up in the app store, but back then it was still marked as unstable. Anyway, it's all good now, thank you!

@girish I checked .env.production, but it doesn't have the Service Dependencies as posted by you. I do, however, get the kind of result you posted when querying env for REDIS.

My Cloudron is version 7.1.4, my Mastodon package is version 2.8.4, though (weirdly, the last update was "years ago").

EDIT: I DO have the service dependencies lines in .env.production, but not grouped in that order, under that heading, and the REDIS_PASSWORD variable has no value.

EDIT2: Just noticed that apparently my package is really outdated, as the current one when installing it from scratch is 3.4.6. Which is weird, because I've always had it set to automatically update, and when manually trying to update, there doesn't seem to be a newer package. Is there a way to update my current install to the latest version without completely wiping it?

@girish Thank you! It was, the solution in your linked thread fixed it.

Hello,
it seems my Mastodon installation is having trouble with its Redis connection.
Opening up the site I'm greeted by an error message ( "We're sorry, but something went wrong on our end.")
I checked the log, which immediately fills with this error message:

ERR! Error: Redis connection to localhost:6379 failed - connect ECONNREFUSED 127.0.0.1:6379

I restarted the whole app, which didn't do anything.
I also restarted the Mastodon Redis from the Cloudron backend, same result.

The apphealthmonitor says 17 alive / 3 dead (the two additional dead services seem to be my two LAMP boxes, which for some reason won't restart properly - could be related?)

Any idea what might be going on?

Thanks in advance,
Richard

@girish Thanks so much!

Hello!

I'm trying to get the Feedreader desktop app for Linux to work with Tiny Tiny RSS. The thing is, Feedreader needs an additional plugin to augment the API, and needs it to be registered as a system plugin. System plugins need to be activated via the config.php, though and as the config.php is in /app/code/ I can't edit it.
I tried turning the plugin into a non-system plugin, and then activating it, but the Feedreader app doesn't seem to recognize the plugin as activated in that case.

What are my options here?

Thanks in advance,
Richard

@girish Thanks a lot for your reply. I wasn't aware that the LAMP/Surfer apps don't count towards the total app count. That's great news!

Hello! I've discussed this before in the chat, and would just like to start a discussion around that topic again. I'm currently using Cloudron to run a few websites on different domains. In order to make www.example.com work for websites that run at example.com, I've set up LAMP apps for each of those, then have a redirect inside those redirecting to the naked domain. This is currently the only workaround to not get an SSL warning when accessing the www.example.com address.

My plan is the basic one, and from the pricing table I see that it's capped at 20 apps. I'm currently still under 20, but I'm guessing that sooner or later I might go over 20, at which time I need to think about how to deal with the fact that I'm basically running an additional app for every extra domain I've attached to my Cloudron.

Now, what are the chances that at some point, when setting up an app, we will have the ability to simply add a subdomain like www to redirect to the actual naked domain, without having to work around this by setting up a separate LAMP app? That would make both the setup easier and lower the number of used apps on the Cloudron.