I'm reworking this now that 6 is out and proxyAuth is an option. Currently got the latest version building and running on the latest node. Waiting for some details on how to do proxyAuth configuration to not break webhooks (rather important for this one!) and then I'll need to get to fixing up the websockets, but overall is looking okay. Switching from file-based to env-based configuration only because it seems better supported by the docs as well.

Z-Push EAS interface for IMAP/CardDav/CalDAV/LDAP/Kopano/MailDir/SQL/more
https://z-push.org

This is something I've been batting around implementation ideas on for a little while now. There's a ton of variability provider-to-provider to account for on automating some of it, so I was leaning toward more capable cluster managers that are already available off the shelf. Easily the most capable is Kubernetes, but it comes with a lot of added complexity. It's distinctly possible based on the way Cloudron works to entertain some of this stuff, and I've been sketching out a number of different ideas. Nothing is formally roadmapped afaik right now.

That said, it would be helpful in thinking about options what you see as the changes in your experience that these sorts of ideas would enable. Adding an additional node, which seems to be what 3 of your 5 ideas are focused on (load balancing, hot stand-by, and auto-scaling), may or may not be the best approach to minimize downtime depending on how the "normal" use would pan out. It's already not all that difficult to keep an alternate machine restored from backups as a standby, but given the way the system handles app-level failures, it's hard to say in what cases that would be useful; there's added difficulty in reversing that failover and keeping it real-time.

Ultimately, what probably does make the most sense to close the gap on those goals while not messing too much with the underlying architecture and existing packaging is some sort of coordinated cluster manager that keeps the single-container approach but allows the system to reallocate those app containers across k different servers. Something short of Kubernetes could achieve this pretty easily, but will need a lot of work to pull off. For these reasons, I've started looking more at Hashicorp's Nomad as a potential solution to the cluster management side of things, but I'm still in the very early stages of what a Cloudron implementation would look like. At its full potential, this could enable things like multi-region and even multi-provider deployments. Ideally, the details of managing this would be hidden away behind the Cloudron interface, but I've not even yet begun to start spiking out an actual implementation.

I'd love some more thoughts and feedback on the approach generally though!

I had a breakthrough with the dumb websockets issue. Hooray! This one should be ready shortly. I know it's been highly requested and hotly anticipated (for me as well) so it's my top packaging to finish. At this point, after a few other tweaks, I'm fairly sure I've got this working. I'll do some final testing tonight, but I expect that I should have an initial build together by this weekend.

Not only is this an awesome find and great-looking app (wish I knew of this in May), but something I have a distinct use for. As such, I've begun an initial packaging effort.

I've extracted the following from one of my projects: https://gist.github.com/jimcavoli/b390565eb98f62faae821c83c8e87100

It has some added substitution for using secrets for all configurable values (I hard-coded a couple of them in the actual project), but is otherwise exactly what I use. It has a built-in cache registry that tries to minimize the build time, some simplistic retry logic, and as written is triggered when a new release is published on the repo. I've had a pretty good experience using it, so figured it might be handy for others, in case you've got some fully-custom app you're deploying from a private registry. The only built-in assumption is that you use the Dockerfile.cloudron naming scheme, but you could edit that as well if you like.

Given the split of box vs app concerns, and the new addition of being able to separate the mail server from the my subdomain, it would be a great added feature to have the option to check a box for setting up proxied records when using the Cloudflare DNS provider.

Previous discussion: https://forum.cloudron.io/topic/2806/is-the-cloudflare-auto-dns-setup-secure-using-dns-only-as-opposed-to-proxied/

Likewise - this seems tantalizingly close to ready - and it's high up my list of things I'd like to get to deploying. What's the remaining to-do list or best way(s) to contribute at this point?

I would like to be able to configure the autoexpunge option for certain special folders globally for all mailboxes, to allow the mail server to clean up after users who don't purge their Junk or Trash folders periodically. Ideally, this could be optionally configurable for any of the predefined folders so that a clear retention policy, to whatever degree the administrator desires, can be applied to all mailboxes.

So I have an initial packaging for this done at https://git.cloudron.io/jimcavoli/n8n-app

