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

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.

LDAP groups would be huge. Been dying for that a couple years now

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.

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

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.

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.

@girish I’m still around - I can pick this back up in the next week or two

LDAP groups would be huge. Been dying for that a couple years now

Got 7.0.1 loaded up on my testbed machine...going to re-update the packaging as needed and ensure recvmail is integrated properly, then we should be good to go here. Hoping for O(days) on that, may be O(weeks) given schedules the next few weeks.

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