Cloudron Forum

I've seen the release and I will be testing this shortly.
Much appreciation @staff !

Hi @jdaviescoates

Thanks for this - I had checked before opening this thread and I believe that Rallly does have a corresponding variable - See here: https://support.rallly.co/self-hosting/single-sign-on

Hopefully this might be of help

Hi @girish, @vladimir.d
Many thanks for looking into this. I was wondering if maybe you had a short update on the timeline for this?
I guess possibly you are waiting for the next Rallly release ?
Or maybe the transition to Cloudron base image v5 could trigger this change too?

Many thanks,

@jdaviescoates said in Chicken and egg - Onboarding 2FA mandatory cloudron user with 2FA app?:

@joseph said in Chicken and egg - Onboarding 2FA mandatory cloudron user with 2FA app?:

vaultwarden is fine because it doesn't have Cloudron SSO

Yet. Vaultwarden itself does now support OIDC.

Or it looks like it will shortly - So would hope for Cloudron SSO to be integrated also!

---

Yet in this case 2FA or the 2FA of Vaultwarden does not really matter, ultimately the issue is the same:

• How to setup Cloudron 2FA with a cloudron-installed 2FA application.

@joseph said in Chicken and egg - Onboarding 2FA mandatory cloudron user with 2FA app?:

Was discussing this with a friend yesteday and an analogy he gave me was this is like saving the password manager's password in the password manager itself This won't end well ultimately

As mentioned, I get some of the security concerns of having the 2FA related application on a server requiring the same 2FA token to be usable, but there is also no denying the advantages:

• A central point to manage this app and related-mechanism rather than spreading thin over various servers / architecture / platform
• Especially on a product/service (Cloudron) that allow for user administrations, administration of the app itself and administration of the 2FA security setting on the same architecture

