Not sure which backend FS you used, but perhaps you should look into
something with snapshotting possibility. That would make backups easy
and manageable. Another option is to run each server in its on VM,
enabling snapshotting and rolling back each configuration pretty easy too.
~A
On 2013-08-20 01:07, Harry Duncan wrote:
Might help if you actually said what your current email system is, and
what mail storage it uses, and what your new mail system is and what
its mail storage is going to be.
I am about to embark on a similar exercise to migrate a fairly old
courier-mta system to a brand spanking new couter-mta system. Going
from courier to courier is going to make the job easier. My current
courier-mta uses an LDAP backend, maildir storage, and is wall to wall
courier, but all on the one machine. What I plan on doing is:
1) Setup a new ldap server on a separate machine, migrate the ldap
tree to that, reconfigure authldaprc to point to the new ldap server,
and then stop ldap on the current mta.
2) Deploy a fileserver, and share the storage by NFS. Mount the NFS
into the current mail server. Rsync the maildir folder to the NFS
location.
3) Need to review relatively recent postings by Sam to the
courier-imap mailing list about what has to be done to avoid NFS
issues, make those changes to the current email system, then pick a
night to switch, pick an off peak hour, stop mta, rsync again, and
then re-mount the NFS share into the directory tree on the current MTA
where it currently expects to find the users homedirs to deliver mail
to, then restart the MTA. Should be a relatively short operation.
4) Deploy my new courier-mta server to include mta, pop, imap,
sqwebmail and smtp, configure authlib against the LDAP server, mount
the NFS storage so that the new MTA can deliver to the same directory
structure.
5) Test the new MTA, and when happy that its going to work out, make
the necessary DNS changes to send mail to the new MTA instead of the old.
6) Let the old MTA run side by side with the new for the duration of
the DNS change which in my case will be purposely short for the
exercise, and when I'm happy that the old MTA is not going to receive
any new email for delivery, and when I am happy that it has emptied
all its queues, then shut it down.
Job done.
For me I'll now have a mailsystem where storage, ldap, and
mailservices are on three distinct servers instead of all on one
server, and where the MTA software is more up to date, and in a better
condition for ongoing maintenance.
Assuming nobody is going to point out other glaring holes in my
strategy, my only other todo's will be to review my original deploy
notes, and the more recent deploy notes for a small MTA that put in
for a customer (something which brought back a lot of memories, highly
recommend it).
The last time I had to migrate an email system, I was migrating from a
SuSE boxed product which was an integration of postfix, cyrus,
skyrixgreen, ldap and a whole other bunch of chewing gum and scotch
tape. That one I migrated in a fairly tedious manner using an IMAP
client. Have to say, I have never looked back since migrating from
that system to courier-mta. At the time there was a lot of FUD about
courier-mta, but the system looked good, and my experience with its
stability and service since is such that I'd be hard pushed to look
any other direction now other than a complete wall to wall courier system.
ymmv
HTH
Harry.
On Mon, Aug 19, 2013 at 4:23 PM, Michael Chonlahan
<michael.chonla...@okcareertech.org
<mailto:michael.chonla...@okcareertech.org>> wrote:
We are looking at going to a new email system but want to forward
current
email to the new system
need some help setting this up.
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
