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

Large filenames cause problems, especially with blob-based storage (e.g. S3-compatible services have a key limit of 1024). This gives problems quite easily with hierarchical storage like syncthing where one might have a set of nested folders that quite easily hit that key limit, especially combined with encryption.

Disabling encryption altogether is not desirable in many cases, but it could be worthwhile to allow disabling filename encryption, in some cases.

(As a longer term project, it may also be worth considering ways to circumvent this limit altogether.)

See https://forum.cloudron.io/topic/3050/backup-feedback-minio/ for the initial discussion leading to this request.

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

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

@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

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

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

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.

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?

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.