I'm not sure I'd want fancy, distributed filesystems on by default for most apps. I feel like most apps would need custom changes to explicitly support distributed storage, and I'm skeptical that a blanket drop-in distributed-fs solution could meet the performance and reliability needs of the diversity of cloudron users.

I'd rather have multi-node app management than distributed app runtime. Manage all your cloudron nodes and assign apps between them, migrate them etc, but most apps can still only be deployed to one cloudron instance at a time. At least I think this would be a better scaling/ha goal for a v1 implementation.

I recently encountered some issues after I switched from wildcard DNS configuration to provider-based automatic DNS configuration.

When you create an app with provider-DNS configured, cloudron will use your provider's API to automatically create the DNS subdomain record to point to your server so cloudron can serve the app. But if you create the app while you have wildcard DNS configured, no specific subdomain will be created. This is expected.

However, if you create the app under wildcard-DNS, then switch to provider-DNS, then the subdomains that would normally have been created when running under provider-DNS are not created automatically when switching between DNS configurations. This can cause a problem when the user deletes their wildcard DNS record because they assume that Cloudron will use provider-DNS to provision DNS entries for all apps.

I propose that Cloudron add a feature to check the DNS entries and reprovision DNS records as required when the user switches DNS configurations. I could imagine this could be implemented by triggering automatically as soon as the user switches DNS configurations, or as a button on the dashboard to recheck that dns entries for all apps are correctly assigned (including my.).

@plusone-nick said in Proposal: Free-Tier Alterations :

It was more of a "its the free tier so its their problem to deal with" proceed at your own risk but fully rethinking it again that might be a good recipe for disaster, leaving people out to dry.

I'm glad you came around, this is definitely the better way to think about it. Sure, the license terms may say that you're on your own, no support etc; but users don't interact with license terms, they interact with your product. If someone has a bad time because of choices you enabled them to make with your product, somebody has to pay something ($, time, ...) to fix it, be it staff, the community, or even the product's reputation. I hope the team avoids going into future-support-debt in exchange for a short-term growth spurt.

I use Roam Research and it's nice for notes, but it's expensive, not self-hosted, and not foss.

There is also Logseq, which is foss roam research alternative that syncs to github that I've tried and like. It's not quite as polished, but it's very new, and imo would be worth it to gain self-hosting. One of the things I was hoping to do when I decided to try cloudron was wrap up logseq into a cloudron app and publish it. But to fully connect the dots here, I'd prefer if it synced to gitea on my cloudron instead which I don't think it currently supports.

If we ever get the code-server app rolling, maybe a combo code-server + foam vscode extension could be interesting here.

I started my configuration out with wildcard setup, but then decided to switch to provider-based dns after installing a couple apps. Then I deleted the wildcard DNS record and tried to use the apps...

These are two minor issues which I was able to solve, but which I didn't see explicitly noted anywhere.

1. Some apps stopped working after I removed the wildcard domain.
   This was solved by going to each app's Location settings page and clicking save, which I guess does the dns setup that is otherwise only done on app initialization.
2. my.example.com stopped working
   Creating the record manually was easy enough, and once propagated it worked fine.
   On second thought, I probably could have gone to https://ip and done... something else on the dashboard. (Maybe save on the domain page?)

I think it would be neat if Cloudron performed these steps automatically when switching from wildcard to provider-based dns.

@imc67 I think password changes would require the user to always type in their old password. The password-derived key could be used to encrypt a second, randomly generated key that is the actual key for encrypting emails, that way a password change would only require re-encrypting the random key, not the whole mailbox. Password resets by admin would be impossible unless you did something like encrypt the old key with a key derived from the admin's password too.

