Auto-update blog content from Obsidian: 2026-06-09 20:24:47

.gitea/workflows/deployment.yml

@@ -108,7 +108,7 @@ jobs:
           cd /blog
           docker compose down ${CONTAINER_NAME} 
           docker compose up -d ${CONTAINER_NAME}
-          sleep 5
+          sleep 30
           echo "- Displaying container logs"
           docker compose logs ${CONTAINER_NAME}
 
@@ -163,7 +163,7 @@ jobs:
           cd /blog
           docker compose down ${CONTAINER_NAME} 
           docker compose up -d ${CONTAINER_NAME}
-          sleep 5
+          sleep 30
           echo "- Displaying container logs"
           docker compose logs ${CONTAINER_NAME}
 
@@ -194,7 +194,10 @@ jobs:
     steps:
       - name: Remove Old Docker Image
         run: |
-          docker image rm $(docker image ls ${DOCKER_IMAGE} 2> /dev/null | awk '$NF != "U" && NR>1 {print $2}')
+          IMAGE_IDS=$(docker image ls "${DOCKER_IMAGE}" 2>/dev/null | awk '$NF != "U" && NR>1 {print $2}')
+          if [ -n "$IMAGE_IDS" ]; then
+              docker image rm $IMAGE_IDS
+          fi
   
   Notify:
     needs: [Check-Rebuild, Build, Deploy-Staging, Test-Staging, Merge, Deploy-Production, Test-Production, Clean]

.gitea/workflows/test.yml

@@ -109,7 +109,7 @@ jobs:
           cd /blog
           docker compose down ${CONTAINER_NAME} 
           BLOG_TEST_BRANCH=${{ gitea.ref_name }} docker compose up -d ${CONTAINER_NAME}
-          sleep 5
+          sleep 30
           echo "- Displaying container logs"
           docker compose logs ${CONTAINER_NAME}
 

content/post/19-migrate-passive-opnsense-node-to-truenas/index.fr.md

