EnglishNew to mailcow, just in planning and design phases
- Best Answerset by tblancher
Just two short remarks about your plans:
1) One of the main goals of Docker (and other container solutions) is service/application isolation. As soon as you start sharing containers between different services, you are losing this benefit. One aspect of this isolation is portability – you can simply move or delete a service or applications without affecting others. The second aspect is security: Suppose you are using a single database container which is shared between services. If an attacker is able to compromise a single service, he could be able to access data of other services as well.
2) Changing the mailcow stack certainly works, but since it is supposed to run on its own as an integral solution, you will probably run into problems. Most of the issues people are having are caused by doing things not the way it was intended. At least it will cause difficulties in getting (community) support when you are running a non-standard installation.
Personally, I’m using a vanilla mailcow installation and separate “stacks” / compose files for other services for my family server, e.g. a Nextcloud installation (although mailcow even has support for a tighter NC integration) and Gitea. As long as you don’t have hundreds of concurrent users, there should be no problem even with several (seemingly redundant) containers like DB servers or web servers.
Regarding Arch: There is no official support for mailcow on Arch, expect to run into problems you have to solve yourself.
tblancher I am running mailcow docker on arch for about 2 weeks now. Been updating Arch everyday with no issues yet. I decided to use lts kernel as a stable measure for the kernel . I check each update to see what packages are being updated before I apply them. Docker it self has been updated no issues yet. I am running 32 gig of ram and system is running using about 25% of ram. This is an experiment for me and learning process. I would also like to run a website on a separate domain on here and still researching on the best way to do it. Since Docker is in its own container I think I install nginx in Arch and run it from there. Not sure though. Whatever I do I don’t want to screw up Mailcow so I am being careful. Also I am learning how to deal with iptables in an effort to stop attacking IP’s from even getting to Mailcow. If you want you can email at danc@dccathome.com and we can share info offline.
Thanks
Dan
These are both very informative answers, thank you! The main reason I intend to use Arch instead of Debian is my plan is to use the Btrfs filesystem, at least for the mailcow/docker volumes, for the snapshot feature. I then make offsite backups from a read-only snapshot, so as not to disturb or interrupt any processes. I will also make regular database dumps to be stored on the Btrfs subvolumes (which I also will make snapshots of), since backing up the database files directly may lead to inconsistencies when restoring. My understanding is that with Btrfs, you should be running the latest stable kernel, with the latest Btrfs tools. Arch provides this assuming you install the linux kernel package, and not linux-lts, or some custom kernel.
Before I started using Arch regularly several years ago, I ran Debian. Debian prides itself on not being the latest upstream releases (“Shiny New Shit” is what they call wanting to be on the latest upstream versions of software). Whenever I was searching for documentation regarding my Debian systems, I’d find myself landing on the Arch wiki. Sadly, some of the content on the Arch wiki isn’t directly applicable to Debian, since Arch typically runs newer versions (with newer features) than Debian. Even so, much of the information was perfectly applicable. The Debian wiki always seemed to be one or two releases behind the current release. I also found that I ultimately disliked the Debian way of configuring the system (with its weird TUI configuration tools, and bespoke programs for managing the configuration), and the strict adherence to only including Free Software (Debian Free Software Guidelines/DFSG).
As for stability, Debian is only more stable because you typically don’t receive a new major or minor release version when you run apt upgrade. I would call it stable with respect to versions, not necessarily more stable (in that it doesn’t crash). I’m pretty proficient with Arch, and there have been very few occasions, if any, where a system upgrade broke my systems. I understand the risks, and I accept them. My VPS provider doesn’t even offer Arch as an OS; I forgo their support and bootstrap Arch over Debian. I even drafted 
an article to repartition the VPS QEMU disk, so I could bootstrap Arch over Debian. I do not intend to consult the mailcow community for anything that appears to be Arch related. discursions
The point about the default ports is important, I can change those ports so the mailcow web interfaces listen on something nonstandard, so my websites work on the standard HTTP(S) ports. I’m OK with that, since there won’t be more than one or two regular users of the mailcow web interfaces. I haven’t yet decided whether we’ll want to use the webmail interfaces, as some of these email domains will be replacing an existing, aging VPS running CentOS 7, with far fewer virtual hardware resources.
This leads to another question: how is ACME/Let’s Encrypt/certbot handled? On my existing VPS I run certbot on the host, not in a container. All of the nginx configurations refer to the fullchain.pem (or the current symlink thereof). Is that acceptable for mailcow? I see 
this Advanced SSL article, which suggests mailcow runs ACME in its own container. It does mention I can do it the way I’ve done it in the past, but that article doesn’t appear to describe how to do it that way. It looks like there are hints to using an external ACME client on the . If I want to run the mailcow web interfaces on nonstandard ports, it looks like the acme-container requires to be listening on port 80. I’ll have to do more digging to make sure I understand this bit before I deploy. The more I think about it, having a separate reverse proxy sounds like the way to go. More digging is definitely warranted. docs.mailcow.email
Luckily it will be several weeks before I acquire the new VPS. Because of the hint about running multiple docker compose stacks on a single Docker host, I can probably start trying mailcow out on my existing VPS. I don’t run any mail domains there currently, though one of my Ghost websites has a Mailgun setup. I’ll likely not enable mailcow for those domains, since I won’t be setting up email addresses for it.
Thanks for the tips! If you have anything further to add, I can check them out if you reply!
tblancher This leads to another question: how is ACME/Let’s Encrypt/certbot handled? On my existing VPS I run certbot on the host, not in a container.
I use an Apache reverse proxy on my host, letting a local certbot handle the certificates for all other services except for mailcow. The mailcow certs are generated by mailcow’s ACME container (like I said: vanilla setup) and used for mail. My reverse proxy also uses those certificates for the mailcow websites, according to the example config you already mentioned.
@“accolon” I use an Apache reverse proxy on my host, letting a local certbot handle the certificates for all other services except for mailcow. The mailcow certs are generated by mailcow’s ACME container (like I said: vanilla setup) and used for mail.
Is your Apache reverse proxy listening on public port 80, for your non-mailcow certs? How does the acme-container behave in this case? You say you use a “vanilla” mailcow setup, so I’m curious how you get both ACME “instances” playing nice with each other.
For my existing VPS, I have pre- and post-hooks which stop and start the nginx container before running certbot renew, in a set of systemd units (service/timer).
maybl8 I am running mailcow docker on arch for about 2 weeks now. Been updating Arch everyday with no issues yet. I check each update to see what packages are being updated before I apply them.
Let’s talk again in a few months, when the novelty of it has gone away, and the excitement about logging into the server every day to perform updates and check packages has become an annoyance. ;-)
mlcwuser I don’t think it will become an annoyance. I have several Arch installs. Some I don’t update everyday. The only problem with that is there is allot of updates if I wait too long. This is the first time I am using it as a server so we will see. I might possibly give it a length of a month and see what that does.
Rolling releases like Arch are a pain, especially if you have several servers with different workloads. In contrast with Debian you know the packages play well with each other because they stick to a certain main version, so no need to study change logs on a daily basis.
This is the reason why NOBODY at service providers uses Arch to provide anything to customers. If you have the time and the will to do so, OK. My time feels wasted to do such grinding. And for what benefit?
And be prepared that if you run into a problem you are on your own…
mlcwuser
Yes, I agree. Updating daily seems too frequent, especially on a (pseudo-)production server. You never know when a kernel upgrade can cause a module you depend on to fail to load (e.g., DKMS fails to build), or there’s a regression in a package you rely on.
I typically upgrade weekly, or usually even less often than that. On my laptop, one time I skipped a minor kernel version since I got notice (probably through my Google feed on my Pixel 6 Pro) that there was a regression in a specific version. This regression affected Intel GPUs, and had the potential to damage laptop screens. Not upgrading for a few weeks saved me from potentially damaging my daily driver laptop. The fix was issued in the very next minor release, so I completely sidestepped the problem by not upgrading too quickly.
In that vein, I’d never set up a process to upgrade automatically, either through cron or a systemd timer. I learned that lesson running Debian Sid. Sid can have the propensity to remove whole categories of packages, and I basically removed X.org by blindly passying -y to apt upgrade.
- Edited
Well, a rolling release distribution may have its advantages in certain situations, but on a production server, and especially on a server running an appliance like Mailcow (yes, Mailcow should be considered an appliance), it has only disadvantages. Besides, all the dependencies the application / appliance needs to do its job are included in the containers anyway, so why would you want to run these containers on a base that is constantly changing when the only thing the base is supposed to do is provide a stable base to run these containers…?
tblancher In that vein, I’d never set up a process to upgrade automatically, either through cron or a systemd timer. I learned that lesson running Debian Sid. Sid can have the propensity to remove whole categories of packages, and I basically removed X.org by blindly passying -y to apt upgrade.
Wrong lesson learned, imho, otherwise you would be using Debian Stable and you would not experience such issues in the first place.
- Edited
Yes, for this particular situation I did indeed switch back to Debian Stable, I had learned that lesson well. But then I was still stuck on old versions of included software, and wanted to use features that were in newer versions. I used Debian for about eight to ten years, and it always seemd they’d settle on older versions before many of these packages were ready for production (at least feature-wise).
[unknown]
After using Arch on some of my machines for a couple of years, I got increasingly tired of many of Debian’s bespoke way of doing things (like network management), and out of date packages missing features. Critical system packages like systemd always seemed woefully out of date, and going upstream while on Debian was always answered with,“use an up to date version.”
It’s a personal preference, I do not expect everyone to use Arch, nor am I hurt if something else (in this case, Debian) works better for others. And yes, if a system update or upgrade breaks my mailcow stack, I get to pick up the pieces and figure out what went wrong. That’s one reason I do not update every day, nor do I update blindly. If it becomes a problem, I’ll deal with it. I can only see Arch updating the Docker packages, or maybe some kernel update breaks Docker causing me issues. Mailcow is containerized for a reason, right? It shouldn’t rely too much on the base system, other than the aforementioned packages. I can always pin these packages to a specific version, so I only upgrade precisely when I want.
Arch is more of a meta-distribution, no two Arch installations are identical (Gentoo which I’ve had experience with long ago was like this). But that means I get to customize it with just what I want, and nothing else. Debian lets the administrator choose some basic options (like how to partition the disk, or what package groups to install), but that will include quite a bit of software that I don’t use, or may not even understand. Arch isn’t like that, you only install packages you want (and their dependencies). When you’re seeking help from the Arch community you need to be aware of what you’ve installed and how you’ve configured it. Nothing, not even the kernel is installed by default with no action by the administrator.
[unknown]
After using Arch on some of my machines for a couple of years, I got increasingly tired of many of Debian’s bespoke way of doing things (like network management), and out of date packages missing features. Critical system packages like systemd always seemed woefully out of date, and going upstream while on Debian was always answered with,“use an up to date version.”
It’s a personal preference, I do not expect everyone to use Arch, nor am I hurt if something else (in this case, Debian) works better for others. And yes, if a system update or upgrade breaks my mailcow stack, I get to pick up the pieces and figure out what went wrong. That’s one reason I do not update every day, nor do I update blindly. If it becomes a problem, I’ll deal with it. I can only see Arch updating the Docker packages, or maybe some kernel update breaks Docker causing me issues. Mailcow is containerized for a reason, right? It shouldn’t rely too much on the base system, other than the aforementioned packages. I can always pin these packages to a specific version, so I only upgrade precisely when I want.
Arch is more of a meta-distribution, no two Arch installations are identical (Gentoo which I’ve had experience with long ago was like this). But that means I get to customize it with just what I want, and nothing else. Debian lets the administrator choose some basic options (like how to partition the disk, or what package groups to install), but that will include quite a bit of software that I don’t use, or may not even understand. Arch isn’t like that, you only install packages you want (and their dependencies). When you’re seeking help from the Arch community you need to be aware of what you’ve installed and how you’ve configured it. Nothing, not even the kernel is installed by default with no action by the administrator.
- Edited
After using Arch on some of my machines for a couple of years, I got increasingly tired of many of Debian’s bespoke way of doing things (like network management), and out of date packages missing features. Critical system packages like systemd always seemed woefully out of date, and going upstream while on Debian was always answered with,“use an up to date version.”
These are hobby systems, after all. It’s a personal preference, I do not expect everyone to use Arch, nor am I hurt if something else (in this case, Debian) works better for others. And yes, if a system update or upgrade breaks my mailcow stack, I get to pick up the pieces and figure out what went wrong. That’s one reason I do not update every day, nor do I update blindly. If it becomes a problem, I’ll deal with it. I can only see Arch updating the Docker packages, or maybe some kernel update breaks Docker causing me issues. Mailcow is containerized for a reason, right? It shouldn’t rely too much on the base system, other than the aforementioned packages. I can always pin these packages to a specific version, so I only upgrade precisely when I want. I can always make use of Btrfs snapshots before a system upgrade, and be able to roll back if mailcow (or any of my docker compose stacks) don’t immediately come back up without my intervention.
Arch is more of a meta-distribution, no two Arch installations are identical (Gentoo, which I’ve had experience with long ago was like this). But that means I get to customize it with just what I want, and nothing else. Debian lets the administrator choose some basic options (like how to partition the disk, or what package groups to install), but that will include quite a bit of software that I don’t use, or may not even understand. Arch isn’t like that, you only install packages you want (and their dependencies). When you’re seeking help from the Arch community you need to be aware of what you’ve installed and how you’ve configured it. Nothing in Arch, not even the kernel, is installed by default with no action or choice by the administrator.
You might say that using Arch is doing it the hard way™, but at least when it comes to Linux, I’ve always been more of a DIY guy than having so much of it decided by others. Again, personal preference. I’m not looking for a turnkey solution, nor needing enterprise support. If I become proficient enough with mailcow to have the opportunity to use it for an enterprise, I’ll probably make other decisions on the Linux distribution of choice.
[unknown]
Sorry for the double post, there was an error when I originally posted this and it doesn’t look like I have the permissions to delete the unintended post.
No one is typing