[Centos] *very* raw script for a new email server
ahpook at gmail.com
Wed Dec 8 18:54:12 UTC 2004
On Wed, 8 Dec 2004 09:14:48 -0600 (CST), Benjamin J. Weiss
<benjamin at birdvet.org> wrote:
> I'm putting up a new email server, but I can't afford downtime when I
> switch servers. So, I've been writing a script that will take a CentOS
> install and turn it into a secure email server with Spam Assassin,
> Amavis-new, ClamAV and external relay using SASL authentication.
Hi Benjamin. I'm sure your script will ultimately work OK, but your
statement that you "can't afford downtime when you switch servers"
suggests you might want to think about how exactly you're going to
do the switch, rather than how quickly you can configure the new server.
It can be very helpful to write up a list of tests that you can perform
after you cut over that will exercise all of the functionality you want
to provide and will tell you whether you need to roll back or not.
"Send a mail locally to an external account - should succeed"
"Send a mail from offsite to a local address - should get there"
"Relay from offsite to a remote address - should be denied"
"Relay from offsite after auth to a remote address - should succeed"
Then once you do the cutover you have a very systematic way of knowing
that everything is working OK.
If you have two physical machines, the old one and the new one, you should
take your time and set up the new one by hand (rather than by script), and
maybe plug it in side-by-side with the old one, without the public IP
address that the world is talking to. When you're ready to cut over,
'ifdown' the old one, 'ifup' the new one, and run your tests. If your
tests fail, depending on how bad the failure is, you can decide to roll
back to the old server by reversing the process or fix things "live".
You really want to do everything possible to avoid cutting off your
rollback path. The worst situation is when you're commited to the new
server but it's not quite working, and you're frantically debugging
shell (or worse, sed!) syntax trying to dig yourself out of the hole.
Sorry this is not specific to centos, but from reading your email I
had flashbacks to some ugly mail server cutovers from the past...
hopefully this helps you avoid some of the pitfalls -- good luck!
More information about the CentOS