@@ -0,0 +1,283 @@
+---
+slug: migrate-passive-opnsense-node-to-truenas
+title: Migrer mon nœud OPNsense HA passif vers TrueNAS
+description: J’ai migré ma VM OPNsense HA passive de Proxmox vers TrueNAS pour garder le routage et le firewalling disponibles même lorsque mon cluster Proxmox est arrêté.
+date: 2026-05-24
+draft: false
+tags:
+  - opnsense
+  - truenas
+  - proxmox
+  - high-availability
+categories:
+  - homelab
+---
+## Intro
+
+Mon réseau homelab est géré par un cluster OPNsense composé de deux nœuds VM. Ces deux VM fonctionnent dans mon cluster Proxmox VE. Vous pouvez trouver les détails dans cet [article]({{< ref "post/15-migration-opnsense-proxmox-highly-available" >}}).
+
+Cette configuration fonctionne bien la plupart du temps. Le problème concerne plutôt les rares cas où le cluster Proxmox lui-même est arrêté. Quand cela arrive, les deux nœuds OPNsense sont indisponibles en même temps, ce qui signifie qu’il ne me reste aucun routeur, donc aucun réseau du tout.
+
+Récemment, j’ai installé un serveur TrueNAS dans le lab, que j'ai documenté dans ce [post]({{< ref "post/18-create-nas-server-with-truenas" >}}). Il est principalement là pour agir comme NAS, mais il pourrait aussi héberger des machines virtuelles. Cela me donne une bonne opportunité d’améliorer la résilience de mon réseau sans changer toute la conception.
+
+💡 L’idée est simple : garder le nœud OPNsense actif sur Proxmox, mais déplacer le nœud passif vers TrueNAS.
+
+De cette façon, si le cluster Proxmox tombe, le nœud OPNsense passif peut toujours prendre le relais et garder le réseau fonctionnel.
+
+---
+## Préparer les nœuds OPNsense
+
+Avant de déplacer quoi que ce soit, je veux m’assurer que les VM OPNsense peuvent fonctionner avec moins de mémoire.
+
+Le serveur TrueNAS n’a pas autant de RAM disponible que le cluster Proxmox, donc la première étape est de réduire l’allocation mémoire des nœuds OPNsense au minimum.
+
+Je commence avec le nœud passif, `cerbere-head2` :
+
+- Éteindre le nœud passif
+- Réduire son allocation mémoire de 4 à 2GB
+- Le redémarrer
+- Vérifier la santé du cluster
+- Basculer le service vers le nœud passif
+- Exécuter des vérifications réseau
+
+Ensuite, je répète la même opération sur le nœud actif, `cerbere-head1`.
+
+Le faire un nœud à la fois me permet de garder le cluster HA en bonne santé tout en validant que l’allocation mémoire réduite est toujours suffisante pour ma configuration.
+
+---
+## Préparer le réseau TrueNAS
+
+La partie la plus importante de cette migration n’est pas l’export du disque ni la création de la VM. C’est le réseau.
+
+Une VM OPNsense n’est pas un simple serveur avec une seule interface de management. Elle a besoin d’accéder à plusieurs réseaux, incluant le management, le WAN, les réseaux utilisateurs, l’IoT, pfSync, la DMZ et les réseaux lab.
+
+Du côté TrueNAS, je commence depuis `System` > `Network` et j’ajoute des interfaces VLAN.
+
+La première est le VLAN utilisateur :
+
+- Type : `VLAN`
+- Nom : `vlan13`
+- Description : `User`
+- Interface parente : `enp1s0`
+- Tag VLAN : `13`
+
+![Créer l’interface VLAN utilisateur dans TrueNAS](images/truenas-create-new-vlan-interface.png)
+
+J’ajoute ensuite les autres VLANs de la même manière.
+
+TrueNAS n’applique pas les changements réseau directement. Il donne l’option de tester les changements d’abord, avec une courte fenêtre de validation. Si la configuration n’est pas confirmée à temps, il revient automatiquement en arrière.
+
+C’est vraiment pratique lorsqu’on change la configuration réseau de la machine à laquelle on est actuellement connecté.
+
+![Confirmer les interfaces VLAN avant d’appliquer les changements réseau](images/truenas-network-confirm-add-vlans.png)
+
+Pour le réseau de management, j’ai créé un bridge appelé `br1`.
+
+Ce bridge porte la configuration IP de management de TrueNAS à la place de l’interface physique `enp1s0`, parce qu’elle doit aussi être partagée avec la VM OPNsense.
+
+![Créer le bridge de management pour TrueNAS et la VM OPNsense](images/truenas-network-mgmt-bridge.png)
+
+Après cela, je retire la configuration IP de l’interface physique et je la garde sur le bridge.
+
+![Configuration réseau avant d’appliquer les changements du bridge](images/truenas-network-changes-before-apply.png)
+
+J’ai initialement essayé d’utiliser DHCP pour le bridge de management après avoir mis à jour l’adresse MAC dans Dnsmasq, mais j’ai finalement décidé de garder une adresse IP statique pour TrueNAS. Après certains changements réseau, DHCP a donné une autre adresse du pool, donc l’adressage statique était l’option la plus sûre et la plus simple pour ce serveur.
+
+Pour la VM OPNsense, je crée un bridge pour chaque VLAN. Par exemple, `br13` utilise `vlan13`, je déplace aussi la description, comme `User`, de l’interface VLAN vers le bridge pour plus de clarté.
+
+La configuration réseau finale de TrueNAS :
+
+![Créer un bridge par VLAN pour la VM OPNsense](images/truenas-network-bridges-for-vlan.png)
+
+---
+## Créer un dataset d’export temporaire
+
+Pour déplacer le disque de la VM OPNsense passive de Proxmox vers TrueNAS, j’ai d’abord besoin d’un endroit pour exporter l’image disque.
+
+Dans TrueNAS, je crée un dataset nommé `storage/vm/disk`, puis je crée un partage NFS à partir de celui-ci.
+
+Dans les options avancées du partage NFS, j’ai configuré :
+
+- Utilisateur Maproot : `root`
+- Hôtes autorisés :
+  - `192.168.88.21`
+  - `192.168.88.22`
+  - `192.168.88.23`
+
+Ce sont les nœuds Proxmox VE autorisés à monter le partage.
+
+Je ne crée pas manuellement de zvol à ce moment-là. Le processus de création de VM dans TrueNAS gère l’import et la conversion du disque.
+
+---
+## Exporter le disque de la VM depuis Proxmox
+
+Depuis l’interface web Proxmox VE, je localise le nœud qui héberge la VM OPNsense passive `cerbere-head2`, elle fonctionne sur `Zenith`.
+
+Je me connecte à ce nœud Proxmox en SSH et je monte le partage NFS depuis TrueNAS :
+
+```bash
+mount granite.mgmt.vezpi.com:/mnt/storage/vm/disk /mnt
+```
+
+Ensuite, j’éteins la VM depuis l’interface Proxmox VE. Je ne l’éteins pas depuis l’intérieur d’OPNsense parce que la VM a la HA activée.
+
+Une fois la VM arrêtée, j’exporte le disque principal en qcow2. Je n’exporte pas le disque EFI.
+
+```bash
+qemu-img convert -f raw -O qcow2 -p \
+         rbd:ceph-workload/vm-123-disk-1 \
+         /mnt/cerbere-head2.qcow2
+```
+
+La conversion a pris environ une minute pour un disque de 20 GB.
+
+À ce stade, le disque OPNsense passif est disponible sur TrueNAS et prêt à être importé dans une nouvelle VM.
+
+---
+## Recréer la VM OPNsense dans TrueNAS
+
+L’étape suivante consiste à recréer la VM OPNsense passive dans TrueNAS avec des paramètres correspondant aussi étroitement que possible à la VM d’origine.
+
+Depuis l’interface web TrueNAS, je vais dans la section `Virtual Machines`.
+
+![La section Machines virtuelles dans TrueNAS](images/truenas-vm-menu.png)
+
+Je crée une nouvelle VM avec ces paramètres.
+
+Pour le système d’exploitation :
+
+- Système d’exploitation invité : `FreeBSD`
+- Nom : `cerberehead2`
+- Horloge système : `Local`
+- Méthode de démarrage : `UEFI`
+- Activer Secure Boot : désactivé
+- Activer Trusted Platform Module : désactivé
+- Timeout d’arrêt : `90`
+- Démarrer au boot : activé
+- Activer l’affichage VNC : désactivé
+
+Le nom de la VM n’utilise pas de tirets parce que TrueNAS ne les autorise pas ici.
+
+Pour le CPU et la mémoire :
+
+- CPU virtuels : `1`
+- Cœurs : `2`
+- Threads : `1`
+- Mode CPU : `Custom`
+- Modèle CPU : `qemu64`
+- Taille mémoire : `2 GiB`
+
+Pour le disque :
+
+- Créer une nouvelle image disque
+- Importer une image : activé
+- Source de l’image : `/mnt/storage/vm/files/cerbere-head2.qcow2`
+- Type de disque : `VirtIO`
+- Emplacement de stockage : `storage/vm`
+- Taille : `20 GiB`
+
+Pour la première interface réseau :
+
+- Type d’adaptateur : `VirtIO`
+- Adresse MAC : garder celle proposée
+- Attacher la NIC : `br1: Mgmt`
+
+Je passe le média d’installation et la configuration GPU, puis je confirme le résumé.
+
+![Résumé avant de créer la VM OPNsense dans TrueNAS](images/truenas-vm-create-new-summary.png)
+
+Après confirmation, TrueNAS convertit l’image qcow2 importée en zvol.
+
+![TrueNAS convertissant l’image disque importée en zvol](images/truenas-vm-disk-image-conversion.png)
+
+Une fois la VM créée, j’ouvre les détails de la VM et j’ajoute les NICs restantes.
+
+![Les périphériques de la VM dans TrueNAS](images/truenas-vm-details.png)
+
+Pour chaque NIC supplémentaire, j’ai utilisé VirtIO comme type d’adaptateur et je l’ai attachée au bridge correspondant.
+
+Pour la NIC WAN, je copie l’ancienne adresse MAC parce que j’utilise une astuce avec une seule adresse IP WAN. J’incrémente aussi le chiffre dans l’ordre des périphériques pour garder le même que dans Proxmox.
+
+![Interface réseau VirtIO supplémentaire pour la VM OPNsense](images/truenas-vm-add-nic.png)
+
+🎉 Enfin, je peux démarrer la VM OPNsense dans TrueNAS.
+
+![OPNsense démarre avec succès comme VM TrueNAS](images/truenas-vm-opnsense-start-shell.png)
+
+---
+## Valider le cluster HA
+
+Une fois que le nœud passif fonctionne sur TrueNAS, je dois valider que le cluster HA OPNsense se comporte toujours correctement.
+
+Je commence par des vérifications de base sur le nœud passif :
+
+- Ping de l’interface de management depuis le bastion : `192.168.88.3`
+- Ping de l’interface utilisateur depuis un laptop : `192.168.13.3`
+- Ping de l’interface IoT : `192.168.37.3`
+- Ping pfSync depuis l’autre nœud : `192.168.44.2`
+- Ping de l’interface DMZ : `192.168.55.3`
+- Ping de l’interface Lab depuis DockerVM : `192.168.66.3`
+
+Je vérifie aussi que le nœud était accessible en SSH depuis mon laptop en utilisant `192.168.13.3`, et que l’interface web était joignable à :
+
+```text
+https://192.168.13.3:4443
+```
+
+Ensuite, je valide l’état HA d’OPNsense :
+
+- Le statut des VIP CARP doit être `BACKUP` sur toutes les VIP
+- La page de statut HA doit montrer que le nœud actif peut se connecter au nœud passif
+- Les services doivent fonctionner comme attendu
+- La synchronisation des services HA doit fonctionner
+- Les vérifications de mise à jour du firmware doivent être accessibles
+
+Depuis le nœud actif, j’utilise la page de statut HA et je force une synchronisation complète avec `Synchronize and reconfigure all`.
+
+---
+## Tests de bascule contrôlée
+
+Avant de tester le failover, je démarre une session SSH vers `dockerVM` pour confirmer que les états du firewall sont préservés entre les nœuds. Je démarre aussi un ping depuis un laptop vers `192.168.37.120`.
+
+Pour le test de bascule contrôlée, j’active proprement le mode maintenance sur le nœud master.
+
+Le nouveau nœud passif devient `MASTER`, et je valide les services importants :
+
+- Routage VLAN supplémentaire avec un ping vers `192.168.37.120`
+- Accès WAN avec un ping vers `8.8.8.8`
+- États du firewall en gardant la session SSH active
+- Résolution DNS externe avec `host redhat.com`
+- Résolution DNS interne avec `host SLZB-06M.mgmt.vezpi.com`
+- Accès à une page internet aléatoire
+- Reverse proxy Caddy
+- Proxy layer4 Caddy
+- Accès Wireguard depuis l’extérieur
+- mDNS en vérifiant si l’imprimante est apparue
+
+✅ La bascule contrôlée est réussie.
+
+---
+## Tests de failover
+
+Après le test de bascule contrôlée propre, je teste un scénario de failover plus direct en forçant un poweroff du nœud actif.
+
+J’ai répété la même checklist de validation.
+
+✅ Le failover est réussi.
+
+Enfin, je redémarre la VM OPNsense active.
+
+🎯 À ce stade, le cluster HA OPNsense est de nouveau opérationnel, avec le nœud passif qui fonctionne maintenant sur TrueNAS au lieu de Proxmox.
+
+---
+## Conclusion
+
+Cette migration est une petite mais importante amélioration pour mon homelab.
+
+Avant, les deux nœuds OPNsense dépendaient du cluster Proxmox VE. Si le cluster était arrêté, toute ma couche de routage réseau était arrêtée avec lui.
+
+Maintenant, le nœud actif fonctionne toujours sur Proxmox, mais le nœud passif fonctionne sur TrueNAS. Cela me donne une meilleure séparation entre le cluster de virtualisation et la couche de failover réseau.
+
+Petit disclaimer, bien que TrueNAS offre des fonctionnalités de virtualisation, il n’est pas comparable à Proxmox VE en termes de clustering et de capacités de gestion d’infrastructure.
+
+Une note à propos de QEMU Guest Agent, la VM OPNsense avait déjà QEMU Guest Agent installé avant l’export. Dans cette configuration, il ne semble pas utile parce que TrueNAS ne l’a pas implémenté comme fonctionnalité d’hyperviseur. Je l’ai gardé installé quand même, parce qu’il est inoffensif.

content/post/19-migrate-passive-opnsense-node-to-truenas/index.md

@@ -1,147 +1,127 @@
 ---
 slug: migrate-passive-opnsense-node-to-truenas
-title: Migrate my Passive OPNsense Node to TrueNAS
+title: Migrate my Passive OPNsense HA Node to TrueNAS
 description: I migrated my passive OPNsense HA VM from Proxmox to TrueNAS to keep routing and firewalling available even when my Proxmox cluster is down.
-date: 2026-03-12
-draft: true
+date: 2026-05-24
+draft: false
 tags:
   - opnsense
   - truenas
   - proxmox
+  - high-availability
 categories:
   - homelab
 ---
-
 ## Intro
 
-My router is the heart of my homelab. When it’s down, everything is down: internet, DNS, VLAN firewall, reverse proxy… the whole stack.
+My homelab network is handled by an OPNsense cluster composed of two VM nodes. Both of these VMs are running inside my Proxmox VE cluster. You can find details in this [article]({{< ref "post/15-migration-opnsense-proxmox-highly-available" >}}).
 
-I’m running an [[OPNsense]] HA cluster made of **two virtual machines** inside my [[Proxmox]] VE cluster. It works great… except for one annoying edge case: when the Proxmox cluster is down (rare, but it happens), I suddenly have **no router left**.
+This setup works fine most of the time. The issue is more about the rare cases where the Proxmox cluster itself is down. When that happens, both OPNsense nodes are unavailable at the same time, which means I do not have any router left, so no network at all.
 
-Recently I installed a [[TrueNAS]] server ([[Build my NAS with TrueNAS]]), and TrueNAS can host virtual machines. So I decided to move **only the passive OPNsense node** to TrueNAS, so that if Proxmox goes dark, I still have a node alive that can take over and keep the network running.
+Recently, I installed a TrueNAS server in the labwhich I document in that [post]({{< ref "post/18-create-nas-server-with-truenas" >}}). It is mainly here to act as a NAS, but it could also host virtual machines. That give me a good opportunity to improve the resilience of my network without changing the whole design.
 
-The objective of this post is simple: explain what I migrated, why I did it, and what configuration choices made it work reliably.
+💡 The idea is simple: keep the active OPNsense node on Proxmox, but move the passive node to TrueNAS.
+
+This way, if the Proxmox cluster goes down, the passive OPNsense node can still take over and keep the network alive.
 
 ---
+## Prepare the OPNsense Nodes
 
-## The Plan: Split the HA Pair Across Two Hypervisors
+Before moving anything, I want to make sure the OPNsense VMs could run with less memory.
 
-The goal was:
+The TrueNAS server does not have as much RAM available as the Proxmox cluster, so the first step is to reduce the memory allocation of the OPNsense nodes to the minimum.
 
-- Keep the **active** OPNsense node running on Proxmox VE (where it already lives).
-- Migrate the **passive** node to TrueNAS.
-- Validate that the HA cluster still behaves properly (CARP VIPs, sync, services, failover).
+I start with the passive node, `cerbere-head2`:
 
-This way, a Proxmox outage no longer means “no routing at all”.
+- Shut down the passive node
+- Reduce its memory allocation from 4 to 2GB
+- Restart it
+- Verify the cluster health
+- Swap the service to the passive node
+- Run network checks
+
+Then I repeat the same operation on the active node, `cerbere-head1`.
+
+Doing it one node at a time allow me to keep the HA cluster healthy while validating that the reduced memory allocation is still enough for my setup.
 
 ---
+## Prepare the TrueNAS Network
 
-## What I Used
+The most important part of this migration is not the disk export or the VM creation. It is the network.
 
-Quick overview of the pieces involved:
+An OPNsense VM is not a simple server with one management interface. It needs access to several networks, including management, WAN, user networks, IoT, pfSync, DMZ and lab networks.
 
-- **OPNsense**: https://opnsense.org/
-- **Proxmox VE** (current home of both OPNsense VMs): https://www.proxmox.com/en/proxmox-virtual-environment/overview
-- **TrueNAS** (new home of the passive node, and storage to transfer the VM disk): https://www.truenas.com/
+On the TrueNAS side, I start from `System` > `Network` and add VLAN interfaces.
+
+The first one is the User VLAN:
+
+- Type: `VLAN`
+- Name: `vlan13`
+- Description: `User`
+- Parent interface: `enp1s0`
+- VLAN tag: `13`
+
+![Create the User VLAN interface in TrueNAS](images/truenas-create-new-vlan-interface.png)
+
+I then add the other VLANs in the same way.
+
+TrueNAS does not apply network changes directly. It gives the option to test the changes first, with a short validation window. If the configuration is not confirmed in time, it rolls back automatically.
+
+This is really convenient when changing the network configuration of the machine you are currently connected to.
+
+![Confirm the VLAN interfaces before applying the network changes](images/truenas-network-confirm-add-vlans.png)
+
+For the management network, I created a bridge called `br1`.
+
+This bridge holds the TrueNAS management IP configuration instead of the physical interface `enp1s0`, because it also needs to be shared with the OPNsense VM.
+
+![Create the management bridge for TrueNAS and the OPNsense VM](images/truenas-network-mgmt-bridge.png)
+
+After that, I remove the IP configuration from the physical interface and keep it on the bridge.
+
+![Network configuration before applying the bridge changes](images/truenas-network-changes-before-apply.png)
+
+I initially tried to use DHCP for the management bridge after updating the MAC address in Dnsmasq, but I finally decided to keep a static IP address for TrueNAS. After some network changes, DHCP gave another address from the pool, so static addressing was the safer and simpler option for this server.
+
+For the OPNsense VM, I create a bridge for each VLAN. For example, `br13` uses `vlan13`, I also move the description, like `User`, from the VLAN interface to the bridge for clarity.
+
+The final TrueNAS network configuration:
+
+![Create one bridge per VLAN for the OPNsense VM](images/truenas-network-bridges-for-vlan.png)
 
 ---
+## Create a Temporary Export Dataset
 
-## Step 1 — Make OPNsense Lighter (RAM Reduction)
+To move the passive OPNsense VM disk from Proxmox to TrueNAS, I first need a place to export the disk image.
 
-TrueNAS on my side doesn’t have “infinite RAM”, so the first step was to reduce memory usage to something more reasonable.
+In TrueNAS, I create a dataset named `storage/vm/disk`, then create a NFS share from it.
 
-I reduced the memory allocation of both OPNsense nodes in Proxmox:
+In the advanced options of the NFS share, I configured:
 
-- Shutdown passive node `cerbere-head2`
-- Reduce RAM, restart, verify HA
-- Swap services to the passive temporarily and test networking
-- Shutdown active node `cerbere-head1`
-- Reduce RAM, restart, verify HA again
+- Maproot user: `root`
+- Authorized hosts:
+  - `192.168.88.21`
+  - `192.168.88.22`
+  - `192.168.88.23`
 
-This kept the cluster healthy while ensuring the VM would fit comfortably on the NAS.
+These are the Proxmox VE nodes allowed to mount the share.
 
-(Details: [[Reduce the memory allocation of OPNsense nodes]])
+I don't manually create a zvol at that point. The VM creation process in TrueNAS handle the disk import and conversion.
 
 ---
+## Export the VM Disk from Proxmox
 
-## Step 2 — Prepare Networking on TrueNAS (Trunk + VLAN Strategy)
+From the Proxmox VE web interface, I locate the node hosting the passive OPNsense VM `cerbere-head2`, it is running on `Zenith`.
 
