Ns8-mail on Debian 12 - postfix fails to start

Support
,
1

Good evening everybody,

I’ve just spawn a Debian 12 droplet on DigitalOcean for getting some more realistic testing scenarios around NS8.

After installation and configuration of ns8-mail the postfix container within mail module was not able to bind to port TCP/25 and constantly restarted.

024-03-19T00:01:11+01:00 [1:mail1:systemd] Started postfix.service - Postfix MTA/MSA server.
2024-03-19T00:01:13+01:00 [1:mail1:postfix/postfix-script] the Postfix mail system is not running
2024-03-19T00:01:14+01:00 [1:mail1:postfix/postfix-script] starting the Postfix mail system
2024-03-19T00:01:14+01:00 [1:mail1:postfix/master] fatal: bind 0.0.0.0 port 25: Address in use
2024-03-19T00:01:15+01:00 [1:mail1:podman] 2024-03-18 23:01:15.612948608 +0000 UTC m=+0.538394023 container died 1115cb2595282d3c745da8e0f72421b97d6110e6ea6db20eb3f6b4b7861fbc30 (image=ghcr.io/nethserver/mail-postfix:1.3.4, name=postfix, PODMAN_SYSTEMD_UNIT=postfix.service, io.buildah.version=1.23.1)
2024-03-19T00:01:15+01:00 [1:mail1:podman] 2024-03-18 23:01:15.651481958 +0000 UTC m=+0.576927343 container cleanup 1115cb2595282d3c745da8e0f72421b97d6110e6ea6db20eb3f6b4b7861fbc30 (image=ghcr.io/nethserver/mail-postfix:1.3.4, name=postfix, PODMAN_SYSTEMD_UNIT=postfix.service, io.buildah.version=1.23.1)
2024-03-19T00:01:15+01:00 [1:mail1:systemd] postfix.service: Main process exited, code=exited, status=1/FAILURE
2024-03-19T00:01:15+01:00 [1:mail1:podman] 2024-03-18 23:01:15.82923951 +0000 UTC m=+0.150357443 container remove 1115cb2595282d3c745da8e0f72421b97d6110e6ea6db20eb3f6b4b7861fbc30 (image=ghcr.io/nethserver/mail-postfix:1.3.4, name=postfix, PODMAN_SYSTEMD_UNIT=postfix.service, io.buildah.version=1.23.1)
2024-03-19T00:01:15+01:00 [1:mail1:postfix] 1115cb2595282d3c745da8e0f72421b97d6110e6ea6db20eb3f6b4b7861fbc30
2024-03-19T00:01:15+01:00 [1:mail1:systemd] postfix.service: Failed with result 'exit-code'.
2024-03-19T00:01:15+01:00 [1:mail1:systemd] postfix.service: Consumed 3.227s CPU time.
2024-03-19T00:01:15+01:00 [1:mail1:systemd] postfix.service: Scheduled restart job, restart counter is at 154.

Cause: Debian 12 (not sure if by default or only within the DigitalOcean image) spawns exim4 on the host OS (packages: exim4-daemon-light exim4-base exim4-config) thus port TCP/25 is already bound.
As it is a testing system I’ve simply uninstalled exim4 and voilá postfix container starts fine and is reachable.

My suggestion: Might it be feasible to check (e.g. during configure-module) if anything else is listening on TCP/25 and at least display a notification within the UI?

I’d rather not suggest to disable or even remove the OS-shipped mail server as this might lead to OS-level notifications not getting delivered at all. I myself use nullmailer for that, this could also be an alternative for others as well.

Kind regards
Christoph

1 Like
2

Please search these forums on ‘mail instances’, it may give you some clues.

HTH

3

The requirement for Debian 12 is a “clean” install, with “no” services besides SSH, like for all other “options” for underlying OS (Rocky, Alma, Centos-Stream).
If you choose a hoster providing a “wrong” config, this must be corrected first!

I am Team Debian, no RedHat relicts!

My 2 cents
Andy

As per the “System Requirements” for installing NS8:

Install NS8 on a clean Linux server distribution, avoiding installation on desktop systems or servers already running other services.

In my book, Exim is a mail service and is even configured as such (sits on Port 25).

Source:
https://docs.nethserver.org/projects/ns8/en/latest/system_requirements.html

4

Thank you for pointing this out. I’ve counter-checked with a Debian installation done from the official ISO and with that one exim4-daemon-light was installed by default, too. Might be used for “internal” mail.
Thus, anybody using Debian as a base system for NS8 might run into this issue.

Consider a SME (which Nethserver still wants to be for) having a “IT interested person” evaluating NS8 for their needs. Not necessarily the mail-modul will be the very first thing in testing. It will essentially prevent a successful “out-of-the-box” experience within when installing the mail module. They might simply be not aware of the fact that the base OS already did install a mail component for its own purposes.
My idea on this post was giving other people searching for “mail-module” in combination with “Debian 12” an additional hint what might prevent postfix container from proper startup.

Thus, I still advocate for a check and notice within the UI.
Might also as well help if multiple mail module instances get installed on the same node, as discussed in one of the other threads LayLow pointed out to search for.

Please don’t get me wrong, but simply referring to “read the manual” (which I did, by the way) or “search the forum” is not helpful in this context. Also if totally aware of the documentation and the system requirements as well, you may face issues you want/need/must resolve fast.

kind regards

5

Hi @chrkli

This is not completly untrue, I concur.

Most “IT interested persons” however, especially those choosing Debian, will have experience installing a linux based server. Especially Debian, which inspires open source freedoms among it’s multiple fans - and they don’t like being dictated which mail server component to choose. Same goes for Webserver, it’s not only Apache or nGinx out there…
In this sense, people, like you, will be aware of a mail server being installed which they didn’t ask for…
I’ld personally junk a distro if it enforces the use of emacs! But as open source, most can easily be installed - or deinstalled, if called for…

While I do acknoledge your first “gotcha”, this one is a bit lacking in base info, or understanding how mail works on a TCP/IP based network (The Internet!).

And how would any client access this thing? The first mail server will use up port 25, which could be solved by using a mail-gateway distributing mail internally via domain-name, and a smarthost setting for outgoing. but how would you intend to solve client mail acess? Limit everything to WebTop or Sogo?
You still would not have “client” access… :slight_smile:

A printer or NAS could use the SMTP smart host for sending reports (they don’t recieve mail), But getting a smartphone QR-Code “scanner” to send mail via WebTop may be a bit more time consuming than the usual mail account…

I also acknoledge the fact that the docs for NS8 are quite lacking - in several aspects.
There’s more there than say an instruction for building a “ship in a bottle” containing the sentence: You will need a bottle… But not that much. I hope the docs proceed as fast as the devs!

But I’ld also like to mention that any decision is up to Nethesis and not mine in any part. I just have my opinions here, not more, not less!

My 2 cents
Andy

6

Hi @Andy_Wismer

thank you very much for your answers, I really appreciate.

Well, I did not intend to start a rage against distribution decision, (pre)installed applications, free and open software an it’s freedom of choice. :woozy_face:

I totally agree to you on that without any “but”

Well, I always hope for the best, too. Unfortunately I’ve met quite a few people just ordering some vServer (or Droplet or whatever a virtual machine might be called) and just relaxing as “the image is installed automagically and there is a nice clickedy-click UI to use”
I do not think NS8 is or ever will be such a clickedy-click-only tool. But people tend to forget they’ve once during installation did something that might prevent another similar thing from working they now want to install using a completey different way.

That’s a good metaphor. As you, I’m sure the instructions for the ship will be there sooner or later. Nethesis in my opinion is doing a really great job!

As for now NS8 is (a huge) software-stack itself, free to be installed, so if Debian is mentioned as “the bottle” it should also consider it’s surrounding at least a bit. You shouldn’t join a party and just ignore all others except the guys you’ve brought yourself.

Ahm, no, sorry, you’re mistaken.

I’ve only read across another thread and there was the idea “check if TCP/25 is in use” appeared, too. That’s why I’ve mentioned it.

For sure the following is nothing one would ever build or would like to administer - especially if thinking about SME.
Nevertheless, here we go:

I’ve got no elaborate thoughts in regard to the reality within a containerized setup, but in non-containerized installations the following should perfectly work:

  • MTA: One central postfix instance using virtual_domains (via LDAP to account providers) for all installed mail-module-domains for in-/outbound and submission.
  • MDA/LDA: Dovecot LMTP feature for transport of accepted mail to the Inbox inside the right mail-module
  • multiple dovecot instances per receiving domain inside the mail-module
  • MAA: Proxy routing based on SNI (e.g. dovecot director or any other layer 7 proxy capable of IMAP) for routing client traffic to correct dovecot instance inside mail-module
  • Antispam: Either centralized as well or find a way to define a “per virtual_domain milter protocol experience” so that every mail-module can have it’s own rSpamd instance.

PRO: no ideas, except maybe personal satisfaction
CONS: really high ressource usage, complexity, amount of possibilities for catastrophic failure, administrative overhead and … ressources wasted

Once again: For sure this is nothing one would ever build or would like to administer - especially if thinking about SME. This neither is anything I think NS8 could or should even try to implement. Those are just (really) crazy ideas I tend to develop on sleepless nights :upside_down_face:

7

Ever tried setting up three cascaded firewalls, all on different systems (CheckPoint/Linux, Cisco PIX, Third-one) with Out Of Band Monitoring and SMS alaming when attacked? All for a client (Bank).
And with working Site2Site VPN to head office?

Been there, done that, even got the T-Shirt!

:slight_smile:

You meet crazy people here, but generally nice ones!

My 2 cents
Andy