Cloudron Forum

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

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.

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.

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 recently stumbled across the MIT-licensed SPFToolbox project and it got me thinking a lot more about more comprehensive mail server features and management tools that would be good to have in Cloudron. SPFToolbox has some nice functionality for running checks for all sorts of things, but its blacklist checker is what started to get my mind running about that feature and potentially others that would be awesome additions to the Cloudron email system to help administrators manage deliverability and so on.

This probably starts to creep into a bigger re-vamp of the email management area of the product, but IMO since mail servers objectively suck to maintain, the ease of use of the Cloudron mail system is a huge selling point. While it's probably not realistic to target everything that services like MXToolbox do, but there could be some more built-in and automated to make life even easier.

Some thoughts out of the gates:

• Blacklist monitoring
• Rspamd - Haraka is ready (https://github.com/haraka/haraka-plugin-rspamd) - with some of its handy modules:
  • Possibly include web ui to shortcut the configuration management; definitely an "advanced" option though
  • Antivirus - https://rspamd.com/doc/modules/antivirus.html
  • Phishing - https://rspamd.com/doc/modules/phishing.html
  • Greylisting - https://rspamd.com/doc/modules/greylisting.html
  • Metric Exporter - https://rspamd.com/doc/modules/metric_exporter.html
    • would let rspamd feed metrics into graphite for graphing in the box ui
  • I'd favor probably pushing some of what are currently haraka plugins' responsibilities around the SPF/DKIM/DMARC space down to rspamd as well given its much higher configurability/visibility if well-implemented
• Perhaps getting into automatic cryptographic signing/encryption with something like CipherMail in the mix - definitely needs some more thought
  • This might be best done by rethinking the way haraka fits in the MTA chain - maybe making other MTA-interfaced apps available via the app store like this one would be a good thing, then in the mail server admin, you could choose which one(s) of those installed are inserted for each domain?

I'm just sort of thinking out loud here, and would like to see what others think about those ideas or any other ideas about the mail server here.

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?

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.

@marcusquinn That statement could be applied to at least 75% of things about Nextcloud.

Love the conversation this has kicked off, and I think there's a few good things to consider here:

• The main thing I was originally aiming at first was better visibility into the mail subsystem and second to that more control over those various components
• Expanding the capability of the mail system to include additional processing by farming out additional processing to external servers like CipherMail, Proxmox, etc. could be done easily for even sparsely-resourced servers. However, optionally enabling certain processing like Antivirus on the same machine is still likely a good idea.

A lot of us are also running fairly beefy servers for large production setups and it seems disingenuous to rule out completely more resource-intensive operations from the core packaging just because some machines at the lower end couldn't support them. Making them optionally available, even subject to certain resource constraints and so on, is exactly what I'm hoping we can get to - a lot more control over the mail system so that administrators can choose how much in terms of resources to invest in that system. A combination of more inspectable, optional services available on the core offering as well as allowing external smtp-based components to slot into the workflow sounds like the best of all worlds.

Initial packaging: https://git.cloudron.io/jimcavoli/snipeit-app

Recently, I accidentally found myself studying this problem. I've relocated backups to GCS recently from DigitalOcean Spaces for one machine...suffice it to say I found the bottleneck in that process. Previously, it appeared to be some traffic management into spaces, and/or the fact that it was heading to the SFO2 region from NYC3 (you know...because...geography). After turning on backups into GCS in the awesome us multi-region automatic replication (nearline), it became very obvious that the main limiting factor was a 10MB/s cap on the disk speed at DO.

Seriously; here's their graph over the last 7 days for Disk I/O performance (it's pretty obvious where the backups are):

The main reason this even showed up is that GCS ingest is way faster from a bandwidth perspective:

Too bad I don't have the old Spaces graph to show as well, but suffice it to say, it wasn't great. So the GCS switchover actually moved the first bottleneck, getting at the main root of the issue.

I'll update on how things go one the server in question gets itself moved into a GCP instance - by my rough math, there should be a noticeable performance bump in at least backups, but likely systemwide once it transitions into the GCP volumes, which are rated at least 50% faster in the case of the small volumes, and in the big one (apps data), should have a network performance ceiling that is roughly 6x higher than the existing DO volumes. I know this is more on the production/operator side than the personal side of usage, and the problem of "throw more, bigger resources at it" is not one most folks can/would take on a NAS/local server and home internet connection, but it's some interesting data and an intriguing problem in any case.

Still pending; I missed an extension in the earlier ask, but that's been merged, so hopefully this will release shortly after the next Cloudron patch version. It's at the top of my list, so as soon as I can get it working, I'll update here.

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/

Yeah, I think I'll pick this one back up once I'm done faffing about with OpenSlides. Especially with the NextCloud integration, but mostly just because I sort of hate osTicket's prevalence with a fiery passion. I find it to be way under-capable and over-used as a general rule, and I don't love that the interface is basically as it was circa like 2008 either. Zammad for the win, hopefully soon!

It would be a good addition to the ingress handling on box to be able to optionally configure mutual TLS authentication for connections to the server. This would allow those of us who do use Cloudflare to enable Authenticated Origin Pulls, and would further allow others who perhaps would like to have a remotely located server only accessible to certain network(s) via a proxy/gateway to do so without the overhead and technically not recommended approach of a VPN connection to the box itself. Similarly, this relieves the need to depend on expensive private ingress solutions (generally also VPN-based) into otherwise inaccessible VPCs of most cloud providers.

This would necessarily have to only apply to the HTTP/S side of inbound traffic, I expect, which would be reasonable, since it is a rather specific protocol layering and I don't believe such a mechanism is necessary or supported for some of the other services that can be operated on a Cloudron installation. This may or may not also need to exclude the actual my.example.com management interface, also a fair compromise to my mind.

Started to try to package this, but stopped almost immediately since it's going to be a lot of effort/figuring out due to the many backing services, several of which are not readily available as adding in Cloudron today. List is in https://github.com/mistio/mist-ce/blob/v4.3.8/docker-compose.yml but includes things like elasticsearch, memcached, and rabbitmq. Obviously some could be put in-container with the app, but a couple are a bit too heavy-duty imo to do that to. Sticking a pin in it for the time being.