Posts made by Robin

@girish said in Incorrect error when removing an obsolete alias for a service:

Did you happen to set this up manually?

Hmm, I don't actually know. It's not impossible I guess...

Good to know though, I'll work on cleaning DNS up

For the record, it did actually remove the alias, so I think the only confusion here is the unexpected extra presentation of an error message.

I had an app hosted at, let's say, "foo.bar.com". It had an alias for "barfoo.net", which was an old domain that subsequently has expired. Today, I tried to remove the "barfoo.net" alias by just trashing it and clicking save, but got an error:

An error occurred during the location change operation: Already Exists: DNS CNAME record already exists

The CNAME that already exists is for "foo.bar.com". It doesn't seem correct that this is an error, since the CNAME it is complaining about was already set up by Cloudron. All I wanted to do was to remove the alias, not also change the location of the service.

(Running Cloudron v7.3.2, using Hetzner DNS if it matters)

Nothing that mentioned the _ (wildcard) cert at least, which is part of why I'm stumped. I don't know what is creating it, or where to look.

So, I still got more cert warnings despite moving the app locations around, and removing the dashboard config, so I decided to try be a bit more brutal about it. I removed the wildcard cert:

rm /home/yellowtent/platformdata/nginx/cert/_.xxx.*

Restarted box, and everything seemed OK. Then I triggered Renew All Certs again, and ... ended up with a new wildcard cert! That doesn't make sense to me... Is there something I can look at that would explain why it wanted to create that? Or some proper way I can nuke the DNS configuration from orbit so it ends up sensible again?

@girish Hmm, one remaining problem... What do I do about my dashboard, which is also affected by the same problem? Would changing its location temporarily (and then switching back) fix it?

@girish Hmm, that didn't match the behaviour I saw. I ended up with two separate SPF records in Hetzner. One that I had already set up from my own DNS setup, and one added from Cloudron - which didn't contain the content of my own record. Thankfully it wasn't difficult to fix, once I read up on it.

@girish I switched from wildcard over to programmatic (via Hetzner). I didn't update individual apps after that change, but I guess I can try that and see what happens...

