The easy as pie CPanel WebFaction migration guide.

for reasons of plenty, I’ve had to end up switching hosting away from the server I won’t be running for much longer. The host I picked, I did largely based on the fact they advertise themselves as being a host for developers–which, for me, translates as a host for geeks. And so far, it looks that way.

I’m coming from a vantagepoint of having full access to my server, so that was something to get used to. But WebFaction, my new host, pretty much lets me do most of what I could do on my own server with a minimal amount of problem–at least so far. The getting set up was a lot easier than I expected, and I expected it to be fairly simple to begin with.

A little background. My server runs cPanel, largely because some of the folks I host aren’t as technically minded as I am, so if they want to make themselves a brand new email address at 4:00 AM, I want to let them. The down side of that, of course, is CPanel likes to get in the way of most skilled sysadmins. I’ve learned to work around it for the most part, and push it out of my way where I can’t, but generally speaking I always hear of it being a fight to accomplish some complex task mostly because the folks at CPanel have a different idea of how things ought to be laid out than, well, most normal people. That said, it’s mostly working around CPanel’s general assumptions that makes migrating to any host in general, and WebFaction in particular, a little bit of a trick. If you’re used to it, then it’s a non-issue in about 5 seconds. If you’re not a sysadmin, then it gets even more fun–but I can probably help you work around that if you’re reading this.

The bulk of the steps will be carried out in your new host’s control panel of choice–WebFaction has a very nice one that takes a bit of getting used to largely on account of they have a different concept of how websites come together than most people are used to, but the basic principles should be relatively translateable. And if you’re considering WebFaction, their support times are trying very hard to compete with mine when I’m awake–no support request I’ve put in has been left longer than an hour.

