On Wed, 8 Dec 2004, Eric Sorenson wrote:
> On Wed, 8 Dec 2004 09:14:48 -0600 (CST), Benjamin J. Weiss
> <benjamin@xxxxxxxxxxx> 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.
> For example,
> "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.
Good idea. :) I hadn't formally written it down, just in my head.
> 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".
My testing methodology has been a bit different. I have an evaluation
copy of VMWare that I downloaded, and I've been using that. I installed
CentOS on it, then took a snapshot. I'll do part of the script, then go
tot the VM, download and run the script. Then I'll see what went wrong,
reset the VM to the snapshot, and do it again.
> 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.
Yep, I agree! Not only am I testing with the VMWare, but I do have a new
box. I'm going to set it up this weekend on a domain that I have but
don't use much, and set it up as the mail server for that domain. Then
I'll migrate my old email from mbox to Maildir, subscribe to a couple of
lists, use the squirrelmail and thunderbird clients, etc. I plan on
testing for about a week. Then, when I'm satisfied, I'll do your
suggestion.
The main reason for the script was because I didn't want to have to type
the same stuff over and over and over while figuring out the process of
getting the server running. I just figured that it might be helpful to
others, so I'm sharing it in the spirit of open source. :) Plus, I figure
that if others take a look at what I'm writing, I might get some good
suggetions on how to improve the code. I've been programming for awhile,
but never in bash before.
> 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!
Hey, no prob! I apreciate the input!
Thanks!
Ben