HOWEVER, I'm honestly not sure I'd be comfortable putting this software into production as-is. It's pretty weak on some security features, but maybe its not the end of the world for people and I'm just super paranoid. There seems to be an undocumented way to do JWT auth, which I'm not going to even try to get into that, since I'm only aware of it from looking at the config file handling typescript code. The only supported authentication right now is basic auth as documented - with a single username/password set by ENV or config file (I went with the latter since it's easier for end-users to edit in /app/data/.n8n/config by terminal).

Either way, everything basically works, and by launching via supervisord with the working directory set to /app/data/output we're able to contain its binary file writing to system (probably a bad thing to do in prod as well, but it works).

Custom nodes can be added to /app/data/custom, the config file is JSON at /app/data/.n8n/config, and the package writes cloudron-provided postgresql configuration to that file at launch.

Some stuff only works in Chrome. That's just an issue with the app. Something about they way they're handling web sockets means other browsers see "Connection lost" in the top right, which is where the Activation toggle should be. Most other things actually work fine, but that's necessary for executing workflows in-browser manually and activating them.

I packaged this one because it seems to have some popularity in asks, but it definitely deserves some due diligence before heading to production for anyone or the app store. It's also pre-1.0 so not sure how much is changing how fast, and the setup as is was a pretty delicate thing to get done. Maybe my concerns are overplayed, maybe not, but either way, there's something we can start to kick the tires on for this app now.

@hollosch No, work remains "in progress" for the time being to get a reliable package finished before it heads there. You can keep track by the "WIP" tag on the thread right now - it'll go "Solved" and green once completed

@nebulon Also while X-Frame-Options is not as current as CSP, it's still considered best practice to get more complete coverage for that protection across browsers, especially older ones:

https://caniuse.com/contentsecuritypolicy2
https://caniuse.com/x-frame-options

At least, that's still the case for every audit and best practice list in the circles I'm in. It is still required by the latest ASVS 4.0.2 (criteria 14.4.7) as well (source: en / de). So I'd encourage both. While you're touching the session cookie, you can also probably go SameSite=Strict as well.

@chymian said in Quo Vadis Cloudron?:

none of you, who where so quick with the answers and flames did understand, what my point is!

That's sort of exactly my point. You took a pretty condescending tone with comments like "or do you want to deliver a system, which behaves like a real server" that are just vaguely argumentative, and the whole thing led off with slamming the community for not answering certain questions to your satisfaction. You led right into your opinions of "how a server should behave" and how that isn't this product, peppered with value judgements about different technical specialties. Yes, the reaction was collectively a bit defensive, but I don't think it's a stretch to understand why.

Either way, I still struggle to understand your goal/point/complaint. It seems like perhaps you're just advocating for more configurations for ever more behaviors and included features. There are multiple ways to achieve everything you've discussed. I don't know what the hangup about 2FA is, but the feature you're complaining about is this:

Which seems to be exactly what you think it should be - a setting to require 2FA for users.

There's every choice in how someone wants to manage/monitor their servers. Nothing about Cloudron precludes installing agents for any sort of monitoring/management system whatsoever for the underlying host. Want to wrangle your k hosts with ansible? Fine. Rather prefer DataDog or Nagios or PRTG or whatever? Go for it. If the point is that Cloudron should make more decisions about things like this, I disagree. If rather you think it precludes their use somehow, it does not. If you think that it should make some of its activities more apparent for such tools to notice, I think we'd have an interesting conversation to have. If you meant something else, please explain further, because at this point those are the only parts I understand.

As a professional whatever, I read all of that, and may I just say...uh, what?

Footnote: pretty difficult to imagine "more control" than root, but that's mostly because I don't consider straight assembly into ring 0 a daily-driving sort of necessity.

I agree about Moodle, and I'm a fan of having more choices in every category on the platform generally. Canvas is the leading alternative in terms of upvotes so far, and likely to arrive sooner. Worth taking a closer look - bit overwhelming to go in through Tutor itself - I'd advise anyone looking to go underneath that (massive) installer/abstraction and check out Open edX directly as a starting point. Just .02 from a cursory look; this isn't too high on my list yet, but I'll try to make a deeper evaluation of it soon.

You can't use that particular method of editing the code, but you could look into setting a custom CSP via the app configuration (may need some maintenance to keep everything working in the future) - https://docs.cloudron.io/apps/#custom-csp - You'd need to get a copy of the CSP header being sent by your installation presently, then you can adjust the iframe sources allowed manually and put the entire adjusted CSP in place.

@girish So the gzip failure is independent the staged builds. Arguing with tar/gzip and GitHub about file formats presently, but I can replicate the issue you were having and am testing against the same Dockerfile with and without buildit on, so once I get that sorted, we can regroup and go from there.

Also running a moderately large EspoCRM instance here, plus some more hobby-scale ones, and agree with all the points made so far. Generally, I'm a fan. The Advanced pack and VoIP extensions have been good additions and I've not had any issues with the company behind EspoCRM either. Just works, admittedly with a bit of learning curve to administer, perhaps, as has been mentioned, but a lot of that is down to the customizations available. Documentation is only okay for most things, in my opinion. Overall, I'd recommend it

@girish yeah, I don't see why not. It works in an older version. I may be able to pin back the specific dependency as well (it's the node dependency from https://github.com/loomio/loomio_channel_server that seems to be doing it). I'll play around with it a bit while we work on the recvmail thing in the mean time.

@girish Yeah, I tried setting that, but the issue is that one part of the app is sending the two-argument version every time, which 5 and lower just don't know how to handle