Update .gitea/workflows/build-deploy.yml

.gitea/workflows/build-deploy.yml

@@ -7,7 +7,7 @@ on:
 
 env:
   REGISTRY: "gitea.vorpax.dev"
-  IMAGE_NAME: "vorpax/quartz-wiki"
+  IMAGE_NAME: "vorpax/wiki"
 
 jobs:
   build-and-push:
@@ -17,6 +17,9 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
       - name: Set up Docker Buildx
         uses: docker/setup-buildx-action@v3
 
@@ -41,6 +44,7 @@ jobs:
         uses: docker/build-push-action@v6
         with:
           context: .
+          platforms: linux/amd64,linux/arm64
           file: ./Dockerfile.prod
           push: true
           tags: ${{ steps.meta.outputs.tags }}
@@ -49,6 +53,8 @@ jobs:
       - name: Image digest
         run: echo "Image built and pushed successfully"
 
+      #- name: Trigger Komodo Webhook
+      #  run: ../scripts/komodo-webhook.sh
   # Optional: Add deployment step
   # Uncomment and configure this section if you want automatic deployment
   # deploy:

.gitea/workflows/build-publish.yaml

@@ -1,34 +0,0 @@
-name: Build and Push Quartz
-
-env:
-  REGISTRY: "gitea.vorpax.dev"
-  IMAGE_NAME: "vorpax/wiki"
-
-on:
-  push:
-    branches:
-      - main
-  workflow_dispatch:
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Login to Gitea Registry
-        uses: docker/login-action@v3
-        with:
-          registry: ${{ github.server_url }}
-          username: ${{ github.actor }}
-          password: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Build and Push
-        uses: docker/build-push-action@v5
-        with:
-          context: .
-          push: true
-          tags: |
-            ${{ github.server_url }}/${{ github.repository }}/quartz:${{ github.sha }}
-            ${{ github.server_url }}/${{ github.repository }}/quartz:latest

compose.yaml

@@ -1,7 +1,7 @@
 services:
   quartz:
     # Option 1: Pull from Gitea Container Registry (recommended for production)
-    image: gitea.vorpax.dev/vorpax/quartz-wiki:latest
+    image: gitea.vorpax.dev/vorpax/wiki:latest
 
     # Option 2: Build locally (uncomment for local development)
     # build:

content/homelab/Proxmox hosts.md

@@ -6,6 +6,6 @@ title: My Physical Nodes
 # All my nodes
 
 My main cluster is composed of 3 Physical Nodes :
-- [[hardware/littleboy|Littleboy]] which is a Firebat T8 Pro Plus
-- [[hardware/optiplex|Optiplex]] which is an Optiplex 7070 SFF with an i7-9700 and 64GB of RAM
-- [[hardware/fatman|Fatman]] which is a custom built gaming PC repurposed into a beefy GPU workhorse
+- [[littleboy|Littleboy]] which is a Firebat T8 Pro Plus
+- [[optiplex|Optiplex]] which is an Optiplex 7070 SFF with an i7-9700 and 64GB of RAM
+- [[fatman|Fatman]] which is a custom built gaming PC repurposed into a beefy GPU workhorse

content/homelab/guides/Connecting a Travel Router to eduroam with 802.1X on OpenWrt.md

