[Centos] *very* raw script for a new email server

Wed Dec 8 19:04:19 UTC 2004
Benjamin J. Weiss <benjamin at birdvet.org>

On Wed, 8 Dec 2004, Eric Sorenson wrote:

> 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.
> 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 

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!