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

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.

@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

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

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)

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.

@nebulon said in OpenHAB not starting after installation:

gosu cloudron:cloudron /app/code/runtime/bin/karaf daemon

Weird.. When I ran /app/pkg/start.sh in recovery mode, I got this:

==> Ensure directories
==> Changing ownership
==> Starting OpenHAB
Killed

When I started the last command by hand, it actually seemed to run okay (at least, no output, and it didn't get killed...

I had a hunch that maybe it was getting OOM killed, and sure enough, I raised the memory allocation to 512m, and it now seems to start successfully, so maybe the default allocation (256m I think it was?) is just a little too low to start, sometimes?

I've installed it, but in the dashboard, it stays in state "Starting..." and the web UI never comes up. Running Cloudron v7.3.4 on 20.04.1 LTS.

Logs says this (in a loop), unfortunately, without more details:

Dec 12 22:20:28 ==> Ensure directories
Dec 12 22:20:28 ==> Changing ownership
Dec 12 22:20:28 ==> Starting OpenHAB
Dec 12 22:20:34 ==> Ensure directories
Dec 12 22:20:34 ==> Changing ownership
Dec 12 22:20:35 ==> Starting OpenHAB
Dec 12 22:20:42 ==> Ensure directories
Dec 12 22:20:42 ==> Changing ownership
Dec 12 22:20:42 ==> Starting OpenHAB
Dec 12 22:20:51 ==> Ensure directories
Dec 12 22:20:51 ==> Changing ownership
Dec 12 22:20:51 ==> Starting OpenHAB

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