@girish That sounds great! The last two incidents were this would have helped me were developing over several days (exploding Rocket.Chat logs and syslog.js), so this should be within the necessary precision to prevent this type of situation.
@joseph said in Emailing notifications of certain crucial system events, such as full disk space:
Email notification can be added but it will be unreliable (and don't want to mislead users). See https://forum.cloudron.io/topic/7555/emailing-notifications-of-certain-crucial-system-events-such-as-full-disk-space/8
Sure, I do understand those limitations. I was just thinking that it would be nice to have an email notification equivalent (maybe with a note pointing out the limitations) for every notification type shown in the Cloudron dashboard.
I am wondering if this might be possible by now. I just got the notification "Server is running out of disk space" on the Cloudron notification tab. Since there is already the possibility to subscribe to email alerts for events like "App is down", couldn't this event be added as well?
I like the idea of Cloudron being a self-contained system, so I don't want to add a custom monitoring system to it that needs to be maintained along side it.
@joseph Unfortunately no.
I was already using 1.6.0 when the problem came up. Using backups, I traced it back to 1.5.2.
I can reliably reproduce the problem by taking a 1.5.1 clone (that works perfectly) and updating it to 1.5.2.
Thanks for checking!
With a fresh install of org.bigbluebutton.greenlight3.cloudronapp@1.7.0 / Greenlight 3.5.0 it works for me as well. So I assume there is an issue with the upgrade from 1.5.1 to 1.5.2.
Update: I noticed that since 1.5.2, the following error is thrown when starting an instance:
`/home/cloudron` is not writable.
Bundler will use `/tmp/bundler20250305-1-8seal41' as your home directory temporarily.
I am using Greenlight with a self-hosted BBB server installed via bbb-install and updated to the latest 2.7.x release.
We started noticing that join links for users without an account stopped working after upgrading from 1.5.1 to 1.5.2.
I cloned the app from the most recent 1.5.1 backup and can confirm that the links are working fine with that version.
When visiting a join link on a Greenlight instance >= 1.5.2, an error screen appears after about 5 seconds. The frontend throws JS errors in the console.
There are no error messages in the apps log or the nginx log, nor in the BBB log.
Does anyone else notice this behaviour?
While debugging our Greenlight instance, I noticed that the Greenlight upstream version in the CloudronManifest.json has not been updated since 5 months.
Alright, thank you for the explanation. I'll reinstall the app then.
The following warning is shown in listmonk after the upgrade to 1.8.0.:
Remove the admin_username and admin_password fields from the TOML configuration file or environment variables. If you are using APIs, create and use new API credentials before removing the them. Visit Admin -> Settings -> Users dashboard. Learn more.
You mention OpenID integration in the changelog, do I need to configure this manually on an existing instance?
@nebulon Thank you very much!
@nebulon Thanks! Will do.
Yes, anything that would allow to set a longer session timeout would already help a lot. Thanks for looking into this.
After using Dokuwiki with the current OIDC integration for a while I realize it is hardly usable in practice. Due to the short validity period of an access token, it frequently happens that pages cannot be saved as the session already timed out while working on a page. Is there any way to increase the session duration?
Alright I see. Either way this is not an ideal solution as users have to frequently re-login.
It seems that the OIDC integration does not properly handle refresh tokens. I get the following message, after which I have to manually repeat the OIDC login:
Service did not provide a Refresh Token. You will be logged out when the session expires.
Since Cloudron OIDC is working with other services, I suppose this is a bug in the Dokuwiki oauthgeneric plugin?
Alright, that sounds very promising! Thanks a lot.
Alright, does that mean I'll have to use the work-around mentioned in https://forum.cloudron.io/post/63987 if I need groups in Dokuwiki?
I am wondering if it is possible to synchronize Cloudron group memberships with Dokuwiki groups with the current OIDC login? The Cloudron Docs still refer to the old LDAP connector.
I just set up a new instance and the Dokuwiki user manager only lists the groups user, generic for my users. The groups from the Cloudron user directory don't seem to be available.