Cloudron Forum

The addmount.sh script is really just an internal helper script and should be treated as internal code. It is only tested with the output of the filled templated of https://git.cloudron.io/platform/box/-/blob/master/src/systemd-mount.ejs?ref_type=heads

What is your intention to use the script directly? The argument passing to the script as well as the templates may or may not change with any release, since it is not treated as some kind of API.

I think if there is something to be solved here it is likely somewhere else in the issue you are hitting.

EXT4 and XFS are basically treated the same way from Cloudron side, so there is no difference in that aspect.

Just to be on the same page, you are still using the same configs sshfs (rsync with hardlinks) as before but only the remote is now not hetzner storage box anymore, but your own server with some disks mounted?

If this is the case, then there is no difference at all from a Cloudron perspective. Maybe the disk I/O is just not as fast in your setup as with hetzner?

Hard to say how those actions are connected to resolve it, but glad it worked out in the end!

Can you run cloudron-support --troubleshoot via SSH on your server? It should suggest a fix.

Thanks for that input. I think what we really need to add is a way to run apps as headless services. We already have a few of those like game servers and synapse (matrix) which have to serve up a placeholder page. That is not ideal indeed. After Cloudron 9 we will also look into other things like maybe databases, they would have very similar requirements then.

Sorry that this is not yet implemented but we will get there in the future, so it is already great to collect requirements for such service type apps like prosody. This helps to avoid developing the wrong things on the platform side

We are currently quite busy with Cloudron 9 development, lets see if we can get some of those things still in.

After reading up a bit on prosody docs, I still dont fully understand what we should do with the default location and what we could serve up as http (currently it shows a 404 error page for example). I saw there is also BOSH which is intended for http, so maybe that can be placed there instead, but so far I don't have a good grip on prosody's use of domains, certs and ports.

On digitalocean you have to also expand the filesystem on that disk manually https://docs.digitalocean.com/products/volumes/how-to/increase-size/#expand-the-filesystem

Agree that those are required for a real instance, I was just trying to understand if we can provide a package where the app does not crash on initial startup until those are set up.

All in all since we at least need changes to the TLS addon to also provide the root domain certs, we are looking at least to a package release after the next Cloudron version only. Just to keep expectations clear.

Yes, we have to add this to the platform as a feature as well as think about how to make the DNS setup for those extra domains required. We have a policy that apps should "work" after installation. Do you know if there is a way that maybe those extra (sub)domains and thus their certs can be optional, just limiting the functionality of the app?

Since we test all app packages with the default (minimum) memory specified, I wonder how this had solved it. Is it possible that the system itself is running low on memory?

I am generally not in the group of AI = bad, however it likely just lacks lots of knowledge about the Cloudron internals, which make recommendations often not very useful in this area (yet).

Overall I am still not sure based on this thread why DNS was involved here and given that you hit 3 different addons with apparently diverse issues, maybe something unrelated to them individually caused the trouble.

We will add a few more helpers to the cloudron-support script for the future, to hopefully get down to such issues faster.

If you haven't deleted the server yet, maybe we could take a closer look via SSH, since you already invested much time in debugging. If you want that, please enable remote ssh support and send a mail to support@cloudron.io with your Cloudron details.

We are reworking the notification UI for Cloudron 9 at the moment and the reboot required hint will be fixed accordingly there. It has caused quite a few misunderstandings in the past as it currently is

loomio and others like minio have multiple http ports (which are routed through the reverse proxy). If I understand the xmpp use-case correctly, then those are just alias endpoints not serving any http content. Even the current main domain will just produce a 404 when hit with a browser. The alias use is more like a bit of a workaround to get DNS setup as well as get valid certs.

I've pushed my changes as a PR https://github.com/DerekJarvis/cloudron-prosody/pull/1

No need to merge that, just to give some idea about the certs handling. The alias domains still need to be manually setup by the user, so maybe we need some platform feature in the future for this.

Ah thanks for letting us know. I rarely hang out on discord these days, given my focus on mostly selfhosted things

The Cloudron package already ships mirotalk sfu 1.8.2 with adjusted configs. The Cloudron package had a custom config.js in place from the start, we might see how to support the env file approach in the future.

Would be good to have the links to such readme or release resources in the future instead of pasting here. This would avoid duplication and thus the risk to quickly have outdated info here.

I took the time to take a bit closer into the package. There is a long way to go to make it compliant with Cloudron packaging. It is a great start and we don't provide good information on what is expected from Cloudron packages, so this is mostly our fault.

For a start, you already added the tls addon, which does provide the certs in /etc/certs/ using that instead of the extra volume mount will ensure the app gets restarted and will pick up the correct certs if they get renewed. I am playing a bit from your package to hopefully get this working.

One question is, apparently certs for the root domain are also required, even though no DNS records for that are? This can be solved by also adding the root domain as an alias to the app.

For the extra required DNS records, we have to see if and how we can integrate this in the platform to support those. We already have some well-known type records, maybe it fits there.

Otherwise there are naturally discrepancies elsewhere, given that this started (as far as I can tell) from some upstream Dockerimage which will not fit, but we can get through one by one. The first I noticed was, that currently it doesn't work with the Cloudron app debug mode, since it uses ENTRYPOINT in Dockerfile, that was easy to change by relying only on CMD

I added the path info directive to test this, but the result is the same. Can't get past any auth there using the Authorization header. The path info is shown (I think correctly) in the debug logs though:

[PATH_INFO] => /accounts/ClientLogin/

I am also no php developer but it seems the auth part of the plugin would be unrelated to that at https://github.com/eric-pierce/freshapi/blob/master/api/greader.php#L39

Oh my bad, didn't read the section. Currently you have to set this then in the database manually. Normally the first created users gets the admin flag. To give other users the admin flag, open a webterminal into the app and run the following command, replacing <USERNAME> accordingly:

PGPASSWORD=${CLOUDRON_POSTGRESQL_PASSWORD} psql -h ${CLOUDRON_POSTGRESQL_HOST} -p ${CLOUDRON_POSTGRESQL_PORT} -U ${CLOUDRON_POSTGRESQL_USERNAME} -d ${CLOUDRON_POSTGRESQL_DATABASE} -c "UPDATE users SET admin=true WHERE username='<USERNAME>'"

So whatever you have posted here, makes no sense in the cloudron context, some of those commands don't even exist, nor is there any cloudron apt repository (apt.cloudron.io does and should not exist). Much AI hallucination happening here it seems

Looks like we have to start from first principles, first mysql didn't work then postgres and maybe redis...? Also it is probably not clear by now in which state the server is and what would have to be undone or not. Given all that, if you have recent backups a fresh start is probably the fastest and safest option to get to some well known state.