In a limited context (single or small number of users), the resources cost related to on-boarding administering and supporting, often non or limited security-literate users, can be apprehended with a simpler concept, whatever this one might be (e.g. 2FA app of the user's choosing etc..).

However, in a different scenario, where the number of user grows, SOPs make sense to be able to strike a reasonable balance between security, scalability and sustainability of the services.
This is within this context that my original question fit in - chicken and egg?

In the end, I would envisioned a situation where Cloudron admins have their 2FA hosted somewhere else (to mitigate security-related / lock up concerns), but end users would benefit from a 2FA Cloudron related app.

Hopefully this make sense also - thank a lot for the inputs already!

Hi,

I am wondering if some might have run into the same question / situation and what was the outcome.

The idea:
Creating Cloudron users with mandatory 2FA authentication
Upon 1st login, the user is then mandated to setup 2FA to access Cloudron's dashboard and thus the installed applications.

Ideally, I would like for the user to be able to setup of their 2FA authentication token within the Cloudron 2FA-installed app.
However, this is currently not possible since the access to the 2FA app is conditioned by.... accessing the dashboard and thus a successful Cloudon login.

So, the chicken and the egg situation.... unless, I am overlooking something?!?
Would anyone see any way around this?

Possibly there are also some security concerns (2FA app on the same server as the user directory kind-of-thing) which I have not entirely drawn out, simply out of the fact that I am not sure that the above is possible to do.

Many thanks for any related inputs here.

Hi all,

Is there a preferred course of actions for moving an existing FreeScout Cloudron app from LDAP to OIDC authentication ?

What is the best approach here ?

Many thanks,

This is great and sound promising - Thanks so much @jdaviescoates . It would be happy to test this / see it implemented.

Hi,

The cloudron Rallly package is OIDC enabled. However I do not think that the new CLOUDRON_OIDC_PROVIDER_NAME parameter to customize the OIDC login button has been implemented yet.

any chance this could be looked at?

Many thanks,

I very much like the llama "service" idea. However failing this I would also be contempt to test a Linkwarden package that includes llama. Possibly this could be an option to have similar to redis and such.

@nebulon Just to confirm: I presume you are saying that the updated package works well, and that you are not saying that the OIDC login works well. Is this correct?

This would seem to match my test: the package does work well in the demo instance, but is without OIDC for now.

Also I suppose the App Status table here is updated regularly, but not automatically which would explain the info/package version discrepancies?

Many thanks again,

@girish Looks like v.3.3.0 is out and includes your fix. Would you consider looking into OIDC with releasing Cloudron's related updated package? Thanks,

Hi @JLX89,

This is something that has been discussed / requested a few times already.
Please see here:
https://forum.cloudron.io/post/91579
https://forum.cloudron.io/post/93245

and here for the latest:
https://forum.cloudron.io/post/96688

In short, my understanding is that it is coming in 8.2. Or could it be sooner @girish ? This seems in relative high demand.
If I get this right the Cloudron part is done, it just needs the related app package to be updated to make use of the Cloudron env variable.

@girish said in Cloudron Source & Release Notes:

@uwcrbc said in Cloudron Source & Release Notes:

Because this list seems to differ somewhat from the "What's coming in 8.1" forum post, I wanted to take a closer look to the release notes and note the differences, see what made the cut off and what has not.

yes, good catch. I will rename that post to 8.2 . We introduced many regressions in Cloudron 8.0. So, we made a 8.1 for mostly bug fixes and some minor features like OIDC group support.

Ah, I understand better now v8.1 vs v8.2. Thanks for this.

Am I right in thinking that the OIDC button branding did not make it into this release?
We are waiting for this for a few apps releases...

Also, just to confirm: is there any official place one show look for a complete set of release notes other than in a Forum/Blog post?

Thanks again.

@girish said in Cloudron Source & Release Notes:

@uwcrbc the repos have moved a bit in last few weeks. We are moving all the app packages into the CI for automated and reproducible builds. I will make a separate post later this week explaining what we have done (it's mostly only technical and probably interesting to a fellow developers but not for cloudron users themselves). In the past, we were quite careless with how people registered and were given permissions. But anyway, to answer your question until that post pops up: we have made a few groups.

Cloudron code base - https://git.cloudron.io/platform
App packages - https://git.cloudron.io/cloudron
For doc repos - https://git.cloudron.io/docs
Unpublished apps, tools, testing stuff etc - https://git.cloudron.io/playground

The repos will most likely not get re-orged further but I will put the final org in my post.

@girish Great - This makes sense. Indeed I got the feeling that a few things were changing recently (Website, pricing tiers, repo - for the better I find!). It is like Cloudron is gearing up for the next stage and it feels good to see.

Possibly I think it would also make sense to update the open source website page to reflect these repo changes.

Hi all,

It seems as Cloudron v8.1 is being pre-release with the following release notes:

Because this list seems to differ somewhat from the "What's coming in 8.1" forum post, I wanted to take a closer look to the release notes and note the differences, see what made the cut off and what has not.
However I seem to struggle to locate release notes for it.
Are these publicly available (I mean other then the popup when triggering the release)? If so, where to find them?

Furthermore, in the process of looking for these release notes, and while I know Cloudron is "source available", I could not find the actual source anywhere.
The following page makes mention of Cloudron Gitlab instance where one can find the app package sources, but I wasn't able to find the "Cloudron code" as mentioned here:

Am I looking in the right place ?

Any help is much appreciated.

In all case, many thanks for this further release.

Apologies for the revival if irrelevant.
I am just wondering if this is still on the map and if so, if there is any hint of time until release?

Many thanks,

Thanks for this - Email sent.

Not too sure what you mean from fuse sshfs, but from the cloudron server I can SSHFS and mount the remote storage backup location just fine, using the same/relevant subaccount.

Did you mean something else?

Hi @nebulon

Yes, it is possible to ssh into the storage box both from a local machine as well as from a Cloudron server.

Hi all,

This could be linked to symptoms described here but also maybe not.

This is happening on 3 out of 6 servers all on Cloudron v8.0.6 and Ubuntu v24.04lts:

• on 3 servers I am unable to mount Hetzner backup (storage box via SSHFS). The error given in Cloudron is the following: "Failed to mount (inactive): Could not determine mount failure reason"
  

• looking in the log of the 2 servers I see the following entries when trying to mount the Backup Storage:

ct 01 15:15:28 box:shell remountMount /usr/bin/sudo -S /home/yellowtent/box/src/scripts/remountmount.sh /mnt/cloudronbackup
[no timestamp]  dependency job for mnt-cloudronbackup.mount failed. See 'journalctl -xe' for details.
Oct 01 15:15:29 box:shell remountMount: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/remountmount.sh /mnt/cloudronbackup errored BoxError: remountMount exited with code 1 signal null
[no timestamp]  at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:122:19)
[no timestamp]  at ChildProcess.emit (node:events:518:28)
[no timestamp]  at ChildProcess._handle.onexit (node:internal/child_process:294:12) {
[no timestamp]  reason: 'Shell Error',
[no timestamp]  details: {},
[no timestamp]  code: 1,
[no timestamp]  signal: null
[no timestamp]  }
Oct 01 15:15:30 box:apphealthmonitor app health: 2 running / 0 stopped / 0 unresponsive
Oct 01 15:15:31 box:shell getStatus execArgs: mountpoint ["-q","--","/mnt/cloudronbackup"]
Oct 01 15:15:31 box:shell getStatus: mountpoint with args -q -- /mnt/cloudronbackup errored Error: Command failed: mountpoint -q -- /mnt/cloudronbackup
[no timestamp] 
[no timestamp]  at genericNodeError (node:internal/errors:984:15)
[no timestamp]  at wrappedFn (node:internal/errors:538:14)
[no timestamp]  at ChildProcess.exithandler (node:child_process:422:12)
[no timestamp]  at ChildProcess.emit (node:events:518:28)
[no timestamp]  at maybeClose (node:internal/child_process:1105:16)
[no timestamp]  at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
[no timestamp]  code: 32,
[no timestamp]  killed: false,
[no timestamp]  signal: null,
[no timestamp]  cmd: 'mountpoint -q -- /mnt/cloudronbackup'
[no timestamp]  }

• all servers (the 3 failing and the 3 working) backups are configured the same and backing up to the same Hetzner Storage Box
• backup configurations on all servers have been set long time ago and numerous backups were successful.
• each server use a different hetzner subaccount and own credential/key. This is the only setting that differs from one server to the next
• all failing servers jumped from 8.0.4 to 8.0.6, with no successful backup since 8.0.4
• some working servers also jumped from 8.0.4 to 8.0.6 but not all.
• restarting a failing server does not solve the issue

So at the moment, I have 3 out of 6 servers not able to back things up.
Based on this, does anyone have any idea what is going on and where to find/dig up more info?

Thanks in advance for any pointers