Cloudron App Packagers
@svallory If I understanding correctly, you want to specify the setting names like S3/SITE_NAME/SITE_DESCRIPTION etc and then these variables can then be configured by UI ? Also, I guess you are expecting these variables to become exposed as environment variables to the app?
Haven't tried but echo "yes" | ./cloudron-setup probably works as well to automate reboot.
@d19dotca said in Server Replication for DNS Failover purposes?:
This might be where Cloudron's multi-server functionality may help
Whenever I read about it, it was more about distributing the load over multiple servers, and not about higher availability/failover (although for at least the user management it may be required).
HA strategies can also be quite different depending on the application itself, so I doubt that there is a "one size fits all" solution to this.
@eddowding ah, great you managed to figure this out. indeed, cloudflare can only proxy http(s) and not email.
@lonkle TBH, we don't really test on any system other than ubuntu. Most likely other platforms don't work. Even on ubuntu derivatives like mint, it is known to not work.
@d19dotca I think your understanding is correct. It's definitely possible to have all the UIDs in sync. However, most of the addon (mongo, postgres, redis) etc users don't exist on the host at all and only exist in containers. So, we will then have to create these dummy users on the host etc.
@d19dotca These directories are created and managed by dovecot. The permissions on a quick look seems fine to me, what is it that you are trying to solve? Or are you just wondering why those permissions are like that?
@svallory check out the environment vars i am using in start.sh here to automate the setup and config changes: https://git.atridad.dev/alt-ron/cloudron-humhub-app/-/blob/master/start.sh
@mehdi only thing I can see is the S3 stuff I guess.
Taking a quick look at a repo, I am not sure which precise values you expect the user to tweak.
Cloudron's philosophy in these sorts of cases is to automatically configure what can be auto-configured (SMTP, domains, DB ...), chose reasonable defaults for the rest, and possibly allow advanced users to tweak the configuration by editing a file in /app/data manually. The start.sh of your app can check if a custom config file exists in a pre-defined location, merge it with the defaults, write the result in a temp file, and use this temp file for the actual app.
