From c8f69e767851bfef5586d5d5ea399646975186e5 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sat, 16 Nov 2024 23:35:12 +0200 Subject: Update content for gemtext --- gemfeed/atom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'gemfeed/atom.xml') 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 @@ - 2024-11-16T23:30:04+02:00 + 2024-11-16T23:34:14+02:00 foo.zone feed To be in the .zone! @@ -114,7 +114,7 @@ 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.

KISS high-availability with OpenBSD
-Le's Encrypt with OpenBSD and Rex
+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).

-- cgit v1.2.3