Standardise on name of posts

They're posts, not articles. This matches the URL

content/posts/arch-revert-to-date.md

@@ -50,4 +50,4 @@ To revert, just restore the backup of the pacman mirrorlist, and re-run the abov
 Generally, having out of date packages on your system is a bad idea. Not only for security reasons, but stability and compatibility. [The article](https://www.ostechnix.com/downgrade-packages-specific-date-arch-linux/) goes through a couple more too.
 
 ## Actually solving my issue
-A few days later, After [posting this article on twitter](https://twitter.com/RealOrangeOne/status/907591524644466688), I had a discussion with [@MortenLinderud](https://twitter.com/MortenLinderud) about the issue, who [pointed out](https://twitter.com/MortenLinderud/status/908262748718596096) that the library had already been fixed. So after updating `psycopg2`, my issue went away!
+A few days later, After [tweeting this post](https://twitter.com/RealOrangeOne/status/907591524644466688), I had a discussion with [@MortenLinderud](https://twitter.com/MortenLinderud) about the issue, who [pointed out](https://twitter.com/MortenLinderud/status/908262748718596096) that the library had already been fixed. So after updating `psycopg2`, my issue went away!

content/posts/docker-in-lxc.md

@@ -18,7 +18,7 @@ In a similar vein to this, [DinD](https://hub.docker.com/_/docker/) (docker in d
 
 ## How
 
-For once, I'm writing an article where the "how-to" section is surprisingly simple:
+For once, I'm writing a post where the "how-to" section is surprisingly simple:
 
 1. Create an LXC container
     1. Ensure "nesting" is enabled (it is by default in Proxmox)
@@ -28,7 +28,7 @@ For once, I'm writing an article where the "how-to" section is surprisingly simp
 
 Yes, it's really that simple! Now, running [`docker run hello-world`](https://hub.docker.com/_/hello-world/) should start a container and work absolutely flawlessly! At least excluding some minor [storage issues]({{<relref "docker-lxc-storage">}}).
 
-For reasons I don't quite understand, I wasn't able to get Alpine linux working as the base OS for the LXC container at the time. I really like Alpine as a minimal base OS, and given everything would be running in docker, the musl _complexities_ didn't bother me. Instead, I just run Debian, and it worked absolutely perfectly first time. Arch also works perfectly for me, as too I suspect would almost any other distro. Revisiting it whilst writing this article, and it seems to work fine. In cases like this, there is no "best distro", the distro doesn't matter - what does is that you're comfortable maintaining it for its lifespan.
+For reasons I don't quite understand, I wasn't able to get Alpine linux working as the base OS for the LXC container at the time. I really like Alpine as a minimal base OS, and given everything would be running in docker, the musl _complexities_ didn't bother me. Instead, I just run Debian, and it worked absolutely perfectly first time. Arch also works perfectly for me, as too I suspect would almost any other distro. Revisiting it whilst writing this post, and it seems to work fine. In cases like this, there is no "best distro", the distro doesn't matter - what does is that you're comfortable maintaining it for its lifespan.
 
 ## But why?
 
@@ -40,4 +40,4 @@ Speaking of passing through mountpoint, [passing through GPUs]({{<relref "lxc-nv
 
 And of course, that's to say nothing of the reduced overhead. Virtualizing a whole OS adds a lot of extra layers between the containers running your application and the CPU executing their instructions. These layers exist for good reason, they add isolation and allow the VM to be completely different to the host OS. But for a docker container, it's probably going to be a Linux-based guest OS anyway, so why not cut out the abstraction layers and benefit from the extra performance.
 
-I've been running Docker inside LXC for a little under a year now, and it's been absolutely fantastic. I have a few separate LXCs running separate Docker instances for things like monitoring (to keep it separate), but my primary "throw-all" LXC has a number of different docker containers with a number of mount points. I wrote up [an article]({{<relref "server-2020-proxmox">}}) a few months ago about how exactly [my Proxmox server]({{<relref "server-2020">}}) is setup, which may inspire your next server project.
+I've been running Docker inside LXC for a little under a year now, and it's been absolutely fantastic. I have a few separate LXCs running separate Docker instances for things like monitoring (to keep it separate), but my primary "throw-all" LXC has a number of different docker containers with a number of mount points. I wrote up [a post]({{<relref "server-2020-proxmox">}}) a few months ago about how exactly [my Proxmox server]({{<relref "server-2020">}}) is setup, which may inspire your next server project.

content/posts/exposing-your-homelab.md

@@ -158,7 +158,7 @@ This method, however good it sounds, comes with a number of drawbacks. It's a lo
 
 With that said, these extra complexities aren't huge, nor especially complicated, and you'll learn a lot whilst doing it!
 
-If you're interested in setting up something like this, I've written articles for both [WireGuard]({{< relref "wireguard-haproxy-gateway" >}}) and [OpenVPN]({{< relref "vpn-gateway" >}}).
+If you're interested in setting up something like this, I've written posts for both [WireGuard]({{< relref "wireguard-haproxy-gateway" >}}) and [OpenVPN]({{< relref "vpn-gateway" >}}).
 
 ## Reverse Proxies
 

content/posts/lightweight-gitlab/index.md

@@ -113,4 +113,4 @@ I do run GitLab's CI runner, but that's on a separate ~~machine~~ LXC.
 
 ![Current usage of my GitLab LXC](pve-stats.png)
 
-If you're interested in reading a little more, you can take a look at [my full configuration](https://git.theorangeone.net/sys/infrastructure/-/blob/master/ansible/roles/gitlab/files/gitlab.rb). GitLab also have their own documentation on running in [memory-constrained environments](https://docs.gitlab.com/omnibus/settings/memory_constrained_envs.html), which I discovered around half-way through writing this article.
+If you're interested in reading a little more, you can take a look at [my full configuration](https://git.theorangeone.net/sys/infrastructure/-/blob/master/ansible/roles/gitlab/files/gitlab.rb). GitLab also have their own documentation on running in [memory-constrained environments](https://docs.gitlab.com/omnibus/settings/memory_constrained_envs.html), which I discovered around half-way through writing this post.

content/posts/plausible-gitea.md

@@ -14,7 +14,7 @@ Plausible, [my analytics tool of choice]({{< relref "self-hosting-plausible" >}}
 
 Plausble recommends putting the tracking script in the `<head />` of the page. Personally I prefer to keep scripts like this at the end of the page, so they don't impact the actual site load. If you want to follow Plausible rather than me, just change `footer.tmpl` below with `header.tmpl`, and everything should work fine.
 
-Gitea's documentation on this [used to be](https://github.com/go-gitea/gitea/pull/14399) a little hard to understand, so I fixed it just before writing this article. Gitea wants the custom templates to live in a `templates` directory, which will sit next to the `conf` directory with your `app.ini`. Here we need to create the file `custom/footer.tmpl`, which will contain the extra HTML Gitea will put immediately before the closing`</body>`.
+Gitea's documentation on this [used to be](https://github.com/go-gitea/gitea/pull/14399) a little hard to understand, so I fixed it just before writing this post. Gitea wants the custom templates to live in a `templates` directory, which will sit next to the `conf` directory with your `app.ini`. Here we need to create the file `custom/footer.tmpl`, which will contain the extra HTML Gitea will put immediately before the closing`</body>`.
 
 Inside `footer.tmpl`, add the script tag for Plausible. You can find this in the Plausible admin panel.
 

content/posts/recovering-orphaned-git-commits.md

@@ -39,6 +39,6 @@ Searching through the output file, I eventually found the commits I needed. Beca
 
 Whilst rather stressful in the moment, experiences like these aren't without their lessons:
 
-- Don't delete your local copies of articles until they're actually live, rather than just committed
+- Don't delete your local copies of posts until they're actually live, rather than just committed
 - Be careful when relying on `git` magic and rebasing
 - `git` is pretty damn good at making sure you don't lose any data

content/posts/secure-wordpress/index.md

@@ -15,7 +15,7 @@ And so, after two weeks of on-and-off poking, research, re-installation and opti
 
 Decisions on the OS are fairly simple. For my site, I used Debian. In part because I'd not used it extensively before, and wanted to see if there were any benefits to Ubuntu, my go-to alternative, but also because it's considered to be dependable and secure. The Debian repos are some of the largest, containing any application I could need for a project like this, all of which have been well tested.
 
-There's nothing about this project, or article, which is Debian specific, or even Linux specific. Running this on something like FreeBSD would work great (and debatable be more secure). Theoretically it's possible to run all these applications on a Windows server. But running a Windows server by choice seems crazy to me!
+There's nothing about this project, or post, which is Debian specific, or even Linux specific. Running this on something like FreeBSD would work great (and debatable be more secure). Theoretically it's possible to run all these applications on a Windows server. But running a Windows server by choice seems crazy to me!
 
 ## Web Server