Start adding post about vault-agents

README.md

@@ -0,0 +1,5 @@
+# Blog
+My personal blog
+
+## Build Docker image
+`docker buildx build --platform=linux/amd64 -t gitea.lol3r.com/leon/blog:latest .`

content/_index.md

@@ -1,5 +1,5 @@
 +++
 title = "List of blog posts"
 sort_by = "date"
-paginate_by = 10
+paginate_by = 20
 +++

content/auto-server-setup/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Automatic Server Setup"
-date = 2026-03-31
+date = 2026-06-01
 description = "Automatic my server setup"
 draft = true
 
@@ -46,6 +46,24 @@ So you specify some machine specific things in my tool:
 
 and then the final configuration for the installer is automatically created.
 
+# Help for unknown config/server
+This is for cases, where a machine that is not currently configured in the software tries to netboot from it.
+
+There are basically 2 cases, where this might happen:
+1. A new machine is supposed to be added and I need to add it to the configuration
+2. A machine, that is not intended for netbooting, was accidentally configured to try netbooting
+
+## New Machine to add to Configuration
+In this case, we want the machine to boot into a sort of exploritory environment, so one can easily find the required information to add the machine to the configuration.
+
+For this purpose I plan to use a barebones linux setup based on this blog about creating a minimal linux kernel[^blog_tiny_linux_from_scrach].
+TODO
+
+## Accidental boot
+The main concern in this case is to not accidentally wipe an existing machine, like my personal computer.
+TODO
+
+
 # Why not MAAS?
 The simple answer is simplicity and that I wanted to understand how these things work.
 Basically even what I am outlining here is already overkill, as I am maybe deploying a new server once every 1 or 2 years.
@@ -55,10 +73,6 @@ Basically even what I am outlining here is already overkill, as I am maybe deplo
 Currently this is mostly still an experimental setup, but I actually want to deploy this for my homelab.
 For this I am planning on setting up 1 or 2 raspberry pies that might also serve some other critical services.
 