@@ -0,0 +1,247 @@
+---
+title: Connecting a Travel Router to eduroam with 802.1X on OpenWrt
+publish: true
+date: 2026-01-05
+tags:
+  - guide
+  - network
+description: A guide on how to connect to 802.1X on OpenWRT
+---
+
+# Connecting a Travel Router to eduroam with 802.1X on OpenWrt
+
+## The Problem
+
+Universities use eduroam, a secure roaming WiFi service that requires 802.1X authentication. 
+This presents a challenge when you want to connect multiple devices or run infrastructure like a homelab node in a dorm room. 
+Most consumer devices expect simple WPA2-PSK networks where you just enter a password, but eduroam requires each device to authenticate individually with a username and certificate validation.
+
+The typical solution is to authenticate each device separately, but this becomes impractical when you need to connect servers, or devices that lack proper 802.1X supplicant support. 
+
+A travel router solves this by authenticating once to eduroam and then providing a standard local network for your devices.
+
+## Understanding 802.1X and eduroam
+
+The 802.1X standard defines port-based network access control. When you connect to an 802.1X network, the access point acts as an authenticator that forwards your credentials to a RADIUS server. The RADIUS server verifies your identity and either grants or denies network access.
+
+eduroam uses 802.1X with EAP-TTLS or PEAP as the outer authentication method and typically PAP or MSCHAPv2 for the inner authentication. 
+The outer method creates an encrypted tunnel using TLS, and your actual credentials travel through this tunnel to the RADIUS server. This provides strong security even on an open wireless network.
+
+The authentication flow involves presenting a username in the format `user@institution.domain`, an anonymous identity to protect your real username during the initial handshake, and validating the RADIUS server certificate against a trusted CA certificate. This last step prevents attackers from impersonating the authentication server.
+
+## Why a Travel Router
+
+A travel router is a compact router designed for mobile use. 
+
+In our case, it serves as a translation layer between the complex 802.1X requirements of eduroam and the simpler networking expectations of our devices.
+
+You authenticate the router once to eduroam, and it provides a local network over Ethernet and wifi where you can connect servers, development machines, or any IoT devices without each device needing to understand 802.1X.
+
+This approach provides several advantages. 
+You can run services that require static IPs or specific network configurations. You can connect devices that lack 802.1X support entirely. You avoid repeatedly entering credentials on multiple devices.
+
+Most importantly, you gain control over your local network segment, enabling you to run monitoring tools, configure custom DNS, or set up VLANs as needed.
+
+## Hardware and Software Selection
+
+This guide uses the GL.iNet Beryl AX (GL-MT3000) running OpenWrt 24.10 with a MediaTek MT7981 chipset.
+
+Like most Mediatek chipsets, The MT7981 has mature driver support shipped with recent Linux Kernel and hence is well supported on OpenWrt, moreover it handles 802.1X authentication reliably.
+
+OpenWrt is a Linux-based router firmware that replaces vendor firmware with a fully configurable system. Unlike consumer router interfaces, OpenWrt exposes the full Linux networking stack and uses the `wpa_supplicant` (along with `hostapd`)  for 802.1X support.
+
+The choice of OpenWrt over the stock GL.iNet firmware ensures we are working with well-documented, upstream software.
+
+## Building a Custom OpenWrt Image
+
+Rather than flashing a stock image and installing packages afterward, building a custom image ensures all necessary packages are included from the start. This is important because you need working internet connection to install additional packages, creating a chicken-and-egg problem.
+
+Visit the OpenWrt firmware selector at `https://firmware-selector.openwrt.org/` and search for "GL-MT3000"
+Then, in the package customization field, you need to make one critical change and add several packages.
+
+The default OpenWrt image includes `wpad-basic-mbedtls`, which is a minimal WiFi configuration tool that lacks 802.1X support. 
+You **must remove this package** and **replace it with the full version**. Enter `-wpad-basic-mbedtls` (note the minus sign) to remove it, then add `wpad-mbedtls` to install the full version with EAP support.
+
+Add these additional packages in the same field: `ca-certificates` for validating SSL certificates, `vim` and `bash` if you prefer these over the default `vi` and `ash` shells. The complete package customization string should read:
+
+```
+base-files
+ca-bundle
+dnsmasq
+dropbear
+firewall4
+fitblk
+fstools
+kmod-crypto-hw-safexcel
+kmod-gpio-button-hotplug
+kmod-leds-gpio
+kmod-nft-offload
+kmod-phy-aquantia
+libc
+libgcc
+libustream-mbedtls
+logd
+mtd
+netifd
+nftables
+odhcp6c
+odhcpd-ipv6only
+opkg
+ppp
+ppp-mod-pppoe
+procd-ujail
+uboot-envtools
+uci
+uclient-fetch
+urandom-seed
+urngd
+kmod-mt7915e
+kmod-mt7981-firmware
+mt7981-wo-firmware
+kmod-hwmon-pwmfan
+kmod-usb3
+kmod-usb-net
+kmod-usb-net-ipheth
+luci
+wpad-mbedtls
+usbmuxd
+libimobiledevice
+vim
+bash
+usbutils
+```
+
+Request the build and download the resulting firmware image. Flash this to your router following the standard flashing procedure for your model.
+
+## Obtaining eduroam Credentials
+
+Your institution should provide an eduroam configuration tool, typically through the eduroam Configuration Assistant Tool at `cat.eduroam.org`. 
+
+Download the Linux installer for your institution, it's a rather convenient Python script which we will extract the configuration parameters from.
+
+Look for the configuration section near the end. You need these specific values: the EAP outer method (likely TTLS or PEAP), the inner authentication method (likely PAP or MSCHAPv2), the RADIUS server hostname, the anonymous identity, and the CA certificate.
+
+The CA certificate appears in the script as a multi-line string starting with `-----BEGIN CERTIFICATE-----`. 
+
+Copy this certificate exactly, preserving all line breaks, and save it to a file. This certificate will be used to validate that you are connecting to your institution's legitimate RADIUS server.
+
+## Initial Router Configuration
+
+Connect to your router over Ethernet after flashing. The default IP is typically `192.168.8.1` or `192.168.1.1`. SSH to the router as root (password may need to be set on first boot through the web interface).
+
+Create the CA certificate file in the appropriate location. Copy your institution's CA certificate and save it to `/etc/ssl/certs/institution-ca.crt`. Set the permissions to be world-readable:
+
+```bash
+chmod 644 /etc/ssl/certs/institution-ca.crt
+```
+
+## Configuring the WiFi Interface
+
+OpenWrt uses the UCI (Unified Configuration Interface) system for configuration. The wireless configuration file is `/etc/config/wireless`.
+
+You can edit this file directly or use UCI commands. The UCI approach is safer as it validates syntax. 
+First, determine which radio to use. Run `wifi status` to see available radios.
+
+The Beryl AX typically has `radio0` for 2.4GHz and `radio1` for 5GHz. Choose based on which band eduroam uses at your location. The 5GHz band often has less interference but shorter range.
+
+Create the eduroam interface configuration:
+```bash
+uci set wireless.eduroam=wifi-iface
+uci set wireless.eduroam.device='radio1'
+uci set wireless.eduroam.network='wan'
+uci set wireless.eduroam.mode='sta'
+uci set wireless.eduroam.ssid='eduroam'
+uci set wireless.eduroam.encryption='wpa2+ccmp'
+```
+
+This creates a station mode interface (meaning the router acts as a WiFi client) associated with the WAN network. 
+
+Now add the 802.1X parameters:
+```bash
+uci set wireless.eduroam.eap_type='ttls'
+uci set wireless.eduroam.auth='PAP'
+uci set wireless.eduroam.identity='your.username@institution.domain'
+uci set wireless.eduroam.anonymous_identity='anonymous@institution.domain'
+uci set wireless.eduroam.password='your_password'
+```
+
+Replace the identity and password with your actual credentials. The anonymous identity protects your username during the initial handshake. Replace `institution.domain` with your institution's actual domain.
+
+The certificate validation is where many configurations fail. In theory, you should validate the RADIUS server certificate against the CA:
+```bash
+uci set wireless.eduroam.ca_cert='/etc/ssl/certs/institution-ca.crt'
+uci set wireless.eduroam.domain_suffix_match='radius.institution.domain'
+```
+
+However, many institution certificates lack proper Subject Alternative Name (SAN) fields, causing modern TLS implementations to reject them. 
+
+If you encounter authentication failures with certificate validation errors in the logs, you may need to disable certificate validation. 
+
+```bash
+uci delete wireless.eduroam.domain_suffix_match
+```
+
+Commit the changes and reload the wireless configuration:
+```bash
+uci commit wireless
+wifi reload
+```
+
+## Configuring the Network Interface
+
+The wireless interface connects to eduroam, but you need to ensure the WAN interface uses this connection. Check the current WAN device:
+```bash
+uci show network.wan
+```
+
+The default configuration often sets the WAN device to `eth0` (the Ethernet port), but you need it to use the WiFi interface. Change it to the wireless interface name:
+```bash
+uci set network.wan.device='phy1-sta0'
+uci commit network
+ifup wan
+```
+
+The interface name `phy1-sta0` corresponds to `radio1` in station mode. If you used `radio0` instead, adjust accordingly.
+
+After bringing up the WAN interface, verify it obtained an IP address:
+```bash
+ifstatus wan
+ip addr show phy1-sta0
+```
+
+You should see an IPv4 address assigned via DHCP. Test internet connectivity:
+```bash
+ping -c 4 1.1.1.1
+ping -c 4 google.com
+```
+
+## Understanding the Authentication Flow
+
+Watch the authentication process using the system log:
+```bash
+logread -f | grep -i "wpa\|eap"
+```
+
+A successful authentication shows this sequence: the supplicant tries to authenticate with the access point, the access point responds, EAP authentication starts, the TTLS method is selected, the TLS handshake completes (or fails with certificate errors), inner authentication occurs, and finally `CTRL-EVENT-EAP-SUCCESS` appears followed by `CTRL-EVENT-CONNECTED`.
+
+If you see `CTRL-EVENT-EAP-FAILURE`, examine the lines immediately before it. Certificate validation errors mention hostnames or certificate chains. Authentication failures with valid certificates usually indicate wrong credentials. Connection attempts that timeout suggest the RADIUS server is unreachable or the configuration parameters are incorrect.
+
+## Troubleshooting Common Issues
+
+Authentication failures usually stem from three issues: incorrect credentials, certificate validation problems, or wrong EAP method parameters.
+
+If logs show certificate validation errors mentioning hostnames or missing SANs, your institution's certificate lacks modern TLS extensions. Disable certificate validation as described earlier. This is a common problem with older certificate authorities.
+
+If authentication fails after the TLS handshake completes, verify your username format matches your institution's requirements. Most institutions use `username@domain`. Check with your IT department.
+
+If the connection succeeds but you have no internet access, the problem lies in the network interface configuration. Verify the WAN interface uses the correct device with `uci show network.wan`. Ensure DHCP is enabled on WAN with `uci set network.wan.proto='dhcp'`. Restart the network service after changes.
+
+## Security Considerations
+
+The router stores your password in plain text in the UCI configuration files. These files are only readable by root, but anyone with root access can read them. Avoid sharing configuration backups publicly and use strong router passwords.
+
+## Conclusion
+
+This setup provides a robust solution for connecting homelab infrastructure to enterprise WiFi networks. The travel router handles the complex 802.1X authentication, presenting a standard local network to your devices. This approach works well in university dorms, campus offices, or any environment using certificate-based network authentication.
+
+*Published on January 05, 2026*

