Moving an Existing cPanel Site to OS X Server

If you have an existing site being served from a cPanel host without needing a database, making the move to OS X Server couldn’t be more straightforward.

DNS Preparations, and the Basic Copy Using Rsync

First, in preparation for the move, you should lower the TTL value on your existing DNS for the site you’ll be moving. That way, the old DNS information can be flushed out more quickly when you’re ready to make the move. Some WHM/cPanel setups are configured with obscenely long TTLs as a way of reducing load on the server, but while this might provide a minor performance boost in ordinary use, when it comes time to move a site, it can be a real pain in the neck.

(If your site uses PHP at all, it may also be worth checking my earlier article “Good Practice for Adapting PHP Code to Alternative Storage Schemes, Including OS X Server’s” to be sure your code won’t be negatively impacted when trying to run from a directory not named public_html and without its own private space in the directory one level up.)

With that done, it’s back to OS X Server. After creating the site in Server.app, being sure to enable .htaccess support, SSI, custom web apps, or anything else you might need, you can simply copy the files you need to the site’s new directory on the new server.

If you like, this can be accomplished via SFTP from your local machine. But unless you have bandwidth to burn, or your site is not particularly large, it will probably happen quite a lot more quickly directly between your old server and the new one using rsync:

(You can also navigate directly to the directory where they’re needed on the new machine, to avoid typing in the full long path to the new location.)

This is just a slight variation on the common ‘-az’ shorthand for ‘archive’. It will preserve existing permissions via the ‘-p’ flag, but if any of the files required especially liberal permissions on your old host, it’s probably better to omit the flag and set up permissions manually on OS X Server. (Setting liberal permissions — such as 777 — on cache directories and the like is a terrible idea yet remains pretty common on WHM/cPanel hosts running Apache as user ‘nobody’. With Apache running as a named user on OS X Server, such liberal permissions should virtually never be necessary.)

If you copy an entire site directory tree using rsync, do take care to check and fix, if necessary, the permissions for the site directory itself: the rsync copy may leave you with something other than OS X’s expected 755 permissions on the site directory, which may yield 401 errors when visiting the site. It might sound like a blazingly obvious thing to check, but it’s easy to forget, and I myself have wasted an hour or more troubleshooting a completely non-functional site just because I forgot:

If your site is using basic or digest authentication to protect files or directories, now would be a good time to update the relevant .htaccess files to make use of user- or group-based digest authentication. (See “Password Protecting Directories, Files or Whole Domains via a Web App”.)

You’ll also need to set up any email users, email aliases and forwarders, and so forth on OS X Server, cron jobs, etc. A separate article can help with the last of those: “Replacing Cron Jobs With Launchd on OS X”.

SSL Certificates

Like many administrative tasks on OS X Server, moving an existing site’s SSL certificate from a WHM/cPanel server is extremely straightforward. If you’ve kept copies of your private key and signed certificate, you can jump straight to importing them into Server.app. If you don’t have copies of these handy, start by grabbing your private key and signed certificate from WHM via the SSL Key/Crt Manager. Click on the ‘download’ icon, which as of this writing won’t actually download anything, but will give you the key in raw form which you can copy and paste into a text file and save with the same name and extension as shown by WHM:

Back in Server.app, you can go through to managing your certificates and the certificate import window:

Simply drag your existing private key (the .key file) and signed certificate (the .crt file) into the certificate identity import window — along with any chained certificates you may need — and hit “Import”.

Now you can choose which services and which sites will use the certificate you’ve imported. Presto — done!

Finishing Up — DNS

And finally, everything is ready for the DNS change that will enable your new server to begin delivering the site. Flick the switches at your DNS provider, wait a little while for the new DNS information to reach your neck o’ the woods, and you should find your site is now being served by the new machine. If you want to begin testing your new site immediately, without waiting for DNS propagation, you can edit your own local machine’s hosts file to associate the domain name with the server’s IP address — or you can even set up a single A record in Server.app reminding the server that the new site lives at the server’s own IP. If you do so, and if DNS on the server is configured to provide services for the machine itself, you can verify that the name will now be correctly resolved from the server itself with nslookup:

The results should tell you that the name was correctly resolved via 127.0.0.1 (i.e., the server itself). You’ll now be able to fire up Safari or another browser on the server itself via Screen Sharing and take a look at how your site will soon be appearing to the outside world. (Note: using any browser directly from a server should always be done with the utmost care due to the potential for interaction with untrusted third-party sites like advertising servers.)

• macOS
• security