What about this: self-host your email storage & webmail, but have a cloudron running on a $5 vps that acts purely as a personal SMTP relay with pinned IP. Emails are never stored on disk, so at most a spying host can only see new correspondence as it flows. (Not perfect, but it's an improvement on just giving up.) Can cloudron be configured as an email relay for another cloudron? It would be nice if you could do that with the free version.

I think it would be nice if more apps supported the option to switch to proxyAuth+X-REMOTE-USER-based authentication for multi-user apps. I prefer proxy-based auth for a couple reasons:

• I don't trust the login page and password handling to apps. Even if they auth via ldap -- they're still touching the password. Proxy auth eliminates this problem altogether, since they only receive the attestation of the user's identity (the header), no secrets, no cookies. I trust the proxy's auth login page way more.
• Ideally the app is never even accessible to the outside world until you're logged in. Apps often have vulnerabilities that can expose data even if you're not logged in. By putting the app behind an authenticating proxy, one can shield it from general internet access, narrowing the scope of attackers from "everyone that can access my ip" to "users on my cloudron" -- a large improvement.
• It's by far the easiest auth system to implement first if you write something custom.

Of course, all apps may not support this yet, and sometimes you do want a public-facing service, and some apps could never work like this (bitwarden), etc, hence "optional".

Thanks @girish, I created a feature request here!

@scooke, Cloudron would know when the user switches DNS configurations when they choose a different provider on the "Domains & Certs" settings page for their domain.

@nebulon said:

we don't overwrite existing DNS records, if they were not setup by Cloudron as such, to mitigate the risk of breaking a mixed setup.

That makes a lot of sense. Curious, does Cloudron log when it encounters an existing DNS record that it should not overwrite?

It seems to be a v2/v3 split. From https://github.com/kerberos-io/opensource/blob/master/README.md (emphasis mine)

Kerberos Open source (v3) is a cutting edge video surveillance management system made available as Open Source under the MIT License. This means that all the source code is available for you or your company, and you can use, transform and distribute the source code; as long you keep a reference of the original license. Kerberos Open Source (v3) can be used for commercial usage (which was not the case for v2). Read more about the license here.

To me (IANAL, etc) it seems the license shouldn't be a particular problem as long as it's based on v3.

Hi!

I'm interested in using git LFS storage from my gitea app but I'm worried that my server could run out of space with many large files. Gitea supports any s3-like storage as a backend for LFS and attachments (see Gitea Config Cheat Sheet). So, using the gitea app terminal I edited /app/data/app.ini to add the following configuration and restarted gitea from the dashboard:

[server]
LFS_START_SERVER = true

[storage.my-storage]
STORAGE_TYPE = minio
SERVE_DIRECT = true
MINIO_ENDPOINT = s3.us-west-001.backblazeb2.com 
MINIO_ACCESS_KEY_ID = {secret-id}
MINIO_SECRET_ACCESS_KEY = {secret-key}
MINIO_BUCKET = my-bucket
MINIO_LOCATION = us-west-001
MINIO_USE_SSL = true

[lfs]
STORAGE_TYPE = my-storage

[attachment]
STORAGE_TYPE = my-storage
MAX_SIZE = 50

And it seems to work, great! Yes, I'm actually using backblaze b2, because it's much more cost efficient than amazon's service. Yay compatibility!

• One question: is /app/data/app.ini the correct place to add gitea custom configurations?

@mehdi said in proxyAuth addon:

It's by far the easiest auth system to implement first if you write something custom.

I don't think it is.

I'm just saying that if you can build your app assuming it's behind an authenticating reverse-proxy, it frees you from a LOT of work designing a system to authenticate the user with credentials or whatever. It's just username = request.Headers["X-Forwarded-User"], done. No validation, no encryption, no hmac, no password hashing function, no password storage, no password resets, etc etc etc

I did some searching ("reverse proxy authentication", "header proxy auth"). I offer these examples for your consideration:

• open source Kanban project management software Kanboard
  • REMOTE_USER
• Jenkins
  • X-Forwarded-User
• Docker suggesting using it to secure access to a registry (Not sure how applicable this one is.)
• Microsoft recently published some docs on how to configure Azure AD to do proxy auth, as well as another article
• Authelia (?)
• Some Oracle enterprise apps
• Some stack overflow questions in this area:
  • https://stackoverflow.com/questions/33368653/how-do-i-set-remote-user-in-a-http-header
  • https://serverfault.com/questions/180726/remote-user-through-apache-reverse-proxy

Perhaps this solution is more common in enterprise apps. Probably for the security reasons I mentioned before.

There's also RFC 7615 / Proxy-Authenticate on MDN which seems related.

Thoughts?

Edit also:

• Galaxy Project (?)
• odoo community (?)
• shibboleth (?)

I think it would be nice if more apps supported the option to switch to proxyAuth+X-REMOTE-USER-based authentication for multi-user apps. I prefer proxy-based auth for a couple reasons:

• I don't trust the login page and password handling to apps. Even if they auth via ldap -- they're still touching the password. Proxy auth eliminates this problem altogether, since they only receive the attestation of the user's identity (the header), no secrets, no cookies. I trust the proxy's auth login page way more.
• Ideally the app is never even accessible to the outside world until you're logged in. Apps often have vulnerabilities that can expose data even if you're not logged in. By putting the app behind an authenticating proxy, one can shield it from general internet access, narrowing the scope of attackers from "everyone that can access my ip" to "users on my cloudron" -- a large improvement.
• It's by far the easiest auth system to implement first if you write something custom.

Of course, all apps may not support this yet, and sometimes you do want a public-facing service, and some apps could never work like this (bitwarden), etc, hence "optional".

I use Roam Research and it's nice for notes, but it's expensive, not self-hosted, and not foss.

There is also Logseq, which is foss roam research alternative that syncs to github that I've tried and like. It's not quite as polished, but it's very new, and imo would be worth it to gain self-hosting. One of the things I was hoping to do when I decided to try cloudron was wrap up logseq into a cloudron app and publish it. But to fully connect the dots here, I'd prefer if it synced to gitea on my cloudron instead which I don't think it currently supports.

If we ever get the code-server app rolling, maybe a combo code-server + foam vscode extension could be interesting here.

I've been struggling with how to pronounce it as well; so far my internal monologue has been settling in the direction of "Andre-a // Git-eh-ah", but stealing the t from git: "Gi-tee-ah". It doesn't sound like it has "git" anymore, but at least there's "tea". Have the devs given any talks on Gitea? I'd rather settle on something instead of sounding it out 4-5 times every time I read it lol

Hi!

I'm interested in using git LFS storage from my gitea app but I'm worried that my server could run out of space with many large files. Gitea supports any s3-like storage as a backend for LFS and attachments (see Gitea Config Cheat Sheet). So, using the gitea app terminal I edited /app/data/app.ini to add the following configuration and restarted gitea from the dashboard:

[server]
LFS_START_SERVER = true

[storage.my-storage]
STORAGE_TYPE = minio
SERVE_DIRECT = true
MINIO_ENDPOINT = s3.us-west-001.backblazeb2.com 
MINIO_ACCESS_KEY_ID = {secret-id}
MINIO_SECRET_ACCESS_KEY = {secret-key}
MINIO_BUCKET = my-bucket
MINIO_LOCATION = us-west-001
MINIO_USE_SSL = true

[lfs]
STORAGE_TYPE = my-storage

[attachment]
STORAGE_TYPE = my-storage
MAX_SIZE = 50

And it seems to work, great! Yes, I'm actually using backblaze b2, because it's much more cost efficient than amazon's service. Yay compatibility!

• One question: is /app/data/app.ini the correct place to add gitea custom configurations?

@girish said:

do you know if these extensions are run in-process or out of process?

Looking through the extensions it appears all of them are defined as separate docker containers, so "separate process". I think Matrix's general strategy is to allow plugging in to the server via api, instead of modifying the server itself.

I'd be interested in all the bridges, though there are a lot. If we're not careful, we'll have 20+ apps just for matrix.

https://matrix.org/bridges/

Thanks @girish, I created a feature request here!

@scooke, Cloudron would know when the user switches DNS configurations when they choose a different provider on the "Domains & Certs" settings page for their domain.

@nebulon said:

we don't overwrite existing DNS records, if they were not setup by Cloudron as such, to mitigate the risk of breaking a mixed setup.

That makes a lot of sense. Curious, does Cloudron log when it encounters an existing DNS record that it should not overwrite?

I recently encountered some issues after I switched from wildcard DNS configuration to provider-based automatic DNS configuration.

When you create an app with provider-DNS configured, cloudron will use your provider's API to automatically create the DNS subdomain record to point to your server so cloudron can serve the app. But if you create the app while you have wildcard DNS configured, no specific subdomain will be created. This is expected.

However, if you create the app under wildcard-DNS, then switch to provider-DNS, then the subdomains that would normally have been created when running under provider-DNS are not created automatically when switching between DNS configurations. This can cause a problem when the user deletes their wildcard DNS record because they assume that Cloudron will use provider-DNS to provision DNS entries for all apps.

I propose that Cloudron add a feature to check the DNS entries and reprovision DNS records as required when the user switches DNS configurations. I could imagine this could be implemented by triggering automatically as soon as the user switches DNS configurations, or as a button on the dashboard to recheck that dns entries for all apps are correctly assigned (including my.).

I started my configuration out with wildcard setup, but then decided to switch to provider-based dns after installing a couple apps. Then I deleted the wildcard DNS record and tried to use the apps...

These are two minor issues which I was able to solve, but which I didn't see explicitly noted anywhere.

1. Some apps stopped working after I removed the wildcard domain.
   This was solved by going to each app's Location settings page and clicking save, which I guess does the dns setup that is otherwise only done on app initialization.
2. my.example.com stopped working
   Creating the record manually was easy enough, and once propagated it worked fine.
   On second thought, I probably could have gone to https://ip and done... something else on the dashboard. (Maybe save on the domain page?)

I think it would be neat if Cloudron performed these steps automatically when switching from wildcard to provider-based dns.