Cloudron Forum

Hmmm using ProxySQL might be pretty cool idea. I'll see if this leads anywhere. Thanks!

One way this could work is by working with Logto upstream to see if we can place a PR that changes the way they create roles and users to use a "security definer" function, basically a custom Postgres function that wraps aroung CREATE ROLE etc but can have more checks.

In this case the default function would be supplied by Logto like logto_create_role and would simply do a CREATE ROLE. Cloudron could also provide something like cloudron_create_role which could enforce that every create role is created as a subrole of the actual database user/role that Cloudron provisions for the user.

Then to bring it all together, the Cloudron Logto app would override the logto_create_role function and instead of doing a raw CREATE ROLE it would pass the execution to cloudron_create_role ...

That all said, it's quite a journey and I'd only reach out to the Logto folks if we can get some buy in that something like cloudron_create_role etc. could be part of a future Cloudron release. cc @girish

@robi No, it's tied to PG at the moment. My guess is that there row-level access policies etc. make the app very tightly tied to Postgres.

One more thought: Does any other app spin up it's own Postgres instanace? Because that would also solve all the problems above. But my gut feeling was that this is considered a bad practive. But I'm happy to stand corrected.

I've been trying to package this for the last couple of days and have definitively gone waaaaay to far down the rabbit hole.

The big challenge is that logto in it's current incarnation is inherently a multi-tenant app. The way it manages it's multi-tenancy internally is by creating a master DB role and then 1 new DB role per tenant in Postgres and also relying on pg's Row-Level-Security a lot.

Unfortunately we cannot create new Postgres roles as a Cloudron app. I've also tried to find ways Cloudron could fix these, e.g. by allowing role creation as long as the new role inherits from Cloudron's PG user for the app. But due to a lack of native restrictions in the CREATEROLE privilege and the lack of triggers for CREATE ROLE statements in PG, that seems nearly impossible to do.

So what I did instead is spending a good amount of time trying to massage logto's seed scripts (which always create 2 tenants, 1 for the app's default tenant and 1 admin tenant) to a place where logot is tricked into using the Cloudron provided DB user & roles.

I got the seeding working and the app will start. But currently you cannot acces the app as some internal lookup seems to be broken by my data manipulation.

I think there is a world where this could be made working by spending more time on manipulating the data just right. But in general it feels like this app in it's current state is not a great fit for Cloudron.

Oh and its https://git.cloudron.io/walski/beszel-app

@girish For sure, added an MIT license.

@girish sure thing, it's https://git.cloudron.io/walski I might have some sort of push access already, but I cannot figure out how to add a repo.

Hey @girish I've packaged Beszel here: https://github.com/walski/cloudron-beszel

It is OIDC enabled (OIDC only in fact) and works well for us. Tried to add all the necessary metadata but I've probably forgotten something

Let me know what I can do to get this into the app store. And as always: Thanks for your great work!

Can I somehow "VPN" the two containers together then? Or would that proxy app have to reach the Outline app through the public internet?

Hey folks,

we've started using an install of the Outline app in our Cloudron to serve as a public facing knowledge base / help center for our company.

Outline is a great fit here as it offers public shares of nested documents that is pretty much exactly what we want. We just add one "root" document in that install, share that and the whole help center will be shared through that.

We are facing two problems now

1. We want to avoid showing users an Outline login or anything similar in the help center
2. We want e.g. the root URL (/) to point to that "root document" instead of Outlines regular home, which for logged out users would be a login form (see 1)

Our solution

What we did is to fork the Outline app, add multi-domain capabilities (that would be easy to upstream) and put NGinx in front of the app in the Docker image.

That Nginx now redirects the root url to the specific root document and also redirects all traffic to Outline's auth to the root url.

You can see the result at: https://hilfe.easy-review.de/ (German)

What the heck is this post about?!

Sorry for the long preface: What I want to know/discuss is: Is there a world in which we don't need to fork the app but could have some sort of minimal mechanism like a mini-Cloudflare-worker equivalent that allows us to customize an app install with some redirect routes?

Does Cloudron put a reverse-proxy in front of any app anyways? Maybe there could be a way to add custom pieces to that proxy's config to allow such redirects?

Thanks for anyone who as a good idea here and hope there is a path here to make Cloudron a tiny bit more awesome yet again

Thorben

Works now! thanks again

I've updated the package and will report back in 24h Thanks for the quick reply and potential fix!

I'm still seeing an error even on the latest package version:

Apr 22 02:00:00 ERROR Making SERP Scraper Cron Request..
Apr 22 02:00:00 TypeError: fetch failed
Apr 22 02:00:00 at Object.fetch (node:internal/deps/undici/undici:11576:11)
Apr 22 02:00:00 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) { <30>1 2024-04-22T00:00:00Z v220191140145101068 9c696bd8-2809-48b5-85d5-15ac8597da82 152032 9c696bd8-2809-48b5-85d5-15ac8597da82 - cause: Error: getaddrinfo ENOTFOUND cloudron <30>1 2024-04-22T00:00:00Z v220191140145101068 9c696bd8-2809-48b5-85d5-15ac8597da82 152032 9c696bd8-2809-48b5-85d5-15ac8597da82 - at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26) { <30>1 2024-04-22T00:00:00Z v220191140145101068 9c696bd8-2809-48b5-85d5-15ac8597da82 152032 9c696bd8-2809-48b5-85d5-15ac8597da82 - errno: -3008,
Apr 22 02:00:00 code: 'ENOTFOUND',
Apr 22 02:00:00 hostname: 'cloudron'
Apr 22 02:00:00 syscall: 'getaddrinfo',
Apr 22 02:00:00 }
Apr 22 02:00:00 }

And the data does not get updated unless I hit the "Reload All Serps"-Button manually. The latter just works, so things are configured correctly.

Yip, they released v1.1.9 on Dec 2nd. That release includes the pyodide fix to run Grist sandboxed within Cloudron, as well as their direct OIDC support (see docs: https://support.getgrist.com/install/oidc/#openid-connect).

I'm more than happy to incorporate these onto my branch and that should then give us a decent to maybe get it into the app store? I just can't promise a timeline right now

Side-note: Looks like direct OIDC support just landed on Grist's main https://github.com/gristlabs/grist-core/pull/717

Ok turns out, that Grist releases after Sept. 11th come with a broken pyodide sandboxing layer (see https://github.com/gristlabs/grist-core/issues/734).

I got everything running using an earlier Grist release (1.1.4 from Sept 8th or so). Before this can be considered for the app store I need to polish the metadata, etc. But you should be able (we do) to install it to your Cloudron using the CLI.

Repo is here: https://git.cloudron.io/walski/grist-app

How little?

16GB RAM, 6 core AMD whatever virtual server. Currently running 13 apps through Cloudron.

I've a version of Grist running on our Cloudron as well. It's using OIDC through oauth2-proxy (https://oauth2-proxy.github.io/oauth2-proxy/) but needs a bit more polishing. E.g. I've disabled Grist's sandboxing, which I want to fix.

Word of warning: The performance so far is not mega great in my preliminary testing. Feels quite sluggish on our little box.

@girish I've opened a merge request as I wasn't sure if I should just overwrite the existing app in that repo. That merge request does exactly that, complete replacement with the app I put together. I've kept the existing CI/CD config but nothing else.

@girish I've DM'd you. You can also just clone the gist as a git repo: git@gist.github.com:e5d5b7ddb781f028b071b6ca12c460cd.git