summaryrefslogtreecommitdiff
path: root/gemfeed
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2024-11-16 23:35:12 +0200
committerPaul Buetow <paul@buetow.org>2024-11-16 23:35:12 +0200
commitc8f69e767851bfef5586d5d5ea399646975186e5 (patch)
tree2c449968e2f870be12fa02f24872b8fa3d117137 /gemfeed
parent069f27b195a926a5889922bb12bfece5ab812dc5 (diff)
Update content for gemtext
Diffstat (limited to 'gemfeed')
-rw-r--r--gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi2
-rw-r--r--gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl2
-rw-r--r--gemfeed/atom.xml4
3 files changed, 4 insertions, 4 deletions
diff --git a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi
index da27356e..02b864ee 100644
--- a/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi
+++ b/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi
@@ -92,7 +92,7 @@ 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 Le's Encrypt with OpenBSD and Rex
+=> https://foo.zone/gemfeed/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).
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 84d4177d..942a6d6a 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
@@ -77,7 +77,7 @@ 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 Le's Encrypt with OpenBSD and Rex
+=> https://foo.zone/gemfeed/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).
diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml
index 7a8ec999..347d23d7 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-11-16T23:30:04+02:00</updated>
+ <updated>2024-11-16T23:34:14+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" />
@@ -114,7 +114,7 @@
<span>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 <span class='inlinecode'>relayd</span> process (with a Let&#39;s Encrypt certificate—see my Let&#39;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.</span><br />
<br />
<a class='textlink' href='https://foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html'>KISS high-availability with OpenBSD</a><br />
-<a class='textlink' href='https://foo.zone/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html'>Le&#39;s Encrypt with OpenBSD and Rex</a><br />
+<a class='textlink' href='https://foo.zone/gemfeed/2022-07-30-lets-encrypt-with-openbsd-and-rex.html'>Let&#39;s Encrypt with OpenBSD and Rex</a><br />
<br />
<span>The OpenBSD setup described here already exists and is ready to use. The only thing that does not yet exist is the configuration of <span class='inlinecode'>relayd</span> to forward requests to k3s through the WireGuard tunnel(s).</span><br />
<br />