content/homelab/hardware/end-devices/index.md

@@ -0,0 +1,32 @@
+---
+title: My everyday devices
+publish: true
+tags:
+  -
+---
+
+# What are my daily drivers
+
+
+## Why the hell am I running MacOS ?
+
+Here is something quite controversial : I find Mac better than most laptops out there.
+
+I know this is quite a controversial statement but, after having struggled for hours trying to make WSL work along with both mosh and my Yubikey, I basically gave up.
+
+Though I'm still and I will always be a Linux enjoyer, you can't deny that both Mac as a piece of hardware and MacOS as an OS get the job done. 
+
+Here are the key points:
+- It enables you to access the Office Suite (I know, OSS alternatives, have you ever managed to setup a Microsoft Exchange Email Client on any other app than Outlook ? I did not.)
+- It natively takes advantages of it's ARM CPU architecture, offering substantially better battery performance than any x86 machine while remaining light and thin.
+- MacOS as a BSD derivative is actually quite close to Linux in a daily usage. Though you might not have access to some of `ps` obscure flags, the ability to install GNU Core Utils and to use those, only by prefixing your command with `g` (`gls`, `gcat`,`gcp` and even `gchroot`) is actually pretty great.
+- Mac is the only option if you need substantial amounts of RAM for both GPU and CPU usage.
+- `brew` is really convenient, trust me.
+
+
+
+## Ipad is great for maths
+
+
+
+## You know what, 

