Smooth domain hosting transfer with DNS.

[bananapar]

We have recently acquired a new server and have nearly finished testing set-up etc. on it.
Our domain hosting/email/DNS is all done on Plesk on an older server.
We want to migrate all of this onto the new server (also using plesk) and use the new server as the primary hosting location (with the old as backup) but want to make sure that the DNS changeover happens in such a way that our customers will not be affected, particularly with regards to still being able to use email.

The current plan is to migrate a domain at a time using the following procedure:
1. Change the TTL for the domain to be quite low. (Probably a day or so before we start)
2. migrate a domain to the new server so it is as up to date as possible.
3. Change the DNS settings with our domain registrar to use our new server (this can take up to 24 hours to change)
4. Change the DNS settings for the domain on the old plesk server to point to the new one.
5. Change secondary DNS for the domain to use the new server

Does this seem reasonable? Will TTL have any effect on cached information on clients' computers? (I suspect not)

[paulie]

Hi,

We do it 1,2,4,5,3 We also disable the domain (holding page saying try again later as its friendlier and we can't suspend the domain as it'll break the DNS piggybacking) on the old server as soon as the migration starts.

One thing we've not got working cleanly is the mail transition. I'm thinking that maybe we should disable email for the duration and after the migration on the old server to force bouncebacks / retries (better than email being stuck on the wrong server). Failing that you could script imapsync to deal with this on the new server, which is what we've used in the past when we've cocked things up (ended up with the mail working on the old server several days after the site went live on the new server!).

Also, depending on which versions of Plesk you're migrating between there are quite a few foibles you may need to be aware of, which versions are you going from to?

[biggles]

+1 for imapsync. After you set it up once you really can't live without it when doing migrations. It doesn't matter if you migrate between servers or between services (Plesk to Googles Apps for example). Or even migrate customers to your platform from other service providers. Imapsync is THE tool for mail migration!

Speaking about google. They have a quite clever way of handling migrations. They use a setup called dual-delivery, which delivers the mail to both mailservers until everyone has moved over. You might do your own dual delivery light when migrating Plesk servers. Just forward a copy of all the mail from the old server to the new server and users will find them in both boxes (just make sure they use IMAP and not pop, because then they will probably end up with duplicates...). You have to setup all mail account on the new server before trying to send the copies forward to it though...

[bananapar]

Thank you very much for the tips.
I do have one question regarding imapsync though. It's quite inefficient to try and sync an email address at a time and though plesk migration manager seems to take care of most things we would like to be sure that nothing is missed.
Would it be possible to sync a whole domain's emails using imapsync? I've found some evidence so far that you can use a master account/password kind of setup etc but I'm still researching the possibilities of that.
Or would be a better option to use something else like rsync and copy any data missing from the new server from the /var/qmail/mailnames/$domain folders on the old?

[biggles]

Personally I do an export of the mailnames and password from mysql and create a list with those accounts. Then I can easily input the file into imapsync and everything runs automatically!

[bananapar]

As my colleague has pointed out to me, all the domains we want to transfer have the same primary nameserver, which is hosted on the older server. This is ns0.domain.co.uk and domain.co.uk also uses ns0.domain.co.uk as it's primary.
the other ns records for these domains use our secondary DNS, which will take about 10 minutes to update the changes.
His suggestion is that we simply change this (ns0.domain.co.uk) to point to the new server for the more immediate redirection but we feel uneasy about this and are sure there is a big problem with doing this that we are missing.
Can anyone suggest if this would be OK?
Main concerns with me are:
a) that this could somehow mess up our connecting to the old server (we had a problem a while back where bind/named had a problem and would not restart, the server then went down and could not be contacted remotely using its hostname or IP)
b) that this does not affect the way the older server handles mail unless we remove domain names etc from various files in = /var/qmail/control/ (such as rcpthosts)

[Highland]

If you have that much concern just keep your TTL low for a while and see if it breaks. Rollback is painless at that point.

I've never had BIND crash a server.

Keep your MX records the same if email is a concern. Again, with a low TTL, the rollback is largely painless.

[bananapar]

Thanks for your reply. I should have explained a bit more that actually we want mail to go to the new server too but how our server deals with mail isn't just based on the MX record, if it's got the domain name in /var/qmail/control/rcpthosts etc it will still take it and then either throw an error or accept it into the mailbox rather than forwarding it on to the new desired location.

[faris]

If the mailbox exists and email is delivered to the old server then it will end up in the mailbox.

If the mailbox is deleted (***or email is just switched off for the domain***) and the email gets delivered to the old server then the email will bounce...but I've had an idea:

You can configure qmail to store and forward email very easily. All you need is a list of all domains you want to store and forward for, then edit/create two configuration files. Any email arriving at the old server will then get forwarded to the new one. And if the new one isn't answering, the old one will store the emails until it does.

/var/qmail/morercpthosts needs to have the full list of domains you want to allow store and forward to work for.
/var/qmail/smtproutes needs to have a line for each domain, as follows: domain.com:ip-address-or-hostname-of-new-server

Then you need to run a little qmail configuration script which I keep forgetting the name of and Breun keeps reminding me. Search here for smtproutes and you'll probably find a previous message where this was discussed.


I'm reasonably sure there's an even simpler way than I'm thinking of, but as I've not tried it I can't really comment on it. I think in smtproutes you can just use *:ip-or-hostname-of-new-server

You still need the full list of domains in morercpthosts though (this is because I think they will get deleted from rcpthosts if you switch off email, although I'm not certain.

Anyway, I'm reasonably sure all this will work. Can anybody think of something I've left out?

But I don't think you need this. Just change the TTL to 300, and firewall port 25 (or shut down qmail) just before you switch over to the new server. Sending servers will not get a connection, and will retry later (for as long as 7 days or even longer in some cases). Each time they re-try, they should do an MX lookup. Once any cached MX records they may have are expunged, they will start deliving to the new server. Hardly any email will be lost IMHO.

Faris.

[scott]

check out smtproutes then, it will let you configure qmail to hand the mail off to another server.

[bananapar]

Thank you for the help guys, morercpthosts and smptroutes certainly seem to be the files we needed to look at and after a quick test they worked quite well.
It also seems that those are also what I need to enable the old server to act as secondary MX/backup mail server.
With regards to the command mentioned by Faris, I think it could the command be qmail-newmrh. There are however a lot of commands under /var/qmail/bin/ so its possible I'm wrong there. (Though it is mentioned in an article I found at http://www.superfrink.net/docs/morercpthosts.html)

[faris]

qmail-newmrh is the one I think.

And yes, those two files are what you want if you need to create a store-and-forward backup MX.

in smtproutes, you can use domain.com:mail.domain.com rather than IP addresses, as long as mail.domain.com always points to the new server.