When I moved May and I over, the steps were almost entirely the same–except, of course, that mine were a bit more involved on account of I’m also running the DNS infrastructure for the server I’m soon to be shutting down. Moving us over went largely like this:

  • Create the necessary platforms on the new host:
    • For May, that’s a couple domain names, a database, a couple email addresses.
    • Me was a couple domain names, a few databases, a few legacy subdomains, and all the necessary pointers to the old server so other people I’m hosting over there don’t break–and also because I haven’t yet migrated my mailing list over yet. Oops.
    • So the new host knows of canadianlynx.ca, the-jdh.com and related infrastructure before it even needs to be forced to use it.
  • Back up the necessary databases from the CPanel server
    • Log in to the CPanel box with SSH, if you have SSH access, and: mysqldump -u username -p database > database.sql
    • Where username is the login name you use to access the database (hint: check the relevant config files for, for example, WordPress to find it), and database is the MySQL DB you’re wanting to back up (again, check the relevant configuration files). This puts a copy of the database as it is right now in the root of your home directory–or in whichever directory you’re sitting in, if not that. It will ask you for your database password, at which point again, check your configuration files if you don’t know it.
  • FTP (or, preferably, SFTP) the .sql file from old host to new–for this, I use WinSCP, simply because I can connect to both old and new at once and tell the thing to pull from one and push to the other. And, well, since I’m lazy, that’s exactly what I do.
  • Depending on the size of your database(s), you’ll have time while they move to go back to your new host’s control panel and create the new databases if you didn’t already do that. You can create the user(s) for them as well, which helps. WebFaction is pretty flexible with DB names, which also means you can probably have the same database name, username and password you had on CPanel, which ought to prevent breakage. I didn’t take that route, but that was for largely OCD reasons.
  • Your database transfer should be done now. Taking the info you used to create your databases on your new host, SSH into your server (WebFaction provides you SSH access by default) and then:
    • mysql -u username -p database < database.sql
    • where username is the username you picked for your new database, and database is of course the new database name. Again, it will ask you for your password–give it the one you set for the new database, not the one from your old host, unless of course they’re exactly the same, or things will break. It’ll take a second or two, but then the contents of database.sql will appear in your new database.
      • Note: WebFaction runs its database server on the same server as your web stuff, which is defined by localhost. MySQL uses this by default, so this command will work. If you’re on another host, like for example DreamHost, they let you create a database hostname to reach a separate, shared MySQL server. To import your database into that, you’ll want: mysql -h database.host.name -u username -p database
  • We’re at a pause point here, as we can’t migrate any farther until we finish setting our infrastructure up on the new host. Right now, your new host knows your domain name exists, but doesn’t know what you’re planning to do with it.
  • On WebFaction, they divide the concept of web hosting into 3 categories–domains, such as the-jdh.com, which let you host your email and generally just point to the server, applications, which are what actually serves up your web content (think WordPress, or your forum software of choice), and websites, which essentially connect applications to domain names–so you can tell, for example, myblog.com to pull its content from the myblog application.
  • On other hosts, generally speaking as soon as you create a “website account”, or “web hosting account”, it gives you space on a server and doesn’t much care what you put in that space. WF tries to customize its environment for the application you’re running, if it can get away with it.
  • Either way, you’ll want to create that space now. On WF, create a static/CGI/PHP application if you’re running, say, WordPress. You could, if you felt like being creative, just create their standard WordPress application, but WF automaticly hands you a database with it then and generally makes more work for you in the long run, but that’s an option.
  • Connect the newly created application to your previously migrated domain name using a website record.
  • Now, return to your FTP client. Connect to your old host and download everything in the public_html folder of your account–that’s where CPanel stores pretty much all website data. Optionally, if your client supports it, tell it to upload it to webapps/appname on your new host, where appname is the name of the application you created above–you did create one, didn’t you?
  • Depending on how much you have up there, it could take a while–mine took a couple hours overall. Now is a perfect time to double check things, then do some preliminary testing. Some web hosts give you a subdomain you can use to test things before they go live. In WebFaction’s case, you get a subdomain in the form of panelusername.webfactional.com, where panelusername is the username you use to log in to your control panel. Configure the website you created above to accept connections from both your domain name and panelusername.webfactional.com, or your new host’s equivalent if not WebFaction. That way, you can access your web content before you actually switch your domain over.
  • Tripple check you’ve created all the email addresses you need while you’re in the panel. Once you change over your name servers, which is the second last step–and last step you’ll actually be able to perform by yourself, any email addresses you’ve neglected to create will stop working on account of they don’t exist on the new server, and you’ve told everyone to forget about the old one.
  • Now is the waiting game. depending on how long it takes for your content to be transferred, I’d advise you grab a coffee or several.
  • When that’s done, and before doing anything else, pull up your webfactional subdomain in a web browser. Make sure there are no errors or anything of the sort–if there, you’ll need to edit configuration files. Most commonly, the error you’ll see is related to databases. Replace all the database info in the affected configuration files with the info from the database you just created, and those problems should solve themselves.
  • Once you have everything working on the webfactional domain name, and are sure everything is set up for when you bring your actual domain name over, it’s time to make the switch. Contact your domain registrar, provided it’s not the same as your old host, and change your nameservers to be the following:
  • <

    • ns1.webfaction.com
    • ns2.webfaction.com
    • ns3.webfaction.com
    • ns4.webfaction.com
  • If your domain registrar is your old host, I’d recommend you transfer it first–I’ve had very good luck with Misk for all things domain. Then make the changes listed above.
  • And that’s all you can do on your end. Now, everyone else needs to catch up with you. It should take about 24 hours or so for everyone to realize you’ve moved–so don’t go cancelling anything on your old host just yet. Once the nameserver changes have updated globally, then you’re safe to cancel things. And at that point, you’re hopefully successfully migrated away from CPanel to wherever your new host is hanging.

I had a few more specialised tasks running, such as a Cron job for scraping the various RSS feeds I read, but those I pretty much scattered in amongst the larger tasks that required waiting for. And now, this site and everything that goes with it lives on a shiny new web server I’m not directly maintaining. If you’re hosted on the server I do maintain, you shouldn’t feel a thing.

