Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote:
> I'm installing apache2 and have a web server - more or less working,
> I'm installing dhelp and ... magic, magic ... it extends the running
> web-server to serve the dhelp content as well. I'm installing smb2www
> and it extends the running web-server to act as smb client as well.
> How do they do this? There is some conf.d directory which contains
> config snippets for each of the packages.
Yes, which feature I requested from the upstream of postfix. I got a
stunning reply that it was a stupid idea, that it would be slow to
parse, and that postconf wouldn't work anymore. So forget about having
this in postfix, we must find another way.
> Why would you like to go another way with mail servers?
Because upstream doesn't want a conf.d folder, unfortunately, and that
the issue is NOT ONLY with postfix, but with so many package that have
to understand each other. Let me give an example.
If you setup postfix + amavis, then postfix must relay emails to the
incoming port of amavis, and amavis got to give the email back to
postfix on another port. Both postfix and amavis have to be configured
so they can talk to each other.
Now, add dkimproxy in the loop. You have to configure dkimproxy to
receive from postfix, relay to amavis, and amavis forwards to postfix.
This is a LOT less trivial than what you pretend.
> Get maintainer support for such conf.d directories, maybe get upstream
> support for such conf.d mimics (sendmail most likely won't need it -
> some m4 magic and triggers will just do it, dunno how it is for the less
> flexible ones like postfix, exim, whatever), change the depending
> packages to put their config snippets in there, everything is fine.
>
>> argument a list of packages that it should use. But the MTA is not the
>> only one to modify here, for example we might have to change the listen
>> and relay port of dkimproxy and amavis, depending if each others are
>> present on the system or not. I am quite in the favor of this system,
>
> I don't think this is really necessary. It would probably be a bit more
> efficient to have one component forwarding the stuff it processed to the
> next one, but I'm sure there is a less efficient but more generic way to
> just bounce it back to the MTA which continues forwarding it to the next
> components. ... And who cares about efficiency in generic approaches.
OF COURSE we do care about the performances of a mail server. Some ISP
are running servers that are managing 100s of thousands of mail a day.
But anyway, this was just an example, there's many use case where you
must configure one of the elements of your mail server.
Thomas
Reply to: