DNS migration
January 22, 2015 at 10:04 AM by Dr. Drang
As predicted, I made a boneheaded mistake last night when switching DNS records to the site’s new host. Things seem to be working now, and if you’re reading this, it means the DNS propagation has made it to your service provider.
I got interrupted while in the middle of following Digital Ocean’s instructions. I had changed settings at my domain registrar and was in the middle of configuring the domain in DO’s control panel. I’d just set the A record when I had to leave the computer for while. When I came back, I thought I was done and didn’t go on to set the CNAME record. Later, after the DNS changes had propagated to my service provider, the server errors told me I’d screwed something up. Luckily, it wasn’t hard to figure out and fix.
There were a couple of things I actually did well. First, before making any DNS changes, I tested the site on the new server to make sure I’d copied everything over and had configured Apache correctly. One way to do this is to substitute the IP number of the new server wherever leancrew.com or www.leancrew.com would appear in a URL. For example,
http://256.256.256.256/all-this/2015/01/dns-migration/
would be the way to address this page on the new server.1 That’s kind of a pain in the ass, though, and it doesn’t help me test my various redirection and rewriting rules.2 To make it easier to test everything before “going live,” I added this line to the /etc/hosts file on my local computer.
256.256.256.256 leancrew.com
The /etc/hosts file takes precedence over DNS, so it directed all my leancrew.com URLs to the new server. I commented the line out (by putting a hash mark at the front) when I wasn’t testing.
With leancrew.com sometimes pointing to the old server and sometimes to the new server, I needed to make sure I knew which one I was polling at any given time. The simplest way I found to do this was with curl:
curl -v http://leancrew.com
The -v option puts curl in verbose mode. In this mode, it doesn’t just fetch the data, it also prints a running log of the conversation with the server. Included in the conversation is the IP number of the server.
Another option I found useful was -L, which causes curl to follow any redirections. Combining -L with -v let me track the redirections to make sure they worked.
I won’t be surprised to find other mistakes over the next few days, but I think the big ones are behind me.
Update 1/22/15 10:28 AM
Well, that didn’t take long. I forgot to change Apache’s DirectoryIndex setting to include index.xml files. That screwed up the RSS feed. It’s fixed now, but some of the feed-syncing services will never check again.
