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