Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote:
> Thomas Goirand <thomas@goirand.fr> wrote:
>> Mario 'BitKoenig' Holbe wrote:
>>> So far this is independent of third packages which is IMHO fine and
>>> desirable. So far, this could be solved by a postfix-conf.d-snippet
>>> shipped with the amavis package.
>> Quite not. You also need to configure the incoming and outgoing ports of
>> amavis the correct way.
>
> Which of course will also be done by the amavis package itself. Still,
> no dependency on third packages so far.
I think you quite don't get it. Here's 3 configuration:
- postfix with dkimproxy
- postfix with amavis
- postfix with dkimproxy + amavis
In these 3 cases, you have different configuration for the ports for
both amavis, and the others.
>>> * postfix ships to amavis
>>> * amavis ships back to postfix
>>> * postfix ships to dkimproxy
>>> * dkimproxy ships back to postfix
>> No, it's not any cleaner, and it's slower. As I wrote previously, we
>
> Cleaner from a dependency-perspective. Why isn't it?
Cleaner for using it, of course not for the packaging. There's no reason
why you should load postfix more, and have the message go 3 times by it,
if it can go there only twice.
> This way you are able to configure the whole integration within one
> package (i.e. amavis ships the amavis-postfix integration, dkimproxy
> ships the dkimproxy-postfix integration, etc. pp), you can just avoid
> any complex chaining-magic.
>
> And slower? What are we talking about? Whole two percent?
Well, both you and me are doing wild guesses here! We wouldn't be able
to tell unless we bench it. But you must be right that the overhead
wouldn't be so big, considering how much CPU amavis with spamassassin
and clamav is taking.
>> Are you trying to say that we shall ship a not performing configuration
>> by default, because big ISP are capable of reconfiguring? If you are,
>
> I'm trying to say that I would prefer a straight, clean dependency-
> minimizing approach over one that does and/or requires complex magic.
> And I'm aware that clean approaches are usually somewhat less performant
> than optimized setups, which, in turn, tend to be more complex.
>
> And I think that a clean and simple approach would help more users than
> one that tries to squeeze the last cpu cycles out of your system for the
> price of being hard to understand.
> Don't get me wrong: I totally agree with you that what we have now is
> neither the one nor the other.
Cool. Then we agree! :)
Just one remark (which doesn't invalidate your point): you named few
percents of cpu cycle, but do not forget to also consider I/O here, as
postfix will also use your HDD when managing its queue. I believe that
the I/O wait is a bigger concern than any CPU load issue in this case.
>> I think we shall try to release the best distribution as we can, with
>> correct, performing values by default, and even, if possible, have a
>> default configuration that you never even need to edit, because it's
>> just right by default. We should at least have this goal in mind,
>
> "those goals" - you named three: correctness, performance and useful
> defaults. Choose two of them :)
Here, you are proposing to trade a little bit of performance, so that we
have a correct, useful default, and with not too complex maintainer
scripts. If we don't trade too much performance, then I don't mind. When
having a server on the edge of collapsing because of the load, a bit
more or less wont mater: you need a faster server and that is it.
> I don't think it's bad to be idealistic. We just have different ideals
> probably :) Well, most likely we just weigh conflicting goals different.
In an ideal world, we wouldn't need such complex setup, as there
wouldn't be any SPAM or viruses! :)
Thomas
Reply to: