From 632beab8ff8648b272521f73f5adaada021dd667 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sun, 11 May 2025 12:13:32 +0300 Subject: update --- ...25-02-01-f3s-kubernetes-with-freebsd-part-3.gmi | 4 +++- ...2-01-f3s-kubernetes-with-freebsd-part-3.gmi.tpl | 4 +++- ...25-04-05-f3s-kubernetes-with-freebsd-part-4.gmi | 4 +++- ...4-05-f3s-kubernetes-with-freebsd-part-4.gmi.tpl | 4 +++- ...25-05-11-f3s-kubernetes-with-freebsd-part-5.gmi | 12 +++++------- ...5-11-f3s-kubernetes-with-freebsd-part-5.gmi.tpl | 12 +++++------- gemfeed/atom.xml | 22 ++++++++++++---------- 7 files changed, 34 insertions(+), 28 deletions(-) (limited to 'gemfeed') diff --git a/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi b/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi index b32d4dc0..de156ab2 100644 --- a/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi +++ b/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi @@ -357,7 +357,9 @@ All good :-) I have the same UPS (but with a bit more capacity) for my main work setup, which powers my 28" screen, music equipment, etc. It has already been helpful a couple of times during power outages here, so I am sure that the smaller UPS for the F3s setup will be of great use. -See you in the next post of this series! +Read the next post of this series: + +=> ./2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi f3s: Kubernetes with FreeBSD - Part 4: Rocky Linux Bhyve VMs Other BSD related posts are: diff --git a/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi.tpl b/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi.tpl index 36105406..1fca33a4 100644 --- a/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi.tpl +++ b/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi.tpl @@ -336,7 +336,9 @@ All good :-) I have the same UPS (but with a bit more capacity) for my main work setup, which powers my 28" screen, music equipment, etc. It has already been helpful a couple of times during power outages here, so I am sure that the smaller UPS for the F3s setup will be of great use. -See you in the next post of this series! +Read the next post of this series: + +=> ./2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi f3s: Kubernetes with FreeBSD - Part 4: Rocky Linux Bhyve VMs Other BSD related posts are: diff --git a/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi b/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi index 18e6b182..2a5416f9 100644 --- a/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi +++ b/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi @@ -503,7 +503,9 @@ Future uses (out of scope for this blog series) would be additional VMs for diff This flexibility is great for keeping options open and managing different workloads without overcomplicating things. Overall, it's a nice setup for getting the most out of my hardware and keeping things running smoothly. -See you in the next post of this series! +Read the next post of this series: + +=> ./2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi f3s: Kubernetes with FreeBSD - Part 5: WireGuard mesh network Other *BSD-related posts: diff --git a/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi.tpl b/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi.tpl index e69a0ded..b8428906 100644 --- a/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi.tpl +++ b/gemfeed/2025-04-05-f3s-kubernetes-with-freebsd-part-4.gmi.tpl @@ -474,7 +474,9 @@ Future uses (out of scope for this blog series) would be additional VMs for diff This flexibility is great for keeping options open and managing different workloads without overcomplicating things. Overall, it's a nice setup for getting the most out of my hardware and keeping things running smoothly. -See you in the next post of this series! +Read the next post of this series: + +=> ./2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi f3s: Kubernetes with FreeBSD - Part 5: WireGuard mesh network Other *BSD-related posts: diff --git a/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi b/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi index 56663d5b..77a06c55 100644 --- a/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi +++ b/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi @@ -62,9 +62,9 @@ The traffic is expected to flow between the host groups through the mesh network * `fN <-> rN`: The traffic between the FreeBSD hosts and the Rocky Linux VMs will be routed through the VPN tunnels for persistent storage. In a later post in this series, we will set up an NFS server on the `fN` hosts. * `fN <-> blowfish,fishfinger`: The traffic between the FreeBSD hosts and the OpenBSD host `blowfish,fishfinger` will be routed through the VPN tunnels for management. We may want to log in via the internet to set it up remotely. The VPN tunnel will also be used for monitoring purposes. -* `rN <-> blowfish,fishfinger`: The traffic between the Rocky Linux VMs and the OpenBSD host `blowfish,fishfinger` will be routed through the VPN tunnels for usage traffic. Since `k3s` will be running on the `rN` hosts, the OpenBSD servers will route the traffic through `relayd` to the services running in Kubernetes. +* `rN <-> blowfish,fishfinger`: The traffic between the Rocky Linux VMs and the OpenBSD host `blowfish,fishfinger` will be routed through the VPN tunnels for usage traffic. Since k3s will be running on the `rN` hosts, the OpenBSD servers will route the traffic through `relayd` to the services running in Kubernetes. * `fN <-> fM`: The traffic between the FreeBSD hosts may be later used for data replication for the NFS storage. -* `rN <-> rM`: The traffic between the Rocky Linux VMs will later be used by the `k3s` cluster itself, as every `rN` will be a Kubernetes worker node. +* `rN <-> rM`: The traffic between the Rocky Linux VMs will later be used by the k3s cluster itself, as every `rN` will be a Kubernetes worker node. * `blowfish <-> fishfinger`: The traffic between the OpenBSD hosts isn't strictly required for this setup, but I set it up anyway for future use cases. We won't cover all the details in this blog post, as we only focus on setting up the Mesh network in this blog post. Subsequent posts in this series will cover the other details. @@ -101,8 +101,6 @@ On the FreeBSD hosts `f0`, `f1` and `f2`, similar as last time, first, we bring ```sh paul@f0:~ % doas freebsd-update fetch paul@f0:~ % doas freebsd-update install -paul@f0:~ % doas freebsd-update -r 14.2-RELEASE upgrade -paul@f0:~ % doas freebsd-update install paul@f0:~ % doas shutdown -r now .. .. @@ -346,7 +344,7 @@ So, because it's better, we are using it. ## Mesh network generator -Manually generating `wg0.conf` files for every peer in a mesh network setup is cumbersome because each peer requires its own unique public/private key pair and a preshared key for each VPN tunnel (resulting in 29 preshared keys for 8 hosts). This complexity scales exponentially with the number of peers as the relationships between all peers must be explicitly defined, including their unique configurations such as `AllowedIPs` and `Endpoint` and optional settings like `PersistentKeepalive`. Automating the process ensures consistency, reduces human error, saves considerable time, and allows for centralized management of configuration files. +Manually generating `wg0.conf` files for every peer in a mesh network setup is cumbersome because each peer requires its own unique public/private key pair and a preshared key for each VPN tunnel (resulting in 29 preshared keys for 8 hosts). This complexity scales almost exponentially with the number of peers as the relationships between all peers must be explicitly defined, including their unique configurations such as `AllowedIPs` and `Endpoint` and optional settings like `PersistentKeepalive`. Automating the process ensures consistency, reduces human error, saves considerable time, and allows for centralized management of configuration files. Instead, a script can handle key generation, coordinate relationships, and generate all necessary configuration files simultaneously, making it scalable and far less error-prone. @@ -924,9 +922,9 @@ peer: 2htXdNcxzpI2FdPDJy4T4VGtm1wpMEQu1AkQHjNY6F8= ## Conclusion -Having a mesh network on our hosts is great for securing all the traffic between them for our future `k3s` setup. A self-managed WireGuard mesh network is better than Tailscale as it eliminates reliance on a third party and provides full control over the configuration. It reduces unnecessary abstraction and "magic," enabling easier debugging and ensuring full ownership of our network. +Having a mesh network on our hosts is great for securing all the traffic between them for our future k3s setup. A self-managed WireGuard mesh network is better than Tailscale as it eliminates reliance on a third party and provides full control over the configuration. It reduces unnecessary abstraction and "magic," enabling easier debugging and ensuring full ownership of our network. -I look forward to the next blog post in this series. We may start setting up `k3s` or take a first look at the NFS server (for persistent storage) side of things. I hope you liked all the posts so far in this series. +I look forward to the next blog post in this series. We may start setting up k3s or take a first look at the NFS server (for persistent storage) side of things. I hope you liked all the posts so far in this series. Other *BSD-related posts: diff --git a/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi.tpl b/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi.tpl index cc0a7eff..e0d2d788 100644 --- a/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi.tpl +++ b/gemfeed/2025-05-11-f3s-kubernetes-with-freebsd-part-5.gmi.tpl @@ -36,9 +36,9 @@ The traffic is expected to flow between the host groups through the mesh network * `fN <-> rN`: The traffic between the FreeBSD hosts and the Rocky Linux VMs will be routed through the VPN tunnels for persistent storage. In a later post in this series, we will set up an NFS server on the `fN` hosts. * `fN <-> blowfish,fishfinger`: The traffic between the FreeBSD hosts and the OpenBSD host `blowfish,fishfinger` will be routed through the VPN tunnels for management. We may want to log in via the internet to set it up remotely. The VPN tunnel will also be used for monitoring purposes. -* `rN <-> blowfish,fishfinger`: The traffic between the Rocky Linux VMs and the OpenBSD host `blowfish,fishfinger` will be routed through the VPN tunnels for usage traffic. Since `k3s` will be running on the `rN` hosts, the OpenBSD servers will route the traffic through `relayd` to the services running in Kubernetes. +* `rN <-> blowfish,fishfinger`: The traffic between the Rocky Linux VMs and the OpenBSD host `blowfish,fishfinger` will be routed through the VPN tunnels for usage traffic. Since k3s will be running on the `rN` hosts, the OpenBSD servers will route the traffic through `relayd` to the services running in Kubernetes. * `fN <-> fM`: The traffic between the FreeBSD hosts may be later used for data replication for the NFS storage. -* `rN <-> rM`: The traffic between the Rocky Linux VMs will later be used by the `k3s` cluster itself, as every `rN` will be a Kubernetes worker node. +* `rN <-> rM`: The traffic between the Rocky Linux VMs will later be used by the k3s cluster itself, as every `rN` will be a Kubernetes worker node. * `blowfish <-> fishfinger`: The traffic between the OpenBSD hosts isn't strictly required for this setup, but I set it up anyway for future use cases. We won't cover all the details in this blog post, as we only focus on setting up the Mesh network in this blog post. Subsequent posts in this series will cover the other details. @@ -75,8 +75,6 @@ On the FreeBSD hosts `f0`, `f1` and `f2`, similar as last time, first, we bring ```sh paul@f0:~ % doas freebsd-update fetch paul@f0:~ % doas freebsd-update install -paul@f0:~ % doas freebsd-update -r 14.2-RELEASE upgrade -paul@f0:~ % doas freebsd-update install paul@f0:~ % doas shutdown -r now .. .. @@ -320,7 +318,7 @@ So, because it's better, we are using it. ## Mesh network generator -Manually generating `wg0.conf` files for every peer in a mesh network setup is cumbersome because each peer requires its own unique public/private key pair and a preshared key for each VPN tunnel (resulting in 29 preshared keys for 8 hosts). This complexity scales exponentially with the number of peers as the relationships between all peers must be explicitly defined, including their unique configurations such as `AllowedIPs` and `Endpoint` and optional settings like `PersistentKeepalive`. Automating the process ensures consistency, reduces human error, saves considerable time, and allows for centralized management of configuration files. +Manually generating `wg0.conf` files for every peer in a mesh network setup is cumbersome because each peer requires its own unique public/private key pair and a preshared key for each VPN tunnel (resulting in 29 preshared keys for 8 hosts). This complexity scales almost exponentially with the number of peers as the relationships between all peers must be explicitly defined, including their unique configurations such as `AllowedIPs` and `Endpoint` and optional settings like `PersistentKeepalive`. Automating the process ensures consistency, reduces human error, saves considerable time, and allows for centralized management of configuration files. Instead, a script can handle key generation, coordinate relationships, and generate all necessary configuration files simultaneously, making it scalable and far less error-prone. @@ -898,9 +896,9 @@ peer: 2htXdNcxzpI2FdPDJy4T4VGtm1wpMEQu1AkQHjNY6F8= ## Conclusion -Having a mesh network on our hosts is great for securing all the traffic between them for our future `k3s` setup. A self-managed WireGuard mesh network is better than Tailscale as it eliminates reliance on a third party and provides full control over the configuration. It reduces unnecessary abstraction and "magic," enabling easier debugging and ensuring full ownership of our network. +Having a mesh network on our hosts is great for securing all the traffic between them for our future k3s setup. A self-managed WireGuard mesh network is better than Tailscale as it eliminates reliance on a third party and provides full control over the configuration. It reduces unnecessary abstraction and "magic," enabling easier debugging and ensuring full ownership of our network. -I look forward to the next blog post in this series. We may start setting up `k3s` or take a first look at the NFS server (for persistent storage) side of things. I hope you liked all the posts so far in this series. +I look forward to the next blog post in this series. We may start setting up k3s or take a first look at the NFS server (for persistent storage) side of things. I hope you liked all the posts so far in this series. Other *BSD-related posts: diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index c84dd44a..99292fc1 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2025-05-11T11:38:56+03:00 + 2025-05-11T12:12:02+03:00 foo.zone feed To be in the .zone! @@ -84,9 +84,9 @@
We won't cover all the details in this blog post, as we only focus on setting up the Mesh network in this blog post. Subsequent posts in this series will cover the other details.
@@ -127,8 +127,6 @@ http://www.lorenzobettini.it http://www.gnu.org/software/src-highlite --> 
paul@f0:~ % doas freebsd-update fetch
 paul@f0:~ % doas freebsd-update install
