Right, if you and your RSS reader can read this, the first stage of the migration of my blog to a static site has successfully completed and you’re now reading the new site. There’s still some more tweaking to do, but I broke it up into multiple milestones to minimise the overall risk of the migration.

The next steps are mostly under the hood, where I clean up some of the oily bits and make sure things are running well and keep running that way. The main work remaining is migrating all content to a new web server, which is just one VM size bigger than the current one. The server is running FreeBSD and uses ZFS, and ZFS benefits a lot from having as much RAM available as I’m willing to pay for. Plus, I’m using this as an excuse to script up the (re-)creation of the server via Ansible so it at least moves from “pet” status to “livestock” status.

One “biggie” that was holding up this blog’s migration to a static site was getting a comments system up and running, followed by importing the existing comments. I had picked Isso a while back as it allows for easy import of existing comments from WordPress. I really didn’t want to depend on a third party comment hosting service like Disqus. I also didn’t want to use Staticman, mainly because it has dependencies on other services like Github or Gitlab. So Isso it was as that allows me to host everything on my own server.

I have a few more loose ends to tidy up before switching to the static version of the blog. One of the important tasks was to make sure I had a spell checker available. Back in the dim and distant past I had set up flyspell-mode with hunspell, but I wanted to check if there was something better available these days. Enter enchant, which acts as a front end to multiple, different spell checkers. I like that Emacs has included support for enchant since version 26, plus one of the backends enchant supports is AppleSpell. In other words, when running on macOS, flyspell can make use of the OS’s built in spell checker and dictionaries.

Instructions on how to actually set up enchant on macOS are a bit thin on the ground, so I decided that I’ll put together a quick write up.

Now that I’ve got the static site up and running, it’s obviously time to switch over immediately, right? Not to fast. After QA’ing my deployment process in production, it was time to check how the two compared from a performance perspective. I like to use several different tests, starting with Pingdom, then using PageSpeed Insights for more details.

The Pingdom speed test gave it a thumbs up, but they’re not running the currently dominant search engine. Fortunately said search engine also offers performance check tooling. This wasn’t quite the thumbs up I had hoped for, though. While the mobile performance is similar - in other words, equally unimpressive - the desktop performance is pretty good for both sites. The WordPress site still has a slight advantages, but after some initial tweaks like disabling highlight.js (the static site uses the basic Hugo highlighter), the static site is pretty close.

I have been toying with the idea of migrating this blog to a static site to simplify its maintenance for some time. While WordPress is a great tool, this blog is a side project and any time I have to spend maintaining WordPress gets deducted from the time I have to write for the blog. Keep in mind that I'm self-hosting this blog and it's actually running on a Linux VM that only handles the blog. This is yet another server that I need to administer, and it's the odd one out, too, as all of the others are FreeBSD or OpenBSD servers.

I’ve mentioned in the past how you can configure the MongoDB Java driver output from Java. Most Clojure applications that use MongoDB use a database driver that wraps the official MongoDB Java driver. I personally use monger for a lot of my projects, but also occasionally created my own wrapper. The methods described in this post should be applicable to other Clojure MongoDB drivers as long as they wrap the official MongoDB Java driver. They should also work if your application directly wraps the MongoDB Java driver itself rather than using a more idiomatic driver.

I don’t usually do Happy New Year posts, but given how “well” 2020 went I thought it was appropriate to start 2021 with a whimsy post.  This post is probably going to date me since it’s been a few years - OK, decades - since these were current.

Well, it’s not the actual computer, but the same model. I was first exposed to computers during the personal computer heyday of the early 1980s. Back then, my school had two computers, one TRS 80 Model 3 and one Sinclair ZX81. The ZX81 was used to teach pupils rudimentary programming. I wouldn’t be surprised if one of the teachers actually built it from a kit as that was the cheapest way to get into one.

Keep in mind that I grew up in Europe where computers like the Apple ][ were very expensive and didn’t gain much traction in the educational field. Or with hobbists, either. Yes, there were some around but you saw a lot more VIC20s, C64s or Ataris. A lot of schools including mine bought European manufactured computers like Sinclairs and later, Amstrad/Schneider CPC 464s.

Update 2021-12-18: It looks like the rdiff-backup port has been removed from the FreeBSD ports tree, so installing it via the port is definitely not an option anymore. Also, the method described below works on FreeBSD 13.0 as well.

My main PC workstation (as opposed to my Mac Pro) is a dual-boot Windows and Linux machine. While backing up the Windows portion is relatively easy via some cheap-ish commercial backup software, I ended up backing up my Linux home directories only very occasionally. Clearly, Something Had To Be Done (tm).

I had a look around for Linux backup software. I was familiar with was Timeshift, but at least the Manjaro port can’t back up to a remote machine and was useless as a result. I eventually settled on rdiff-backup as it seemed to be simple, has been around for a while and also looks very cron-friendly. So far, so good.

In part 2, I reconfigured my WireGuard VPN to use an Unbound DNS server on the VPN server rather than rely on a third party server I had used for the original quick and dirty configuration. It was important for me to set up a validating DNS server, which I did in that part.

In this part, I’m extending the existing configuration to include some basic block lists for known ad and tracking servers. As I’m mainly trying to use the VPN while on the road, I want to ensure that anything I end up doing using the VPN is as secure as I can make it with reasonable effort. That makes tracking and preventing malicious ads the next step. That said, I’m not planning to go for a full Pi-Hole like setup. Initially, I am trying to do is integrate one known good blocklists into the Unbound configuration and automate the process. I can get fancy with a more Pi-Hole like setup later if I want to.

In the first part, I described how I set up the basic OpenBSD WireGuard VPN server. I also hinted that I wanted to set up my own validating, filtering DNS server. With a little bit of spare time during the holidays I decided now was a good time as any.

Making sure the VPN server uses the local Unbound DNS resolver first

Before I set up Unbound itself, I need to make sure that the VPN server’s resolv.conf points at its local DNS server first.