Yesterday, a client of mine was having their DreamHost dedicated server migrated to a new dedicated server because the one they are on intermittently becomes unresponsive at 8pm ET, seemingly at random.

DreamHost’s diagnosis is that the server is on a Linux kernel version that is supposedly causing this, and their recommended solution to the problem isn’t to just upgrade to a kernel that doesn’t have this problem, which would be trivially simple, but to upgrade the entire operating system and migrating to a new dedicated server.

As a person who manages servers for a living, I get it: it can suck having to support old stuff sometimes. The old server is on Ubuntu 14.04.6 LTS, which is quite old at this point, but isn’t due to reach End of Life until April 2022. The new dedicated server they’re moving us to is only on Ubuntu 18.04.5 LTS, which isn’t even the newest Ubuntu at this point, which would be Ubuntu 20.04.1 LTS. Still, any opportunity to force a customer to do a major OS upgrade because the service you’re providing is failing intermittently, I suppose if you don’t give a shit about your customer, you make them do it.

There’s only four small sites being hosted on this server.

There are a combined total of 103.3 GB worth of files, and 7.5 GB worth of MySQL data. These numbers might seem large by year 2000 standards, but in 2020, this is trivially small; it can all fit comfortably in RAM on any modern server, or stored on a modern iPhone.

Transferring this from one server to another over a 1 Gbps link shouldn’t take more than 19 minutes, and less than 2 minutes on a 10 Gbps link. Migrating from one server to another shouldn’t take more than 30 minutes, tops, and that’s if you’re a Neanderthal and type with your fucking elbows.

Thinking that this should be a quick and easy migration, we requested the migration back on October 28th, asking for a date and time when the migration could be done. On October 30th, DreamHost responds saying the data center team would need to do some prep, and that they’d let us know when they could schedule the upgrade, “likely early next week.”

Apparently, “early next week” in DreamHost-speak takes over a month.

Fast-forward a month, and on November 28th, I send a follow-up message asking what the status is with our request. Four days later, on December 2nd, I get a response saying they’re ready to go. I respond on December 3rd, requesting the soonest available time slot, because at this point I just want to get this over with. I get a response late that night saying that they’ll schedule the upgrade for the next day, December 4th, at 11am PT/2pm ET. Fantastic, we’ve got a plan!

The time comes, it’s 2pm ET, and I’m sitting here, with the Cloudflare panel open in one tab, the DreamHost panel open in another, and the sites all lined up in 4 other tabs, ready to pull the trigger on changing the DNS to point everything at the new server to minimize whatever downtime I can. I’m prepared.

At 2:57pm, I get an email from DreamHost saying that they’re only now starting the migration. Okay, fine, whatever. The email says I’ll receive an automated email once the upgrade is done. Cool, let’s get this over with!

… time passes …

… and some more time passes …

… I’m starting to wonder if my spam filter ate their automated email …

… and the sites still haven’t been migrated …

At 7:26pm, I send an email pointing out that at least one of the sites is down because it can no longer connect to its database. I point out that I haven’t gotten an email that the migration has completed yet, so either their process has failed or they have seriously taken four and a half hours, so far, to complete a migration that should have been 30 minutes, tops.

At 8:37pm, having gotten no response to my earlier email, and the site still being down, I send another email, asking for an update. How much longer could this possibly take?

Getting no responses to my emails, I decide to give DreamHost support’s “live chat” a shot. I queue up at 9:17pm, and eventually get connected to a person at 9:27pm. I ask for a status update with our migration. I notice that while I was waiting in queue, an email arrived at 9:16pm saying their upgrade process failed and had to be restarted.

Are you fucking kidding me?

I stay on the live chat to try and get progress updates, and see if there’s any chance this is going to actually get done tonight. Sadly, at 10:19pm, I’m told that the migration process has failed again, and that the tech who was doing it will revert part of the migration to point the sites at the databases on the old dedicated server to bring the sites back online, and that they’ll come back to this on Monday.

At 10:42pm, I’m informed that the sites should be back online and that and that there’s nothing more that will be done this evening. I confirm that the sites are back online, and end the chat.

***

I was a long-time DreamHost customer, myself, since 2006. But, after they changed their service offering in 2015, I had enough and closed my account.

At that time, I was just happy enough to leave and leave it at that. But now, 5 years later, seeing that the DreamHost experience has continued to get worse over time, I’ve decided that not only am I not going to give them my business, I’m not going to have my clients give them their business, either.

If you’re currently hosted at DreamHost and unhappy and want to move away, but haven’t because you’re either uncomfortable moving your site by yourself, or you’ve tried hiring someone in the past to do it and they failed, I want to help move you.