-## Better help for unknown config
-Currently it is a bit annoying to get the first configuration for a client going, because you need to find all the serial numbers etc.
-In the long run I want to boot into a minimal live linux setup[^blog_tiny_linux_from_scrach], which one can then use to find all the info needed for setting up your config.
-
 # References
 [^autoinstall]: [autoinstall docs](https://canonical-subiquity.readthedocs-hosted.com/en/latest/intro-to-autoinstall.html)
 [^cloud-init]: [cloud-init homepage](https://cloud-init.io/)

content/homelab-ipv4-expose-2/index.md

@@ -0,0 +1,172 @@
++++
+title = "Homelab - IPv4 Expose - Deployment"
+date = 2026-05-20
+description = "Deploying my new IPv4 expose setup"
+
+[taxonomies]
+categories = ["Homelab"]
+tags = ["Homelab", "IPv4", "IPv6"]
+
+[extra]
+toc = true
++++
+
+Implementing the ideas and conclusions from my initial post about exposing my IPv6 Homelab to IPv4 clients ([Homelab IPv4 Expose](@/homelab-ipv4-expose/index.md)) in the real world and deploying the entire system.
+
+<!-- more -->
+
+# Background
+This will cover some of the background needed for this setup, if you have already read the previous post or are familiar with jool, NAT64 and ipv-proxy, you can skip this section.
+
+## Jool
+[Jool](https://github.com/NICMx/Jool) is a tool that implements a bunch of IPv6 and IPv4 translation mechanisms.
+This does the heavy lifting, when it comes to actually processing the packets and performing the low-level translations.
+
+## Stateful NAT64
+[Stateful NAT64](https://nicmx.github.io/Jool/en/run-nat64.html) is one of the mechanisms to translate between IPv6 and IPv4 networks.
+It works similarly to normal NAT, with the addition of not only mapping ports and addresses, but mapping between an IPv6 and IPv4 address.
+So one side of the translation has a unique IPv6 address + port combination and the other side is a unique IPv4 address + port combination.
+
+## ipv-proxy
+[ipv-proxy](https://github.com/Lol3rrr/ipv-proxy) is a custom tool, I developed, which dynamically reads configuration from consul to expose IPv6 services to IPv4 clients.
+This usually runs on some external server, which can do both IPv4 and IPv6.
+Services in consul can then add specific tags, which are found by the ipv-proxy, which then exposes the IPv6 only service from the IPv4 address of the server, by forwarding all the traffic.
+
+Previously this only worked with TCP and was doing the forwarding naively in user-space software, but as part of this I added support for using jool to do the actual forwarding.
+
+# Plan
+Okay so there are a couple of goals/requirements I have for this deployment:
+1. The entire setup should be automated and portable between vendors
+2. Extend ipv-proxy to natively use jool for forwarding
+3. Use wireguard for connecting to my internal consul cluster
+
+## 1. Automated and portable setup
+To make sure my setup is repeatable and portable between different providers, I decided to fully rely on cloud-init.
+{% details(summary="cloud-init config") %}
+```
+#cloud-config
+ssh_authorized_keys:
+  - ${macbook_ssh_key}
+  - ${ubuntu_ssh_key}
+
+package_update: true
+package_upgrade: true
+
+packages:
+  - jool-dkms
+  - jool-tools
+  - ndppd
+
+write_files:
+  - path: /etc/sysctl.d/99-forwarding.conf
+    permissions: '0644'
+    content: |
+      net.ipv4.conf.all.forwarding=1
+      net.ipv6.conf.all.forwarding=1
+      net.ipv6.conf.all.proxy_ndp=1
+  - path: /etc/ndppd.conf
+    permissions: '0666'
+    content: |
+      proxy ens2 {
+          rule ${ipv6_prefix} {
+              static
+          }
+      }
+  - path: /etc/modules-load.d/jool
+    permissions: '0666'
+    content: |
+      jool
+  - path: /usr/local/bin/ipv-proxy
+    permissions: '0777'
+    source:
+      uri: https://github.com/Lol3rrr/ipv-proxy/releases/download/${ipv_proxy_version}/ipv-proxy
+  - path: /etc/systemd/system/ipv-proxy.service
+    content: |
+      [Unit]
+      Description=Proxy IPv4 traffic to IPv6
+      After=cloud-init.target
+      Wants=cloud-init.target
+
+      [Service]
+      Type=simple
+      ExecStart=/usr/local/bin/ipv-proxy %{ for addr in consul_addrs ~}--consul-addr ${addr} %{ endfor ~} --backend jool --public-ip ${proxy_ipv4_public} --jool-pool6-subnet ${proxy_ipv6_subnet}
+
+      [Install]
+      WantedBy=multi-user.target
+
+wireguard:
+  interfaces:
+    - name: wg0
+      config_path: /etc/wireguard/wg0.conf
+      content: |
+        [Interface]
+        Address = 10.200.0.200/32
+        MTU = 1280
+        PrivateKey = ${wg_private_key}
+
+%{ for peer in wg_peers ~}
+        [Peer]
+        # Name ${peer.name}
+        PublicKey = ${peer.public_key}
+        AllowedIPs = ${peer.ip}/32
+        Endpoint = ${peer.endpoint}
+        PersistentKeepalive = 25
+%{ endfor ~}
+
+runcmd:
+  - "sysctl -w net.ipv4.conf.all.forwarding=1"
+  - "sysctl -w net.ipv6.conf.all.forwarding=1"
+  - "sysctl -w net.ipv6.conf.all.proxy_ndp=1"
+  - "sysctl --system"
+  - "modprobe jool"
+  - "systemctl daemon-reload"
+  - "systemctl enable ipv-proxy.service"
+  - "systemctl start --no-block ipv-proxy.service"
+```
+{% end %}
+
+The configuration essentially does everything mentioned in the first post of this mini-series + setting up wireguard.
+
+
+## 2. Extend ipv-proxy
+In its original state, the ipv-proxy could only do "manual" forwarding and connect to a single consul address, which both needs to be reworked.
+
+The first change, was to add support for different backends that perform the actual forwarding.
+Previously it was pretty hard-coded how the forwarding worked, but now all the behaviour for the forwarding is abstracted away and the core logic just
+gets something that knows how to do all the forwarding specific stuff.
+This allowed me to easily add a jool backend, which just needs to implement the corresponding trait and integrate it into CLI, but the rest of the logic is left untouched.
+Another benefit, that I hope to utilize soon, is that I can also pass in dummy/mock/test implementations for forwarding, to test the core logic and its interaction with the forwarding.
+
+The second change, was more subtle and in the pursuit of better reliability, as it now supports having multiple consul addresses.
+Previously one could only pass a single address and if that had issues, then the ipv-proxy was basically not working anymore.
+However now, I can pass the addresses of all my consul servers and it will try all of them until one responds, which means I no longer have a single point of failure in this regard.
+
+## 3. Wireguard setup
+This is required for my use-case, because ipv-proxy needs access to my consul cluster regardless of any proxy status or issues and to ensure this, I simply setup a wireguard network.
+Specifically in my case, all of my internal servers act as wireguard servers listening on their public IPv6 address for connections and then the external server connects to all of them for redundancy.
+
+
+# Deployment
+## Hosting Provider
+Hard Requirements:
+* Provides at least 1 public routable IPv4 address
+* Provides at least a /33 IPv6 subnet
+    * /32 for the NAT64
+    * 1 address for the server itself
+* Supports automation using terraform and cloud-init
+* Reliable
+
+Soft Requirements:
+* Competitive prices
+* European provider
+
+
+I ultimately decided to go with [Scaleway](https://www.scaleway.com/), because they tick all the boxes for me.
+
+## Automation
+The entire deployment is completly automated using terraform and cloud-init, as mentioned earlier.
+Using this combination allows me to completly automatically and easily spin up a new instance, and I am making use of that by never touching the existing instance for changes, but instead just recreating/replacing the entire thing.
+
+# Final Thoughts
+With everything combined, I now have a completly automated system for setting up my external proxy server and the proxying my services.
+All I need to do in my day-to-day to expose something to IPv4 clients, is to add a corresponding tag to the service definition.

content/homelab-monitoring/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Homelab - Monitoring"
-date = 2026-05-04
+date = 2026-06-04
 description = "My current homelab monitoring setup"
 draft = true
 

content/homelab-overview/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Homelab - Overview"
-date = 2026-05-04
+date = 2026-06-04
 description = "A quick and rough overview of my Homelab setup"
 draft = true
 

content/quickfacts-1/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Quickfacts - Part 1: The Mental Model"
-date = 2026-04-02
+date = 2026-06-01
 description = "Building a Mental Model"
 draft = true
 

content/quickfacts-automata/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Quickfacts - Automata Model"
-date = 2026-04-02
+date = 2026-06-01
 description = "Building an automata based model for factorio"
 draft = true
 

content/quickfacts-intro/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Quickfacts - Intro"
-date = 2026-04-01
+date = 2026-06-01
 description = "An introduction to my Quickfacts project"
 draft = true
 

content/streaming/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Streaming setup"
-date = 2026-03-31
+date = 2026-06-01
 description = "Custom streaming setup to complement teamspeak"
 draft = true
 

content/trying-nix/index.md

@@ -0,0 +1,22 @@
++++
+title = "Trying Nix"
+date = 2026-06-01
+description = ""
+draft = true
+
+[taxonomies]
+categories = []
+tags = []
+
+[extra]
+toc = true
++++
+
+Testing out Nix by converting my neovim setup into a nix flake to be easily installed/managed across systems.
+
+<!-- more -->
+
+## Installing Nix
+To install nix, I followed the instructions on the [official nix website](https://nixos.org/download/) for installign the multi-user setup.
+
+

content/udmpro/index.md

@@ -1,6 +1,6 @@
 +++
 title = "Homelab - UDMPro"
-date = 2026-03-31
+date = 2026-06-01
 description = "Documenting my configuration for the UDMPro"
 draft = true
 

content/vault-agents/index.md

@@ -0,0 +1,41 @@
++++
+title = "Vault Agents"
+date = 2026-06-02
+description = "Setting up vault-agents for my servers"
+draft = true
+
+[taxonomies]
+categories = ["Homelab"]
+tags = ["Homelab", "Vault"]
+
+[extra]
+toc = true
++++
+
+My journey to setting up vault-agents on my servers to handle dynamic secrets in configurations.
+
+<!-- more -->
+
+# Configuring Vault Itself
+We first need to setup vault such that the vault agents can authenticate to vault itself.
+
+# Deploying Vault Agents
+TODO
+Testing
+
+# Using them to template Configs
+A couple of examples how I am going to use the vault agents templating features
+
+## Nomad mTLS
+We can use vault agents to template the TLS certificates for nomads mTLS configuration.
+1. Get all currently valid CA certificates and store them in the trust bundle
+2. Get a leaf certificate for the current node
+
+## Consul ACLs
+To configure the ACL tokens for consul
+
+# References
+[^vault_pki_api]: [Vault PKI API](https://developer.hashicorp.com/vault/api-docs/secret/pki)
+[^consul_template_secrets]: [Consul Template Secrets](https://github.com/hashicorp/consul-template/blob/main/docs/templating-language.md#secret)
+[^vault_agent_templates]: [Vault Agent Templates](https://developer.hashicorp.com/vault/docs/agent-and-proxy/agent/template)
+

templates/macros/post_macros.html

@@ -0,0 +1,40 @@
+{% macro meta(page) %}
+    <svg class="icon i-clock" viewBox="0 0 32 32"
+         width="16" height="16" fill="none" stroke="currentcolor"
+         stroke-linecap="round" stroke-linejoin="round" stroke-width="6.25%">
+        <circle cx="16" cy="16" r="14"/>
+        <path d="M16 8 L16 16 20 20"/>
+    </svg>
+    <data>{{ page.reading_time }} minute read</data>
+    <svg class="icon i-edit" viewBox="0 0 32 32"
+         width="16" height="16" fill="none" stroke="currentcolor"
+         stroke-linecap="round" stroke-linejoin="round" stroke-width="6.25%">
+        <path d="M30 7 L25 2 5 22 3 29 10 27 Z M21 6 L26 11 Z M5 22 L10 27 Z"/>
+    </svg>
+
+    {% if page.date %}Published: {{ page.date | date(format="%F") }}{% endif %}
+{% endmacro meta %}
+
+{% macro page_in_list(page) %}
+    <article itemscope itemtype="http://schema.org/CreativeWork">
+        <header>
+            <h2 itemprop="name">
+                <a href="{{ page.permalink | safe }}">
+                    {% if page.draft %}[Draft]{%endif%}
+                    {{ page.title | safe }}
+                </a>
+            </h2>
+            <data class="muted">{{ self::meta(page=page) }}</data>
+        </header>
+        {% if page.description or page.summary %}
+        <section itemprop="summary">
+	            {% if page.description %}
+                    {{ page.description | safe }}
+	            {% else %}
+	            {{ page.summary | safe }}
+	            {% endif %}
+                <nav class="readmore"><a itemprop="url" href="{{ page.permalink | safe }}">Read More&nbsp;&raquo;</a></nav>
+            </section>
+        {% endif %}
+    </article>
+{% endmacro page_in_list %}