Technical Difficulties: Unnecessary Details

I wrote briefly yesterday about the broken commenting here and mentioned in passing that I had made some hasty decisions when moving the domain data. This post is going into unnecessary detail about what those choices were, and a plan to get things working again.

But first: why I moved web hosts.

The Straw

I really didn’t want to move web hosts at all. I’ve hosted my domain with the same company since the middle of 1999, long before I had even thought of leaving Oracle let alone moving to the States. Their web hosting service was very good: not the cheapest, but apart from some glitches early on they were helpful and responsive, with features to their service that allowed me to do all the things I wanted on a public web host.

The thing they did badly was email.

We’d had a few issues over the years with email sent to the domain being bounced. There would be a short period (usually 24-36 hours) where a sender would have emails returned because the message had been routed through a relay with a higher-than-acceptable rate of spam transmission. We would find out about it when some kind soul would try to reach us by other means.

The intent to not promote spam-supporting relays is very noble, but the response from the support was that the sender should send their email through a different relay.

That was an unacceptable answer in 2000 when most email users were tech savvy enough to be using email, but now? How many people have any control over the routing or delivery of their email? Why should anyone even care?

Then towards the end of last year we had two significant breakages in email. First we couldn’t send anything for two days, then a few weeks later the whole email system fell over for three days.

Three days.

In the end we didn’t appear to lose any email, but that – along with the blasé lack of communication about these outages – was the final straw: I started looking for a replacement web host.

The deadline was the end of February.

Hosts of Reasons

Choosing a web host is a lot like choosing a phone provider: every company has different features and different pricing models, but it is possibly to normalise the variant scales into something comparable.

The biggest difference between web hosts and phone companies is that there are only a dozen or so phone companies to look at. Web hosts are legion.

I figured out the features I needed and started tabulating based on a superficial Google search. I needed:

  • Perl CGI support
  • WordPress w MySQL
  • multiple domain hosting (more on this later)
  • storage minimum
  • email support

The last two were quickly relegated to mere sanity checks, because every host had offerings at their lowest plan tier that dwarfed my needs. Hosting multiple domains is also a very common feature; it’s not usually present in the cheapest offering, but you don’t have to get the gold-plated option either.

The main division seemed to be between Unix and Windows shops: I saw Microsoft-based hosts that provided scripting support, but I have no wish to give Microsoft money even by proxy so those were eliminated from consideration.

In the end I found three hosts who looked most promising at comparable prices and I asked their tech support teams some questions to gauge responsiveness and so on.

In the end, I settled on a host and bought a hosting plan.

Then all I had to do was transfer the data.

The Migration Plan

Twenty two years is a long time. Many things can happen to a web site in twenty two years.

All of the static content on my website lives on my laptop. I have deployment scripts that copy files from the ground up to the public server using rsync, which makes it pretty efficient.

The things I was worried about were the Mornington Crescent servers, this blog, and email handling.

I resolved to do a staged migration:

  1. stand up the website on the new host with another domain I own.
  2. test web site setup and email delivery
  3. migrate current data snapshots
  4. fix layout issues
  5. cut across hosting of, overlaying the HTML document root
  6. setup new email addresses

Things worked as expected on the stand-in domain, and I was finding the setup I needed. Then we had that ice storm and I was unable to do anything much with the website stuff for a week.

When our Internet was restored, I had only a few days to finish the migration and cancel service before drifting into the new billing period.

But it all went fairly smoothly, in the end. There were some weird behaviours early on when things were still in the process of propagating. The hardest thing was getting the blog to work.

The Mending

… which of course is where we came in, because the blog does not, in fact, work.

The broken commenting seems to be an artifact of how I switched domains across. The WordPress installation seems to have a baked in reference to the domain I installed it on originally, even though I moved its home directory to the new location. I know this because if I go to the blog via the other domain then I can leave comments.

The most likely plan to fix this is:

  1. split the document root so has its own directory, then move the content from its current shared location into the new document root.
  2. reinstall WordPress on
  3. import blog into new location

I’ve been verifying installing WordPress on distinct domains and want to test blog import in the new instance. I will be separating from its neighbour next.

It should be fixed in a couple of days. I only hope I don’t have to delete the domain and recreate it un-mirrored, but if I do then I am sure it won’t take all that long to setup the email addresses again.

The Aftermath

One lasting consequence of going through this process is that I see endless adverts for one of the providers I looked at but decided against (they use Microsoft tools for email management so I was never going to use them).

Anyway. Hopefully that will die down eventually. Maybe I should go and look at boats so I get more variety in my spamvertising.

Leave a Reply