So as I discussed a while ago, I did a DNS migration (https://forum.cloudron.io/topic/7429/how-to-do-a-smooth-dns-migration/2) from a manually updated wildcard, to Hetzner. For the most part, this has gone smoothly, but I seem to be running into a corner case with Lets Encrypt certificates. I've started getting upcoming expiry warnings for a bunch of domains now. I tried to force renewal, which gave me the following logs (for each service on subdomain.example.com)...

Aug 15 12:01:04 box:tasks update 6255: {"percent":76,"message":"Ensuring certs of xxx.subdomain.example.com"}
Aug 15 12:01:04 box:reverseproxy ensureCertificate: xxx.subdomain.example.com certificate already exists at /home/yellowtent/platformdata/nginx/cert/_.subdomain.example.com.key
Aug 15 12:01:04 box:reverseproxy expiryDate: /home/yellowtent/platformdata/nginx/cert/_.subdomain.example.com.cert notAfter=Oct 26 11:00:56 2022 GMT daysLeft=72.04156950231481
Aug 15 12:01:04 box:reverseproxy providerMatchesSync: /home/yellowtent/platformdata/nginx/cert/_.subdomain.example.com.cert subject=CN = *.subdomain.example.com domain=*.subdomain.example.com issuer=C = US, O = Let's Encrypt, CN = R3 wildcard=true/true prod=true/true issuerMismatch=false wildcardMismatch=false match=true

This looks okay, in theory, but then at the end I see the following:

Aug 15 12:01:04 box:reverseproxy expiryDate: /home/yellowtent/platformdata/nginx/cert/xxx.subdomain.example.com.cert notAfter=Sep 3 11:00:56 2022 GMT daysLeft=19.041567395833333

And the daysLeft here seems to match up with the mail warnings I'm getting...

So they don't seem to be renewing properly... Is there something I can do to force a renewal? And is this some kind of a bug/unhandled edge case in Cloudron, perhaps caused by the DNS provider switch?

@nebulon Hmm, okay. Been way too long since I've looked at running an email setup, so I had no idea! Good to know.

There is still a bit of a problem, though, in that it seems like the record creation doesn't play very well with other existing SPF records. I had an existing SPF record for my main domain, so this meant I ended up with two of them when Cloudron pushed its one. I've now merged them together, so I guess I'm fine, so long as Cloudron doesn't try install it again...

Not sure if this can be a problem or not...

I ended up doing pretty much exactly that. Configured DNS at Hetzner as it should have been, swapped NS records, and prayed. Then I let Cloudron loose on it too. Guess this can be considered solved.

I recently switched to using managed DNS for a domain. The domain in question is configured to use outbound-only mail via an external SMTP server, as I have mail already hosted elsewhere. Isn't it wrong that I got an SPF record automatically created for this domain, then?

Hmm, I guess Hetzner let me fix their side of it without NS records being set up. So I could:

• clone the appropriate records from my current DNS provider, and ensure they resolve as I expect
• repoint NS records to Hetzner
• wait for propagation of the NS record change (?)
• change Cloudron's DNS configuration

Any other/better options?

I have a domain, which is currently set up on the Cloudron side via "Wildcard". This setup has worked fine in the past because I've been blessed with a static IP address, but unfortunately that won't be the case in the near future, so I figure I need to migrate to something.

In the past, I've used Hetzner for hosting some stuff, so I already have an account there. I created a DNS API token, and tried to switch my domain to use Hetzner for setup. However, this fails with the error message "Domain nameservers are not set to Hetzner".

I can kind of understand why this is checked and an error raised, but on the other hand, it's a bit of a problem, as I guess it means that I'll need to switch NS over to Hetzner before there are any records created there by Cloudron, which means downtime...

It ,might be kind of nice to have a way to force this somehow, like "Yes, I know what I'm doing, I'm migrating to this DNS provider, please just create the right records" checkbox, or something... Or am I missing something else here?

I haven't seen anything like that personally. My usage is always pretty stable (see below). Perhaps it's down to an app you have installed, or something you configured in one of them?

You can find the referenced documentation for the docker addon at https://docs.cloudron.io/packaging/addons/#docker nowadays.

I'm also a big fan of automatic reboots. Both to keep things updated, but also because in my opinion, the more often something restarts, the less likely you are to get bitten by somehow relying on stale state.

(Meaning, you're more likely to notice that something no longer restarts immediately after it breaks, rather than 3-4 months down the line when you no longer remember what you changed :))

@nebulon The way I was thinking about this working would be to leave this entirely up to the apps rather than involving box/db in this much at all. Come up with a decent abstraction for it, and offering that as part of the manifest perhaps? Something like this:

"credentialSetup": {
	"path": "/app/code/foo",
        "arguments": [ "--user", "CLOUDRON_INSTALL_USER", " --password", "CLOUDRON_INSTALL_PASSWORD" ],
	"username": {
	    "default": "admin",
	    "canChangeAtInstallation": true,
	    "canChangeAfterInstallation": true,
	},
	"password": {
	    "default": "changeme",
	    "canChangeAtInstallation": true,
	    "canChangeAfterInstallation": true,
	}
}

Use would be as follows.

On install, check for credentialSetup presence.
If it's not present, then don't do anything.
If it's present, validate it (path must be present).

If at least one canChangeAtInstallation is true, then show a workflow asking them to set up an account/password before allowing the thing to be started.
The initial value for fields is set to its default if present (we should ideally not provide a default password, but it's just there for completeness).
If a field doesn't have canChangeAtInstallation, then it is set to read-only.

(The same logic exists for AfterInstallation, but it's separate in my manifest suggestion, as I can imagine that some apps won't be able to allow changing either user or password easily. But this could also be done later, as a separate feature. I think the installation flow is the most important part.)

When the user enters the login information, run credentialSetup.path in the image, replacing CLOUDRON_INSTALL_USER and CLOUDRON_INSTALL_PASSWORD in any of the arguments with the user-provided information.

Treat exit code 0 as "login information was successfully set", anything else is an error (and intercept anything on stderr back to send back to the user).

--

This will rely on then updating apps to have a helper script to actually make this work, but it's a low priority task anyway...

... and I guess it would also mean that older box's wouldn't be able to install apps updated to use this, unless they still also defaulted to admin/changeme on the image itself, but that's not really a problem I think.

I haven't used the command line tool for a while. I tried to use it today, and was greeted with this: Failed to get apps: 401 message: No such token. Logging in again fixed it.

I think this was an expired token, so it might be the 401 response is wrong. It would also be great if there was some handling/translation of the error codes on the cli side for user-friendliness.

Thanks for the quick response!

@girish I patched my docker.js manually, and I can confirm that port 53 is now exposed on all interfaces, as I would expect! Thanks!

A number of applications don't have LDAP. This is unfortunate, but what really makes me nervous is the "admin/changeme" credentials that are used by default in a number of applications.

I understand why this is, but I don't think it's a great solution. I think that a better solution for these cases would be to suggest (or perhaps even require) that a password should be provided during setup, ideally before the image is ever started, so there's no window where someone can log in and cause mischief.

I guess this would require an install step per-app (to e.g. chuck the password through htpasswd, or whatever the application requires, and then figure out where in the target image to stick the password...) - but I think this would be way better than the current day situation, if not quite as perfect as the grand single-signon utopia I'd like to see.

Noticed this in my journal log. Not sure if it's important or not.

Aug 11 22:26:22 cloudron.xxx collectd[915384]: WARNING: Error loading config file: .dockercfg: $HOME is not defined

@nebulon Kind of depends on the app type, too, I guess? The one I really notice this stand out on is for LAMP. I have maybe 4-5 of these, all serving static sites. I don't really care when they update, but whenever they do, I get a bunch of notifications for them all at once.

I don't know. I guess I see your point, and maybe it's fine to just leave it be. Ultimately, I guess if you don't design for people to have too many things of the same type, it probably won't matter anyway.

@girish Yeah, I can understand this would be complicated. And like I say, it's not super important, so feel free to just stick it on the backburner...

I don't know if you store additional metadata about notifications, so excuse me if I'm wildly idiotic, but I wonder if you could store a JSON object or something along with the notification's data, containing the following:

• that it's an update notification
• of a given app id
• to a given app version
• applied to a list of 'n' locations

like:

extra_data: {
"type": "app_update",
"app_id": "com.foo.Bar",
"app_version":"1.0.0",
"installed_locations":[...]
}

Then, you'd want to scan unread notifications for a matching:

• type (app_update)
• of the same app id/version
• and if it all matched, append to the locations, and regenerate the body based on the installed_locations & changelog, rather than submitting a new one.

Not straightforward, and not really a reusable solution, though...

@girish Yeah, binding to all interfaces would work for me. And I think it's reasonable enough to assume that Cloudron can "own" any interfaces it is given access to, just like a 0.0.0.0 bind would normally, so that seems fine...

Some searching finds me this, which looks potentially useful:

https://serverfault.com/questions/1019363/using-ip-address-show-type-to-display-physical-network-interface

The one liner given there (with jq) does indeed report only the two physical interfaces I have:

# ip -details -json link show | jq -r '
> .[] | 
>       if .linkinfo.info_kind // .link_type == "loopback" then
>           empty
>       else
>           .ifname
>       end
> '
enp1s0
enp2s0

The recent improvements to notifications are great, but I have one more candidate that I think could be improved.

If I have multiple installs of the same app (a good example might be Wordpress, or LAMP) on different locations, it might be nice if an upgrade notification for all those locations was grouped into one, rather than triggering a notification per location.

Rather than this:

Title: $appname at $applocation updated to $appversion (package version $packageversion)
Body: The application installed at https://$applocation was updated.

Changelog:

...

How about this?

Title: $appname at len($locations) locations updated to $appversion (package version $packageversion)
Body: The application installed at the following locations was updated:

• https://$applocation1
• https://$applocation2
• https://$applocation3

Changelog:

...

I guess this is very low priority, and might be a bit tricky to accomplish easily, but I think it would be a very worthwhile addition to larger installs with many apps of the same type.

I tried installing AdGuard Home to give it a try. However, I noticed that I wasn't getting any responses to DNS queries I was throwing at the Cloudron machine. I connected in through ssh, and checked netstat -anlp, and saw that port 53 was only bound on one of the two interfaces that machine has.

I went digging, and found that src/docker.js treats port 53 in a special manner (see getLowerUpIp). This doesn't work for my specific case, where I have two interfaces, and one of those interfaces is for a special internal-only purpose and doesn't really have any external network access.

I'm not sure how this could best be resolved. I guess the easy solution might be to bind to all external interfaces, rather than just the first?

@girish Yes, that would have been the case. Sorry for not responding here, real life has been busy the past few days

Thanks for the fix!

After upgrading to 6.3, I have a single app (Gitea) that seems to be sending upgrade notifications constantly - apparently 4 times a day or so. Not sure what the root problem is there - please let me know if I can be of any help.

@girish Fix seems to have worked for me, thanks!

For satisfying my own curiosity, can you explain why using the mountpoint method was no longer sufficient?

@girish Yeah, I'm using uid=yellowtent,gid=yellowtent, so I think that is indeed my problem

@nebulon said in Backups appear to not work after upgrade:

@robin Is that mountpoint by any chance sshfs?

Yes, it is indeed sshfs

As the title says...

Provider mountpoint
Location /mnt/ibt/backup
Storage Format rsync
Encryption is enabled if that matters.

I'm getting this as a notification:

Unable to chown:EACCES: permission denied, chown '/mnt/ibt/backup/snapshot/app_22f1c4f7-7480-405d-aae9-258e7cc5cee7/O4m2+us4iuqCWWOtbom2RZncffaPgi9HNTF936n7CaU'

However: I think the error is incorrect, or weird, or something, though, because the permissions are most definitely correct. Cloudron is the only thing that ever touches that mountpoint, and it has access to do whatever it wants:

-rw-r--r-- 1 yellowtent yellowtent 3732 Jul 9 15:41 /mnt/ibt/backup/snapshot/app_22f1c4f7-7480-405d-aae9-258e7cc5cee7/O4m2+us4iuqCWWOtbom2RZncffaPgi9HNTF936n7CaU

I tried removing the problematic file, and forcing a new backup, but the same error happened again.

@girish Yeah, I ran:

/home/git/gitea/gitea convert -c /run/gitea/app.ini as user git, and now things seem converted:

ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci ROW_FORMAT=DYNAMIC

On the downside, the convert tool seems to unconditionally convert, and is quite slow, so I guess it can't easily be run as part of the startup process or something

Searching around their issues, I find this: https://github.com/go-gitea/gitea/issues/11081

My existing install has this:

ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC |

So perhaps this might have been a bug that they corrected in a release sometime after I had already installed?

Long story short, I've got some problems with encoding.

See the following Github issue: https://github.com/go-gitea/gitea/issues/16016
Which links to the following solution: Are you using MySQL? If so you probably need to convert the tables to utf8mb4, gitea convert can help with that but take a backup before doing it.

I don't remember enough about MySQL anymore to know how to look into this myself, but I'm happy to try help test if you want to try hold my hand, @girish

Should be fixed in the next Koel release, I guess: https://github.com/koel/koel/pull/1306

@girish I just got this to happen again immediately after a Cloudron host reboot. Could it be that Cloudron tries to start Koel too early, before MySQL is ready for connections?

(And could this be a problem with other applications, too, if so?)

If an app outputs a reasonable volume of logging (let's say, a few hundred lines), the performance of a browser tab viewing those logs seems to bog down pretty seriously over time.

I don't know for sure how the viewer is implemented, but if it's trying to keep the entire log content loaded, that might be a problem with some more chatty apps. And if it's trying to keep it all in the DOM, that's also perhaps a problem.

I imagine this isn't an easy problem to solve, just thought I'd report it

(I'm using Firefox if it matters).

Potential patch here: https://github.com/rburchell/koel/commit/21dadd1363e1534e81a8e6b125a22a7aeb27508a, I'll try find the time to shepherd this upstream in some form.

Not sure if it makes sense to also consider some actions on the Cloudron side. It strikes me that it is a bit fragile to have an 'env' file that is modified by the application, but with this particular bug fixed in Koel, I guess it wouldn't be a problem anymore...

Yep, steps to reproduce:

• Set up a koel instance
• Open a terminal, edit /app/data/env
• Break one of the database variables (I added an 'x' at the end of DB_DATABASE I think)
• Restart Koel, and watch as your logs explode your browser, and Koel doesn't recover

I guess this MIGHT conceivably be a Koel bug: I think that it should not endlessly try to connect to the database when not run in interactive mode. And it should also probably not write the database environment variables in such a mode...?

@girish Theory: setUpDatabase in app/Console/Commands/InitCommand.php calls setKey() to alter the env file.

setUpDatabase is called from maybeSetUpDatabase, if the PDO connection throws an exception. My guess is that the database connection dropped right when Koel was starting up, and it responded by setting the environment variables to empty (since it's run in non-interactive mode), and wrote those to the env file?

Another finding, from reading Koel's documentation:

https://docs.koel.dev/#streaming-music

Use native PHP readfile(). This is the default method, and the slowest and most unstable one. Only use this method if you can't others.

Might be nice to look into changing STREAMING_METHOD, assuming that it's easy to enable?

I started experimenting with Koel recently, just to take a look at it. I don't know exactly what I've done in the web UI, but when restarting Koel, it was broken, and stuck in an endless loop with this in the logs:

Koel cannot connect to the database. Let's set it up.
Database hosts array is empty.

Koel cannot connect to the database. Let's set it up.
Database hosts array is empty.

Koel cannot connect to the database. Let's set it up.
Database hosts array is empty.

Also may be worth noting that the logging was happening so fast, it was impossible to view it in Cloudron's viewer (kept killing my browser).

Checking around, I noticed that /app/pkg/env.template and /app/data/env had some suspicious changes (note, I removed the APP_KEY entry just in case that's sensitive):

--- env.template        2020-10-31 05:21:45.000000000 +0000
+++ /app/data/env       2021-04-10 07:14:34.260807115 +0000
@@ -8,14 +8,14 @@
 #   sqlite-persistent (Local sqlite file)
 # IMPORTANT: This value must present for artisan koel:init command to work.
 DB_CONNECTION=mysql
-DB_HOST=${CLOUDRON_MYSQL_HOST}
-DB_PORT=${CLOUDRON_MYSQL_PORT}

-DB_DATABASE=${CLOUDRON_MYSQL_DATABASE}
-DB_USERNAME=${CLOUDRON_MYSQL_USERNAME}
-DB_PASSWORD=${CLOUDRON_MYSQL_PASSWORD}
+DB_HOST=
+DB_PORT=
+DB_DATABASE=
+DB_USERNAME=
+DB_PASSWORD=
 
 # A random 32-char string. You can leave this empty if use php artisan koel:init.
-APP_KEY=
+APP_KEY=base64:xxxxxxx
 
 # Another random 32-char string. You can leave this empty if use php artisan koel:init.
 JWT_SECRET=
@@ -139,4 +139,3 @@
 MAIL_ENCRYPTION=
 MAIL_FROM_ADDRESS=${CLOUDRON_MAIL_FROM}
 MAIL_FROM_NAME=Koel
-

Sure enough, when I added the database environment entries back, start.sh successfully worked. My guess is that something (Koel itself?) rewrites /app/data/env on some condition in the UI, and it doesn't manage to keep the environment variables there when it does that.

@atrilahiji Well, you also don't really need to compete with Signal if you can use it as a trojan horse using e.g. https://docs.mau.fi/bridges/python/signal/index.html. Of course, this comes with its own set of challenges: making a good experience with many moving parts is not easy - and bridges are inevitably another moving part, often of questionable quality since they aren't a primary focus.

Sometimes, there are notifications, like this one:

Failed to new certs of xxx: Unexpected status: invalid. Renewal will be retried in 12 hours

These often require extra context to understand what went wrong, or how to rectify the problem (for many backup failures, for example).

It would be great if the notification provided some sort of a pointer to jump into Cloudron's logs at the time of the event in this case, to dig into the problem further.

I haven't had a chance to look at authentication (or anything else, really) yet unfortunately. Life's been busy.

I did push up what I appear to be running, though, I haven't had a chance to test it independently (I am not using your repo directly, but a rather customised setup, so I copied my changes into it by hand).

You can see my fork here: https://github.com/rburchell/cloudron-influxdb

@nebulon My thinking for write protection was actually that it could - literally - use filesystem permissions rather than introducing a database. Check if the file is writable before deleting/writing, and fail if it isn't writable (or offer to override, which will have to chmod +w it)

https://github.com/damoeb/rss-proxy

Looks like an interesting tool. Also has a docker-based workflow, so might not be too hard to package up

Just brain-dumping from trial and error session...

For authentication, start without auth first. Then connect influx client, and run:

CREATE USER admin WITH PASSWORD 'foobar' WITH ALL PRIVILEGES;

Then, you can safely enable auth (set the config keys `http/auth-enabled, http/pprof-auth-enabled to true), and will need that user/pass to run any queries.

Not sure if there's an easier way or not... If there isn't, perhaps this could be done via start.sh somehow - detect that a given launch is the first one (if the db doesn't exist yet) - start it, create an admin user, then stop & restart with auth enabled.

@doodlemania2 I will try to do so if / when I can get the time to finish poking around, and verify that it actually works once I finish. I just had a child last week, so spare time is a bit hard to come by at present

I think you may want to use "healthCheckPath": "/health", rather than /metrics, as that endpoint is actually designed for this use.

Some other confusion: influxd 1.x uses a different configuration format, so I think config.json isn't really useful, as JSON is 2.x and up (I am not certain, I have only used 1.x so far).

Run /app/code/influxd config to get a snapshot of the default configuration.

Once I had that in place, lastly, for whatever reason, I had to pass the config file explicitly as a parameter rather than using the environment variable you were trying: exec "/app/code/influxd" -config /app/data/influxd.conf in start.sh.

Some other configuration recommendations/thoughts:

• I think you should probably also recommend (or somehow, require) authentication, along with creating a default user account, since this is probably going to be run on public-facing servers. For 1.x, see here.
• You should also consider setting reporting-disabled = "true" in the configuration, to prevent phoning home. See the documentation notes here.

A few other small suggestions while I'm thinking of it:

• It would be nice if the admin UI had the ability to multiselect (and perhaps "select all") files, to delete a bunch of stuff at once.
• It would be neat if it were possible to write-protect a file to prevent it being overwritten or deleted without removing the write protection

Some feedback, based on having tried out surfer (great little app, by the way!)

• The "App passwords" dropdown for a surfer instance mentions SFTP, which seems a little wrong.
• It might be useful to mention _webdav in the documentation, as an alternative for interacting with surfer?
• It would be great to be able to customize the handling of some mimetypes. For example, when uploading a QML file, surfer will serve it up with application/octet-stream, rather than a text type, which makes browsers offer to download it, which is a bit annoying given how they are basically just text.

Lastly, a small script here for anyone who wants basic "upload this file" functionality but cannot use npm for whatever reason. You are expected to have a file ~/.surfer/auth with two lines (user/pass), and ~/.server/server which contains the bare hostname to upload to. You can use Cloudron's app passwords feature to avoid using your "regular" password, for some added paranoia.

#!/usr/bin/env bash
set -euo pipefail

user=$(head -n1 ~/.surfer/auth)
password=$(tail -n1 ~/.surfer/auth)
server=$(cat ~/.surfer/server)

# the file to upload...
FILE=up.sh.txt
curl -T "$FILE" -u "$user:$password" https://$server/_webdav/
echo "Uploaded to https://$server/$(basename $FILE)"

Cloudron sends health check notifications for each app ("App xxx is down / back online"). In normal use, this is quite useful, but when working on my Cloudron machine (rebooting it, or whatever), I then get a flood of emails for each application, so my inbox looks like:

Aaa is back up
Bbb is back up
Ccc is back up
Aaa is down
Bbb is down
Ccc is down

Suggested improvements:

• Perhaps it might make sense to delay the activation of health check alerts until (host or app) uptime is over a certain value?
• Consider merging notifications for multiple applications into one (or at least, one mail)

I haven't seen the high cpu usage as such

Might be that this is due to the differences in HW config we're running on? As I understand it, this will "scale up" based on the number of cores you have. I'm running on a Threadripper, which has rather a few of them.

Trying to install the fixed version now, observations:

• Before install, beam.smp is taking up a steady 6% CPU
• After upgrading (via cloudron update --app xxx --appstore-id com.onlyoffice.coudronapp@1.6.1), CPU use is more or less nonexistent: I no longer see it in the top consumers at all

So I think this looks successful

Hi,

I noticed that beam.smp is using a lot of CPU inside my cloudron instance. I tracked this down to belonging to onlyoffice, and doing some further digging, I found this post that might be interesting.

tl;dr:

When I set the number of scheduler threads to 1 the CPU usage dropped from 23 % to 3 %.

Setting RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS="+S 1:1" apparently does the trick, and there's a linked issue on the onlyoffice github that appears to do exactly that as a part of their Dockerfile.

I'm unsure how to test this, but perhaps this may be the same issue / fix for Cloudron's case, too?

Yes indeed, a title was also missing. I assumed it was the ID when I went doc searching, but of course title makes more sense. Thanks