All, 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. The script is still *very* raw, and I'm relatively new to bash script writing. I still have some areas of work to do: - I need to incorporate the "alternatives" command to switch from sendmail to postfix, instead of using the redhat-switch-mail and changing it via gui. - I need to figure out how to automate the certificate generation. Right now I still have to type in a password at the prompt, as well as hit <enter> to accept the defaults - Some of my sed commands are kludgy. I'm still learning the ins and outs of sed - I have *no* idea whether or not Vipul's Razor is working or not. - I need to fix the yum "extras" section. - I need to improve the iptables handling. Anyway, if you guys'd like to take a look and make comments, I'm open to suggestions and whatnot. It's at: http://www.benjamin.weiss.name/mail-server.sh Thanks! Ben
On Wed, 8 Dec 2004, Benjamin J. Weiss wrote:> All, > > 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. > > The script is still *very* raw, and I'm relatively new to bash script > writing. I still have some areas of work to do:If you are new to bash, or programming in general, I think you might find learning python is more specifically suited to the task, and more powerful. However bash can work quite nicely for a lot of things ;-)> - I need to figure out how to automate the certificate generation. Right > now I still have to type in a password at the prompt, as well as hit > <enter> to accept the defaultshave you looked at "expect"? It is designed for this sort of operation. There are modules for python or perl both, and I imagine you could also get it to work from the shell. We have scripts for apache ssl cert generation that use pyexpect.> - Some of my sed commands are kludgy. I'm still learning the ins and outs > of sedIf you are doing search/replace filters, many sed commands can be replaced from the shell with perl's re interpreter by doing: perl -pi.orig -e 's/search-this/replace-with-this/' filename which is more overhead, buts lets you make a backup file (named filename.orig), and gives you the power of perl's re engine, which is arguably more forgiving in syntax than sed.> - I have *no* idea whether or not Vipul's Razor is working or not. > > - I need to fix the yum "extras" section. > > - I need to improve the iptables handling. > > Anyway, if you guys'd like to take a look and make comments, I'm open to > suggestions and whatnot. > > It's at: > > http://www.benjamin.weiss.name/mail-server.sh > > Thanks! > > Ben > > _______________________________________________ > CentOS mailing list > CentOS at caosity.org > http://lists.caosity.org/mailman/listinfo/centos >-- Ryan Sweet <ryan.sweet at aoes.com> Advanced Operations and Engineering Services AOES Group BV http://www.aoes.com Phone +31(0)71 5795521 Fax +31(0)71572 1277
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. 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! -=Eric
On Wed, Dec 08, 2004 at 09:14:48AM -0600, Benjamin J. Weiss wrote: > All, > > 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. I'm also doing a new server at the moment. Postfix, spamassassin, courier-imap, ClamAV, ClamSMTP, Maildrop, Squirrelmail. > - I have *no* idea whether or not Vipul's Razor is working or not. I suppose you use this at spamassassin time. Add '-D' to your spamd options (/etc/init.d/spamassassin) and see in your logfiles. I maded RPMs myself from the spamassassin tar and noticed the dependency on the perl-DB_File package was not specified in the spamassassin spec. You need that however (at least if you are doing spamassassin at local delivery time like I do) Cheers, -- Henk van Lingen, Systems & Network Administrator (o- -+ Dept. of Computer Science, Utrecht University. /\ | phone: +31-30-2535278 v_/_ http://henk.vanlingen.net/ http://www.tuxtown.net/netiquette/