Server move wrapup

RIP (Rest in Peace) tower: 10:08 pm, March 3^rd, 1999–1:30 pm, June 23^nd, 2003.

Well, it stopped serving web pages around 10:30 pm Sunday the 22^nd, but it was finally turned off between 1:00 and 2:00 pm Monday. I had it mailing me a status every hour; the last one I received was 1:00 pm Monday—giving 444 days, 13 hours and 13 minutes of continuous operation since the last reboot.

For a machine that was going to be tossed out, it served us well.

Now, a recap of the steps Mark [1] and I went through to move services off of tower and onto our new machine, swift.

• 1. DNS (Domain Name Service). On Friday [2], I set the DNS records to have a time to live of one hour (from its normal setting of one day). Since we couldn't keep the old server running at the same time, we felt this would minimize the amount of time service would appear unavailable. While this increases the load on the nameservers, it does keep the DNS propagation delays to a minimum. It would take a full day for the changes to fully propagate (since the previous TTL (Time To Live) was one day), but since we had until Monday, this was sufficient for our needs (thankfully).
• 1.
• 1. Note: Make sure that the primary name server you are using isn't itself being moved from one server to another. Unbeknownst to me, Rob [3] (who has his own colocated server and handles our primary DNS) was that weekend moving everything to a new server. A mixup in communication meant that the changes I thought I made weren't being propagated for about four to six hours. Ah well.
• 1.
• 2. Configure services. We methodically went through each service on tower, making sure we had it installed and running on the new server.
• 2.
• 3. Synchronize files. While we were configuring services, we were also moving data files off of tower and onto swift. One of the first services we shut off was FTP (File Transfer Protocol), to prevent anyone from changing files. We also restricted shell access for the same reason. Email (namely POP (Post Office Protocol)) was left open—we planned on making email the last thing to move over.
• 3.
• 3. Note: Make sure that all the files are synchronized before making changes on the new server. I had fixed all the CGI (Common Gateway Interface) programs when Mark suggested we do one last sync just to make sure. Lost all that work and had to do it over again.
• 3.
• 4. IP (Internet Protocol) address. It wasn't until Saturday that we got the IP address of the server, and that was when we were at the new colocation facility. Slide the machine into the rack, hook up the crash cart, configure the IP address, reboot and start checking the services. Once it was up, we could continue remotely.
• 4.
• 4. Note: Make sure that the IP address obtained isn't blocked because of spamming [4]. Had any of us there done that, we could have avoided snafu (Situation Normal All Foulded Up) yesterday [5] (as a sidenote—it was a mailing list I'm on that bounced because of the block, but Rob notified me that he himself uses SPEWS (Spam Prevention Early Warning System) [6] and had thought an email I sent to him had bounced).
• 4.
• 5. DNS, part II. Do not up the TTL on DNS records for a few days, until everything is working well. This helped us when the snafu happened.
• 5.

Although things weren't as flawless as the time we moved tower into DialTone [7], it could have gone a lot worse than it did. But since we had been planning on this anway, things worked out, and so far, no major problems have cropped up since yesterday.

[1] http://www.conman.org/people/myg/

[2] /boston/2003/06/20.1

[3] http://www.tragic-smurfs.com/

[4] http://combat.uxn.com/

[5] /boston/2003/06/23.1

[6] http://www.spews.org/

[7] http://www.dialtoneinternet.com/

Gemini Mention this post

Contact the author