Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand <thomas@goirand.fr> wrote:
> What happens here is that, if you take a normal Debian system, then
> install postfix, then let's say amavis, they don't talk to each other.
...
> much spams. It is also totally unrealistic to say that it's up to the
> system administrator to configure everything by hand. If, like me, you
> do at least one setup a day, it takes too much time for no reason, and
> it has to be automated in some way.
There are lots of examples out there where already works what you are
requesting for mail servers.
Let's have a look at web servers (well, apache... okay) and how they
deal with it.
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.
Let's have a look at DHCP and how they deal with it.
I'm installing dhcp3-client and my machine's network settings are
configured automagically.
I'm installing resolvconf and my name servers become configured
automagically via DHCP. I'm installing samba and it's also getting
configured automagically via DHCP. I'm installing ntp and my ntp-server
is configured automagically via DHCP.
How do they do this? There is some conf.d directory which contains
config snippets for each of the packages.
Let's have a look at SysV boot mimics and how they deal with it.
I'm installing the sysvinit packages ... well, you can imagine the rest:
... There is some conf.d directory which contains config snippets for
each of the packages.
Why would you like to go another way with mail servers?
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.
regards
Mario
--
who | grep -i blonde | talk; cd; wine; talk; touch; unzip; touch;
strip; gasp; finger; gasp; mount; fsck; more; true; gasp; umount;
make clean; sleep
Reply to: