Cloudron Forum

@girish Thanks for this. Access given / mail sent. Appreciate the help.

@girish Thanks for this - After looking into the box.log:

• post systemctl restart box I do see indeed box:apphealthmonitor app health: xx running / 0 stopped / 0 unresponsive entry type every 10 seconds or so.
• pre systemctl restart box (when we experience the issue) I do not see much of the box:apphealthmonitor app health:xx entries. Rather, I do have a few rare box:apphealthmonitor setHealth: <<CONTAINER_UID>> (<<URL>>) waiting for 1192.461 to update health entries

Hopefully it helps?

@nebulon Yes - this fixes the issue temporarily at least

@nebulon Thanks - To the untrained eye, there is nothing in htop that pops up as flagrantly hogging resources.
The swap is high but I am not sure if this is a relevant indicator

At last - I think I was too eager to see this resolved.
The problem is still there with the exact same symptoms.
How can we proceed further? @nebulon @james Would another remote troubleshooting/debugging be helpful?

Happy to report that the updated cal.com package seems to have fixed the underlying server issue.
Many thanks,

Also: interestingly the moment the server started playing up is indeed the moment that I had roughly linked to our latest cal.com deployment.
I say latest because this Cloudron server had a previous cal.com app instance that we used as a test a while back - not sure if relevant but maybe it can help inform the situation.

@nebulon Interesting.
The server provider is ssdnodes - So far I have had nothing to complain about (just about the opposite). Happy to play the liaison part should we need to relay info / ask questions of them.
Many thanks,

@nebulon Hi @nebulon - Thanks for this. Email sent.

@james said in Cloudron instance scaling issues after a few hours / couple of days, apps responsive but showing a permanent "Starting..." status:

I have reviewed the data and could find anything really suspicious.

"couldn't find....." ?

How do we go from there? Happy to enable remote SSH support if helpful.

Many thanks,

@james Hi James - I have now sent you the link. Thanks.

This has been going on for the last 3-4 weeks.

Cloudron v8.3.2 (Ubuntu 24.04 LTS)
22 Apps.

This instance have been running fine for a couple of years at least.
On a fresh start or reboot, the instance works just fine.
However with time going by, with no changes of significance and no out of the ordinary operations (use of the apps, scheduled(successful) daily backup, automatic app updates)

With 1-2 days the instance show signs of a "strange" nature:

• App restart (after an update for example, but this goes with manual restart too) show the app locked into a "Starting..." state on the dashboard.
• The app itself is most of the time still responsive and can be used as normal.
• As far as I can tell, both the "standard" logs of the app as well as the log of the Cloudron instance are not showing anything of relevance / out of the ordinary
• Performance indicators from the Cloudron instance seem to be perfectly fine.

More time goes, more apps show the same "Starting...." state.
It does not matter which app it seems.

If left untouched, other problems appears on the Cloudron instance such as email fetching problem without a Freescout app for example.

A quick fix, but not a permanent one is to run systemctl restart box on the instance terminal.
This returns the apps status back to "Running" and things like the fetching of email within Freescout is back to operational.

Also running cloudron-support --troubleshoot return all green / does not show any error.

Has someone been across this behavior already? What would be the next step in troubleshooting and/or permanently solving this?

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,