Cloudron Forum

Hi @joseph,

MeshCentral provides an interface that lets you access a fleet of devices via remote desktop or a terminal, along with sending some basic commands like reboot. However, it's not a full-featured RMM that handles automatic patching and updates; we get around that with powershell scripts on the Windows side and unattended-upgrades on Linux.

Our team is relatively small, and has about 6 desktops and laptops. MeshCentral primarily gives our IT team an easy way to remote in, install an app, or help walk a user through a process.

Hi everyone,

We needed MeshCentral at work, and instead of just running it on our Docker server we decided to package it for Cloudron.

This Cloudron CA does utilize Cloudron's PostgresSQL, Mail, and optionally SSO.

Please note that AI was used in the packaging of the application.

We have only tested the functionality of the regular MeshAgent that works over HTTPS, and have not tested the Intel AMT functionality of MeshCentral.

Repo: https://github.com/paramedicspecialist/meshcentral-cloudron
Install: https://raw.githubusercontent.com/paramedicspecialist/meshcentral-cloudron/main/CloudronVersions.json
CA: https://ca.cloudron.io/app/meshcentral

Hello,

We have been trialing Grist for a new project but have run into an issue.

We are attempting to publish a form so it's publicly accessible, however we are running into an issue where it redirects to OIDC login instead of showing the form.

This appears to be caused by the environment variable GRIST_FORCE_LOGIN, which needs to be set to false for forms to be publicly accessible.

We tried setting this in the env.sh file, but it had no effect. Upon investigating, it appears the variable is being set to true in start.sh, and user configuration from env.sh is sourced earlier.

Any suggestions, other than cloning the package? Maybe env.sh can be called after the hard coded variables?

Thanks!

I updated to 4.13.0 and can no longer reproduce the issue. All of our workflows appear to be working, and there are no new errors in the log. Appreciate the quick turnaround!

I noticed a similar issue today after updating to 4.9.0 with one of our n8n workflows that posts binary files to StirlingPDF through the HTTP Request node.

The application logs for n8n show the following error:

Mar 04 13:33:02 Unable to calculate form data length
Mar 04 13:33:02 data should be a string, Buffer or Uint8Array