Cloudron Forum

The update tests failed in our CI, we are investigating and then see how to fix the package.

The way Immich works is, that if a config file is used, it disables the config UI. Since Cloudron needs to pre-configure (and also reconfigure) apps in the package, it uses the config file. Personally I also feel like this is not great, but it is what the upstream project has, unless this changed recently.

So looking at the webinspector while trying to use the translation widget, it reveals that the CORS preflight check (OPTIONS https://transitionnetwork.org/remote-widgets/translate.php) does not succeed. This means you have to allow CORS (and thus responding to the OPTIONS call) in your php application.

@mouse77 you should be able to just use the domain as it is shown in your screenshot, if you own that domain and can change the DNS records for it at your nameserver provider.

For wildcard usage, you need to setup 2 DNS A records as a minimum. One for cloudron.indesigner.net and another one (the wildcard) for *.cloudron.indesigner.net . Both are A records and should point to your server's public IPv4 address.

Since you have selected the wildcard DNS backend, you need to setup a wildcard A record for your domain pointing to your server's IPv4 address as mentioned in the info below the selection input.

I can't quite see how anything between those versions could have affected this and especially since reverting the app will put the old app back anyways, the only issue may come from the cli then or the token actually be invalid.

To rule out one bit also, is the SSL certificate valid for the app?

Also do you see any error in the server side app logs and can you use the cli outside your CI/CD?

Thanks for the api docs link hint. This is fixed now.

Just did a new humhub installation and enabled the user registration. I can see the captcha but the form submits fine for me. Do you have any browser extensions which may block something here?

Yes, apps on Cloudron are in the end running as docker container on the system. But that should be more seen as a techical detail and not very relevant to the end-user.

Welcome here

Not sure at which setup screen you got stuck, but the first step in Cloudron is to give it a dashboard domain to have a way to access the dashboard to then configure it and install apps. We have docs for this at https://docs.cloudron.io/installation/#domain-setup

Afterwards you will be asked to create the owner account of that Cloudron, before you hit the actual dashboard then.

Do you have any questions about a specific step there?

@ntnsndr by virtue of having a server at that provider, you already trust that provider in the first place. So I wouldn't be worried about that aspect. I was more wondering about what other non-standard services they run on those VPS images which could interfere otherwise with the Cloudron system. Not saying that it is an issue, but just raising awareness, that this may be a source of irritation in the future.

well since those are in app images which are read-only also, and actually just the Readme of that node_module, there is no reason for concern. I would be more concerned about the Hostinger malware scanner here. What is it and it scans the rootfs blindly of servers?

So those env variables are for the immich docker compose environment, which Cloudron does not use. So they won't help us here. The config file does not have this, since it is not something which should be configured.

Instead like the docker compose setup, our package needs to be able to deal with paths accordingly, so we would have to essentially introduce our own "env" vars to define paths to be able to use Cloudron volume mounts. However given that those are not backed up in the same way main app storage is, a restore will inevitably cause issues with the files in storage getting out of sync with the app's database.

All in all I am really not sure if we should even lead users down that path with the risk involved for the benefit of cheaper storage

Good question, seems like I didn't actually implement removal of those! Maybe I get around over the weekend, or otherwise PRs are welcome for that project

@vladimir.d also has a branch with an attempt to get it working at https://git.cloudron.io/packages/dolibarr-app/-/tree/oidc-v21?ref_type=heads

Fixed package version is out.

So the chown in the docker image will not help here, since /app/data is mounted as a read+write volume and will thus not be part of the image itself. Hence things done in the Dockerfile will not affect the permissions of files in /app/data

To change permissions or ownership, the chown has to be done in the app startup script. Usually start.sh.

With which email client are you trying to log in? Can you try with say thunderbird to rule out one part of the problem angle, which would be a webmailer installed on that Cloudron.

so the package already runs with export DEBUG="releasebell*" by default. So if the logs look the same for the starred project then, I am also not sure how to proceed. You could set the app in recovery mode and add more debug() calls in the code itself.

Edit: the project itself is at https://git.cloudron.io/packages/releasebell-app where also the code is, happy to accept contributions and fixes there of course.

hm since I can't reproduce this myself, we kinda need as much info like logs as possible to take some educated guess for your case. Maybe you hit some rate-limits against github api or I don't know.