Cloudron Forum

@bmann Not sure if this answers your question, but our process is this: Initially, I enabled "teams" and disabled "signups" at /settings/admin/flags, then configured some teams and Google Login. When we have new team members join, I invite them to the appropriate team (e.g. /settings/teams/2/members > Add.) When they accept the invite, I believe this creates the user account automatically. The issue that we ran into is that there was (and still is) no way to subsequently delete that user account from the admin GUI.

@marylou @nebulon Currently, accessing Etherpad's admin interface is a two-step process (after the config mentioned above):

1. First, visit /admin-auth/ to authenticate with your Cloudron user. If successful, you'll see the word "Authorized" appear.
2. Next, visit /admin. This should no longer redirect you to /admin/login, and should instead show you the Etherpad admin console.

@nebulon Thank you! Great to hear. Happy to say that our custom skin loads properly.

@nebulon We're circling back to custom skins as being our primary blocker to updating Etherpad. We believe that the Cloudron packaging change that prevents custom skins from working was when these lines were commented out: https://git.cloudron.io/cloudron/etherpad-lite-app/-/blob/master/start.sh?ref_type=heads&blame=0#L29-33

Would it be possible to reinstate symlink creation for custom skins located in app/data/skins? I believe the link needs to be added into the /src/static/skins directory to work.

@marylou Where we ended up landing: both buttons are visible but only Google Login button gets used. Not perfect, but the app is fantastic.

I think access to the admin UI will still be needed in order to access Etherpad's Plugin Manager. (I don't believe there's a way to specify or update plugins from the json file.)

@nebulon Is there a way that I can add my custom skin files to /run/etherpad-lite/src/static/skins/? I can't access that directory from Cloudron's File Manager.

Thanks for clarifying!

I've noticed that after I apply security updates from the Cloudron Notifications page, all apps show as "Running" immediately after the Cloudron has finished rebooting, even before apps are passing their own health checks. I suspect all apps should initially be in the "Stopped" state after the reboot.

I wanted to express appreciation to the Cloudron team for great tooling to support reliable updates. The Etherpad app has changed quite a bit since the previous package, and a great set of platform-level features has made managing potentially breaking version updates very manageable:

• allowing user to specify exactly when auto-updates should run
• only auto-updating if the new version is marked as “stable”, with unstable updates available but not automatic
• allowing user to disable auto updates for specific app(s)
• cloning an app to test changes in a sandbox
• backups automatically created before each version update
• one-click to roll back to any past version

Together, these make it low-stress to manage big updates. Great work on the platform!

Previously, custom skins could be added to the /app/data/skins directory and would render correctly if specified in skinName in the settings.json file.

In this latest version in (org.etherpad.cloudronapp@4.1.0, v2.1.1), custom skins are no longer loading from this directory. Instead, Etherpad is now looking for them in the /src/static/skins directory.

Here's the error in the logs:
[ERROR] settings - Skin path /run/etherpad-lite/src/static/skins/<name> does not exist. Falling back to the default "colibris".

This folder structure previously worked but no longer does. Was the /app/data/skins path defined somewhere in the Cloudron package? Perhaps it needs to be re-added?

@nebulon I noticed that the app links to an admin login at /admin/login, but Cloudron's login lives at /admin-auth/.

Great to hear! Looking forward to testing it out!

@nebulon Confirming that the latest version of cal.com has embed.js rendering and working again!

@nebulon Looking forward to trying it. We only do app updates during a weekly maintenance window on Saturday, so it will be a few more days before I can report back.

(Cal.com typically takes 10+ minutes to become available after a restart, so I’m particularly careful to avoid weekday updates with this app.)

We ran into this issue recently, too. As a temporary workaround, we updated the code snippet from <domain>/embed/embed.js to https://cal.com/embed/embed.js. The upstream issue is at https://github.com/calcom/cal.com/issues/14990. It looks to me like this regression is being fixed in the calcom/docker repo with https://github.com/calcom/docker/pull/364. Hopefully this gets incorporated in the next upstream release.

@girish We were exploring the Pro plan, but didn't initially realize that it would require a separate Metabase app and a data migration path. If we were to move forward with this in the future, I could see migrating to the hosted metabase.com solution. I agree that it probably doesn't make sense for Cloudron to package.

Great to hear!

@girish Confirming that the issue was unrelated. It was very helpful to be able to manually refresh certificates and then view the log files. Thanks!

I just took a look at Cloudron's Event Log, and I'm seeing cron errors that I don't recall seeing before: An entry stating "Certificate install for <subdomain> failed" for each Cloudron app subdomain. Could this have something to do with how Cloudflare is preparing (refs 1, 2) for the Let's Encrypt certificate chain changes later this year? Or perhaps totally unrelated?