Problem to be Solved
I have done something very drastic under the hood on podfeet.com and you haven’t even noticed! In a way, that’s a very good thing. I actually changed hosting companies for podfeet.com from Bluehost to DigitalOcean. Before we get into some nuts and bolts about that, let’s talk about the problem to be solved, shall we?
A few months ago I ran into a problem on my website where I ran out of disk space. Bart and I fussed around with a few things like how many backups to store and such, and essentially kicked the can down the road a bit. Well that “bit”, bit me this week.
In order to serve up the glory that is podfeet.com, I have to have two things: a domain name (that I rent from one company), and a physical server (which I rent from another company.) As you can imagine, the cost of the server is related to whether I share it with anyone (I don’t), how much disk space and RAM I ask for and a few other things like whether I have a static IP address (I do).
Option 1 – Increase disk space at Bluehost
The first option we considered was simply adding more disk space to my current server at Bluehost. This sounds super easy, and there is a little button that allows you to add another 30GB (which would double my storage). That’s $10/month more than I was paying, but I love all of you as much as I love my own children so it was worth it to me.
Here’s the problem. When Bluehost lets you have another 30GB, that storage is on a separate disk. So in order to actually use this space, I would have to actually go back and change links and such to put some content on one volume and other content on a different volume. I was soooo not going to deal with a mess like that.
My first option was to work with the Bluehost team to migrate my server to a new one so they could start it with enough disk space to be comfy for a long time. A few years back I upgraded my server to a Virtual Private Server, aka VPS. This sped things up quite a bit because I wasn’t sharing resources with anyone, and it also gave me a measure of protection against malware crawling over from other people’s servers.
The other benefit was that Bluehost would answer my calls pretty much on the first ring, so I didn’t have to wait in line with the great unwashed over on shared hosting plans. I was immediately directed to the VPS support team for my technical support.
But when I called them to talk about how to move my server, the “technical” support person (and I put technical in quotes on purpose) said all I had to do was click the button to add another 30GB for another $10/GB. I explained the problem with that (he was unaware of how it works) and he said he’d escalate my call to the VPS people and that they would email me in 24-48 hours. Wait, email? And I have to wait days just to talk to someone about how to move my server?
I hung up and called back expecting someone smarter, but I got someone less informed. Again this “tech” support person said I could push the button to add more disk. We chatted for a while and he needed my login password to check something out. I probably shouldn’t have given it to him, now that I think about it, but don’t worry, I changed it later.
My password was created from Bart’s amazing service XKPasswd.net, so it’s about 328 characters long, has numbers, letters, special characters and a goat in it. As I tried to read it back to this joker, he got confused when I said, “tilde”. He asked me what that was. I assumed it was just a bad cell connection, so I said, “You know, the character to the left of the 1 on your keyboard, above the backtick?” He said, and I’m quoting here, “Oh, you mean the squiggly thing?”
Now I’m not saying everyone should know what the tilde is, but a linux tech support person at a hosting company absolutely positively beyond any shadow of a doubt would have, many times a day, typed the ~ character because it means “home directory” in linux! He said he didn’t know what I was talking about.
At this point I hung up and decided to investigate option 2, moving to a new hosting company. Before I tell you about that though, the VPS people did write back to me two days later, and they told me to push the button to add a second 30GB disk. The only good news is I was offered a survey from that email. I may just have explained in that survey about why this answer was what pushed me to change hosting companies.
Option 2 – Choosing A New Host
Bart and I started looking at options for a new host. I was interested in Linode and DigitalOcean, and since Bart has an affiliate relationship with DigitalOcean, we went down that path. I’m going to spoil part of the story, but using Bart’s referral code I got $50 credit towards my hosting! After I burn through that $50, and I spend a real $50 of my own money, then Bart gets $50. That’s crazy pants.
Ok, now pretend you don’t know that this moving to DigitalOcean worked. We took a look at their costs for hosting what they call a droplet. Get this, their droplet with 3GB of Memory (I had 2 on Bluehost) and 60GB of storage (double what I had), it was only $15/month when I’d been paying $28/month over at Bluehost. This was too good to be true!
Well, of course, it was too good to be true. It turns out I was getting a service called WHM/cPanel over on Bluehost and that was not included on DigitalOcean. Ever since I was a wee-tiny young podcaster, I’ve had access to cPanel and I never appreciated that it was a really cool thing of value. I took it for granted. It wasn’t until Bart and I were comparing web hosting services that I learned how much I was actually relying on it. I also didn’t understand how cPanel and WHM (Web Host Manager) were related.
cPanel is a company and it builds two products: cPanel, and WHM. Yeah, confusing right out of the gate. These two services actually provide completely different functions. cPanel allows a user to administer their website through a graphical user interface (GUI) instead of the command line. WHM allows a system admin to manage the server itself.
For example, amongst many other things, with cPanel I can do stuff like use a web-based S/FTP client to upload files, I can look at my database with MySQL, and run backups. WHM is for more heavy lifting stuff like upgrading the operating system and the supporting tools that power my website like the scripting language php and the webserver software Apache. I use WHM to automatically renew my security certificate so you get that adorable little lock symbol next to https:// in the URL bar for podfeet.com.
I enjoyed learning the value of this because we discovered that I did have to pay for it but I now knew why I really wanted to pay for it. The cost of cPanel and WHM doubles the cost of my hosting of podfeet.com but now that I realize that I was so dependent on these tools, $15/month isn’t bad at all. Remember, I was paying $28/month before to Bluehost, and now I’m paying $30/month and getting double the storage and 1 more GB of RAM. I’m a happy camper!
Moving to DigitalOcean
Moving a website is a terrifying operation, at least to me. I haven’t done this since I moved from GoDaddy about 356 years ago. Bart explained that we can do this with our lovely new friend, WHM. At this point in the story, I have an IP address, a server has been provisioned, and it has an operating system, centOS which is the free version of Red Hat linux. But there’s no podfeet stuff anywhere near this new server.
We trotted into the WHM interface on my shiny new droplet, and in WHM found the tool called cpmove. This application tells my other server over on Bluehost to generate a full backup, zip it up, and then send it over to my DigitalOcean server and the new server will expand it. There are some switches here and there on what to do about the changing IP address, but it was quite straight forward.
But there was a HUGE problem. Remember the problem to be solved way back at the beginning? I was out of disk space on my old server. I had literally megabytes of space left. I’ll spare you the days and days of messing around we did trying to make some space, up to and including where I removed a folder called NosillaCast that had a bunch of stuff from 2015 and before … but also had my RSS feed which means the NosillaCast podcast itself wasn’t working for a few hours.
Eventually, we figured out that the full backup would require 2X the space of the backup (3.8GB) plus an extra GB just for fun. So guess what I had to do? I had to push the darn button to buy a 30GB disk! As soon as I did that, I could point the backup to that new drive, and it had oodles of room to store the files. It only cost me $4.77 because it was pro-rated and it worked perfectly.
Once we had a real backup it was positively magical how WHM was able to scoop it up, unpack it, change the IP address all over the place and make it work!
Another fun, nerdy thing to tell you about is how the DNS records play into this. Remember I said I have to have two things to make podfeet go – a physical server where the files are stored, and I have to have the domain podfeet.com registered. The DNS records are what allow you to type podfeet.com and the servers across the world know to send you to 18.104.22.168 where my site actually lives.
Believe it or not, I still do the domain registration over at GoDaddy and it’s been really great. Gone are the large-chested, scantily clad women on the front page. There are pictures of real-looking people doing real-looking jobs instead and I’m super happy about that.
Bart did something tricky in my DNS settings that I don’t 100% understand. In DNS there’s a thing called an A record, and that was set to simply the @ symbol and pointed to the original IP address. He had me create a second A record and had it set to www2 and pointed that one to my new IP address. Like I said, I don’t completely understand the lingo here, but the result was that for a while you could reach podfeet on Bluehost at www.podfeet.com and podfeet on DigitalOcean at www2.podfeet.com and they were identical because one was a backup of the other.
Once we verified that the new podfeet on DigitalOcean was fully functional, we changed the A record to point to the new IP on DigitalOcean. Now there’s one and only one podfeet. Other than the backup problem because I had no place to store it, the process was spectacularly easy.
After this adventure, I had a smidge of tidying up to do. Here’s a really weird thing we found. I could securely log into my new site as root using what’s called a secure shell, or SSH client. Root login is all-powerful with all privileges. However, I couldn’t log in using my user account. I couldn’t securely FTP either as my FTP client kept telling me my authentication wasn’t valid.
I had to get Bart involved again and we discovered something really interesting, and good about DigitalOcean. These guys simply do not allow you to log in with a user name and password, which is what I was trying to do. You have to use RSA Secure keys to log in. Speaking of things I vaguely understand but couldn’t explain, RSA keys are much more secure than a username and password. This threw us for a long time but once we realized the password was never going to let me in, we used the keys I had for my server and – Bob’s your Uncle – I was good to go.
Another thing I had to clean up was the podcast feeds. I use an awesome tool called Feeder from Reinvented Software to create the little text files that make all the glory that is the Podfeet Podcasts come into your devices. I push a button and then the next episode gets published. Feeder is actually securely FTP’ing that little file up from my Mac to the podfeet.com server.
I happily pushed my little publish button on Feeder for Programming By Stealth this week, but when I checked in my podcatcher, there was no episode to be found. That’s when I remembered that I had to go change the credentials for the feed file over to the new server. I was trepidatious because what if Steve Harris, the developer of Feeder, wasn’t clever and forward-thinking enough to allow me to use RSA keys to authenticate to the new server? I shouldn’t have worried because of course, he thought of that. I fixed the feeds and we were back in business.
I lied about one thing in this whole story. I said that I moved my server and you didn’t even notice. Well, that’s true for all of you but two. Dorothy noticed something amiss when she couldn’t upload the Programming By Stealth Index to podfeet.com. Her fabulous index is wee tiny text files, but she just happened to try to push those kilobytes upright while I had wedged the entire server trying to make those backups.
The second person who noticed was Chris. He tried to get the NosillaCast and discovered that the last episode was missing. He decided to finally join our Slack for the first time at podfeet.com/slack and post a question about it. Luckily I happened to be playing on my Mac right when he wrote it and that’s when I realized I’d fixed the Chit Chat Across the Pond Lite feed, the Chit Chat Across the Pond feed, and the Programming By Stealth feed, but not the NosillaCast feed. While I was in there, I fixed the Taming the Terminal feed because I know I’ll forget between now and when Bart and I record a new episode. It will happen by the way!
The bottom line is that I learned a lot, Podfeet.com has lots of room to grow, it’s much faster now too. It may be because it’s a fresh install of the operating system (we essentially did a nuke and pave), or it may be because it’s a new, more efficient version of the programming language php, or maybe DigitalOcean gave me better resources, or that extra GB of RAM is helping out. It costs me an entire $2/month more plus that $4.77 for the few days of the extra 30GB on Bluehost, but you’re worth it.
1 thought on “I Moved Podfeet and You Didn’t Even Notice – Bluehost → DigitalOcean”
> Here’s the problem. When Bluehost lets you have another 30GB, that storage is on a separate disk. So in order to actually use this space, I would have to actually go back and change links and such to put some content on one volume and other content on a different volume. I was soooo not going to deal with a mess like that.
This might not necessarily have been the case actually. It depends on how your old server was set up at Bluehost. If the server (I am assuming it is a Linux server) was set up using Logical Volume Management (LVM) then adding additional space would be as simple as incorporating the new disk space into your LVM volume group. You can then expand the size of the filesystem to occupy the new space. No erasing/reformatting/rebooting required.
I would be very surprised if your old Bluehost server was NOT set up this way (using LVM) as pretty much every server I have worked on lately, from the cheapest virtual private server (shared hosting) all the way up to a fancy 8-core dedicated server, has been set up using LVM.