Cloudron Forum

Lets not limit that to certain apps, having a system wide (or at least covering the data directories) AV which will use Cloudron notifications would be nice (initial request https://forum.cloudron.io/topic/2090/clamav-installation-that-scans-the-local-storage-for-malware-and-notifies-the-admin)

Maybe you need to use the full path to the php version/executable that you're using, e.g. /usr/bin/php8.1 /app/data/public/scheduled.php schedule:run >> /dev/null 2>&1

@MiroTalk thanks for the detailed writeup. Looks good and as @jdaviescoates suggested, this probably only needs aliases enabled in the manifest and we're good to go

@MiroTalk thanks for your work and input, maybe I should have explained why: This specific example would be for 1:1 sessions for a customer of mine (therapist), where the join-links are supposed to be sent via email (that's why the separate domain, for credibility's sake).

I have a Mirotalk instance that I use for my own stuff on miro.example.com. Is it possible to add alias domains, so a customer could use talk.customerdomain.com with the same instance as mine? Thus saving resources and not having to install the app several times. I know this is possible with Nextcloud (not on Cloudron though I believe), would be nice to have that possibility, if technically feasible.

@potemkin_ai if you hover the date it will show the exact time

@girish thanks, appreciate it! already tested, templates are back

@girish I'm afraid this update removed the custom invoices templates, I can't create new invoices because the templates are now "missing". Could you symlink that path again? /app/data/invoices was used for templates, /app/data/data/invoices/ for exported pdfs (https://www.kimai.org/documentation/invoices.html#create-your-own-invoice-document for reference)

@simon I had that as well a few years (!) ago, when I was using a non-SSD VPS with little CPU and just too many records in the sqlite db. The quick fix was using a lower interval and regularly hit the "Shrink Database" button in the settings, the real fix was migrating to a server with a faster storage

I had a question about that a while ago: https://forum.cloudron.io/topic/12503/what-will-happen-when-i-enable-ipv6-on-cloudron-when-some-domains-don-t-support-it/2?_=1733313066534

@girish suggested this:

If you change the provider of the things you don't control to no-op, and make sure A/IPv4 is correct, then it won't crash and just ignore them. Certs should also be renewed (as long as there is no incorrect AAAA record).

Thanks for clarifying. Yeah I realized that a while ago, planning to do it differently, maybe even before the migration!

Sorry for semi-hijacking this topic, but since it's somewhat connected, I think it's okay

I'm also about to migrate a VPS with a bigger setup. It uses a number of custom apps and the Docker registry is also part of the Cloudron apps. The migration can only work if I do a dry-run, right? If the Docker registry isn't up during the restore process, the apps can't pull from the live-registry, or am I overthinking this and it will work because it is either still online on the old server or will be on the new one? Are there "priority apps" during the restoration which would make it easier? I think I saw multiple apps being restore at once, so that wouldn't work.

Ah yeah, that's what I thought. Moved the build app to somewhere else. Would be nice to add --cpu-quota to the build command to mirror the apps settings (from https://dev.to/code42cate/dont-build-docker-apps-without-this-flag-48kg)

I'm using the build service to build a custom image. The last step, when it starts to compile everything, almost brings down the whole server, meaning all Couldron apps and system view become unresponsive, because it uses all available CPU power. I've tried setting it to 50%, which would mean it's only allowed to use 4 cores of the available 8, but as soon as it's running, it will max out all cores. The build-app itself shows almost no CPU usage (0.something%), but the system view shows this:

Any suggestions on how to limit the resources so this won't happen?

Sidenote: the link with the questionmark in Cloudron in the apps/resources view points to https://docs.cloudron.io/apps/#cpu-quota which is not working anymore, the current one is https://docs.cloudron.io/apps/#cpu-limit

https://forum.cloudron.io/topic/12817/oidc-login-broken-with-8-1-0-update/7?_=1732142838325

thanks @nebulon & @girish, this does indeed fix everything, appreciate it

Quick update: apparently removing that snippet and fresh install is working, but for various reasons, reinstalling all my Directus instances is not a great option. Thing I've tried and didn't work: restarting app/box/server, changing location, permissions, cloning, using a fresh browser.

@girish thanks for the reply, but still getting the same error even after restarting box and Directus. Any other ideas? Some cache that I might need to empty?

Hi there! I already sent an email to support, but since it's quite urgent, trying here as well, maybe someone has a solution for this. After updating to 8.1.0, OIDC authentication doesn't work anymore. It's easily reproducable, fresh install on 8.0.6 works, 8.1.0 doesn't.

It says Service Unavailable and refuses to login and logs show this:

WARN: [OpenID] Unknown OP error
err: {
"type": "OPError",
"message": "unauthorized_client (requested grant type is not allowed for this client)",
"stack":
OPError: unauthorized_client (requested grant type is not allowed for this client)

Any ideas/workarounds @nebulon @girish @joseph?

thanks for the pointer @humptydumpty, but I would want to show all the rows in a shared view by default (which doesn't seem to be an option anyways, maxed out at 100 it seems). It doesn't seem to be very robust, do you have a recommendation for an alternative? Basically I have tabular data and need to show each tab (~300 rows each) to a individual users (readonly) with different authentication, filtering is a bonus.