MailCow in Production Datacenter
-
@travisdh1 said in MailCow in Production Datacenter:
@Curtis said in MailCow in Production Datacenter:
@scottalanmiller said in MailCow in Production Datacenter:
(especially with Docker which seems to make the distro matter so much more than normal.)
Isn't one of the major selling point of Docker platform Independence? You can run it on any distro, even Windows?
That's what everyone says about it, but that's not been anyone's experience with it. Docker uses a shared kernel, so if you are using a different distribution or even just a different version of the same distribution as the developers, things randomly break.
And that's what blocks Windows. Docker itself can't even run on Windows, let alone the workloads within it. Docker isn't a full VM, only a container. Containers, by definition, aren't distro agnostic, let alone OS agnostic.
-
@travisdh1 said in MailCow in Production Datacenter:
things randomly break.
I agree. I have avoided docker because some things do not seem reliable. And I have applied mailcow updates that break things that should not be broke: I mean what happens makes no sense.
On the other hand, I have moved mailcow from Debian to CentOS within short maintenance windows and docker has eased the process.
Now that I think about it, mailcow is probably the only docker based deployment I have and probably will for some time -
@dave_c said in MailCow in Production Datacenter:
Now that I think about it, mailcow is probably the only docker based deployment I have and probably will for some time
This scares me. Because to me it tells me that MailCow lacks the resources to put out the product correctly, which is mirrored in their statement of stepping away from it full time, and doesn't have a production mindset. Maybe they've gotten lucky in the past that things keep running. But it sounds like they are just getting lucky, not really planning around reliable processes. And that your updates break things seems like what we'd expect from that process.
-
@scottalanmiller The issue is getting Let's Encrypt - SSL Certificates to work behind the nginx proxy. Are you using only the global settings AS/AV? Or are you using other installed tools. Still find spam emails counts are high with just those settings.
-
@gtech said in MailCow in Production Datacenter:
The issue is getting Let's Encrypt - SSL Certificates to work behind the nginx proxy.
DNS based challenges resolve this for most things.
-
@gtech said in MailCow in Production Datacenter:
The issue is getting Let's Encrypt - SSL Certificates to work behind the nginx proxy.
That's a pain but there are multiple ways to handle it. Our proxy gets the certs, Zimbra pulls them from the proxy.
-
@gtech said in MailCow in Production Datacenter:
Are you using only the global settings AS/AV? Or are you using other installed tools. Still find spam emails counts are high with just those settings.
No third party tools, just PyRazr and such that are included and recommended in the Zimbra guides. We find it comparable to the spam we get on O365 or GSuite.
-
@scottalanmiller
He has a business to run. Mailcow is a community based project; the project lead used to work full time on it but no longer. He is using mailcow in his hosting business
Regarding the reliable process: I agree, at least in part
Regarding the update break: It happened once and there were at least 2 ways of solving it. It wasn't a big problem but was a problem -
@gtech
Why do you need a proxy? -
@dave_c said in MailCow in Production Datacenter:
@gtech
Why do you need a proxy?Why wouldn't you? You don't want to just assign public IPs to your email web interface in most cases.
-
@scottalanmiller
I do not use a proxy for mailcow as it comes with the same nginx that I would use as a proxy. I have access to nginx.conf to make almost any adjustment I need -
@dave_c said in MailCow in Production Datacenter:
He has a business to run. Mailcow is a community based project; the project lead used to work full time on it but no longer. He is using mailcow in his hosting business
He does, and there is nothing wrong with that. But no matter what the legitimate reason, it reflects very poorly on a product when it comes to considering whether we want to use it in production or not. Not that we are looking for support from the developer, but it is just "another piece of concern" along with the deployment methodology. That he isn't full time and has a hosting business with no full time people is a concern for people looking to use that, for sure!
-
@dave_c said in MailCow in Production Datacenter:
I do not use a proxy for mailcow as it comes with the same nginx that I would use as a proxy.
I'm assuming you aren't running in a datacenter. We want it behind the same nginx proxy that all of our interfaces are behind. They all share one. That MailCow comes with one doesn't help us in any way.
-
Not to say that it is bad that it has its own Nginx, but that seems like just extra complexity that doesn't need to be there, that adds more places for things to break.
-
@scottalanmiller
I am running it on rented servers and I understand why you want it to be behind you proxy@scottalanmiller said in MailCow in Production Datacenter:
but that seems like just extra complexity that doesn't need to be there, that adds more places for things to break.
How would you serve the PHP code of the control panel if you are not including a web server within mailcow?
-
@dave_c said in MailCow in Production Datacenter:
How would you serve the PHP code of the control panel if you are not including a web server within mailcow?
Same way that MailCow does... run it in its own instance that only does that. I don't know what they use, but I would guess Apache. The Docker instance in MailCow that runs the PHP code for the web server is called sogo-mailcow. The Nginx instance in MailCow that we are talking about is called nginx-mailcow and is a reverse proxy that does not run PHP.
-
@dave_c said in MailCow in Production Datacenter:
I am running it on rented servers and I understand why you want it to be behind you proxy
If they just had it as an "on/off" option, I think including it is great. But it seems like bypassing it is cumbersome and might break future updates. That's a big problem here, sure I can get in under the hood and try to alter things, but will that work reliably as they deploy anew?
-
What does your current docker-compose.yml file look like?
-
@stacksofplates said in MailCow in Production Datacenter:
What does your current docker-compose.yml file look like?
I'll let you know once it installs. I've already started a fresh ground-up install.
-