Switching out really is that simple if you know exactly where to look. And if you’re lost at any point, Google is your friend–and so are the comments. Now, let’s go see if I need to finish breaking anything else on my new host before I get too comfortable.

Dear CPanel. You need to support Postfix. I’ll even ask nicely.

Since my former web host gave me the boot for fairly ridiculous reasons, I’ve had the pleasure of getting extremely familiar with a server and software of my very own. Part of the setup I’ve got going on now involves CPanel, which escentially lets me set up a website, email address, or any number of other things automatically inside of about 5 seconds as opposed to doing the configuring all manual like and probably contributing to my brain damage in the process. It actually isn’t too different from the control panel software the old host uses–except that they insist theirs is custom-made, but you’ll have that. There’s the occasional minor issue with the software, but over all they can be worked around or otherwise plain ignored if they aren’t already in the process of being fixed (see also: IPV6 eventually). I can’t say I love CPanel, but I’m fairly sure it wants me to. And it’s almost convinced me. Almost, except for one minor problem.

I like to be able to tweak, adjust, reshuffle, arange, configure and otherwise mess with pretty much anything I can get my hands on. If it can be changed and not result in flatlining the server, I’m all over it like white on rice. For the most part, CPanel lets me do this thing and doesn’t complain too much. Try something funky with spam settings? Sure, here ya go. Shove an extra layer of security over web trafick? Let me help you with that. And if by some freak accident I completely bork the thing, I’m usually only about two commands away from tossing the breakage aside and restoring to a last known reasonably good configuration–thank christ, since one thing doing this on my own has shown me is I’m an absolute fail at storing my pieces of configuration files in 50 million places. But where CPanel’s limits show up isn’t necessarily in CPanel itself but rather in the software it chooses to support.

Fast forward to my only real, niggling issue with CPanel. Hardly a dealbreaker, but it would definitely work towards making me a lot more open to not trying to roll my own. CPanel doesn’t handle email quite the way I’m used to it handling–even when I wasn’t hosting my own email. For starters, CPanel installs Exim as its mail transport agent (MTA). Now, don’t get me wrong–Exim’s good for what it does. I have no real complaints with Exim. I just can’t do anything overly useful with it without recompiling the source–something CPanel doesn’t do, and so if I were to attempt it, I’d probably be walked over as soon as the nightly updates ran. It’s not as flexible with logging as I’d prefer either, giving too much information in some areas and yet too little in others.

I’d have much rathered if CPanel supported, either natively or otherwise, the use of Postfix for its mail relaying. I’ve started advocating for as much on their feature requests site in recent days. Based on what I know, the two are very similar. But for all their similarities, the way they handle is almost completely different–at least if you’re me. For starters, Postfix leaves more to the configuration files and less hardcoded so direct access to the source is required–again, useful given CPanel doesn’t compile its MTA and doesn’t give you the option of doing so. Additionally, Postfix is a more security-focused MTA, in the sense that it can be jailed/chrooted without breaking the rest of the system similar to how cPanel already gives you the option of locking individual users into a jailed environment so they can’t affect anything outside their own space. The ability for Postfix to drop priveleges doesn’t hurt its case any either. Postfix also tends to handle message delivery differently from Exim–generating a message for each individual address, rather than grouping messages addressed to more than one recipient into one bulk message. This has the added advantage of a single address that generates a temporary failure doesn’t cause the MTA to hold back on delivering that or any other message to anyone else who just so happens to be using the same mail destination–something that’s come up to very occasionally annoy me.

I’m noticing as well that Exim, unlike Postfix, is relatively quiet when potential problems crop up. For instance, Postfix can be configured to send email on certain types of failure, not just to BCC you when the server itself generates a delivery status notification. So if Postfix is encountering a resource issue, let’s say it’s close to running out of diskspace, it can alert you by email. It can also log the details of an SMTP interaction for more involved diagnosing. For instance: figuring out at which point in the transaction is a connection falling apart, so I can better figure out what needs a good solid tweak in the nose to do what it’s told.