Contact me and tell me about your DreamHost experience, and I’ll see to it that you’re moved to better hosting.

I was born in the 1970s, grew up in the 1980s and 1990s, and a latch-key kid. On top of that, I’m an only child.

Amanda’s only a few months older than I am. We both grew up in the northeastern United States. She has an older sister, so she’s not an only child, like me.

If I ever wanted anything, I had to figure out how to get it myself. I had no one to ask for help.

I never learned how to ask for help.

She describes asking for help as this wonderful thing, where you just put your faith in the universe that if you just ask, that you can trust people who will answer.

The audiobook is filled with great stories of times where she’s needed things and just by asking, got what she needed, usually.

She tells the story of someone who doesn’t usually ask for help, and the one time he does, when he really needed it–to have his aunt reconcile with his dying mom–and she refused, it crushed him.

I may be misremembering details of the parable, as I was listening to it while driving, but I seem to recall her advice is to not only ask for help when you absolutely need it, but to just ask for help all the time, so that you can learn to handle rejection which is inevitable. Definitely sounds like some sage advice.

I don’t know how to ask for help.

The times when I need help, it’s because I don’t even know what I need. Exactly how do you ask the universe for help when you don’t even know what you need?

This is my conundrum. As someone who has learned to be wholly independent, if I knew what I needed, I would just go out and get it or go and do it myself.

I’m only half-way through Amanda’s audiobook, so maybe she’ll explain what to do in this situation. I wanted to get these thoughts down in writing while they were bouncing around in my head, though.

Do you know how to ask for help?

How did you learn how to ask for help?

I first signed up for my DreamHost account back in January of 2006. For the most part, it’s been a great experience. I originally signed up for the two-year plan for $214.80 ($8.95/month), and added VPS to my account in March 2009, for an additional $18/month.

I was okay spending the extra money in order to have a VPS that I had full control over. DreamHost even tweeted about offering root access with their VPS back in February 2011. It was definitely part of the attraction for many customers.

Then, on November 17, 2015, DreamHost sends out an email informing customers that in two weeks, they would be removing everyone’s sudo (root) access, on November 30.

Wow. Just … wow.

What recourse did we have? Try and sign up for their DreamCompute offering, which is still in public beta, and there’s now a wait-list to even get access to it?

Sell me a product, then take away a key feature but still charge the same price, while suggesting an upsell into a different product offering if I want to get that feature back? That’s called bait-and-switch, and that borders on fraud.

This was the last straw. Several times in the past I’ve wanted to switch away but was too busy to really do it, but this forced my hand: I had to move away, and from the looks of it, I wasn’t the only one.

I ended up moving my stuff over to Amazon AWS. It looks like it’ll cost me around $10-12/month, netting me a savings of close to $15/month compared to the $26.95/month I was spending at DreamHost.

I’m relieved now that I’ve actually gotten around to moving everything off DreamHost. No more wondering if they’re going to change their product offerings again. No more wondering if my sites are going to come back up when they’re down.

Well, DreamHost, it’s been nice knowin’ ya, but I’m officially done. I suppose it was good while it lasted, but like many good things, this too had to come to an end.

Edited to add: And, the account is now fully closed.

Here are the versions of the tools that I used:

$ rsync --version | head -1
rsync version 3.1.0 protocol version 31
$ cvs --version | head -2 | tail -1
Concurrent Versions System (CVS) 1.12.13 (client/server)
$ git --version
git version 2.6.3
$ cvsps -V
cvsps: version 3.13

First, I grabbed a copy of the CVSROOT, and checked out the module so I had a reference copy to compare to when I’m done.

$ rsync -av aolserver.cvs.sourceforge.net::cvsroot/aolserver/ aolserver-cvs
$ cvs -d $(pwd)/aolserver-cvs co -d nsmysql-cvs nsmysql

Then, I create the working directory for the local git repo.

$ mkdir nsmysql
$ git init nsmysql

Next, do the actual CVS-to-Git conversion.

$ cvsps --root $(pwd)/aolserver-cvs nsmysql --fast-export | git --git-dir=nsmysql/.git fast-import

Finally, do a diff to compare the two working directories to make sure the import worked correctly.

$ cd nsmysql
$ git checkout master
$ diff -x .git -x CVS -urN . ../nsmysql-cvs

If everything looks good, go ahead and push it up to GitHub.

$ git remote add origin git@github.com:aolserver/nsmysql.git
$ git config remote.origin.push HEAD
$ git push -u origin master

I don’t do this often, but when I do, I always have to figure it out each time, so hopefully next time I’ll find this blog post at the top of my search results and save myself some time.