* * * * *

                              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. 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.

 2. Configure services. We methodically went through each service on tower,
    making sure we had it installed and running on the new server.

 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. 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.

 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. 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).

 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.


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] gopher://gopher.conman.org/0Phlog:2003/06/20.1
[3] http://www.tragic-smurfs.com/
[4] http://combat.uxn.com/
[5] gopher://gopher.conman.org/0Phlog:2003/06/23.1
[6] http://www.spews.org/
[7] http://www.dialtoneinternet.com/

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.