On Mon, 2003-03-17 at 09:08, Tom Walsh wrote: > We are investigating the procedure of moving our current mail server to > newer (and perhaps more stable) hardware. (The current server expereinces > random reboots, which are frustrating to say the least.) > > Our current configuration is a fBSD 4.2 machine running qmail+vpopmail using > tcp.smtp.cdb file rather than db based tcp.smtp.cdb. The vpopmail DBs are > located on another server that will not be upgraded, but be reused by the > new server. > > We plan on setting up a new complete server, taking some down time to backup > the existing vpopmail mail store (via tar?) restoring that on the new > server, and then bringing up the new server. > > I am looking for someboy that has done this before to provide me with any > gotchas that we might encounter. > > Here are some of the key points I for see: > > 1) backing up the current vpopmail store and restoring that on the new > server and making sure the permissions are correctly assigned on the new > server.
tar -czvf /home/vpopmail/domains/* domainback.tar.gz (IIRC) > 2) contents of tcp.smtp file (whitelists for RBLSMTPd, etc...) I've never needed to play with the tcp.smtp files. > 3) anything else I am missing? I did user data in the mysql table also. > I am going to write up the entire process to make sure we don't miss > anything, but I was alos looking for some input on some of things that I > might be missing, or not seeing. > > Any help is appreciated, I've done this twice. My install is based on Matt Simerson's toaster. I basically setup a new system, manually created the domains, then untar'd(?) the users' data back into the domain directory. The only gotcha I had, was making sure the vpopmail directory information pointed to the same location on the new server. IIRC, mine was first installed into /usr/vpopmail, and the newer version was /home/vpopmail. A symlink does the trick there. Of course, double check that the owner is correct (or do another 'make install' after you've untar'd the users - it'll do a recursive chown). I think that was it. It's easy enough that you can create the new server, move a bunch of user data over, then test it out. Once your sure it's working 'turn off' the old server, backup all the data, restore it on the new, and put the new in place of the old. Unless you want 100% uptime, then you'll have to drop the new one in place BEFORE you restore the current data to it.. But that just feels wrong to me... Rick
