Cloudron Forum

We're running our Cloudron on AWS EC2, initially created from a AWS Marketplace AMI. I just attempted to upgrade to a different instance type with a newer Intel-based processor instance type (r5.large => r7i.large), and saw this error message:

Failed to modify instance type for instance. The instance configuration for this AWS Marketplace product is not supported. Please see the AWS Marketplace site for more information about supported instance types, regions, and operating systems.

The Cloudron AMI that we started from is no longer available in the Marketplace. What would you recommend in order to move to a newer processor? Perhaps a fresh Cloudron install on a new instance that is not connected to the Marketplace? Or launch a new Cloudron Marketplace AMI and restore a backup from the current instance? Appreciate any advice on this.

Removing 2.7 seems to have been seamless. Thank you!

Thanks for the pointer! I doesn't look like Inspector is reporting spurious findings, though: Python 2.7 appears to be fully installed and active on the system, and is not just remnant configuration files picked up by SSM.

I don't see any indication that Python 2.7 is used by any Cloudron containers, so I think that removing the python2.7 and python2.7-minimal packages is the best path forward. My hesitation is the presence of the python-is-python2 package:

$ sudo apt-get --simulate remove python2.7 python2.7-minimal
The following packages will be REMOVED:
  python-is-python2 python2 python2-minimal python2.7 python2.7-minimal

$ dpkg -l | grep python-is-python2
ii  python-is-python2                      2.7.17-4                                all          symlinks /usr/bin/python to the DEPRECATED python2

Wondering if that changes the recommended path forward.

We run Cloudron on an AWS EC2 instance (Ubuntu 22.04LTS), and Amazon Inspector is flagging security issues with Python 2.7 on this box that are now only being fixed in Ubuntu's "Extended Security Maintenance" (esm3). As best I can tell, we're not actually using Python 2.7 for installed apps, so I'm wondering about uninstalling Python 2.7 entirely from our Cloudron. What would you recommend?

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):

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/.