Cloudron Forum

Hello @mononym Good thing we have already created the matrix auth service as an app. But I am not 100% sure if this migration tool will work since it is specific for the ESS Community version. Will need to test this.

Hello @robi @robi said: Is there a way through the CLI? Currently, no.

Hello @tobiasb Good suggestion. I ask myself, is the manifest the correct singular location for this config? Maybe we set the initial value via the manifest but also allow a custom value in the service overview from the dashboard. But at least adding this to the manifest should be doable.

Can you extract the blocklists from Wordfence to have it populate the Cloudron deny list?

Thanks for reporting, work item is https://git.cloudron.io/apps/contacts/-/work_items/18

@teiluj Thanks for creating this app wish. I was just setting up a local container to play around with this app and it's promising. Would be worth looking into @girish

Worth verifying directly whether the issue is on Exoscale's end or something in the Cloudron configuration. The "code: undefined message: HTTP: undefined" error pattern specifically means the HTTP request to S3 is not completing at all - it's not getting a 4xx/5xx response from the server, it's getting no response or a connection-level failure. A quick test from the Cloudron host itself would help clarify. Install s3cmd and test bucket listing directly: s3cmd --host=sos-ch-gva-2.exo.io --host-bucket="%(bucket)s.sos-ch-gva-2.exo.io" ls s3://<your-bucket>/ If that also fails with a connection error, it confirms the issue is network-level between your Cloudron server and the Exoscale endpoint. Possible causes: DNS resolution failure for the S3 endpoint hostname A firewall change on your host or at Exoscale Their S3 service still not fully recovered in your region Check if the hostname resolves: dig sos-ch-gva-2.exo.io And test basic TCP connectivity: nc -zv sos-ch-gva-2.exo.io 443 If both resolve and connect fine, the problem is likely still at the API level on Exoscale's side. In that case, triggering a manual backup from the Cloudron dashboard and watching the logs in real-time will give you the full error chain: journalctl -fu box.service If you need backups running today and Exoscale isn't cooperating, you can temporarily point the backup endpoint at a different S3-compatible service (Backblaze B2, Wasabi, etc.) to confirm your Cloudron setup itself is fine. That also rules out whether the issue is specifically with Exoscale or something in the Cloudron backup configuration.

I have put in a fix now to adjust the java heap memory dynamically. Hopefully that works.

@da5nsy sent you an invite

@ruihildt so we didn't announce that yet but it is already in the normal app library published as unstable for testing. It is just called "Calendar"

@robi @jdaviescoates i deleted the user

@girish agreed, all their posts look decidedly like "give me an upvote for this innocent looking post so I can come back and post spam links"