diff options
| author | Paul Buetow <paul@buetow.org> | 2024-11-16 23:35:12 +0200 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2024-11-16 23:35:12 +0200 |
| commit | c8f69e767851bfef5586d5d5ea399646975186e5 (patch) | |
| tree | 2c449968e2f870be12fa02f24872b8fa3d117137 /gemfeed | |
| parent | 069f27b195a926a5889922bb12bfece5ab812dc5 (diff) | |
Update content for gemtext
Diffstat (limited to 'gemfeed')
| -rw-r--r-- | gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi | 2 | ||||
| -rw-r--r-- | gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi.tpl | 2 | ||||
| -rw-r--r-- | gemfeed/atom.xml | 4 |
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'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.</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'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'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 /> |