-To host an OPNsense VM properly, TrueNAS must be able to present the right networks to the VM (Mgmt, VLANs, etc.). In my case, I needed a trunk configuration.
-
-In TrueNAS, I went to `System` > `Network` and created VLAN interfaces (example with VLAN 13):
-
-![truenas-create-new-vlan-interface.png](images/truenas-create-new-vlan-interface.png)
-
-TrueNAS is nice here: changes aren’t applied blindly. You can **test** them and you get a rollback window, which is exactly what you want when you’re touching the network config remotely:
-
-![truenas-network-confirm-add-vlans.png](images/truenas-network-confirm-add-vlans.png)
-
-### Management bridge
-
-I created a bridge `br1` for the management interface, shared between:
-
-- TrueNAS itself
-- the future OPNsense VM
-
-And moved the IP configuration to the bridge:
-
-![truenas-network-mgmt-bridge.png](images/truenas-network-mgmt-bridge.png)
-
-Final view before apply:
-
-![truenas-network-changes-before-apply.png](images/truenas-network-changes-before-apply.png)
-
-### Static IP vs DHCP (and why I stayed static)
-
-I initially tried switching the management bridge to DHCP by updating the MAC address in OPNsense (Dnsmasq override):
-
-![opnsense-update-dnsmasq-override-truenas-bridge.png](images/opnsense-update-dnsmasq-override-truenas-bridge.png)
-
-Then I attempted to flip TrueNAS from static to DHCP:
-
-![truenas-network-bridge-switch-static-to-dhcp.png](images/truenas-network-bridge-switch-static-to-dhcp.png)
-
-But DHCP didn’t behave as I expected: it kept receiving random IPs from the pool. I suspected existing leases played a role. I even tried manually editing leases and restarting the service, but after another change, it still ended up with a random address again.
-
-In the end, I gave up and kept **a static IP** for TrueNAS. It’s boring, but it’s predictable.
-
-### The key decision: bridge VLANs (not just VLAN interfaces)
-
-This became important later: I originally planned to attach VLAN interfaces directly to the OPNsense VM, but it didn’t behave well.
-
-So I created **one bridge per VLAN** (ex: `br13` with `vlan13` as the only member), and used those bridges for the VM NICs:
-
-![truenas-network-bridges-for-vlan.png](images/truenas-network-bridges-for-vlan.png)
-
-That ended up being the difference between “split-brain chaos” and “stable HA”.
-
-(Full notes: [[Configure the trunk in TrueNAS]])
-
----
-
-## Step 3 — Move the VM Disk From Proxmox to TrueNAS
-
-To migrate the VM cleanly, I exported the Proxmox disk to TrueNAS.
-
-### Create a dataset and export it via NFS
-
-I created a dataset (initially called `disk`) and exported it with NFS, restricting access to my three Proxmox nodes (by IP):
-
-- 192.168.88.21
-- 192.168.88.22
-- 192.168.88.23
-
-(Notes: [[Create a new dataset in TrueNAS to export Proxmox VM disk]])
-
-### Export the passive OPNsense disk
-
-On the Proxmox node hosting the passive VM (`cerbere-head2`), I mounted the NFS share:
+I log into that Proxmox node over SSH and mount the NFS share from TrueNAS:
 
 ```bash
-mount granite.mgmt.vezpi.com:/mnt/storage/disk /mnt
+mount granite.mgmt.vezpi.com:/mnt/storage/vm/disk /mnt
 ```
 
-Then I shut down the VM from Proxmox (HA enabled, so I didn’t do it from inside OPNsense), and converted/exported the main disk (not the EFI disk) from Ceph RBD to a qcow2 file:
+Then I shut down the VM from the Proxmox VE interface. I don't shut it down from inside OPNsense because the VM has HA enabled.
+
+Once the VM is stopped, I export the main disk to qcow2. I don't export the EFI disk.
 
 ```bash
 qemu-img convert -f raw -O qcow2 -p \
@@ -149,150 +129,155 @@ qemu-img convert -f raw -O qcow2 -p \
          /mnt/cerbere-head2.qcow2
 ```
 
-The conversion took around a minute for a 20GB disk.
+The conversion took about one minute for a 20 GB disk.
 
-(Notes: [[Export the passive OPNsense VM disk from Proxmox]])
+At this point, the passive OPNsense disk is available on TrueNAS and ready to be imported into a new VM.
 
-### Dataset reorg (cleaner layout)
+---
+## Recreate the OPNsense VM in TrueNAS
 
-I reorganized datasets on TrueNAS side to something more VM-oriented:
+The next step is to recreate the passive OPNsense VM in TrueNAS with parameters matching the original VM as closely as possible.
 
-- created `storage/vm`
-- renamed `storage/disk` to `storage/vm/files`
+From the TrueNAS web interface, I go to the `Virtual Machines` section.
 
-Commands used:
+![The Virtual Machines section in TrueNAS](images/truenas-vm-menu.png)
 