content/homelab/hardware/proxmox-nodes/gerboise.md

@@ -0,0 +1,36 @@
+---
+title: Gerboise - GmkTec K12
+publish: true
+tags:
+  - homelab
+  - hardware
+  - proxmox
+---
+
+# Littleboy
+
+**Model**: GmkTec K12
+
+## Specifications
+
+- **CPU**: AMD 
+- **RAM**: $1\times 32 \text{Go} + 1\times 16 \text{Go} \, \, \text{DDR5 SO-DIMM}$
+- **Storage**: 1To NVME for Now
+- **Network**: 2\*2.5Gbe Ethernet + 1 Mediatek Wifi + Bluetooth card (It's currently plugged into my [[GLiNet Beryl AX | GLiNet Beryl AX travel router]] and [[Connecting a Travel Router to eduroam with 802.1X on OpenWrt | connected to eduroam]] )
+
+## Role in Cluster
+
+This node has a peculiar role in my cluster as it is the only node away from my parent's place. 
+I carry it along with me at HEC, it serves as a local experimentation test bench and as a secondary source of daily computing power along with my [[Macbook Pro]].
+
+## Services Running
+
+- List services/VMs/containers running on this node
+
+## Notes
+
+Add any additional notes, configuration details, or special considerations for this node.
+
+---
+
+Back to [[Proxmox hosts|Physical Nodes]]

content/homelab/memos/Gitea Webhook and CI CD using Komodo.md

@@ -0,0 +1,27 @@
+---
+title: Gitea Webhook and CI CD using Komodo
+publish: true
+tags:
+  -
+---
+
+# Gitea Webhook and CI CD using Komodo
+
+You need to whitelist the url you're sending a webhook to in the `config/app.ini` file.
+
+The `[webhook]` section might look something like that 
+
+```ini
+[webhook]
+
+ALLOWED_HOST_LIST = loopback,private,*.vorpax.dev
+```
+
+
+To my own dismay Gitea doesn't offer granular configuration for webhook dispatch (for instance, to trigger your webhook only when some actions are completed).
+
+Neither does Komodo enables you to easily verify some basic parameters inside of the webhook's json body.
+
+In the future, I'll probably setup all of that in CI/CD runners like Gitea Actions, though I would likely trade convenience for a much larger potential to extend CI/CD usage in my Homelab.
+
+I'm actually contemplating an eventual deployment of GitLab on Gerboise, I don't really know if it is worth the ressource overhead...

content/homelab/memos/macos, ssh and Yubikey.md

@@ -0,0 +1,18 @@
+---
+title: How to make your Yubikey work with MacOS's ssh client
+publish: true
+tags:
+  - macos
+  - ssh
+  - fido
+---
+
+# The quick and easy fix
+
+
+```bash
+brew tap theseal/ssh-askpass
+brew install michaelroosz/ssh/libsk-libfido2-install
+```
+
+https://github.com/Yubico/libfido2/issues/464#issuecomment-2588422088

content/homelab/services/Trust a certificate from a private local certificate authority.md

@@ -0,0 +1,116 @@
+---
+title: Trust a certificate from a private local certificate authority
+publish: true
+date: 2026-01-11
+tags:
+  - guide
+  - step-ca
+  - runbook
+description:
+---
+
+# Trust a certificate from a private local certificate authority
+
+## Overview
+
+Make your device trust your private CA for TLS encryption.
+
+## Prerequisites
+
+- A local CA running (in our case step-ca) and reachable at `CA_URL`, for instance `https://local-ca.homelab.internal:443`
+- An end device with access to a normal shell (*eww, Powershell*).
+- very basic understanding of what a PKI is and how certificate trust works.
+
+
+### Initial problem
+
+When doing 
+
+```bash
+curl $CA_URL
+```
+
+you get :  
+
+```
+curl: (60) SSL certificate problem: unable to get local issuer certificate
+More details here: https://curl.se/docs/sslcerts.html
+
+curl failed to verify the legitimacy of the server and therefore could not
+establish a secure connection to it. To learn more about this situation and
+how to fix it, please visit the webpage mentioned above.
+```
+
+Which is normal as your root Certificate authority uses a self-signed certificate.
+
+## Steps
+
+### Step 1: Setup
+
+If not already done, install step cli on your end-device : 
+
+```bash
+brew install step
+```
+
+refer to official documentation https://smallstep.com/docs/step-ca/installation/ for additional installation details for your OS.
+
+### Step 2 : get CA fingerprint
+
+`CA_FINGERPRINT` is the fingerprint of your root certificate.
+
+If you don't have any other device than Step CA with the CA configured, run 
+
+Inside of your host/container running step CA (or any client with step ca already configured)
+
+```bash
+step certificate fingerprint <(step ca root)
+```
+
+### Step 3: Bootstrap cert
+
+You'll need to run :
+
+```bash
+step ca bootstrap --ca-url $CA_URL --fingerprint $CA_FINGERPRINT
+```
+
+
+where `CA_URL` is the address of the CA with protocol
+
+### Step 3 : Install certificate
+
+
+```bash
+step certificate install <(step ca root)
+```
+
+
+### Step 4: Verification
+
+In most modern distributions and *UNIX* derivatives, curl (particularly when installed by default) is configured to run with the system trust store
+
+Now after running
+
+```bash
+curl $CA_URL
+```
+
+you get 
+
+`404 page not found`
+
+Which is completely fine.
+
+### You successfuly installed a certificate.
+
+## References
+
+- https://smallstep.com/docs/step-ca/installation/
+- Related resources
+
+
+
+---
+
+*Created: 2026-01-11*

quartz.config.ts

@@ -29,26 +29,26 @@ const config: QuartzConfig = {
       },
       colors: {
         lightMode: {
-          light: "#faf8f8",
-          lightgray: "#e5e5e5",
-          gray: "#b8b8b8",
-          darkgray: "#4e4e4e",
-          dark: "#2b2b2b",
-          secondary: "#284b63",
-          tertiary: "#84a59d",
-          highlight: "rgba(143, 159, 169, 0.15)",
-          textHighlight: "#fff23688",
+          light: "#eff1f5",
+          lightgray: "#e6e9ef",
+          gray: "#9ca0b0",
+          darkgray: "#4c4f69",
+          dark: "#1e1e2e",
+          secondary: "#7287fd",
+          tertiary: "#8839ef",
+          highlight: "rgba(114, 135, 253, 0.15)",
+          textHighlight: "#7287fd88",
         },
         darkMode: {
-          light: "#161618",
-          lightgray: "#393639",
-          gray: "#646464",
-          darkgray: "#d4d4d4",
-          dark: "#ebebec",
-          secondary: "#7b97aa",
-          tertiary: "#84a59d",
-          highlight: "rgba(143, 159, 169, 0.15)",
-          textHighlight: "#b3aa0288",
+          light: "#1e1e2e",
+          lightgray: "#313244",
+          gray: "#585b70",
+          darkgray: "#a6adc8",
+          dark: "#cdd6f4",
+          secondary: "#b4befe",
+          tertiary: "#94e2d5",
+          highlight: "rgba(180, 190, 254, 0.15)",
+          textHighlight: "#b4befe88",
         },
       },
     },
@@ -61,8 +61,8 @@ const config: QuartzConfig = {
       }),
       Plugin.SyntaxHighlighting({
         theme: {
-          light: "github-light",
-          dark: "github-dark",
+          light: "catppuccin-latte",
+          dark: "catppuccin-mocha",
         },
         keepBackground: false,
       }),

scripts/komodo-webhook.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/bash
+
+curl -X POST -d ${1} -H "Authorization: Bearer ${2}"