The Northern Spy: going the new server route
TweetFollow Us on Twitter

The Northern Spy: going the new server route


Under another hat, the Spy runs WebNameHost, which is a small hosting company in business for a decade now, and offering professional hosting in a safe environment for Christian, authors, small businesses, and personal sites. This is less than a living business, but much more than a hobby, as his teaching demands that he be able to discourse with students on all manner of computing technology without seeming too much a fool or irrelevant. It also needs to break even.

Though he is otherwise Mac-centric, the commercial hosting environment of choice is a CentOS machine running Cpanel/WHM, with billing and help desk provided by WHMCS, previously a separate company, but as of this month a WHM partner. Cork, the machine he was using for everything was a dual opteron of several years seniority running CentOS 4, and therefore his version of CPanel (11.32) was the last he could use without upgrading as future versions would no longer support CentOS 4. Since it is as much work to upgrade the OS as it is to set up a new server, and somewhat less likely of success, he opted for the new server route.

After obtaining several quotes, he elected to stay with his current data centre Atjeu, move company and personal accounts (including this column) to Tara, a virtual server, and all customers to Mayo, a new dedicated. What follows is a step by step that if successfully followed should achieve such a move with little or no down time (except for the inevitable glitches, which will be mentioned at the end.) Some of this material was adapted from several existing guides, but with many additional steps and comments.

Step 0: Optimize things with respect to the old server
This should be done a few weeks before the prospective move. Any hosting service that has been in business for more than a year or two has fossils on its servers. These may be accounts not properly deleted by the supposedly completely automated billing system for the failing memory of the aging sysop, freebies or test accounts no longer being used, dead databases forgotten by their owners, or email accounts never read or forwarded (they only host; mail is elsewhere) that have accumulated thousands of junk emails.

The less you transfer to the new machines, the shorter the time taken. Paying attention to these details allowed the Spy to remove some 4G of unnecessary data. It's also important to check the backup logs to ensure that process has been functioning without errors.

