Update content for gemtext

5 files changed, 9 insertions, 9 deletions

diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
index 0f15de27..3d0bc299 100644
--- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
+++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
@@ -44,8 +44,8 @@ It would be fine if my personal website wasn't highly available, but the geek in
 * It's fine if my sites aren't reachable for five or ten minutes every other month. Due to their static nature, I don't care if there's a split-brain scenario where some requests reach one server and other requests reach another server.
 * Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available.
 * Let's Encrypt TLS certificates should always work (before and after a failover).
-* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn't part of the OpenBSD base system, but I coded my own monigoring system in Go)
-* Don't configure everything manually. The configuration should be automated and reproducible. (This isn't part of the OpenBSD base syste, but I didn't need to install any external package on OpenBSD either)
+* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn't part of the OpenBSD base system, but I coded my own monigoring system in Go.)
+* Don't configure everything manually. The configuration should be automated and reproducible. (This isn't part of the OpenBSD base system, but I didn't need to install any external package on OpenBSD either.)
 
 ## My HA solution
 
diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl
index 40a41e7b..473a9d66 100644
--- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl
+++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl
@@ -44,8 +44,8 @@ It would be fine if my personal website wasn't highly available, but the geek in
 * It's fine if my sites aren't reachable for five or ten minutes every other month. Due to their static nature, I don't care if there's a split-brain scenario where some requests reach one server and other requests reach another server.
 * Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available.
 * Let's Encrypt TLS certificates should always work (before and after a failover).
-* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn't part of the OpenBSD base system, but I coded my own monigoring system in Go)
-* Don't configure everything manually. The configuration should be automated and reproducible. (This isn't part of the OpenBSD base syste, but I didn't need to install any external package on OpenBSD either)
+* Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn't part of the OpenBSD base system, but I coded my own monigoring system in Go.)
+* Don't configure everything manually. The configuration should be automated and reproducible. (This isn't part of the OpenBSD base system, but I didn't need to install any external package on OpenBSD either.)
 
 ## My HA solution
 
diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml
index fe2206f8..171fc305 100644
--- a/gemfeed/atom.xml
+++ b/gemfeed/atom.xml
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8"?>
 <feed xmlns="http://www.w3.org/2005/Atom">
-    <updated>2024-03-30T22:47:35+02:00</updated>
+    <updated>2024-03-30T22:48:57+02:00</updated>
     <title>foo.zone feed</title>
     <subtitle>To be in the .zone!</subtitle>
     <link href="gemini://foo.zone/gemfeed/atom.xml" rel="self" />
@@ -65,8 +65,8 @@ _____|_:_:_|  (o)-(o)  |_:_:_|--&#39;`-.     ,--. ksh under-water (((\&#39;/
 <li>It&#39;s fine if my sites aren&#39;t reachable for five or ten minutes every other month. Due to their static nature, I don&#39;t care if there&#39;s a split-brain scenario where some requests reach one server and other requests reach another server.</li>
 <li>Failover should work for both HTTP/HTTPS and Gemini protocols. My self-hosted MTAs and DNS servers should also be highly available.</li>
 <li>Let&#39;s Encrypt TLS certificates should always work (before and after a failover).</li>
-<li>Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn&#39;t part of the OpenBSD base system, but I coded my own monigoring system in Go)</li>
-<li>Don&#39;t configure everything manually. The configuration should be automated and reproducible. (This isn&#39;t part of the OpenBSD base syste, but I didn&#39;t need to install any external package on OpenBSD either)</li>
+<li>Have good monitoring in place so I know when a failover was performed and when something went wrong with the failover. (This isn&#39;t part of the OpenBSD base system, but I coded my own monigoring system in Go.)</li>
+<li>Don&#39;t configure everything manually. The configuration should be automated and reproducible. (This isn&#39;t part of the OpenBSD base system, but I didn&#39;t need to install any external package on OpenBSD either.)</li>
 </ul><br />
 <h2 style='display: inline'>My HA solution</h2><br />
 <br />
diff --git a/index.gmi b/index.gmi
index 43bf810a..36432ae6 100644
--- a/index.gmi
+++ b/index.gmi
@@ -1,6 +1,6 @@
 # foo.zone
 
-> This site was generated at 2024-03-30T22:48:01+02:00 by `Gemtexter`
+> This site was generated at 2024-03-30T22:48:57+02:00 by `Gemtexter`
 
 ```
    |\---/|
diff --git a/uptime-stats.gmi b/uptime-stats.gmi
index e0b4467d..d1af372a 100644
--- a/uptime-stats.gmi
+++ b/uptime-stats.gmi
@@ -1,6 +1,6 @@
 # My machine uptime stats
 
-> This site was last updated at 2024-03-30T22:48:01+02:00
+> This site was last updated at 2024-03-30T22:48:57+02:00
 
 The following stats were collected via `uptimed` on all of my personal computers over many years and the output was generated by `guprecords`, the global uptime records stats analyser of mine.