Cloudron Forum

@james Understood. For situations like these, is posting on this public forum still preferred over email to support@ or security@?

Same drill as before, but with a new minimum target release...

The downloads below include the minimum safe release for each Metabase version.
 
63
0.63.10
Docker image: metabase/metabase:v0.63.10
Download the JAR here: https://downloads.metabase.com/v0.63.10/metabase.jar

There is not yet a web link documenting this, so I'd recommend reaching out to help@metabase.com if you want independent first-party confirmation on this.

In case this is useful, I saw the Cloudron app update as being available yesterday and successfully updated. “About Metabase” (in app) reports 0.63.5 but the Cloudron Info tab still says “Metabase 0.63.2.7”.

@joseph The CEO of Metabase (not my company’s CEO) sent an email out to their email list. I sent a response to help@metabase.com and they replied immediately to confirm. I’d recommend reaching out to them to confirm. I’ll forward the full email to the Cloudron email account.

@luckow Found it here: https://hub.docker.com/r/metabase/metabase/tags?name=v0.63.5

@luckow I emailed Metabase to ask about the missing release.

Notification email came from company CEO sent out earlier this morning. I tried to upload a PDF of the email but can't upload PDF to this forum.

Until then, the recommended temporary workaround is for users to block the affected endpoint (/api/session/reset_password).

Metabase posted a security advisory today about a zero-day vulnerability giving access to admin accounts. Self-hosted users running Metabase 63 prior to 0.63.5 are vulnerable. I went to update to v0.63.5, and see that it isn't available yet on Cloudron. Requesting an expedited build.

We've seen inconsistent email delivery even on the latest release, which I believe was due to issues specific to Google Calendar (our primary calendar service.) I filed an Issue and I saw a few PRs referencing this with a fix, but nothing was merged. Even if it had been merged, there hasn't been a new release issued on this repo in almost three months (down from multiple per week prior to the strategy change.) Hope to see it revived, but not counting on it.

I noticed that they haven't issued a new release since March 1, where they were previously cutting releases every few days. Looks like they are still merging PRs into calcom:main, but unclear when that will turn into a new release. Any idea who is managing the release process for the repo?

Thanks, @girish!

@joseph I'll share that with them.

Metabase posted this security advisory today: Authenticated users are able to retrieve sensitive information from a Metabase instance, including database access credentials. I went to update to v0.58.7, and see that it isn't available yet on Cloudron. Wanted to request an expedited build.

From my read of the security advisory, disabling outbound email is a sufficient workaround until the new build is installed. I've done this by providing Metabase with invalid SMTP credentials in env.sh

Got it. Thank you.

We recently ran a load test of our systems, and saw something a bit surprising with Etherpad. Under significant load, the CPU utilization maxed out far below the "Max CPU" line set based on the CPU limit set in the Resources tab. Is possible that the Etherpad app (or Cloudron) isn't taking into account the number of cores available, as described in the docs?

When will this auto-update on Cloudron? We'll all need some time to work through the full list of breaking changes (https://docs.n8n.io/2-0-breaking-changes/) before then.

Sorry. bash wasn't supposed to be there. Failed attempt to format the markdown code block.

Wanted to share a working solution, lightly adapted for Cloudron from Github issue comment referenced above:

1. Enter Recovery Mode
2. On the app's terminal: sqlite3 /app/code/data/kuma.db "DELETE FROM setting WHERE key = 'migrateAggregateTableState';"
3. Exit Recovery Mode

Looks like logrotate was configured to time out after 90 seconds, and so the large Etherpad log files failed to rotate, and disk filled. Looks like it's time to extend the timeouts and generally review the logrotation config.

Thank you!