I wanted to flag that the latest Cloudron build is the first beta release candidate for Chatwoot v4. (Chatwoot posted a migration guide to accompany the upgrade, but looks like pgvector may already be installed and available.)
I spotted this before our Cloudron app auto-updated so I was able to turn off auto-updates for this app, but I wanted to recommend marking this beta of a major version such that it doesn't get updated by Cloudron automatically.
@nebulon I see. Thank you!
It looks like Cloudron is trying to set NODE_ENV=production in start.sh:57, but this clearly isn't working based on what is in the logs.
@robi Adding a .env file with NODE_ENV=production unfortunately didn't change this.
@luckow Warning message in the logs says "This mode is slower for users and less secure than production mode."
Wanted to flag that I see an example in the Etherpad documentation that sets this via Docker Compose: https://docs.etherpad.org/docker.html#:~:text=NODE_ENV%3A production
I noticed while while restarting the Etherpad app that it is currently loading in development mode.
[WARN] settings - Etherpad is running in Development mode. This mode is slower for users and less secure than production mode. You should set the NODE_ENV environment variable to production by using: export NODE_ENV=production
In which file should I add NODE_ENV=production? I'm not seeing anything in the File Manager for environment variables.
@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):
/admin-auth/ to authenticate with your Cloudron user. If successful, you'll see the word "Authorized" appear./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:
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 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.