The Spy also found two corrupt databases in need of repair (customers hadn't noticed -- go figure) and these had to be fixed, as an account transfer will fail in such cases.

Finally check to ensure all accounts do indeed have their DNS correctly resolving and that you have access to the registry for that account (not needed if the nameserver names will remain the same and just change IP numbers).

Step 1: Provision the new server(s)

A week or more before planning to move accounts, cut the deal with the data centre to set up the new servers (one at a time). Once they are up and running with at least some of the IPs you need (if staying in the same DC, others can be moved) there is much work to do before it is ready to accept accounts.

First, the server needs to be securely locked down. Whatever such facilities the DC has installed, go immediately to ConfigServer, and buy their whole meal deal for $150, having them set up the firewall, mailscanner, and several other WHM plugins. Configure these, and tweak the WHM and firewall settings as needed to match your security policies. Use the php settings to forbid some of the more dangerous php functions, copy your server-wide email and firewall black and white lists from the old server, configure exim, get the backup routines going with a test account, and generally watch what goes on for a week.

Chances are there will be issues to solve, possibly involving the partitioning of the disk space. For cPanel, most of the space has to be in /home, not in /root, and a dedicated should have a second drive for /backup, which must be mounted and functioning.

Second, you may have other software you need to install. In past times, for instance, Fantastico was usually provisioned (sometimes as a DC throw-in) for customers to install their own scripts. Now, Softaculous may be a better choice (still being tested by the Spy). However, any such tools, skins, etc, must be installed and tested on the new server before any accounts are moved. In some cases you may have to have licenses reissued with the new server IP, but with companies such as WHMCS, this process can be undertaken by the licensee directly.

In addition, there are probably Perl or other modules that you installed at one time or another on the old box that need to be installed on the new. Compare lists and refresh the new accordingly. Your customers will be sure to let you know later when something fails.

Step 2: Reset the TTL much lower on all DNS zones

When a request is made to any website, data concerning the location of website, mail, etc. is pulled from the DNS. To cut down on the frequency of such requests, they are cached locally and by intermediate machines. Because this information can and does change from time to time, each record (line) of the DNS announces a number of seconds the data can live in the cache (TTL or Time to Live) before it has to be replaced by a new query.

Since you don't want old data sending queries to the old server for a long time after the move to the new, this TTL must be set to a fairly low values. Do this at least three days before the move by an SSH to the old server as root and issuing the commands:
cd /var/named
perl -pi.bak -e "s/14400/314/g" *.db
/etc/rc.d/init.d/named restart

This will change all the domain database files line by line from a 14400 to 314 TTL time and back up each .db file as it goes. The Spy picked 314 because it is the first three digits of pi, is unlikely to occur in any of the DNS records, and gives a TTL of just over five minutes. 300 or 399 will do as well. Do not use a value below 256. (Test question: why not?) Why three days? Because some machines don't respect the TTL all that well, and there needs to be time to inform them of the change.

Step 3: Cluster the old and new server

In WHM for both the old and new server, select Configure Cluster, and with the key from the other server, add it to a cluster. Activate clustering. This will cause the DNS records to synchronize between the two. Check the new server to ensure that it has the copies.

Post a sticky on your monitor as a reminder to self not to delete a DNS zone as it will delete on both machines. Deleting an account would delete it on the one machine and the DNS zone for it on both.

Step 4: Move accounts

A few days before moving a group of accounts, warn the reseller or if you are the reseller, warn all account holders that there could be outages in mail, ftp, and cpanel on the day of the move. If there are no glitches, this should not actually happen. But when Murphy strikes, you won't be exorciated for not telling them.

Moving should be done on a per reseller basis, to cut down on later corrections after you mess up the first few times. Do this using the "copy multiple accounts and packages from another server" function on the new server. Use Express move all the time. This will ensure that the account on the old machine is suspended so no new traffic goes there. Leave the window showing the move results open until it is finished or the move will abort. Check the log of the move to ensure all was OK.

Of course, as each account is moved and its DNS is changed to reflect the new environment, the clustering will ensure that the old DNS is changed too, pointing any would be traffic to the new machine. And, at this point, it is the DNS on the old machine that is the live one, not the one on the new, even though the latter is a copy and is where the changes are happening.

The first time, you might want to copy only the packages. While in the process moving accounts, it may be a good idea to stop the mail and ftp services, and cpanel as well if you are particularly paranoid about not wanting data to appear on the old server and not get moved.

Move the reseller account first, ensuring it gets its dedicated IP as needed, and that appropriate IPs are delegated to it for creation of accounts (main shared and any dedicateds).

Sign on to the new machine as that reseller and make another trip to the Move multiple accounts section, select all that resellers customers and again express move them all. The nameservers should stay the same, the new delegated shared IP should be attached, and any that had dedicated IPs should get new ones, SPF records should be updated, databases moved, mail and cron jobs also, the works—all this reflected in the DNS.

However, the move routine does have a bug. If the DNS FTP record is a CNAME, all will be well. If it was the IP of the old box, it will not be changed. This has to be fixed after the fact, probably by the root as most reseller accounts are not given access to DNS editing. Don't forget that DNS changes happen on both machines. While you are at it, scan all the DNS records to ensure they are otherwise correct, but do not change the TTL. Restart any stopped services on the old machine until you are ready to move the next reseller.

For each account with a dedicated IP, go to the data centre control panel (or put in a ticket as needed) and ensure that the DC has a correct reverse pointer to the new IP. If you were having mail announce using the the data in /etc/mailips and /etc/mailhelo that data and /etc/mail_reverse_dns must be edited and saved according to the new IPs, these settings tweaked in whm, and exim restarted. If you had a global setting for such announcing, these files are populated automatically.

Repeat for each reseller until done. Note that if you are moving within the same DC, you may elect to keep your IP numbers. In this case, you may find yourself deleting some from the old box and adding them to the new as you go. If so, don't forget to have the DC move them from your one account to the other. You cannot delete an IP if it is still being used, so at the end of the day there will still be some to add to the new box.

Step 5: Re-number the nameservers

The nameservers for the main box and those various resellers that also have them all have to be edited, first on the new server, then at the registrar.

Change the nameserver IP for each nameserver you use t your domain registrar. This may require a ticket, but at Enom, this is quite simple. Just go the the main (top) menu selecting Domains-Advanced Tools-Register A Name Server, then Update. Enter the nameserver and its new number on the new box. Do this for both nameservers for each account that has them. After this is complete, on the new server, edit the dns zones for those nameservers to reflect the new numbers you will be using.

Important: Do not try to do this change earlier in the process, though you can do it on a per reseller basis after each reseller is moved. The DNS on a machine points to web files relatively. Thus, the new machine cannot, prior to an account move, point back to the old, but because the DNS does have IP numbers updated, once the account is on the new, it is pointed to there locally.

Step 6: Wait several days before declustering

Unlike your DNS records, which currently have a low TTL, those at the registrar have a high one. Thus, there will be a few days before you can assume all the cached DNS records have been refreshed with the new ones. Only then can you decluster the two machines.

Step 7: Reset the new DNS

After a few days more have gone by and you have made any further corrections, SSH to the old server as root and issue the commands:
cd /var/named
perl -pi.bak -e "s/314/14400/g" *.db
/etc/rc.d/init.d/named restart

This will change all the domain database files line by line back from a TTL of 314 to 14400, and as before, making backups. You may need to make global changes to the SPF records to remove the surviving mention of the old server's IP as a correct sender, and to clean up the ftp records if this hasn't already been done. If you are unsure of what command needs to be issued here, practice on the old box, as it is now decoupled from the new.

Step 8: Inform customers that all is complete
and, of course invite them to test things. Note that all mailman lists must now be accessed at the new box, not the old one.

Step 9: Decommission the old box

After yet a few more days more have gone by and you have solved the additional problems that arose reqarding email not working, software settings not being correct, Perl modules your customers needed not being installed, etc. it is time to let the old DC know that its box is no longer needed and can be decommissioned. If staying in the same DC and keeping IPs this is the time to add the last of the old numbers to the new box and have the DC move them between the defunct account and the new one. Congratulations. Except for troubleshooting the problems that customers only now bring you, you're done.

--The Northern Spy

Opinions expressed here are entirely the author's own, and no endorsement is implied by any community or organization to which he may be attached. Rick Sutcliffe, (a.k.a. The Northern Spy) is professor and chair of Computing Science and Mathematics at Canada's Trinity Western University. He has been involved as a member or consultant with the boards of several organizations, including in the corporate sector, and participated in industry standards at the national and international level.

He is a long time technology author and has written two textbooks and six novels, one named best ePublished SF novel for 2003. His columns have appeared in numerous magazines and newspapers (paper and online), and he's a regular speaker at churches, schools, academic meetings, and conferences. He and his wife Joyce have lived in the Aldergrove/Bradner area of BC since 1972.

Want to discuss this and other Northern Spy columns? Surf on over to ArjayBB.com. Participate and you could win free web hosting from the WebNameHost.net subsidiary of Arjay Web Services. Rick Sutcliffe's fiction can be purchased in various eBook formats from Fictionwise, and in dead tree form from Amazon's Booksurge.

URLs for Rick Sutcliffe's Arjay Enterprises:
The Northern Spy Home Page: http://www.TheNorthernSpy.com
opundo : http://opundo.com
Sheaves Christian Resources : http://sheaves.org
WebNameHost : http://www.WebNameHost.net
WebNameSource : http://www.WebNameSource.net
nameman : http://nameman.net

General URLs for Rick Sutcliffe's Books:
Author Site: http://www.arjay.ca
Publisher's Site: http://www.writers-exchange.com/Richard-Sutcliffe.html

URLs for items mentioned in this column
CPanel:: http://www.cpanel.net
Atjeu:: http://www.atjeu.com
WHMCS:: http://www.whmcs.com
Configserver:: http://www.configserver.com
One source:: http://forums.cpanel.net/f5/guide-transferring-all-accounts-new-server-1...

 
AAPL
$97.90
Apple Inc.
+1.47
GOOG
$720.09
Alphabet Inc.
+15.85
MSFT
$51.59
Microsoft Corporation
+1.56
MacNews Search:
Community Search:
view counter

view counter
view counter
view counter
view counter
view counter
view counter

How to build a successful civilisation i...
GodFinger 2 grants you godlike powers, leaving you to raise a civilization of followers. In the spirit of games like Black & White, the GodFinger games will see you building bigger and better villages, developing more advanced technology and resources while keeping your followers happy. [Read more] | Read more »
How to get all the crabs in Mr Crab 2
Mr. Crab 2 may look like a cutesy platformer for kids, but if you're the kind of person who likes to complete a game 100%, you'll soon realise that it's a tougher than a crustacean's shell. [Read more] | Read more »
How to be a star in Britney Spears: Amer...
If you've ever wanted to be a star, baby, then you've probably already checked out Britney Spears: American Dream and are happily making your way up the charts. But fame doesn't come easy, and everyone needs a helping hand sometimes. So we've got some tips to make sure you end up getting money for nothing and your chicks for free. [Read more] | Read more »
AppSpy is hiring a part time Staff Write...
| Read more »
How to save lives in ER Surgery Simulato...
A serious earthquake has struck a nearby town in ER Surgery Simulator - Emergency Doctor, and it’s up to you to save the victims. [Read more] | Read more »
Tips and tricks to get a high score in G...
Ketchapp Games loves the endless runner genre. And its newest game, Gravity Switch, is no exception. Gravity Switch takes a fresh approach, though, as you move a block, suspended in zero gravity, safely through a maze of shifting pillars. If the block hits one of the pillars, or if you’re flung into open space, it’s game over. [Read more] | Read more »
Tips and tricks to get a high score in S...
Smash Fu is a high-paced tile-tapping game that requires quick reflexes and some practice. You’ll have to smash bricks with the skill of a seasoned black belt to get a high score. To raise the stakes a bit, you’ll also have to avoid tapping any dynamite that is thrown your way - missteps can be deadly. Fear not, though. We have a few tips in store... | Read more »
How to keep the ball rolling in Dropple
If you're new to the minimalist puzzler Dropple, you may find yourself struggling to make it beyond the first couple of steps before your ball falls into the endless abyss below. [Read more] | Read more »
Game Craft releases new Legend of War ti...
Set for release at the end of this month, real time strategy title Legend of War seems sure to delight with a veritable feast of sweet features to get stuck into. Developed by Game Craft, the game is due for release through both the App Store and Google Play on May 26th. With the utilisation of spells, weapons and a good deal of strategic thinking... | Read more »
How not to die in Traffic Rider
Traffic Rider, an Out Run-esque game in which your ride a motorcycle recklessly into trffic, might not seem particularly complicated. [Read more] | Read more »
All contents are Copyright 1984-2010 by Xplain Corporation. All rights reserved. Theme designed by Icreon.