Mailcow-dockerized: ARM (armhf) support ? rpi / raspberrypi / odroid

[extremeshok]

I have extensive experience with docker on arm, so before I get to work on this, has anyone got mailcow-dockerized ported or running on arm ?

Did a quick search through the repo and I do not see any references to arm.

Does the repo owner have any issues against arm support being added ?

Thanks

[mkuron]

A Raspberry Pi doesn’t have enough memory. You need around 1GB if you disable ClamAV or 2GB if you don’t. Recent Odroid models should be sufficiently equipped though.

Please give it a try and open a pull request if it works out. You‘ll need to swap out the base images and use arm instead of amd64 repositories where available and compile yourself where not. Just don’t duplicate all the Dockerfiles as that would create a maintenance nightmare.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MatthiasLohr]

@extremeshok Did anything happen here?

[David91919]

RAM issue on RPI is solved by now, would be great to see MC on RPI

[andryyy]

RAM is/was the smallest problem.
Maintenance is another, but the biggest problem is missing software for ARM.

I won't maintain mailcow on ARM, but feel free to port it and create a PR etc. - I think SOGo won't work reliable on ARM though.

[Braintelligence]

Some people even have issues with 4GB RAM if they use ClamAV and SOLR, so I wouldn't say that RPi4 would have none at all.

[Adorfer]

Until ARM-based 1U servers (with decent amount of RAM) become largely availabe at reasonable cost, ARM is not a suitable platform for mailservers on (small) enterprise level.

[bolet]

I have the mailcow stack running on armhf (odroid hc1, 8-core, 2gb), with, as expected, the usual resource hungry services disabled. It consumes less than 1gb, and I plan to run it on a (small) swarm for better resilience (with glusterfs as persistent storage). I'd argue that arm is a perfect platform for small traffic servers, which is my case.

The major part was rebasing debian/strecth-slim and ubuntu/bionic services on debian/buster-slim (the original distros were lacking armhf versions of some required packages). The other part was building mariadb:10.3, which also resulted in rebasing on debian/buster-slim. I believe the rebase on a common distro would benefit the consistency of the project.

Anyway, I'd be glad to share the patch if anyone is still interested.

[Adorfer]

offereing "state of the art" anti-spam and FTS are the key features of mailcow (and to offer it as a real alternative to hosting at gmail/M365 etc).
getting rid of that sounds like offering a modding/patch for a semi-truck getting rid of the hook and any lockable doors. Of course it's still a truck, but does not fit in most use cases.

[bolet]

Let's not be dictators! What about letting users decide how they want to configure mailcow? Isn't it one of the freedoms permitted by "free software"? :-)

I'll personally be happy to enable all the features when I switch to a higher end (arm64 based) server, but until then I still prefer using mailcow stripped from a few features than configuring a mail server from scratch (which is what I've been running for about 20 years).

[luckyluc74]

@bolet Would be great, if you could share the patch for mailcow stack for armhf. And I have to agree with you that there are users that are very interested to see mailcow stack running on armhf/aarch64, i am one of those users. I am currently Running 3 raspberry pi 4 (4GB) in swarm and would be nice to run arm version of the mailcow stack on it.

Very recently Ubuntu released version 19.10 with raspberry pi 4 support ( aarch64) . Would be great to also see a aarch64 version of mailcow.

[bolet]

@luckyluc74 Here is the patch : buster+arm.zip

Sogo image from mailcow runs but is broken because it still pulls amd64 code (I keep getting 502 errors).

This project builds sogo from sources and is a good starting point. But then I found out that debian:buster includes pretty recent (4.0.7) Sogo packages, so here is my patch to this last project.

All pieces seem to work now, but I haven't yet taken the time to put them all together. I'll keep this bug posted as I move on, but feel free to help :-)

[luckyluc74]

@bolet thank you for sharing the patch and extra info. That SOHO is not working is ok for me, because I am going to use Roundcube instead of SOHO anyway.

[bolet]

@luckyluc74 I since forgot about this patch. It has to be applied to julienfastre project which results in a working arm sogo build. Then use it with the rest of mailcow.

Since then I also tested mailu which is more lightweight than mailcow, and more fit to rpi like servers.

[luckyluc74]

@bolet thanks for the update and information, appreciated! I have to say I like Mailcow. But mailu is also nice.

[Xeroxxx]

So now (acutally since May 2020) Raspberry Pi 4 with 8GB and VMware ESXi on ARM is available since October I would be happy to see offical support :)

Works patched within a ARM VM like a charm except SoGo (patch above) :)

[bonanza123]

@Xeroxxx I am trying to run mailcow on RPi4 (8GB). Could you link me to the correct docker images to use?

[bolet]

@bonanza123 As far as I know, there are no working mailcow images for any ARM platform. My previous patches still need to be applied and the image built on your device.

The maintainers of mailcow don't seem eager to include ARM support, and though I am happy to participate here and there in various projects, I don't have the resources to maintain an up to date fork of mailcow. This unfortunate situation is common in open source projects...

PS: With Apple's M1 chip showing ARM can outperform Intel/AMD chips (at equal watts), there is hope for a growing consideration for ARM.

[mkuron]

The maintainers of mailcow don't seem eager to include ARM support

The only place you could currently run it on right now is pretty much a Raspberry Pi at home, and we really don‘t encourage running a mail server at home. ARM rackmount or cloud servers are still not common (and not cheaper or higher performance than x86). As long as nobody makes a compelling case beyond "nice to have", I still see no reason to add ARM support to Mailcow. It would take additional effort for testing, and as long as nobody is going to use it productively, that‘s not worth it.

With Apple's M1 chip showing ARM can outperform Intel/AMD chips (at equal watts), there is hope for a growing consideration for ARM.

Not a typical Linux machine, unfortunately. It‘s a very nice chip though and I hope we will at some point see similar chip designs in the server market.

[bolet]

we really don‘t encourage running a mail server at home

That's a sensible opinion, but please have some consideration for ppl with a different one. My experience running a home mail server has been fine for over 20 years (with admittedly a friend running a secondary MX).

It would take additional effort for testing

I can understand that. Maybe a solution would be to discard official support for ARM, and let the community take care of this specific platform? I'd argue the whole project would benefit from this. It's a somewhat similar situation to supporting more compilers, it usually ends up making the code more robust.

In my case, though mailcow was my 1st choice, I ended up installing mailu on my home ARM swarm, and I got quite familiar with it (I even patched most images). Months later, I had to deploy a mail server for my company, and because my knowledge of mailu, I also installed it there even though we had a high end x86 server. Don't you I think it's a pity?