Cloudron Forum

@SansGuidon thanks, fixed in https://git.cloudron.io/platform/box/-/commit/e45af9b611f4d0c3b77d4329aac24bacf98e4e6c . I could not figure out why it's not reproducible on that old Cloudron but I can reproduce it everywhere else . Maybe some Ubuntu 20.04 quirk .

@SansGuidon What is your ubuntu and docker version?

That Cloudron is on Ubuntu 20.04 and docker 27.3.1 . Here it's not reproducible.

My test cloudron is on 24.04 and docker 28.1.1 (it's from dev branch). Here it's reproducible.

@SansGuidon thanks for the repro. I have to say I can easily reproduce not only your test but also uptime kuma backup issue on my test Cloudron. At the same time, I have verified that @joseph's observation is also correct - our prod uptime kuma does not produce any spurious logs. Wonder what is going on... I am debugging.

@Latinosnctv I think this involves running a forked version of mattermost. I think this is beyond our product's reach. We don't maintain patches and feature sets over upstream apps - unless there is some major security issue and that too only as a short term measure.

If you (or someone) has resource, please fork away our package - https://git.cloudron.io/packages/mattermost-app/ . Just have to point it to the upstream fork and build it yourself.

@jrl-abstract27 upstream Ghost runs an activity pub service that selfhosters can use (with limits) - https://docs.ghost.org/hosting#hosted-activitypub-usage-limits . AFAIK, it does not take any more storage.

@timconsidine yes, it was struggling a bit. I restarted it (I guess around the time of your post).

@gdeflaux Can you check with the latest package? The latest one has sockpuppetbrowser which supposedly fixes the problem.

ActivityPub integration should work in the latest package.

The latest package uses ap.ghost.org as the ActivityPub service. It has some service limits per https://docs.ghost.org/hosting#hosted-activitypub-usage-limits :

• Maximum 2,000 followers
• Maximum 2,000 following
• Maximum 100 interactions per day (interactions include posts/notes, replies, likes, and reposts)

@vladimir.d actually managed to get a selfhosted AP (ActivityPub) server working as well. But the AP server requires it's own database/redis, among other things. This makes quite a complicated setup. Maybe we will package AP as a separate app package (a single AP server can also handle multiple ghost instances).

@andreasdueren thanks, I have added it to @vladimir.d 's list but he also has a big backlog .

@imc67 max port is 65535 so it can't be 70000 . A package cannot change the port ranges (just like it cannot change the installated domain names) . But for new installation, it will recommend 20000 instead . I have also fixed up the sfu package, will be published shortly .

There's a final round of UI testing going on (https://git.cloudron.io/platform/box/-/issues/847)

@imc67 some blind guess here. I think what's happening is that something in box side (maybe backups code) is occupying that port 41000. This is in turn blocking the containers from using that port.

Digging deeper, this seems possible. The ephemeral port range is

$ cat /proc/sys/net/ipv4/ip_local_port_range
32768	60999

So, 40000 is not a good choice for a container to listen to. @imc67 a quick fix for you is to change sftpgo to use some other port which is outside the 32768-60999 range. In the meantime, I will fix the package to default to some port range outside the ephemeral port range.

I think it would be nice to also warn people when try to run containers in ephemeral port ranges. I will put a note in the docs for a start. @james what do you think?

@matix131997 were you also using rsync ? Which backup provider? "If the provider storage had blocked such files" is particularly interesting to me. Are there providers that block specific filenames from being uploaded?

In @jamie.mckenzie 's case, I found that many files are missing. Unfortunately, it's hard to know where exactly the problem is. There are many things at play - Wasabi (which often has errors), WP Developer (where plugins can delete and change files), Backups have been failing for a while (on that specific Cloudron), Cloudron Backup code having some bug .

As mentioned in another thread, we have added integrity check to the backup logic now for the coming release. With that, we can know for sure what files were actually uploaded to the storage. And if it's the mistake of the storage provider or cloudron code that files are missing.

As a follow up: the issue here was that the current OIDC module we use has a bug that Interaction.json keeps growing in size. This happens because the Interaction tokens are not cleaned up . The fix is to simply delete the file rm /home/yellowtent/platformdata/oidc/Interaction.json . The issue is fixed in Cloudron 9 (because the node oidc module was upgraded).

Given the confidential nature of this, please write to us at support@cloudron.io if they need some information on our side.

@jamie.mckenzie that does not seem correct. There must be a wp-config.php inside data .

I sent you a mail from support@ since there are more questions that I need answered which are probably sensitive.

@BetaBreak I wrote to you from support@

Support for OCSP was removed here - https://forum.cloudron.io/topic/14265/how-to-disable-ocsp-stapling/5 . OCSP is being deprecated in favor of CRLs

Fixed here - https://git.cloudron.io/platform/box/-/commit/ac7001b96e176e540ede9bb81e3fcb17ae7f6416