I like CPanel well enough, now that I’m not improv learning it as I go–or having to fight with it to do what it aught to be doing pretty well out of the box. I’d like it even more if it supported the Postfix mail agent. And for that, I’d even be willing-ish to say please. Now if we could just skip right down to the part where all I have to do is flip a switch, we’ll be in business. Your move, CPanel.

In which cPanel and CentOS actually, uh, kind of do what they should?

I’m still trying to figure out if it’s just because somebody decided to smack me in the head a little too hard, or I woke up in an alternate reality at some point, or what. But an interestingly weird thing happened over the course of the last couple days. I asked cPanel and CentOS very nicely to do something for little innocent old me, and the server didn’t actually catch fire.

A little background, for those of you who may be almost as sadistic as me. Installing Icecast on a CPanel server, any version, any time, used to be a right royal bitch. Compile the thing from source, curse as it spits out 80 million missing dependencies, compile those dependencies from source, curse as it still can’t find them–by the way, /usr/local/lib64 being in root’s environment path apparently does not help when the configure script is freaking braindead, then spend the next 5-10 minutes tracking down all those dependencies, finding the exact shared object the configure script wants to reference, then symlink the whole damn batch to a directory wherein the damn script wouldn’t bitch. If I didn’t occasionally *use* Icecast, just setting up the dependency structure for the compile process would warrant hourly billing for the poor bastard who asked for it. But since I do, and hey, it was an excuse to flex muscles I haven’t needed to flex since the last time I smashed Gentoo, I figured oh what the hell. So Icecast existed, compiled from source, dependencies and all. and I kept 80 million notes for the next time, just in case. And then the wickedest weirdest awesomest thing happened.

I’m not sure if it’s a CentOS 6 thing, or the version of CPanel I’m running, or hell, maybe the OS devs just finally decided let’s update a bunch of packages that we haven’t actually updated in at least a year and a half (Did I mention I hate binary OS’s for that?). But on a random thinggy, I thought hey, let’s run a theory. They’ve had time to fix their shit, and they’re not Debian, so maybe. So I skip the tracking down of my usual source dependency packages, and go straight to the configure process. It falls on the floor. Apparently, the server has ogg-vorbis support (hey, that’s an improvement right there), but it’s 0.6.x. Awesome. Wicked. Nifty. Cool. But Icecast wants 1.x. Well fuck me running. So I’m all ready to go tarball hunting. I’ve got links, I’ve got references to other links, I’ve got ice cold (no, literally ice cold) caffeine, bring it, bitch. I do the usual dance. make sure my links haven’t broken in a year and a half, make sure nothing was unexpectedly updated and I need to do something slightly different this time around, and I find something so new it still has that new geek smell. Where before, the CentOS package manager absolutely hated to do anything remotely involving Icecast and its dependencies, this time, I was fed exactly the command I needed, in exactly the format I expected, that I’m pretty sure I tried a year and a half ago that made just about everything fall down around my ears. But, hey. Maybe. I didn’t find this in Google last time I looked, so maybe. It would certainly make me less dependent on vodka, if nothing else. So I do the do, and suddenly, I’ve got updated libraries the configure script likes, and a couple packages I’m pretty sure the box I set this all up from via source last year is still missing. And because CentOS did whatever CentOS does with it, the configure script *should*, God willing, find the damn things without me needing to perform minor surgery. So I run it, kick back, and hope the booze store’s still open just in case this thing blows up–it wasn’t, by the way. And the thing not only compiles, but compiles like a dream. Thing threw less warnings on this box than it did last year.

I nearly fainted. CPanel doing what I say is a rare occurance when it comes to actual, significant admin things. CentOS doing what I say is even more rare, for anything, administrative or not. Both of them cooperating on the same task, at the same time, and neither’s arm needing to be twisted? That alternate universe theory sounds better and better all the time. And then I go and install something like Logwatch (believe it or not, the server was not handed to me with that installed), and I run smack into CPanel’s damned yum.conf exclude line. Okay, right universe. CPanel just wanted to mess with my head. Did I mention I hate it when CPanel wants to mess with my head?