-paul@f0:~ % doas freebsd-update -r 14.2-RELEASE upgrade
-paul@f0:~ % doas freebsd-update install
 paul@f0:~ % doas shutdown -r now
 ..
 ..
@@ -398,7 +396,7 @@ PersistentKeepalive = 25
 

 
Mesh network generator


 

-Manually generating wg0.conf files for every peer in a mesh network setup is cumbersome because each peer requires its own unique public/private key pair and a preshared key for each VPN tunnel (resulting in 29 preshared keys for 8 hosts). This complexity scales exponentially with the number of peers as the relationships between all peers must be explicitly defined, including their unique configurations such as AllowedIPs and Endpoint and optional settings like PersistentKeepalive. Automating the process ensures consistency, reduces human error, saves considerable time, and allows for centralized management of configuration files.

+Manually generating wg0.conf files for every peer in a mesh network setup is cumbersome because each peer requires its own unique public/private key pair and a preshared key for each VPN tunnel (resulting in 29 preshared keys for 8 hosts). This complexity scales almost exponentially with the number of peers as the relationships between all peers must be explicitly defined, including their unique configurations such as AllowedIPs and Endpoint and optional settings like PersistentKeepalive. Automating the process ensures consistency, reduces human error, saves considerable time, and allows for centralized management of configuration files.

 

 Instead, a script can handle key generation, coordinate relationships, and generate all necessary configuration files simultaneously, making it scalable and far less error-prone.

 

