fix links

2 files changed, 5 insertions, 5 deletions

diff --git a/about/novels.gmi.tpl b/about/novels.gmi.tpl
index e1334f74..e1416570 100644
--- a/about/novels.gmi.tpl
+++ b/about/novels.gmi.tpl
@@ -106,8 +106,8 @@ _-"   .       '  +  .              .        ,//////0\ | /00HHHHHHHMMMMM
 
 ### Andreas Brandhorst
 
-* 2024 - Der Riss (german)
 * 2023 - Oxygen: Welt ohne Sauerstoff, Audiobook (german)
+* 2024 - Der Riss (german)
 
 ## Unread books already in my shelf
 
diff --git a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl
index 31459951..79a97b4f 100644
--- a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl
+++ b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl
@@ -22,7 +22,7 @@ Let's begin...
 
 My previous setup was great for learning Terraform and AWS, but it is too expensive. Costs are under control there, but only because I am shutting down all containers after use (so they are offline ninety percent of the time and still cost around $20 monthly). With the new setup, I could run all containers 24/7 at home, which would still be cheaper in terms of electricity consumption. I have a 50 MBit/s uplink (I could have more if I wanted, but it is plenty for my use case already).
 
-=> https://foo.zone/gemfeed/2024-02-04-from-babylon5.buetow.org-to-.cloud.html From `babylon5.buetow.org` to `.cloud`
+=> ./2024-02-04-from-babylon5.buetow.org-to-.cloud.html From `babylon5.buetow.org` to `.cloud`
 
 Migrating off all my containers from AWS ECS means I need a reliable and scalable environment to host my workloads. I wanted something:
 
@@ -80,8 +80,8 @@ All of this (every Linux VM to every OpenBSD box) will be connected via WireGuar
 
 So, when I want to access a service running in k3s, I will hit an external DNS endpoint (with the authoritative DNS servers being the OpenBSD boxes). The DNS will resolve to the master OpenBSD VM (see my KISS highly-available with OpenBSD blog post), and from there, the `relayd` process (with a Let's Encrypt certificate—see my Let's Encrypt with OpenBSD and Rex blog post) will accept the TCP connection and forward it through the WireGuard tunnel to a reachable node port of one of the k3s nodes, thus serving the traffic.
 
-=> https://foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html KISS high-availability with OpenBSD
-=> https://foo.zone/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html Let's Encrypt with OpenBSD and Rex
+=> ./2024-04-01-KISS-high-availability-with-OpenBSD.html KISS high-availability with OpenBSD
+=> ./2022-07-30-lets-encrypt-with-openbsd-and-rex.html Let's Encrypt with OpenBSD and Rex
 
 The OpenBSD setup described here already exists and is ready to use. The only thing that does not yet exist is the configuration of `relayd` to forward requests to k3s through the WireGuard tunnel(s).
 
@@ -121,7 +121,7 @@ For visualization, Grafana will be deployed alongside Prometheus. Grafana lets m
 
 Alerts generated by Prometheus are forwarded to Alertmanager, which I will configure to work with Gogios, a lightweight monitoring and alerting system I wrote myself. Gogios runs on one of my OpenBSD VMs. At regular intervals, Gogios scrapes the alerts generated in the k3s cluster and notifies me via Email.
 
-=> https://foo.zone/gemfeed/2023-06-01-kiss-server-monitoring-with-gogios.html KISS server monitoring with Gogios
+=> ./2023-06-01-kiss-server-monitoring-with-gogios.html KISS server monitoring with Gogios
 
 Ironically, I implemented Gogios to avoid using more complex alerting systems like Prometheus, but here we go—it integrates well now.