Re: [exim] Help With Exim Argument

Michael Johnson wrote:

> Hi Gang
>
> I really like using Exim, and recommend it in most cases. However,
> I've started working at a place where they're using Postfix. They
> don't have a secondary mail server, and I'd like to set up Exim as the
> secondary. The reasons I have so far are:
>
> 1. Not having a secondary MX is a really bad idea.

Agree having no (failover/fallback) is a 'really bad idea'.

But the 'conventional' concept of a secondary MX may no longer be the
best solution.

Unless you have traffic that needs a cluster to handle the load,
the secondary MX is, load-wise, actually a standby server anyway.
Mostly idle.

In order to seamlessly load-share, it is best to have external, shared,
storage.
Think NFS (software) or shared SCSI/FCAL/FW/SSAL storage ($hardware$).

Keeping that in sync and working entails a whole 'nuther set of problems.

An alternative is a 'hot standby' that normally does no work, save that
of syncing
from the master any user-account, white/blacklist, and settings changes,
optionally rsync'ing mail storage contents.

Weigh this:

- Given two servers *identically* configured as to MTA/POP/IMAP,
accounts, settings
even to (apparent) use of the same IP.

- Each with their own separate IP, which may be an internal,
non-routable one.
(so long as you can ssh to it somehow)

- Given ONE 'published' IP for mx services, which is 'neither of the
above', in-use by the active mx

- Given daemons that monitor the health of the 'active' mx
(checkservice, monitord, etc.)

IF/AS/WHEN the 'active' fails the 'MX heartbeat' test, and is otherwise
controllable, it is commanded to drop that public IP,
(or has done so inherently if it died outright).

The former standby - equipped with a reasonably current image of its
dead sibling, even to mail store content,
is commanded to take over the public mx IP.

Life goes on, both for MTA and IMAP/POP accounts. There may be an IMAP
message or two missing, and
other stuck in the queue of the dead box, but smtp retry will take care
of temporarily dropped connections.

Presuming both servers have RAID1, the chances are very good that any
traffic not
already mirrored at the time of failure - including whatever was in the
queue -
can be manually recovered and migrated to the 'active'.

It is *way* easier to keep two mx 'identical' with one 'offline' than
than to sort the
grief of who's-on-first, bounces, etc, of primary/secondary mx.

Plus - you can rotate the duty periodically, do full archiving
from the off-duty box, test upgrades and changes, easily replace HDD, even
roll-in an entire new server seamlessly.

'Big iron' approach, proven over half a century - where paired servers
rotated the
duty every 24 hours for *all* functions.

- Given today's cheap hardware costs, (pair of Mac Mini, baby UPS, even
FW-shared external RAID)
why not simpy duplicate?

>
> 2. If there's an attack which brings down Postfix, Exim will still
> take the load until we can get Postfix fixed.

Twins. On on-watch, one on-call.

>
> 3. Setting up Exim to be a secondary server is simple and it can
> easily handle the load.

Not as 'simple' as identical twins. ;-)

>
> I'm going to need more than three bullets in the chamber. I'm not
> looking to convert them to all Exim. I do want to get Exim in there
> and running so they can see how well it works. I like diversity in my
> systems. I'd also like to be able to bring good, well thought out
> arguments to them.
>
> Thanks...
>
> -Michael
>

While the above tinned-box approach will work with any MTA (or any other
service), Exim is marvelously
amenable to being fed account, configuration, and other information from
any and all forms of database, either via SQL calls, or from LDAP, GDB,
BDB, CDB or flat files exported to it.

This lets you keep account and configuration data readily backed up, or
optionally *always* mastered
on yet a third box, yet run from the current 'local' copy on each mx
server if/as/when that link is down.

Needless to say, the above 'two box' approach also covers any other set
of services one chooses to 'clone' and gives you time to test and do
repairs and still eat and sleep ;-).

HTH,

Bill