@@ -1007,9 +1005,9 @@ peer: 2htXdNcxzpI2FdPDJy4T4VGtm1wpMEQu1AkQHjNY6F8=
 

 
Conclusion


 

-Having a mesh network on our hosts is great for securing all the traffic between them for our future k3s setup. A self-managed WireGuard mesh network is better than Tailscale as it eliminates reliance on a third party and provides full control over the configuration. It reduces unnecessary abstraction and "magic," enabling easier debugging and ensuring full ownership of our network.

+Having a mesh network on our hosts is great for securing all the traffic between them for our future k3s setup. A self-managed WireGuard mesh network is better than Tailscale as it eliminates reliance on a third party and provides full control over the configuration. It reduces unnecessary abstraction and "magic," enabling easier debugging and ensuring full ownership of our network.

 

-I look forward to the next blog post in this series. We may start setting up k3s or take a first look at the NFS server (for persistent storage) side of things. I hope you liked all the posts so far in this series.

+I look forward to the next blog post in this series. We may start setting up k3s or take a first look at the NFS server (for persistent storage) side of things. I hope you liked all the posts so far in this series.

 

 Other *BSD-related posts:

 

@@ -2161,7 +2159,9 @@ Apr  4 23:
 This flexibility is great for keeping options open and managing different workloads without overcomplicating things. Overall, it's a nice setup for getting the most out of my hardware and keeping things running smoothly.

 

-See you in the next post of this series!

+Read the next post of this series:

+

+f3s: Kubernetes with FreeBSD - Part 5: WireGuard mesh network

 

 Other *BSD-related posts:

 

@@ -3276,7 +3276,9 @@ Jan 26 17:36:32 f2 apcupsd[2159]: apcupsd shutdown succeeded
 

 I have the same UPS (but with a bit more capacity) for my main work setup, which powers my 28" screen, music equipment, etc. It has already been helpful a couple of times during power outages here, so I am sure that the smaller UPS for the F3s setup will be of great use.

 

-See you in the next post of this series!

+Read the next post of this series:

+

+f3s: Kubernetes with FreeBSD - Part 4: Rocky Linux Bhyve VMs

 

 Other BSD related posts are:

 

-- 
cgit v1.2.3