Re: RFC: Running Postfix chrooted in Debian
Hi,
On 12/18/24 19:38, Jonathan Dowland wrote:
I would also like to see this. Perhaps it's because the maintainers
don't want to close the door to alternative init systems, by making
their package depend on systemd features?
Most likely it is because BSD does not have systemd, and quite a lot of
Postfix installations, especially larger ones, run on BSD.
Postfix's "master" process effectively implements an orchestrator for a
microservice architecture, similar to what systemd does. This could be
replaced by systemd by writing a generator that creates units from
master.cf.
Simply converting the default master.cf to unit files and shipping these
as default would still be a massive regression, because it would
obsolete a lot of documentation on how the Postfix system is
orchestrated and how to integrate new services like clamav and
spamassassin or to deliver to courier.
All of these recipes would become "instead of this one line in
master.cf, you need to create a service unit, socket unit and possibly
timer unit." My expectation would be that the next sentence would be
"Please refer to the systemd documentation on how to do that.", and
while the systemd documentation is exhaustive, it is significantly less
targeted to the operation of mail systems than the manual page for the
master.cf configuration file format.
Specifically, changes to master.cf are frequently of the form "make this
service local-only, and instead expose a copy of it with a special
instance name that makes it write to a special queue." As a text file
modification, that is easy, but replicating this with systemd units is
going to be a complexity nightmare. Do we want to use template units?
Drop-in directories? Templated drop-ins?
I don't see this happening without upstream support. However, upstream
has little incentive to do so: they currently have an orchestrator that
works, is completely controlled by them and not subject to another
project's interface changes (rare as they may be), and is free to make
the assumption that the services being started are vaguely related to
mail delivery.
If they were to ship unit files, they'd end up in the same documentation
nightmare as we would if we were to start doing so, and if they create a
generator and start using systemd as the controlling process, they would
not gain anything, because neither can they drop their own orchestrator
(so this creates additional testing surface, as their services would now
need to implement *two* service manager protocols), nor would that
directly provide any additional functionality.
Simon
Reply to: