Moving this blog to a new host
Colophon posts are coming thick and thin these days. But, if I want to keep writing, I must write about what occupies my mind. And here we are.
(Aside: What is it with all these bloggers that seem to spend more time tweaking their setup than actually writing and blogging? We're legion.)
Moving on from Wordpress and Cloudways
For the last few years — barring a bit of experimentation here and there — I've hosted this blog on Cloudways. Aside from the terrible experience that is their web interface for managing your server(s), I've been happy enough with Cloudways. If you want a one-click VPS solution for your Wordpress sites, you could do worse.
After moving on from Wordpress I wanted to change that. For one, it's pointless to pay for bells and whistles to manage your Wordpress sites when you have a simple static website. You can get a clean VPS with the same specifications for about half the price by going directly to [Digital Ocean](https://www.digitalocean.com/.
Indeed, my first thought was to move my site to a similar VPS with Digital Ocean. Upon reflection, I decided I should put my money where my mouth — or in this case, my pen — is. The past year I've written frequently about my dislike for big tech. I've been vocal about the importance of supporting independent alternatives.
To promote change and fight the tech oligopoly we need to be mindful in all choices related to technology. Does picking this service or that device help entrench the incumbent, or does it contribute to the resilience of the resistance? This is mind, I set out to find a truly independent option. A call for suggestions on Mastodon yielded many good options.
The one that stood out more to me than the others was OpenBSD.amsterdam.
Why OpenBSD/.amsterdam?
Firstly, they are truly an independent option. With some 800 Virtual Machines hosted across 24 servers, you can probably fit their entire operation inside a tiny corner of the space dedicated to powering the employee coffee machines at AWS.
Secondly, they are a mission driven operation. For every virtual machine they rent out, a portion of the turnover is donated to the OpenBSD Foundation. A foundation dedicated to the "development, advancement and maintenance" of the software deployed to their machines, OpenBSD.
And what's OpenBSD, you ask? From the horse's mouth:
The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography.
Free and open source technology is the foundation on which all modern technology rests. Although you'd be hard pressed to realise, considering most of what we — as consumers — are exposed to is proprietary software. But almost all of it is built from the work done through initiatives like OpenBSD. That these initiatives continue to flourish is pivotal. Because it gives us options.
The option to take a stand against big tech hinges on the availability of DIY options — like OpenBSD provides.
The option to compete against big tech depends on accessible foundational technology upon which you can build your products or services — like OpenBSD provides.
Don't get me wrong. OpenBSD is just one of many amazing grass root initiatives out there. The point is not that you should find a way to support them specifically. (But if you do, I don't mind!) But rather to say that when you have the means to support one such initiative, you should. Because our chances of avoiding the worst of the dystopian visions for the future of technology depends on it.
As for me, I've been thinking about setting up my own web server at some point in the future. To learn more about the sysadmin work I tend to dread. Initially, I thought something like Ubuntu Server would be the obvious option. Upon doing some more research, however, I found that OpenBSD's philosophy and mission highly aligned with my own. Their "less is more" approach appeals to me, as do their emphasis on standardisation and correctness. Why struggle with a full fledged Apache or nginx server when the much more simple HTTPd will meet all of my needs?
Which made this host switch the perfect opportunity to start dipping my toes in the water. A virtual machine is the obvious way to experiment and learn before trying to set up a physical machine.
Making the move
First order of business: Make the order. Already at this point I managed to mess up. When going through the order form, you're asked to share your public key for SSH access to your VM. Being a complete n00b, I only included the actual key. A quick look at the example — who's got the time?! — and I would've seen that I should have included the key type specification as well.
The result?
I couldn't log in to my VM once it was deployed and I got all the details. No worries. The good folks at OpenBSD.amsterdam sorted it out quickly. I was soon up and running.
Next, I had to start finding my way around an OpenBSD installation. There's a first time for everything, and unless you're particularly gifted (I'm not) you'll feel clumsy for a while. I certainly did. Still do!
One of the biggest challenges for me is handling and editing files without a GUI to rely on. Text editors in particular. OpenBSD's "vi" was no exception to that. Navigating my way around configuration files without being able to resort to a mouse/trackpad was incredibly awkward for me. In the past, I've done all file editing locally and then used FTP to update the files.
This time around, I was determined to give it a proper go.
The web server
A quick look at the OpenBSD Handbook taught me everything I needed to know. About httpd, they write:
OpenBSD comes with a built-in webserver called httpd. (..) it’s a very basic webserver that supports FastCGI and TLS. The biggest downside of this server is the lack of gzip compression which results in larger than necessary files being transmitted and the accompanying performance penalty. The idea behind this is very much in line with the larger OpenBSD philosophy that security is top priority and performance may take a hit in achieving that.
For a simple static website like this, that's a perfect match. Following the steps outlined in the guide, it took me no more than a few minutes to get the basics in place. I quickly reached a newly created index.html by typing the server IP into the address field of my browser. Easy!
A decade back, that would've been sufficient to get going. Nowadays, however, clients fetching data from a web server expect you to be able to transport data securely. That requires SSL. For websites, that means you need to obtain a certificate for the server that authenticates at the domain level. Thanks to Let's Encrypt you can get that free of charge.
OpenBSD ships with a program for handling these kinds of certificates. It's called ACME client, which is short for Automatic Certificate Management Environment. Neat. How do we do this? Thankfully, the OpenBSD Handbook had me covered here as well.
I followed the instructions more or less to a tee. And within an hour of getting access to my virtual machine, I had set up the certificate management and everything was ready to go. Of course, you can't obtain a valid certificate for a domain until the domain actually points to the web server in question. So I had to update the DNS records for my domain before I could get a valid certificate.
Setting up the build process
Before pointing my domain to the new server, I wanted to make sure my website was available at the new server. With a static website, that's a breeze. Upload the files that make up your website, and you're set.
With a more advanced site that's dynamically generated with a database and all, it's a little more work. (Luckily, I wrote this tutorial 18 years ago. The steps would still be the same. But, depending on the software you're using, there are tools to simplify the process.)
If you read the post where I wrote about creating Windrunner (my custom static site generator) you know that my build process is super simple. When a page is created or updated, a simple Python script connects to the server through SFTP to upload the new and updated files.
I had done exactly zero research to figure out if that was possible out of the box with OpenBSD. Would it perhaps require installing some extra packages? No idea. So what did I do? Well, I fired up FileZilla and tried to connect to the server to upload the files. Connecting went just fine. But when I started to upload the files to the correct directory, it didn't work.
Permission denied.
Some quick research revealed the solution. My user needed ownership of the directory to be able to create and upload files and directories.
After that, it was all smooth sailing. The files in place, I changed the DNS records for my domain. Within a few minutes I was able to get a valid certificate from Let's Encrypt. A few minutes more and I saw the site served from my new host in my own browser.
Success!
I wanted to tweak some things in my setup, however. My script for updating the site relies on password authentication when connecting to the FTP server. My main user has root access. I didn't want that user to be able to authenticate with just a password. To get in with that user should require an SSH key.
So my next step was to add a new user dedicated entirely to updating this website. The new user could authenticate with a password and got access to the directory for this website, and only that directory. And I disabled password access for the admin user. Let nobody claim that I don't take my infosec seriously!
And that was it. My website was now being served from my new OpenBSD virtual machine, and the scripts that generate and update my website were connected to that machine.
Redirects
In [this note] I mentioned that I had reimplemented all the redirects that ensured links based on my old permalink structure remained functional. Using a standard apache server, I would rely on the mod_rewrite module to do this. By creating a .htaccess file in my root directory, I would enable the module and specify the redirects.
httpd doesn't support the mod_rewrite module. It does, however, support simple redirects. You can specify them directly in the configuration file. In my old .htaccess I had some 300 redirects in the following form:
Redirect 301 /my-inspiration/ https://lars-christian.com/posts/2024-08-20-my-inspiration
Whereas in the httpd.conf file the correct syntax is:
location "/my-inspiration/*" { block return 301 "https://lars-christian.com/posts/2024-08-20-my-inspiration/" }
I'm sure there are a hundred smarter ways to solve the conversion, but I turned to a spreadsheet. A simple (well, "simple" because you want to write "" which I always find tricky!) formula did the trick. In less than a few minutes, I had converted all the redirects to the correct syntax and updated my httpd.conf file to implement them.
Security headers
If you follow my notes (see subscribe for feed details) you might recall that I tried to implement security headers for the website. Unlike all the previous steps, that was a thoroughly frustrating experience. I just could not get it to work. And, worse, I couldn't for the life of me understand why.
No progress in that department since. In other words, still not sending security headers. At some point I might revisit that challenge.
Next steps
Apart from the security headers, I have everything in place on my virtual machine. At some point, I want to move Run161 over to this server as well. Given it still runs on Wordpress, however, I have to decide on an approach.
As of now, the site isn't actively updated. So one possibility is to do a static capture of the site as is, and upload it to the new server. But who knows what the future might bring. Another option is do the necessary work to set it up with my custom static site generator. It's significantly more complicated than this blog, however, so that will require adding quite a bit of functionality to my site generator. A third possibility is to install Wordpress locally and use a plugin to generate a static version of the site that's uploaded to the server.
Beyond that, nothing planned. If you have any ideas about fun ways to use an OpenBSD virtual machine, be sure to let me know.