I’ve previously been using Ghost as the primary software for my website, although that has turned out to be a questionable decision. Software support was fine and the service was stable enough, but general experience of trying to get it to work nicely with Docker (and security updates) has made it a bit of a hassle to manage, especially if I wanted to do something else with my server.
In addition, trying to make the website a portfolio for what I had already done and accomplished proved harder than I expected. A lot of my academic work is not published in part due to academic-integrity agreements. Most everything that you see here is in fact my own work, done with minimal guidance and on my own time, which brings us to the primary reason I am switching over to a VPS.
Server infrastructure is fun to play around with, less fun to maintain when maintenance becomes complicated enough that hearing about a new vulnerability makes you worried that some state actor is going to breach my home network and read my search history. This new site is contained on a remote site, under how many layers of abstractions – a proxy, a firewall, another firewall, a hypervisor, another firewall, and then Docker, with regular snapshots. Short of the datacenter itself getting hit by a missile, it is slightly more secure. Either way, I’ve decided that it would probably be for the best to migrate to a VPS.
So, I have two tasks ahead of me:
• Migrating the data from Ghost to WordPress.
• Migrating the infra from my home to a remote server.
Migrating to the remote server itself was a painless operation. Provisioning the server and setting up the OS was a breeze – two clicks and done, which is a testament to how nice the datacenter itself was. The dashboard that managed the VPS was sluggish as hell for some reason – though the VPS itself was quick enough that it was faster to manage everything over CLI. I added my SSH keys and updated the server, set up users and permissions and everything was set. Nothing I hadn’t already done and I was in familiar territory.
Migrating Ghost to WordPress also quick. I knew there wasn’t any clean way to preserve the data that I had already wrote aside from simply copying the written text, so I simply dumped the contents of the website into several files and re-posted them onto this new site. As a bonus, Word has a much better inbuilt spellchecker than Firefox or Chrome and fixed several typos left out and about. Modifying the article dates wasn’t possible without at least some hassle, but would be possible to publish the articles into the past by modifying the database directly.
Unfortunately, I consider myself to be “good with technology”. I reasoned that it wouldn’t be that hard to roll my own self-hosted instance of WordPress and set up the required software for it. I’ve done it enough times with other sites that I was feeling confident that nothing would break too much and the site migration would be done by the end of the day. Psyche!
The site itself was being accessed directly from a public IP address and I needed to pass it through a reverse proxy if I ever wanted to run more than a single WordPress site. I set up the reverse proxy, edited the DNS records, and changed the site URL. My site immediately crashed.
As it turns out, there were three problems with the method that I had used so far.
- I had wrongly assumed that I had access upon catastrophic failure.
- DNS records rely on a working proxy manager and correct IP addresses.
- SSL can’t be implemented halfway.
Addressing the first problem was just a matter of patience. Rather that pop a hard drive to look through the data that I could salvage, I could only access bits of the server at a time – and instead searched through the files to download the main “wp_posts.ibd” database. As a coincidence, this is about the time that I managed to edit the publication dates to match my prior articles. I hadn’t made many changes beyond moving some articles, so no loss.
The second problem was a slightly more involved process. I didn’t know what to look for, but I knew that the error originated when I tried to redirect from the proxy manager into the docker container (hint) – and the original site that resolved to the IP address was no longer resolving. The reverse proxy listens on ports 80 and 443, which means that any attempt to revisit the site from the IP: PORT resulted in a default page being shown. Accessing the site via IP meant that the site would redirect to the existing URL and then show the default page. Loading the site directly would show a “catastrophic error”. As it turns out, once the proxy manager took over the redirection, directing the page to the VPS IP was a mistake – it needed to be redirected to the internal Docker network.
The third problem was implementing SSL. WordPress can implement SSL on its own and does so, but there is no way of telling it to do so without editing the PHP files directly. Changing the URL to HTTPS within WordPress meant that the site was receiving an SSL Cert, but didn’t know what to do with it – and the site would not resolve. Instead, I opted to first configure SSL at each step – from user to Cloudflare, from Cloudflare to proxy, and finally proxy to site, testing each step. If you examine the little lock in your browser, you’ll see that everything works now.
Despite this crazy little adventure, I wish I migrated the server sooner. Over the course of the last year, I learned enough to begin to work on websites that are publicly accessible and deal with the ensuing security concerns and issues that arise from publicly facing servers. Sure, there are some kinks to work out, but there are other benefits. When on-prem is my-bedroom-closet, there are some things that you notice after a while.
I don’t need to deal with physical hardware or the process of shuffling around a server to deal with power and cooling. Reinstalling Ubuntu becomes a one click process. I managed to get two 9’s of reliability out of consumer hardware and no UPS – amazing for the equipment but simply not worth the effort, this VPS has three 9’s of reliability in their SLA. Load times decreased from ~2 seconds to ~0.5 seconds. No more server hum. Nice.