-```bash
-zfs list
-sudo zfs create storage/vm
-sudo zfs rename storage/disk storage/vm/files
+I create a new VM with these settings.
+
+For the operating system:
+
+- Guest Operating System: `FreeBSD`
+- Name: `cerberehead2`
+- System Clock: `Local`
+- Boot Method: `UEFI`
+- Enable Secure Boot: disabled
+- Enable Trusted Platform Module: disabled
+- Shutdown Timeout: `90`
+- Start on Boot: enabled
+- Enable Display VNC: disabled
+
+The VM name does not use dashes because TrueNAS do not allow them there.
+
+For CPU and memory:
+
+- Virtual CPUs: `1`
+- Cores: `2`
+- Threads: `1`
+- CPU Mode: `Custom`
+- CPU Model: `qemu64`
+- Memory Size: `2 GiB`
+
+For the disk:
+
+- Create new disk image
+- Import Image: enabled
+- Image source: `/mnt/storage/vm/files/cerbere-head2.qcow2`
+- Disk Type: `VirtIO`
+- Storage Location: `storage/vm`
+- Size: `20 GiB`
+
+For the first network interface:
+
+- Adapter Type: `VirtIO`
+- MAC Address: keep the proposed one
+- Attach NIC: `br1: Mgmt`
+
+I skip installation media and GPU configuration, then confirm the summary.
+
+![Summary before creating the OPNsense VM in TrueNAS](images/truenas-vm-create-new-summary.png)
+
+After confirmation, TrueNAS convert the imported qcow2 image into a zvol.
+
+![TrueNAS converting the imported disk image into a zvol](images/truenas-vm-disk-image-conversion.png)
+
+Once the VM is created, I open the VM details and add the remaining NICs.
+
+![The VM devices in TrueNAS](images/truenas-vm-details.png)
+
+For each additional NIC, I used VirtIO as the adapter type and attach it to the corresponding bridge.
+
+For the WAN NIC, I copy the old MAC address because I use a single WAN IP address trick. I also increment the digit in the Device Order to keep the same as in Proxmox.
+
+![Additional VirtIO network interface to the OPNsense VM](images/truenas-vm-add-nic.png)
+
+🎉 Finally I can start the OPNsense VM in TrueNAS.
+
+![OPNsense booting successfully as a TrueNAS VM](images/truenas-vm-opnsense-start-shell.png)
+
+---
+## Validate the HA cluster
+
+Once the passive node is running on TrueNAS, I need to validate that the OPNsense HA cluster is still behaving correctly.
+
+I start with basic checks on the passive node:
+
+- Management interface ping from the bastion: `192.168.88.3`
+- User interface ping from a laptop: `192.168.13.3`
+- IoT interface ping: `192.168.37.3`
+- pfSync ping from the other node: `192.168.44.2`
+- DMZ interface ping: `192.168.55.3`
+- Lab interface ping from DockerVM: `192.168.66.3`
+
+I also check that the node was accessible over SSH from my laptop using `192.168.13.3`, and that the web interface was reachable at:
+
+```text
+https://192.168.13.3:4443
 ```
 
-(Notes: [[Reorganize the dataset in TrueNAS]])
+Then I validate the OPNsense HA state:
+
+- CARP VIP status must be `BACKUP` on all VIPs
+- HA status page must show that the active node can log in to the passive node
+- Services must be running as expected
+- HA service synchronization must work
+- Firmware update checks must be accessible
+
+From the active node, I use the HA status page and force a full synchronization with `Synchronize and reconfigure all`.
 
 ---
+## Switchover Tests
 
-## Step 4 — Create the OPNsense VM on TrueNAS (Import Disk + Rebuild NICs)
+Before testing failover, I start a SSH session to `dockerVM` to confirm that firewall states are preserved across nodes. I also start a ping from a laptop to `192.168.37.120`.
 
-Now the fun part: recreating the VM on TrueNAS with the same “spirit” as the Proxmox VM.
+For the switchover test, I gracefully enable maintenance mode on the master node.
 
-From `Virtual Machines`:
+The new passive node become `MASTER`, and I validate the important services:
 
-![truenas-vm-menu.png](images/truenas-vm-menu.png)
-
-### VM settings I used
-
-I created a new VM with:
-
-**Operating System**
-- Guest: FreeBSD
-- Name: `cerberehead2` (TrueNAS doesn’t like dashes)
-- Boot: UEFI
-- Secure Boot: Disabled
-- TPM: Disabled
-- Start on Boot: Enabled
-- VNC: Disabled
-
-**CPU & Memory**
-- Virtual CPUs: 1
-- Cores: 2
-- Threads: 1
-- CPU Mode: Custom
-- CPU Model: `qemu64`
-- Memory: 2 GiB
-
-**Disk**
-- Import image enabled
-- Source: `/mnt/storage/vm/files/cerbere-head2.qcow2`
-- Disk Type: VirtIO
-- Location: `storage/vm`
-- Size: 20 GiB
-
-**Network**
-- Adapter: VirtIO
-- Attached to `br1` (Mgmt)
-- MAC: kept the generated one here
-
-Summary screen:
-
-![truenas-vm-create-new-summary.png](images/truenas-vm-create-new-summary.png)
-
-After saving, TrueNAS converted the imported image into a Zvol:
-
-![truenas-vm-disk-image-conversion.png](images/truenas-vm-disk-image-conversion.png)
-
-### Adding the additional NICs
-
-After the VM was created, I added the additional NICs in the VM device list:
-
-![truenas-vm-details.png](images/truenas-vm-details.png)
-
-At first, I attached VLAN interfaces directly and started the VM… and instantly broke my network (great success).
-
-The VM itself booted fine though, and seeing OPNsense come up cleanly on TrueNAS was a good sign:
-
-![truenas-vm-opnsense-start-shell.png](images/truenas-vm-opnsense-start-shell.png)
-
-But HA-wise, it was a mess: split-brain symptoms, with the TrueNAS-hosted node thinking it was MASTER on almost everything except Mgmt.
-
-The fix was the VLAN bridging approach mentioned earlier: once I switched the VM NICs to attach to **bridges (`br13`, `br20`, etc.) instead of VLAN interfaces**, the cluster came back to a healthy state.
-
-Second try: stable. ✅
-
-(Notes: [[Create the OPNsense VM in TrueNAS]])
-
----
-
-## Step 5 — Validate HA: CARP, Sync, Services, Switchover and Failover
-
-Once everything was in place, I validated the new setup with a proper checklist. I wanted to be sure the cluster worked exactly as before.
-
-### Basic checks
-
-- Ping each interface as relevant (Mgmt/User/IoT/pfSync/DMZ/Lab)
-- SSH access
-- Web UI access
-- CARP VIP status must be `BACKUP` on the passive node
-- HA status (active must be able to log into passive)
-- Services state + “Synchronize and reconfigure all”
-- Check updates availability (`System` > `Firmware` > `Check for updates`)
-
-### Switchover test (graceful)
-
-I started:
-- a SSH session to DockerVM (to check state keeping)
-- a ping to an IoT host from a laptop
-
-Then tested:
-- CARP role switch
-- inter-VLAN routing
-- WAN ping to `8.8.8.8`
-- firewall state (SSH session stays alive)
-- DNS resolution (external + internal)
-- Caddy reverse proxy + layer4 proxy checks
+- Extra VLAN routing with ping to `192.168.37.120`
+- WAN access with ping to `8.8.8.8`
+- Firewall states by keeping the SSH session alive
+- External DNS resolution with `host redhat.com`
+- Internal DNS resolution with `host SLZB-06M.mgmt.vezpi.com`
+- Access to a random internet page
+- Caddy reverse proxy
+- Caddy layer4 proxy
 - Wireguard access from outside
-- mDNS discovery (printer visibility)
+- mDNS by checking if the printer showed up
 
-✅ Switchover successful.
-
-### Failover test (hard)
-
-Then I forced power off of the active node and repeated the same functional tests.
-
-✅ Failover successful.
-
-At the end: restarted the active VM, and the HA pair returned to normal operation.
-
-One note: QEMU Guest Agent doesn’t bring value here because TrueNAS doesn’t implement it as a hypervisor (I still left it installed since it’s harmless).
-
-(Full checklist and validation steps: [[Validate the new OPNsense VM and cluster state]])
+✅ The switchover is successful.
 
 ---
+## Failover Tests
 
+After the graceful switchover test, I test a more direct failover scenario by forcing a poweroff of the active node.
+
+I repeated the same validation checklist.
+
+✅ The failover is successful.
+
+Finally, I restart the active OPNsense VM.
+
+🎯 At that point, the OPNsense HA cluster is operational again, with the passive node now running on TrueNAS instead of Proxmox.
+
+---
 ## Conclusion
 
-This project solved a real weakness in my homelab: my “highly available” router cluster was still depending on a single platform (Proxmox). By moving only the **passive OPNsense node** to **TrueNAS**, I now have a router that can survive a full Proxmox outage.
+This migration is a small but important improvement for my homelab.
 
-The biggest takeaway for me was networking on TrueNAS: attaching VLAN interfaces directly to the VM was not reliable in my setup, but bridging each VLAN (`br13`, `br20`, etc.) made the HA behavior stable and predictable.
+Before, both OPNsense nodes depended on the Proxmox VE cluster. If the cluster was down, my whole network routing layer was down with it.
 
-Next step is to monitor the cluster for a few days before doing the cleanup of the migration on the Proxmox side.
+Now, the active node still runs on Proxmox, but the passive node runs on TrueNAS. This gives me a better separation between the virtualization cluster and the network failover layer.
+
+Little disclaimer, while TrueNAS offers virtualization features, it is not comparable to Proxmox VE in terms of clustering and infrastructure management capabilities.
+
+A note about QEMU Guest Agent, the OPNsense VM already had the QEMU Guest Agent installed before expert. In this setup, it does not seem useful because TrueNAS does not have it implemented as a hypervisor feature. I kept it installed anyway, because it is harmless.

content/post/20-automating-proxmox-update-ansible/index.fr.md

@@ -0,0 +1,311 @@
+---
+slug: automating-proxmox-update-ansible
+title: Automatiser les mises à jour de Proxmox VE avec Ansible
+description: Automatisez les mises à jour d’un cluster Proxmox VE avec Ansible, Semaphore UI et Ntfy, incluant les vérifications Ceph, les redémarrages progressifs et les rapports.
+date: 2026-06-09
+draft: false
+tags:
+  - proxmox
+  - ansible
+  - semaphore-ui
+  - ntfy
+categories:
+  - homelab
+---
+## Intro
+
+Dans mon homelab, les mises à jour font partie de ces choses faciles à repousser.
+
+Pas parce qu’elles sont compliquées, mais parce qu’elles sont manuelles. Je dois me connecter au bon système, vérifier l’état, appliquer les mises à jour, redémarrer si nécessaire, vérifier que tout revient correctement, puis répéter le même processus pour le composant suivant.
+
+Et comme c’est manuel, je le garde généralement pour plus tard.
+
+Quand Proxmox VE 9.1 est sorti, je voulais déjà mettre à jour mon cluster, mais pas manuellement. Puis Proxmox VE 9.2 est devenu disponible il y a quelques jours, et je n’avais toujours pas construit de processus propre autour de cela. C’était un bon déclencheur pour enfin commencer à automatiser les mises à jour des parties importantes de mon homelab.
+
+L’objectif plus large est de simplifier et d’automatiser le patching de plusieurs composants clés :
+
+- Proxmox VE
+- OPNsense
+- TrueNAS
+
+J’ai décidé de commencer par Proxmox parce qu’il est central dans le lab, et parce qu’un workflow de mise à jour progressive est un bon candidat pour l’automatisation.
+
+---
+## Les Outils Utilisés
+
+Le processus de mise à jour est construit autour de quelques composants que j’utilise déjà dans le lab.
+
+[Proxmox VE](https://www.proxmox.com/en/proxmox-virtual-environment/overview) est ma plateforme de virtualisation. Le cluster utilise aussi Ceph, donc avant de toucher à un nœud, je veux m’assurer que le cluster est en bonne santé et que Ceph remonte `HEALTH_OK`.
+
+[Ansible](https://docs.ansible.com/) est utilisé pour décrire le workflow de mise à jour sous forme de playbook.
+
+[Semaphore UI](https://semaphoreui.com/) est utilisé pour exécuter le playbook depuis une interface web et le planifier.
+
+[Ntfy](https://ntfy.sh/) est utilisé pour les notifications. Si les mises à jour sont planifiées, j’ai besoin de savoir quand quelque chose se passe, surtout si le cluster n’est pas prêt ou si une mise à jour échoue.
+
+---
+## Création d’un Topic Ntfy Dédié
+
+Avant de planifier quoi que ce soit, je voulais un canal de notification dédié au homelab.
+
+J’ai créé un topic `homelab` dans Ntfy et un utilisateur dédié nommé `semaphore` avec un accès en écriture seule à ce topic.
+
+```bash
+ntfy user add semaphore
+ntfy access semaphore homelab wo
+```
+
+L’idée est que Semaphore a uniquement besoin de publier des messages. Il n’a pas besoin d’un accès en lecture.
+
+J’ai aussi ajouté le topic sur mon téléphone mobile afin de pouvoir recevoir des notifications lorsque l’automatisation s’exécute.
+
+Dans Semaphore, j’ai créé un groupe de variables nommé `Ntfy Homelab` pour stocker les valeurs nécessaires aux playbooks :
+
+- `ntfy_url`
+- `ntfy_topic`
+- `ntfy_user`
+- `NTFY_PASSWORD`
+
+Le mot de passe est stocké comme variable d’environnement dans l’onglet `Secrets`.
+
+![Groupe de variables Semaphore utilisé pour stocker la configuration Ntfy des notifications du homelab](images/semaphore-ntfy-homelab-variables.png)
+
+---
+## Conception du Workflow de Mise à Jour Proxmox
+
+Pour Proxmox, je ne voulais pas d’un playbook qui exécute simplement `apt upgrade` sur tous les nœuds. À la place, il fait les actions suivantes :
+
+- Vérifier la santé du cluster
+- Arrêter et envoyer une notification Ntfy si le cluster n’est pas prêt
+- Pour chaque nœud, vérifier si des mises à jour sont disponibles, et si oui :
+  - Activer le mode maintenance
+  - Attendre que les LXC et les VM quittent le nœud
+  - Mettre à jour les paquets
+  - Désactiver le rééquilibrage Ceph
+  - Redémarrer le nœud
+  - Activer le rééquilibrage Ceph
+  - Désactiver le mode maintenance
+  - Attendre que Ceph soit en bonne santé
+- Envoyer un rapport Ntfy final
+
+Le playbook complet est disponible sur mon [dépôt Homelab](https://github.com/Vezpi/Homelab/blob/main/ansible/proxmox/update_proxmox.yml)
+
+---
+## Détails du Workflow
+
+Avant de démarrer la mise à jour progressive, le playbook vérifie :
+
+- Le quorum du cluster Proxmox
+- La santé de Ceph
+
+Si l’une de ces vérifications échoue, le playbook s’arrête et envoie une notification Ntfy au lieu d’essayer de continuer.
+
+```yaml
+- name: Verify cluster quorum
+  ansible.builtin.command: pvecm status
+  register: quorum_status
+  changed_when: false
+  failed_when: quorum_status.stdout is not search('Quorate:\\s*Yes')
+
+- name: Verify Ceph health
+  ansible.builtin.command: ceph health
+  register: ceph_health
+  changed_when: false
+  failed_when: "'HEALTH_OK' not in ceph_health.stdout"
+```
+
+C’est une partie importante de l’automatisation. Une mise à jour planifiée ne doit pas continuer aveuglément si le cluster n’est pas dans un bon état.
+
+Le playbook met à jour les nœuds Proxmox avec `serial: 1`.
+
+Cela signifie qu’un seul nœud est traité à la fois, ce qui est exactement ce que je veux pour une mise à jour de cluster.
+
+Pour chaque nœud, le playbook commence par rafraîchir les dépôts et vérifie si des mises à jour sont disponibles en utilisant le mode check d’Ansible.
+
+```yaml
+- name: Refresh repositories
+  ansible.builtin.apt:
+    update_cache: true
+
+- name: Check if updates are available
+  ansible.builtin.apt:
+    upgrade: dist
+  check_mode: true
+  register: apt_check
+```
+
+Si aucune mise à jour n’est disponible pour un nœud, la partie lourde du workflow est ignorée.
+
+Si des mises à jour sont disponibles, le playbook stocke la version actuelle de Proxmox, active le mode maintenance, attend que les invités quittent le nœud, applique les mises à jour, redémarre le nœud, puis attend que Ceph soit de nouveau en bonne santé.
+
+```yaml
+- name: Enable maintenance mode
+  ansible.builtin.command: >
+    ha-manager crm-command node-maintenance enable {{ inventory_hostname_short }}
+```
+
+Une fois le mode maintenance activé, le playbook attend qu’il ne reste plus aucun LXC en cours d’exécution sur le nœud :
+
+```yaml
+- name: Wait for LXCs to leave node
+  ansible.builtin.shell: |
+    pct list | awk 'NR>1 && $2=="running" {count++} END {print count+0}'
+  register: lxc_count
+  changed_when: false
+  until: lxc_count.stdout | int == 0
+  retries: 60
+  delay: 15
+```
+
+Il fait la même chose pour les VM en cours d’exécution :
+
+```yaml
+- name: Wait for VMs to leave node
+  ansible.builtin.shell: |
+    qm list | awk 'NR>1 && $3=="running" {count++} END {print count+0}'
+  register: vm_count
+  changed_when: false
+  until: vm_count.stdout | int == 0
+  retries: 60
+  delay: 15
+```
+
+Une fois que le nœud est vide, la mise à niveau des paquets peut s’exécuter :
+
+```yaml
+- name: Update packages
+  ansible.builtin.apt:
+    upgrade: full
+    autoremove: true
+    autoclean: true
+```
+
+Avant de redémarrer, le playbook définit `noout` sur les OSD Ceph :
+
+```yaml
+- name: Disable Ceph rebalancing
+  ansible.builtin.command: ceph osd set noout
+```
+
+Puis le nœud est redémarré :
+
+```yaml
+- name: Reboot node
+  ansible.builtin.reboot:
+    reboot_timeout: 900
+    post_reboot_delay: 30
+```
+
+Après le redémarrage, le rééquilibrage Ceph est réactivé, le mode maintenance est désactivé, et le playbook attend que Ceph revienne à `HEALTH_OK`.
+
+```yaml
+- name: Enable Ceph rebalancing
+  ansible.builtin.command: ceph osd unset noout
+
+- name: Disable maintenance mode
+  ansible.builtin.command: >
+    ha-manager crm-command node-maintenance disable {{ inventory_hostname_short }}
+
+- name: Wait for Ceph to be healthy
+  ansible.builtin.command: ceph health
+  register: ceph_status
+  changed_when: false
+  until: "'HEALTH_OK' in ceph_status.stdout"
+  retries: 60
+  delay: 15
+  delegate_to: "{{ groups['nodes'][0] }}"
+```
+
+Le résultat est une mise à jour progressive contrôlée au lieu d’une procédure manuelle nœud par nœud.
+
+---
+## Envoi d’un Rapport de Mise à Jour
+
+À la fin du workflow, le playbook envoie un rapport via Ntfy. Il détermine d’abord si au moins un nœud a été mis à jour :
+
+```yaml
+- name: Determine if updates occurred
+  ansible.builtin.set_fact:
+    updates_performed: "{{ groups['nodes'] | map('extract', hostvars) | selectattr('update_report', 'defined') | list | length > 0 }}"
+```
+
+Ensuite, il envoie un message au topic `homelab`.
+
+Si aucune mise à jour n’était disponible, la notification l’indique et utilise une priorité plus basse.
+
+Si des mises à jour ont été appliquées, la notification liste les nœuds mis à jour et affiche la version de Proxmox avant et après la mise à jour.
+
+La logique de rapport est basée sur le fact `update_report` sauvegardé pendant la mise à jour du nœud :
+
+```yaml
+- name: Save update report
+  ansible.builtin.set_fact:
+    update_report:
+      old: "{{ pve_old_version.stdout }}"
+      new: "{{ pve_new_version.stdout }}"
+```
+
+Le corps de la notification construit ensuite un résumé à partir de tous les nœuds :
+
+```yaml
+body: |
+  {% set updated_nodes = [] %}
+  {% for node in groups['nodes'] %}
+    {% if hostvars[node].update_report is defined %}
+      {% set _ = updated_nodes.append(node) %}
+    {% endif %}
+  {% endfor %}
+  {% if not updates_performed %}
+  No updates available on the cluster.
+  {% else %}
+  The following nodes were updated:
+  {% for node in updated_nodes %}
+  {% if hostvars[node].update_report.old == hostvars[node].update_report.new %}
+  - {{ hostvars[node].inventory_hostname_short }}: version {{ hostvars[node].update_report.old }} (unchanged)
+  {% else %}
+  - {{ hostvars[node].inventory_hostname_short }}: version {{ hostvars[node].update_report.old }} → {{ hostvars[node].update_report.new }}
+  {% endif %}
+  {% endfor %}
+  {% endif %}
+```
+
+Cela rend la tâche planifiée beaucoup plus facile à considérer comme fiable. Je n’ai pas besoin d’ouvrir Semaphore à chaque fois pour savoir ce qui s’est passé.
+
+---
+## Exécuter le Playbook depuis Semaphore
+
+Une fois le playbook prêt, je l’ai poussé dans le dépôt et j’ai configuré un modèle de tâche Semaphore pour l’exécuter.
+
+![Modèle de tâche Semaphore utilisé pour exécuter le playbook de mise à jour Proxmox](images/semaphore-playbook-update-proxmox-template.png)
+
+À partir de là, je pouvais lancer le workflow et le regarder agir sur le cluster.
+
+Pendant l’exécution, le nœud cible entre en mode maintenance et les workloads en cours d’exécution sont migrés hors de celui-ci.
+
+![Nœud Proxmox en mode maintenance pendant que le playbook de mise à jour migre les workloads hors du nœud](images/proxmox-update-playbook-maintenance.png)
+
+C’est à ce moment-là que l’automatisation devient vraiment utile. Le playbook n’applique pas seulement les mises à jour. Il prend aussi en charge les étapes opérationnelles autour de la mise à jour.
+
+---
+## Planification de la Mise à Jour
+
+Après avoir affiné le playbook et validé le workflow, j’ai créé une planification dans Semaphore.
+
+Dans `Schedule`, j’ai cliqué sur `New Schedule`, sélectionné `Cron`, donné un nom, sélectionné une planification hebdomadaire, puis choisi le vendredi à 4h00 UTC.
+
+![Planification hebdomadaire Semaphore pour le playbook de mise à jour Proxmox](images/semaphore-schedule-proxmox-update.png)
+
+À ce stade, le processus de mise à jour de Proxmox n’est plus quelque chose dont je dois me souvenir pour le faire manuellement.
+
+Il s’exécute selon une planification, vérifie l’état du cluster avant de faire quoi que ce soit, met à jour un nœud à la fois, et envoie une notification avec le résultat.
+
+---
+## Conclusion
+
+Ce projet est parti d’un problème simple : je ne mettais pas mon homelab à jour régulièrement parce que le processus était encore trop manuel.
+
+L’automatisation des mises à jour Proxmox était la première étape importante. La partie importante n’était pas seulement d’exécuter les mises à niveau de paquets, mais de les entourer des vérifications et des étapes opérationnelles qui ont du sens pour un cluster Proxmox avec Ceph.
+
+Semaphore me donne une façon propre d’exécuter et de planifier le playbook. Ansible décrit le processus de manière répétable. Ntfy boucle la boucle en me disant ce qui s’est passé.
+
+Les prochaines étapes logiques sont de continuer avec la même approche pour les autres composants clés du lab : OPNsense et TrueNAS.

content/post/20-automating-proxmox-update-ansible/index.md

@@ -0,0 +1,311 @@
+---
+slug: automating-proxmox-update-ansible
+title: Automating Proxmox VE Updates with Ansible
+description: Automate Proxmox VE cluster updates with Ansible, Semaphore UI and Ntfy, including Ceph checks, rolling reboots and reports.
+date: 2026-06-09
+draft: false
+tags:
+  - proxmox
+  - ansible
+  - semaphore-ui
+  - ntfy
+categories:
+  - homelab
+---
+## Intro
+
+In my homelab, updates are one of those things that are easy to postpone.
+
+Not because they are complicated, but because they are manual. I need to connect to the right system, check the state, apply the updates, reboot if needed, verify that everything comes back correctly, and then repeat the same process for the next component.
+
+And because it is manual, I usually keep it for later.
+
+When Proxmox VE 9.1 came out, I already wanted to update my cluster, but not manually. Then Proxmox VE 9.2 became available few days ago, and I still had not built a clean process around it. That was a good trigger to finally start automating updates for the important parts of my homelab.
+
+The larger goal is to simplify and automate patching for several key components:
+
+- Proxmox VE
+- OPNsense
+- TrueNAS
+
+I decided to start with Proxmox because it is central to the lab, and because a rolling update workflow is a good candidate for automation.
+
+---
+## The Tools Involved
+
+The update process is built around a few components I already use in the lab.
+
+[Proxmox VE](https://www.proxmox.com/en/proxmox-virtual-environment/overview) is my virtualization platform. The cluster also uses Ceph, so before touching a node, I want to make sure the cluster is healthy and that Ceph is reporting `HEALTH_OK`.
+
+[Ansible](https://docs.ansible.com/) is used to describe the update workflow as a playbook.
+
+[Semaphore UI](https://semaphoreui.com/) is used to run the playbook from a web interface and schedule it.
+
+[Ntfy](https://ntfy.sh/) is used for notifications. If updates are scheduled, I need to know when something happens, especially if the cluster is not ready or if an update fails.
+
+---
+## Creating a Dedicated Ntfy Topic
+
+Before scheduling anything, I wanted a notification channel dedicated to the homelab.
+
+I created a `homelab` topic in Ntfy and a dedicated user named `semaphore` with write-only access to this topic.
+
+```bash
+ntfy user add semaphore
+ntfy access semaphore homelab wo
+```
+
+The idea is that Semaphore only needs to publish messages. It does not need read access.
+
+I also added the topic on my mobile phone so I can receive notifications when the automation runs.
+
+In Semaphore, I created a variable group named `Ntfy Homelab` to store the values needed by the playbooks:
+
+- `ntfy_url`
+- `ntfy_topic`
+- `ntfy_user`
+- `NTFY_PASSWORD`
+
+The password is stored as an environment variable in the `Secrets` tab.
+
+![Semaphore variable group used to store the Ntfy configuration for homelab notifications](images/semaphore-ntfy-homelab-variables.png)
+
+---
+## Designing the Proxmox Update Workflow
+
+For Proxmox, I did not want a playbook that simply runs `apt upgrade` on all nodes. Instead, it doing the following:
+
+- Check cluster health
+- Stop and send a Ntfy notification if the cluster is not ready
+- For each node, check if updates are available, if so:
+  - Enable maintenance mode
+  - Wait for LXCs and VMs to leave the node
+  - Update packages
+  - Disable Ceph rebalancing
+  - Reboot the node
+  - Enable Ceph rebalancing
+  - Disable maintenance mode
+  - Wait for Ceph to be healthy
+- Send a final Ntfy report
+
+The full playbook is available on my [Homelab repo](https://github.com/Vezpi/Homelab/blob/main/ansible/proxmox/update_proxmox.yml)
+
+---
+## Workflow Details
+
+Before starting the rolling update, the playbook checks:
+
+- Proxmox cluster quorum
+- Ceph health
+
+If one of these checks fails, the playbook stops and sends a Ntfy notification instead of trying to continue.
+
+```yaml
+- name: Verify cluster quorum
+  ansible.builtin.command: pvecm status
+  register: quorum_status
+  changed_when: false
+  failed_when: quorum_status.stdout is not search('Quorate:\\s*Yes')
+
+- name: Verify Ceph health
+  ansible.builtin.command: ceph health
+  register: ceph_health
+  changed_when: false
+  failed_when: "'HEALTH_OK' not in ceph_health.stdout"
+```
+
+This is an important part of the automation. A scheduled update should not blindly continue if the cluster is not in a good state.
+
+The playbook updates the Proxmox nodes with `serial: 1`.
+
+That means only one node is handled at a time, which is exactly what I want for a cluster update.
+
+For each node, the playbook first refreshes the repositories and checks if updates are available using Ansible check mode.
+
+```yaml
+- name: Refresh repositories
+  ansible.builtin.apt:
+    update_cache: true
+
+- name: Check if updates are available
+  ansible.builtin.apt:
+    upgrade: dist
+  check_mode: true
+  register: apt_check
+```
+
+If no updates are available for a node, the heavy part of the workflow is skipped.
+
+If updates are available, the playbook stores the current Proxmox version, enables maintenance mode, waits for guests to leave the node, applies the updates, reboots the node, and then waits for Ceph to be healthy again.
+
+```yaml
+- name: Enable maintenance mode
+  ansible.builtin.command: >
+    ha-manager crm-command node-maintenance enable {{ inventory_hostname_short }}
+```
+
+After maintenance mode is enabled, the playbook waits until no running LXC remains on the node:
+
+```yaml
+- name: Wait for LXCs to leave node
+  ansible.builtin.shell: |
+    pct list | awk 'NR>1 && $2=="running" {count++} END {print count+0}'
+  register: lxc_count
+  changed_when: false
+  until: lxc_count.stdout | int == 0
+  retries: 60
+  delay: 15
+```
+
+It does the same for running VMs:
+
+```yaml
+- name: Wait for VMs to leave node
+  ansible.builtin.shell: |
+    qm list | awk 'NR>1 && $3=="running" {count++} END {print count+0}'
+  register: vm_count
+  changed_when: false
+  until: vm_count.stdout | int == 0
+  retries: 60
+  delay: 15
+```
+
+Once the node is empty, the package upgrade can run:
+
+```yaml
+- name: Update packages
+  ansible.builtin.apt:
+    upgrade: full
+    autoremove: true
+    autoclean: true
+```
+
+Before rebooting, the playbook sets Ceph OSD `noout`:
+
+```yaml
+- name: Disable Ceph rebalancing
+  ansible.builtin.command: ceph osd set noout
+```
+
+Then the node is rebooted:
+
+```yaml
+- name: Reboot node
+  ansible.builtin.reboot:
+    reboot_timeout: 900
+    post_reboot_delay: 30
+```
+
+After the reboot, Ceph rebalancing is enabled again, maintenance mode is disabled, and the playbook waits for Ceph to return to `HEALTH_OK`.
+
+```yaml
+- name: Enable Ceph rebalancing
+  ansible.builtin.command: ceph osd unset noout
+
+- name: Disable maintenance mode
+  ansible.builtin.command: >
+    ha-manager crm-command node-maintenance disable {{ inventory_hostname_short }}
+
+- name: Wait for Ceph to be healthy
+  ansible.builtin.command: ceph health
+  register: ceph_status
+  changed_when: false
+  until: "'HEALTH_OK' in ceph_status.stdout"
+  retries: 60
+  delay: 15
+  delegate_to: "{{ groups['nodes'][0] }}"
+```
+
+The result is a controlled rolling update instead of a manual node-by-node procedure.
+
+---
+## Sending an Update Report
+
+At the end of the workflow, the playbook sends a report through Ntfy. It first determines if at least one node was updated:
+
+```yaml
+- name: Determine if updates occurred
+  ansible.builtin.set_fact:
+    updates_performed: "{{ groups['nodes'] | map('extract', hostvars) | selectattr('update_report', 'defined') | list | length > 0 }}"
+```
+
+Then it sends a message to the `homelab` topic.
+
+If no updates were available, the notification says so and uses a lower priority.
+
+If updates were applied, the notification lists the updated nodes and shows the Proxmox version before and after the update.
+
+The report logic is based on the `update_report` fact saved during the node update:
+
+```yaml
+- name: Save update report
+  ansible.builtin.set_fact:
+    update_report:
+      old: "{{ pve_old_version.stdout }}"
+      new: "{{ pve_new_version.stdout }}"
+```
+
+The notification body then builds a summary from all nodes:
+
+```yaml
+body: |
+  {% set updated_nodes = [] %}
+  {% for node in groups['nodes'] %}
+    {% if hostvars[node].update_report is defined %}
+      {% set _ = updated_nodes.append(node) %}
+    {% endif %}
+  {% endfor %}
+  {% if not updates_performed %}
+  No updates available on the cluster.
+  {% else %}
+  The following nodes were updated:
+  {% for node in updated_nodes %}
+  {% if hostvars[node].update_report.old == hostvars[node].update_report.new %}
+  - {{ hostvars[node].inventory_hostname_short }}: version {{ hostvars[node].update_report.old }} (unchanged)
+  {% else %}
+  - {{ hostvars[node].inventory_hostname_short }}: version {{ hostvars[node].update_report.old }} → {{ hostvars[node].update_report.new }}
+  {% endif %}
+  {% endfor %}
+  {% endif %}
+```
+
+This makes the scheduled job much easier to trust. I do not need to open Semaphore every time to know what happened.
+
+---
+## Running the Playbook from Semaphore
+
+Once the playbook was ready, I pushed it to the repository and configured a Semaphore task template to run it.
+
+![Semaphore task template used to run the Proxmox update playbook](images/semaphore-playbook-update-proxmox-template.png)
+
+From there, I could launch the workflow and watch it act on the cluster.
+
+During execution, the target node enters maintenance mode and the running workloads are migrated away from it.
+
+![Proxmox node in maintenance mode while the update playbook migrates workloads away](images/proxmox-update-playbook-maintenance.png)
+
+This is the point where the automation becomes really useful. The playbook is not only applying updates. It is also taking care of the operational steps around the update.
+
+---
+## Scheduling the Update
+
+After refining the playbook and validating the workflow, I created a schedule in Semaphore.
+
+In `Schedule`, I clicked `New Schedule`, selected `Cron`, gave it a name, selected a weekly schedule, and picked Friday at 4:00 AM UTC.
+
+![Weekly Semaphore schedule for the Proxmox update playbook](images/semaphore-schedule-proxmox-update.png)
+
+At this point, the Proxmox update process is no longer something I need to remember to do manually.
+
+It runs on a schedule, checks the state of the cluster before doing anything, updates one node at a time, and sends a notification with the result.
+
+---
+## Conclusion
+
+This project started with a simple problem: I was not updating my homelab regularly because the process was still too manual.
+
+Automating Proxmox updates was the first milestone. The important part was not only running package upgrades, but wrapping them in the checks and operational steps that make sense for a Proxmox cluster with Ceph.
+
+Semaphore gives me a clean way to run and schedule the playbook. Ansible describes the process in a repeatable way. Ntfy closes the loop by telling me what happened.
+
+The next logical steps are to continue the same approach for the other key components of the lab: OPNsense and TrueNAS.

docker/entrypoint.sh

@@ -21,12 +21,6 @@ rm -rf "$CLONE_DIR"
 echo "- Cloning $REPO_URL (branch: $BRANCH)..."
 git clone --recurse-submodules --branch "$BRANCH" "$REPO_URL" "$CLONE_DIR"
 
-# Patch references not yet fixed in Stack theme
-sed -i 's/\.Site\.Data/hugo.Data/g' "$CLONE_DIR/themes/stack/layouts/_partials/article/components/photoswipe.html"
-sed -i 's/LanguageDirection/Direction/g' "$CLONE_DIR/themes/stack/layouts/baseof.html"
-sed -i 's/\.LanguageCode/.Language.Locale/g' "$CLONE_DIR/themes/stack/layouts/baseof.html"
-sed -i 's/\.LanguageCode/.Locale/g' "$CLONE_DIR/themes/stack/layouts/rss.xml"
-
 # Generate static files with hugo
 echo "- Building site with Hugo v$HUGO_VERSION in $HUGO_DEST..."
 hugo --source "$CLONE_DIR" --destination "$HUGO_DEST" --baseURL="https://${URL}" ${DRAFTS} --logLevel info --cleanDestinationDir --gc --panicOnWarning --printI18nWarnings

i18n/en.yaml

@@ -75,4 +75,9 @@ footer:
         other: " "
 
     designedBy:
-        other: " "
+        other: " "
+
+pagination:
+    jumpToPage: "Jump to page"
+    jump:  "Go"
+    pressEnter: "Press Enter to jump"

i18n/fr.yaml

@@ -74,4 +74,9 @@ footer:
         other: " "
 
     designedBy:
-        other: " "
+        other: " "
+
+pagination:
+    jumpToPage: "Aller à la page"
+    jump:  "Aller"
+    pressEnter: "Presser Entrée pour aller"