Blog Navigation
Partners
Latest Activity
Phil explains how to use the old telephone tones to wane off telemarketers!
Migrating / Initial configuration of a CPanel/WHM server
For any CPanel administrator, migrating accounts between servers is an issue that comes up now and again and I have not found any really great sources online on how to do this properly and minimize downtime so I thought I’d write my own guide. As always, the information provided is on an as-is basis with no warranty that this will work for your situation.
Background:
Since November, the Matthouse CPanel server (int) was sick. It started in early November by going offline with no response (my nagios monitor caught it). I thought nothing of it and hard-rebooted the machine. I read the error logs and found nothing out of place.
Aside: The kernel is the lowest level of an operating system, it is what makes disk access and other critical functions available to an operating system, BIOS typically calls a bootloader that then runs the kernel. Kernel panics are basically a condition when the kernel doesn’t know how to handle an error, and since the kernel holds the operating system up, the computer crashes and a BSOD (or equivalent) is displayed on the screen.
The next night, int crashed again, but because of the non-existent error logs, I decided to wait for a KVM device to be connected so that I could read the console screen. Thankfully when a system crashes, it leaves information up on the screen that is helpful to the administrator. In my case, the quota service was causing the panic. I disabled the quota service after rebooting the system and this helped for about a week. Then it happened again with a similar error on the console. After a lot of digging, I ran out of ideas and finally had the server checked for hardware problems. All the tests passed successfully so I let it be. Strange enough it made it for another week then the same problem occurred.
At this point, I thought it would be in the best interest of my clients to get them off the existing server and onto some new hardware in hopes of finding a long term solution to this problem. This is where the title of this blog comes into play. How do I implement a new CPanel server and move all the customers to it with almost no downtime? If you wish to know the solution, please open up the full version of this blog and read on.
The process:
In my case, I had 2 CPanel servers in the same datacenter that could talk to each other, the old server named int, and the new server named bit. Since I was planning an IP change for all the websites, I wanted to change some information in DNS ahead of time for the domains being transferred.
DNS typically has a TTL (Time To Live) value on each record under a domain. This basically informs all of the DNS servers that grab a certain record that they can cache this record for at most the seconds specified by this value. This value helps prevent internet users from bombarding your DNS server for information every time they want to communicate with your website. I should mention that in my experience, not all DNS servers (from ISPs) honor these values, but most do.
Typically, TTL values are set between 1-48 hours depending on the record type. This is why about 2 -3 days prior to migrating any domain, changing the TTL (Time To Live) value for each DNS record of each domain is advisable. I typically change the value to 120 seconds (or 2 minutes). This means that most of the world will know about the transfer very quickly.
Before I explain how to configure a WHM server from scratch (my style at least), I’d like to touch on DNS a little more.
For my case, I have a WHM DNS cluster configured using int and a WHM DNS Only Server named nibble. Int handles ns1.matthouse.us and nibble handles ns2.matthouse.us. I have several other servers which would be unreachable if nibble didn’t exist and int was down. Since int was changing to bit, the IP address of ns1.matthouse.us would also change. I didn’t want any downtime for ns1.matthouse.us, so I opted to change the IP address as soon as I got bit operational. I will explain when and how to do this in a later section.
The first step to any new server migration is to get the new server ready. This means installing an operating system and CPanel. I’ve found that during a default CentOS 5.5 installation, I disable the following services using the chkconfig command: avahi-daemon, Bluetooth, cups, and isdn. Also, if you’re new to installing CPanel, disable SE-Linux in the file “/etc/selinux/config”. I also typically run “yum update” prior to the initial CPanel installation.
Installing CPanel is easy enough to do, simply change to the /home directory, download their installer through the wget command and then run the script. For me, it takes about an hour to install CPanel.
At this point, you will want to navigate to port 2087 in a web browser to get to the WHM setup screen. I typically use most of the default options and information provided by the ISP. I do enable cphulk which is a brute force detector. I also enabled quotas since they are a useful tool in monitoring disk usage, although they might be the cause of int’s problems.
Once done with the initial configuration of WHM, I immediately update mysql via the whm upgrade tool. After the mysql upgrade completes, I rebuild apache with the default settings since they’re quick and I will have to rebuild later anyways. After mysql is upgraded successfully, it is wise to check for errors since I’ve found that I occasionally have some to deal with.
At this point, I began synchronizing all the settings from int to bit for the basic configuration and many other settings pages. I also reserved an IP from apache since I typically leave a single IP address for SSH / nameserver access since I don’t like how hackers sometimes target single websites.
I then typically will install ruby, imagemagick, gd, and sqlite3 via the automated installers in the /scripts directory via SSH. I also install clamd for antivirus, but unfortunately, a current issue with WHM causes issues when installing clamd so I will refer you to this thread for help: http://forums.cpanel.net/f5/cron-root-usr-bin-freshclam-quiet-no-warnings-117753.html#post681037.
At this point, I recommend securing mysql and the temporary directory via the provided scripts from WHM. Typically these are done automatically by the server but it never hurts to re-run them.
I then ran easyapache to update apache to the settings that were on int. I downloaded a yaml build profile from int and uploaded it to bit. My build profile is provided since I typically install suphp and other features to enable a secure environment that you might want to use. If you wish to download my build profile, it is located here: http://famousphil.com/content/Build7.yaml
After apache builds, I also added some mime handlers for office 2007 documents since apache seems to omit them by default. http://www.onlinehowto.net/Tutorials/Apache/Apache-MIME-type-configuration-to-open-docx-pptx-xlsx-MS-Office-files/1436. These were placed into the apache pre-main include editor provided by WHM.
At this point, I always like having a firewall installed. I use CSF from http://configserver.com since it has a login failure daemon that tracks more than simple brute force hack attempts. I will leave the configuration to you.
I also installed and configured an SSL certificate. I typically use namecheap since they provide cheap rapidssl certificates that work in most browsers. I typically enable the certificate for the server’s hostname (bit.matthouse.us) so that CPanel doesn’t have certificate errors and I also enable the certificate on the email services. As a quick side note, if you don’t realize it by now, you also should set reverse DNS entries for your main IP address and add appropriate SPF records so that your server’s email isn’t rejected by major email providers.
At this point, both servers are ready for the transfer when the time comes. The last step for me was to transfer ns1.matthouse.us to bit. To do this, I had bit establish a relationship with nibble and begin synchronizing DNS changes with nibble. Before I did this, I made sure to delete all the DNS zones from bit using the appropriate utility in WHM. I then established the relationship and synched the changes. Once I verified the changes were made, I modified the DNS zones on both int and bit to point ns1.matthouse.us to bit. I then went to the registrar’s website and modified the ip address for the child nameserver appropriately. At this point, all that I had to do was wait about 2 to 3 days (since this is the typical cache time for these types of records) then begin the physical account transfer. As a note, my method of migrating a nameserver before the transfer can cause problems that I will mention below.
So now that both servers and DNS are prepared for the clients, WHM makes a great tool called “copy multiple accounts/packages from another server”. I just ran this tool on all the accounts and about an hour later, everything was transferred and DNS was updated automatically. This is where the DNS problem comes into light. I noticed that some of the custom DNS entries were changed to the new IP inaccurately (it wasn’t a consistent problem), I also noticed some duplicate records were made. Unfortunately, there is no easy way to fix the IP changes that weren’t supposed to happen other than to manually change them all back. But for the duplicate records issue, I ran the DNS cleanup tool that WHM has.
After the transfer completed, I went through all the records and changed their TTL’s back to 14400 on the server (while fixing the IPs that changed). Once I finished this, the server move was complete. Keep in mind that this guide isn’t all inclusive and it may not work for you, but it can definitely help you prepare to do your first CPanel server migration.
Tags: BSOD, CPanel, crash, DNS, Kernel, Kernel panic, migration, Transfer, TTL, WHM
Posted in Hosting / Server Administration
Excellent tutorial. I run into this at times. The funniest illustration was when a client requested me to do some maintenance work and update her site as well. I did. I billed her and she paid. The very following day, she emailed asking me why I billed without upgrading her site. Sigh.
Thanks!
You’re so cool! I don’t suppose I’ve read anything like this before. So nice to find somebody with some original thoughts on this subject. I really thank you for starting this up. this website is something that is needed on the internet, someone with a little originality wonderful job for bringing something new to the internet!