Did your migration go through properly? Any troubles? Austin Jorden Digitalpath Texas http://www.dptexas.com
On Mon, August 14, 2006 4:06 am, Kurt Bigler wrote: > My uplevel talked me into using an even simpler approach (more like > yours), > making my original question partly moot. The two servers (freebsd jail > vps's actually) are binary-compatible so we just rsync'd the entire server > (vps). We will do a final rsync for the real transition after doing some > testing first. > > However your step 5 concerns me. I'm assuming in the scenario I just > described that your step 5 isn't necessary, and please correct me if I'm > wrong. The uid/gid's should be identical, and I confirmed that vpopmail > gets 89:89 on both servers. Qmailadmin seems to think the domains and > users > were transferred ok. Pop and smtp access seems to work. > > My originally described approach was intended to be more "conservative" > and > even permit me to migrate one domain at a time in a leisurely and careful > way, and would avoid shutting down qmail until the entire transition is > complete. From a message on the toaster list I gleaned that I would need > to > hand-empty the virtualdomains file on the old server to implement my > original step 5. > > Thanks for your detailed info, which confirmed my uplevel's suggested > strategy, and which I'll file for future use, and is a good piece for the > archives. > > -Kurt > > > on 8/13/06 9:31 PM, Austin Jorden <[EMAIL PROTECTED]> wrote: > >> I've worked with your exact setup before nearly. >> >> The best thing you can do is.. >> >> 1) Do nothing on your old vpopmail machine yet. >> 2) Install vpopmail on your new machine >> 3) DO-NOT create your domains or anything on your new machine yet. >> 4) Use Rsync through SSH to copy your vpopmail directory from your old >> server to your new one. I know the exact command if you want it. >> should >> be /home/vpopmail >> 5) Create your domains on your new machine, you'll get a warning >> "Domain >> already exists" however it will create anyways and all of your users >> will >> be automatically created, and your domains will get the correct UID and >> GID's. >> 6) When you're sure it'll work for you (which I'm 99.9% positive it >> will), simply use rsync to recopy your old vpopmail directory to your >> new >> one on the new server. RSync will only copy the new files, so it >> doesn't >> recopy anything, therefore you don't have any missed e-mails. >> 7) Repoint your DNS and you have a complete transfer. >> >> on your old machine, >> do this.. >> >> rsync -av -e ssh /home/vpopmail 0.0.0.0:/home >> >> Replace the 0's with the destination IP address, it'll prompt you for >> the >> new servers root password, enter it in and it'll build file list and >> transfer everything over. >> >> You may get some warnings and/or errors from rsync saying "Some files >> could not be transfered" that's because some files your trying to >> transfer are currently being used, etc. To stop that, simply cutoff >> the >> connections and then transfer (possible right before you transfer >> everything to make the new server active) >> >> If you have any questions, let me know. >> >> - Austin Jorden >> >> On Sun, August 13, 2006 8:35 pm, Kurt Bigler wrote: >>> I'm migrating my vpopmail server to a new machine. The DNS zones >>> fortunately do not have to be moved. >>> >>> My tentative plan for how to achieve the transition is as follows. >>> >>> (1) set up the new server with identical vpopmail domain/user structure >>> (2) have the new server ready to receive SMTP for these domains, but >>> with >>> no >>> MX pointing to it yet >>> (3) set up the old server to route ALL outgoing SMTP through the new >>> server >>> >>> At that point everything is basically set up for a transition, but >>> nothing >>> has really changed yet except how outgoing SMTP is being routed. >>> >>> (4) On the old server, delete all domains currently delivered locally >>> there, >>> but still accept incoming messages for those domains. (Also retain >>> maildirs >>> and contents for later copying. So I can't just vdeldomain.) The idea >>> is >>> that incoming messages still go through the old server, but as soon as >>> the >>> local domains are gone they get passed on to the new server with all >>> other >>> outgoing SMTP. >>> (5) Copy all residual POP directory contents left on the old server to >>> the >>> new server. >>> >>> (6) Re-point the MX to the new server. Actually this is probably just >>> an >>> A >>> record change since the MX hostname will remain the same. >>> (7) Update all other relevant A records that end-users have entered >>> into >>> their MUA configurations. >>> >>> >>> I'm not sure of a couple things in the above plan. >>> >>> >>> (a) Basically how do I achieve step (4) above? Do I manually empty the >>> assign file and/or virtualdomains files since I need to retain the POP >>> directories and so can't use vdeldomain? >>> >>> (b) On the new server, is there any advantage (or necessity) to >>> accepting >>> delivery for the domains but deferring the actual local delivery until >>> the >>> old POP contents are copied over first? >>> >>> >>> Thanks for any thoughts. >>> >>> -Kurt Bigler >>> >>> >>> >>> >> >> >> > > >