I recently tried (unsuccessfully) to replace one of my qmail servers (Red
Hat Linux 6.2)
by:
1) creating new qmail server (lets call it mail2)
2) tar'ing up the following dirs:
/var/qmail/control
/var/qmail/queue
/var/qmail/users
/home/vpopmail/domains (cause I use vpopmail)
/home/vpopmail/users (cause I use vpopmail)
3) stopping the qmail processes on mail1 (the qmail server to be
replaced) and mail2
4) un-tar'ing the files on the mail2
5) shutdown server mail1
6) rename and re-IP mail2 to mail1 by editting the following:
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/hosts
/etc/sysconfig/network
/etc/HOSTNAME
7) bring up new qmail server (now known as mail1)
The hopes were by following this pattern I would:
* experience very little down time
* if a problem occured, all I had to do was simply shutdown new
qmail server and bring up old one
* no DNS changes to make
The only problem was it didn't work. Everything seemed to come up OK. Email
could be queued up
but would not get delivered UNTIL I bounced the box. In this case all the
mail that was queued
up got sent but any new mail still experienced the problem (it would queue
up but would not be
delivered until I rebooted the box).
After a few frustrating attempts at fixing, I simply shut the new box down
and brought
up the old one.
The only thing I could guess was the when qmail is compiled, I remember the
instructions were specific about making sure (hostname -f) responded with
the
FQDN. Since at the time the box was compiled, the FQDN of the
new qmail server was mail2.domainname.com, this caused some problem
when I shifted the FQDN to mail1.domainname.com.
Questions:
Is their a better way to perform this task?
Did I miss some key task when I renamed and re-IP'd the new qmail server?
Steve Woolley
[EMAIL PROTECTED]
