Depuis, j’ai avancé sur un point important : les sauvegardes. Mes VM et mes containers sont sauvegardés avec un Proxmox Backup Server (PBS) distant. C’est déjà très rassurant. Si un LXC se casse la figure, je peux le restaurer. Si une VM part en vrille après une mise à jour douteuse, pareil. Si c’est moi qui provoque une catastrophe (le plus probable, c’est souvent un problème interface-clavier :)), je peux rollback aussi.

Mais il me restait une question un peu moins confortable : et Proxmox lui-même ? Comment je restaure l’hôte ?

Parce que si le SSD de mon mini PC me lâche complètement, je peux réinstaller Proxmox, restaurer mes containers, et repartir. En théorie. Sauf qu’entre les deux, il y a tout ce que j’ai configuré sur l’hôte : le firewall, fail2ban, le durcissement SSH, les optimisations pour limiter les écritures sur le SSD, les jobs de backup, les services désactivés parce qu’ils ne me servent à rien…

Bref, tout ce que l’on fait une fois juste après l’installation de Proxmox et que l’on oublie ensuite. Jusqu’au jour où il faut le refaire. Et là, on se retrouve à lâcher un “oh merde” et plus si affinités avec les noms d’oiseaux.

Le vrai problème : reconstruire la configuration

Dans mon cas, on parle d’un homelab personnel. Je n’ai ni baie de stockage, serveurs en cluster, ou redondance des disque. J’ai un simple mini PC, un SSD, des backups, et néanmoins l’envie de dormir tranquille sans transformer mon salon en datacenter.

Le scénario qui m’intéresse est donc assez simple : si demain je dois repartir d’une installation Proxmox propre, comment je reconstruis ma configuration sans passer une soirée à cliquer partout dans l’interface web et à relire mes propres notes ? (si elles existent, et si elles sont à jour)

J’ai d’abord pensé à des solutions assez naturelles. Versionner quelques fichiers de configuration dans Git. Sauvegarder tout /etc/pve. Écrire des scripts shell pour rejouer certaines étapes. Toutes ces pistes peuvent marcher, mais elles me semblaient vite fragiles ou incomplètes.

Versionner /etc/pve, par exemple, donne une photo intéressante de l’état de l’hôte Proxmox, mais ce n’est pas forcément une recette de reconstruction. Un fichier de configuration n’explique pas toujours dans quel ordre appliquer les choses, ni quels paquets installer, ni quels services relancer. Et un script shell peut vite devenir une suite de commandes qui marche le jour où on l’écrit, puis que l’on n’ose plus toucher six mois plus tard.

En fouillant un peu, je suis retombé sur Ansible. Je connaissais de loin, sans l’avoir vraiment utilisé. Ça ressemblait exactement à ce qu’il me fallait : décrire l’état souhaité de mon serveur, versionner cette description, puis pouvoir la rejouer quand j’en ai besoin. Bon. On va commencer à joeur avec.

Ce qu’Ansible m’apporte dans un homelab

Ansible sert à automatiser la configuration et l’administration de machines. On écrit des fichiers YAML qui décrivent des tâches : installer un paquet, copier un fichier, créer un utilisateur, modifier une configuration, démarrer un service, lancer une commande, etc.

La force, ce n’est pas seulement d’automatiser. Des scripts peuvent déjà le faire. Ce qui m’intéresse surtout, c’est l’idée d’idempotence.

Dit simplement, une tâche idempotente peut être exécutée plusieurs fois sans empiler les effets de bord. Si je dis à Ansible “le paquet fail2ban doit être installé”, il ne va pas tenter de l’installer encore et encore comme si c’était la première fois. Il vérifie l’état actuel, puis agit seulement si nécessaire. Si je dis “ce fichier doit contenir cette configuration”, il peut détecter s’il y a un changement à appliquer.

C’est bête, mais ça change beaucoup de choses. Je peux relancer mon playbook après une petite modification sans avoir peur de casser tout le reste. Je peux faire évoluer ma configuration par morceaux. Je peux relire l’historique Git pour comprendre pourquoi j’ai changé une règle de firewall ou modifié une option SSH. Et surtout, je peux relancer l’ensemble si je dois reconstruire mon serveur de zéro. Et ça, c’est génial.

Pour un homelab, c’est très confortable. On bidouille, on apprend, on teste. Mais à force de petits changements, le serveur finit par contenir beaucoup de décisions implicites. Ansible m’aide à les rendre explicites et les versionner.

Ce que j’ai commencé à versionner

Mon objectif n’était pas de faire “du Ansible pour faire du Ansible”. Je voulais d’abord couvrir les réglages que je n’avais pas envie de refaire à la main en cas de réinstallation.

J’ai donc commencé par la base Proxmox : les règles firewall, les IP sets, les security groups, la configuration des backups, le stockage PBS distant, les paquets installés sur l’hôte, les services à activer ou désactiver. J’ai aussi ajouté des réglages autour de la sécurité : fail2ban, SSH, nouvel utilisateur d’administration, certaines permissions.

Ensuite, j’ai ajouté les optimisations que j’avais déjà identifiées pour mon mini PC. Par exemple la configuration de journald et rrdcached pour réduire les écritures inutiles, la désactivation de services dont je n’ai pas besoin dans mon contexte comme la haute disponibilité, le bluetooth, le wifi, etc.

J’ai de plus en plus aimé Ansible, alors j’ai continué en m’intéressant à l’intérieur des containers LXC / VM. Oui, ils sont normalement “protégés des catastrophes” grâce aux backups sur PBS. Mais prenons un cas d’usage concret qui arrive souvent : la modification d’un fichier de conf. Qui a envie de faire un rollback de tout le container juste pour revenir en arrière sur ce fichier ? Moi, clairement pas. C’est pour cela que j’avais d’ailleurs commencé à utiliser git pour annuler rapidement une erreur Home Assistant.

Le petit bonus que j’ai trouvé en cours de route, c’est que je ne suis même pas obligé d’ouvrir le SSH sur chaque container si je ne veux pas : je peux indiquer à Ansible de passer par l’hôte Proxmox et utiliser pct pour agir dans le container. Mon petit côté parano sur la sécurité aime bien ça.

Reconstruire, maintenir, lancer des tâches

Au départ, je pensais surtout “plan post-apocalyptique” : le SSD meurt, je réinstalle Proxmox, je lance Ansible, puis je restaure mes VM et LXC depuis PBS. C’est déjà une très bonne raison de faire l’effort. Mais à l’usage, j’ai découvert des intérêts qui vont au-delà. Ansible devient aussi mon outil du quotidien.

Si je veux modifier la configuration de Caddy, je la modifie dans Ansible, je l’applique sur mon serveur et je versionne. Quand je veux ajouter une règle sur le firewall, même chose. Dans la plupart des cas, je n’agis plus directement sur le serveur ou sur l’interface.

Et puis, il y a le côté tâches que j’aime bien avec Ansible. Quand je modifie la configuration d’un service, il faut souvent le redémarrer pour que la modification soit prise en compte. Avec Ansible, c’est facile et intelligent : la configuration sera copiée puis le service sera redémarré uniquement s’il y a une différence entre la nouvelle et ancienne configuration (vous vous souvenez, l’idempotence).

Un autre cas d’usage que j’aime bien, je démarre et arrête des services via Ansible. C’est agréable. Une seule commande me suffit pour lancer un playbook Ansible plutôt que de passer par l’interface et le terminal pour démarrer un LXC, attendre qu’il soit prêt, lancer un container docker puis lancer un second container qui dépend du premier.

À quoi ça ressemble concrètement ?

Un playbook Ansible est une suite de tâches. Pour donner une idée, voici un exemple simple :

---
- name: Configurer la base de mon hote Proxmox
  hosts: proxmox
  become: true

  tasks:
    - name: Installer fail2ban
      ansible.builtin.apt:
        name: fail2ban
        state: present
        update_cache: true

    - name: Copier la configuration SSH
      ansible.builtin.copy:
        src: files/sshd_config
        dest: /etc/ssh/sshd_config
        owner: root
        group: root
        mode: "0644"
      notify: Redemarrer ssh

    - name: S'assurer que fail2ban est actif
      ansible.builtin.service:
        name: fail2ban
        state: started
        enabled: true

  handlers:
    - name: Redemarrer ssh
      ansible.builtin.service:
        name: ssh
        state: restarted

On lit ça presque comme une checklist : installer fail2ban, copier la configuration SSH, vérifier que le service tourne. Le handler permet de redémarrer SSH uniquement si le fichier de configuration a changé. C’est le genre de détail qui évite de faire des actions inutiles.

J’ai petit à petit créé des playbook pour chaque sujet. J’ai essayé de garder une logique modulaire et unitaire : règles firewall (par container), SSH, backups, optimisations, paquets, containers, services. Ça rend l’ensemble plus facile à relire et à faire évoluer. Si demain je veux modifier uniquement Caddy ou ajouter une règle firewall, je sais où aller. Si j’ai besoin d’utiliser un playbook au sein d’un autre, je peux.

Il existe aussi des collections Ansible, c’est-à-dire des ensembles de modules qui apportent de nouvelles fonctionnalités pour nos playbook. J’ai notamment regardé la collection community.proxmox, qui ajoute des possibilités orientées Proxmox. C’est pratique pour éviter de tout piloter à coup de commandes shell, en particulier sur des sujets comme le firewall où ça m’a bien aidé.

Et on peut aller plus loin. Ansible propose par exemple un système de variable glboale ou par host, des variables chiffrés grâce à Ansible Vault, l’affichage d’informations, l’exécution d’étapes conditionnés à un résultat précédant, un input de l’utilisateur, etc.

Pourquoi pas Terraform ?

Pendant mes recherches, je suis aussi retombé sur Terraform. Les deux outils sont souvent cités ensemble et ils peuvent être complémentaires. Terraform est très fort pour provisionner de l’infrastructure : déclarer des ressources, créer des machines, gérer leur cycle de vie. Ansible est plutôt orienté configuration : installer, modifier, maintenir ce qui tourne sur les machines.

Sur un setup plus ambitieux, un combo Terraform + Ansible pourrait avoir du sens. Terraform pour créer les VM/LXC, Ansible pour les configurer ensuite.

Dans mon cas, ça me semblait trop. J’ai un mini PC, quelques services, et surtout un besoin d’apprendre sans empiler les couches trop vite. Terraform aurait ajouté un outil, un état à gérer, une logique supplémentaire. Pour l’instant, Ansible couvre très bien mon besoin.

C’est aussi une décision importante dans un homelab : accepter de ne pas reproduire une infrastructure d’entreprise miniature ou d’ajouter de la complexité inutile. Sauf si l’objectif est d’apprendre Terraform, évidemment, le homelab reste un bon terrain d’expérimentation.

Bref

J’ai commencé à utiliser Ansible pour une raison très concrète : je ne voulais pas que la configuration de mon hôte Proxmox repose uniquement sur ma mémoire, quelques notes, et l’espoir que rien ne casse.

Mes VM et mes LXC sont sauvegardés avec PBS, mais ça ne suffit pas à reconstruire proprement tout le contexte autour. Le firewall, fail2ban, les optimisations, les jobs de backup, … tout ça fait partie de mon serveur. Ansible me permet de transformer cette configuration en quelque chose de versionné, rejouable et progressivement améliorable.

Pour mon usage, c’est un bon compromis : assez simple à prendre en main, assez puissant pour éviter les scripts fragiles, et suffisamment lisible pour que mon futur moi le comprenne toujours.

Et finalement, c’est peut-être ça le vrai bénéfice : préparer la panne, oui, mais surtout rendre la maintenance quotidienne plus facile. La réinstallation complète arrivera peut-être un jour. En attendant, chaque petite évolution devient une occasion de laisser une trace claire.

Mais dans la pratique, quand on bidouille Home Assistant, on touche souvent plein de fichiers YAML. Une automation par ici, un script par-là, un template capteur, un package custom… et parfois on casse quelque chose.

Le backup complet est utile en cas de gros incident, mais pour “annuler juste cette modif de fichier”, c’est un peu l’équivalent de sortir un char d’assaut. C’est exactement là où Git devient très pratique : versionner finement la configuration, commit par commit, et revenir en arrière sans avoir à rollback la totalité de la VM via un backup.

Backup VM et versionning fichier : ce n’est pas le même besoin

Le backup Proxmox protège bien l’infrastructure : panne, corruption, catastrophe, migration. D’ailleurs, je parle du backup de Proxmox, mais ce serait la même chose pour quelqu’un qui ferait ses backups via Home Assistant directement.

Git, lui, protège le quotidien :

• “J’ai modifié sensors.yaml, maintenant plus rien ne se déclenche.”
• “Mon nouveau template Jinja passe, mais le résultat est faux.”
• “J’ai testé une config vite fait, je veux revenir à l’état d’hier.”

Dans ces cas-là, restaurer une sauvegarde complète est disproportionné. Avec Git, on peut juste comparer, annuler ou restaurer les fichiers concernés.

Les deux se complètent très bien : backup global + historique précis des changements.

Quoi versionner dans Home Assistant (et quoi ignorer)

De mon côté, je versionne surtout les fichiers de configuration “métier” :

• configuration.yaml
• automations.yaml
• scripts.yaml
• scenes.yaml
• le dossier packages customs
• le dossier templates customs

Et j’exclus le reste quand ce n’est pas utile à versionner :

• secrets
• bases de données
• logs
• fichiers temporaires/cache

C’est le moment où il faut être un peu plus rigoureux pour éviter des problèmes futurs. L’idée est simple : garder un repo propre, lisible, utile pour revenir en arrière rapidement.

Deux règles simples :

1. Ne jamais versionner les secrets (secrets.yaml, tokens, credentials, etc.).
2. Exclure les fichiers volumineux ou très verbeux (DB, logs, temporaires).

De toute manière, avant chaque commit, je vérifie les fichiers qui vont être versionnés. S’il y en a un nouveau qui passe au travers de mon gitignore, je modifie mes règles pour l’exclure.

Mise en place : workflow simple et efficace

Je reste volontairement sur un setup simple, sans sur-ingénierie.

Ajouter l’addon Studio Code Server

Sur Home Assistant, j’installe l’addon Studio Code Server. Il apporte un environnement pratique pour éditer les fichiers de config (c’est mieux que File Editor), et en plus, il permet d’avoir accès à Git et au terminal.

Générer une clé SSH depuis Home Assistant

Depuis le terminal de l’addon, je génère une clé SSH dédiée à ce besoin. L’objectif : permettre à Home Assistant de pull et push vers GitHub sans mot de passe.

Créer le repository GitHub

Je crée un repo, a priori privé. Ensuite, dans les settings du repo, j’ajoute la clé publique de Home Assistant dans Deploy keys.

Pourquoi une deploy key plutôt qu’une clé perso classique ? Parce que ça limite l’accès à ce seul repo. C’est plus propre et plus sécurisé que d’ouvrir l’accès à tout mon compte. Technique du moindre privilège !

Initialiser Git dans le dossier de configuration

Dans le dossier de config Home Assistant (souvent /config), j’initialise le repo et je lie le remote :

git init
git remote add origin git@github.com:UTILISATEUR/NOM_DU_REPO.git
git fetch origin
git checkout -b main origin/main || git checkout -b main
git add .
git commit -m "Add: initial configuration"
git push -u origin main

Le checkout avec fallback permet de gérer les deux cas :

• repo déjà initialisé avec un commit (README, .gitignore, etc.)
• repo vide

Utilisation au quotidien

Maintenant que tout ça est en place, mon flux est très simple :

1. Je modifie une automation ou un script.
2. Je teste dans Home Assistant.
3. Si c’est bon : git add, git commit, git push.
4. Si ça casse : je regarde le diff, je corrige, je discard.

Je passe d’un mode “je croise les doigts” à un mode “je peux expérimenter sans peur”. Et c’est souvent là que ça change tout : on ose mieux itérer, parce qu’on sait revenir proprement.

Bref

Si tu as déjà des backups Proxmox, tu as une très bonne base. Mais pour le quotidien Home Assistant, Git apporte une finesse que le backup VM ne donne pas. Pas besoin d’une grosse usine : un repo, une clé SSH, un .gitignore et des commits réguliers.

La vraie question devient ensuite “comment faire évoluer sereinement sa maison dans le temps ?” plutôt que de perdre du temps à retrouver des configurations qui marchaient avant :)

La sécurité pour dormir tranquillement sur mes deux oreilles (ou une seule si on dort de côté :)), la longévité pour que le matériel souffle un maximum de bougies et que le serveur reste stable, et la sobriété pour diminuer autant que possible l’énergie consommée.

C’est autour de ces trois piliers que j’ai construits ma feuille de route « Post Install Proxmox ». Je la partage, et je détaillerais certaines parties dans des futurs articles dédiés.

La sécurité

Contre l’intrusion, des remparts tu dresseras. — Yoda, maître DevSecOps dans une galaxie lointaine.

Je n’ai pas envie de m’inquiéter alors que mon serveur va tourner potentiellement 24 heures sur 24 et sans ma présence. Je veux minimiser le risque et la surface d’attaque. Pour cela, je vais appliquer plusieurs principes de sécurité :

• Le moindre privilège. Par défaut, aucun droit. Je donne le minimum nécessaire.
• Le zero trust. Par défaut, pas de confiance. Même si ça vient de l’intérieur (réseau local), je veux authentifier.
• La multiplication des couches de défense. Rien n’est infaillible. Je veux plusieurs niveaux de sécurité.

Mettre à jour Proxmox

Tout d’abord, on maintient à jour nos outils et Proxmox ne déroge pas à la règle. Je vais le faire tout de suite après l’installation. Pour la première fois, c’est un peu particulier et je m’appuie sur un script de la communauté.

Pourquoi un script ? Pour effectuer au passage quelques configurations nécessaires. Je veux par exemple désactiver le support entreprise et des services comme la haute disponibilité et ceph qui ne me sont pas utile pour mon serveur single-code.

Ce script vient d’un site communautaire et on peut en trouver un tas d’autres pour ajouter facilement des containers ou addon, faites-y un tour ! Pour notre cas, on a simplement à taper une commande et se laisser guider par les questions :

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"

S’il y a une erreur sur les repositories, on peut regarder la documentation pour modifier un fichier de configuration à la main.

Note : Attention avec les scripts, on ne fait pas confiance aveuglément. On regarde d’où ça vient, on regarde le code.

Microcode Update

Un processeur aussi se met à jour, même si c’est souvent transparent avec des systèmes plus friendly. Les mises à jour nous intéressent car elles corrigent des bugs, améliorent la performance et la sécurité. Avec mon N100, il faut regarder du côté de Intel. On peut aussi passer par un script de la communauté qui gère Intel et AMD.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/microcode.sh)"

Firewall

Le pare-feu est essentiel pour fermer un maximum de porte d’entrées. Je vais l’activer pour commencer, puis mettre une politique Input DROP par défaut - rien n’est autorisé à entrer, le DROP étant au passage silencieux (le demandeur aura un timeout, mais il ne sait pas si c’est parce qu’il n’y a personne ou s’il est rejeté).

J’ai cependant besoin du port 22 pour SSH et du port 8006 pour accéder à l’interface Web de Proxmox. Ces deux ports sont sensibles, ils correspondent à de l’admin. Je vais les ouvrir mais avec des restrictions sur les IPs : je veux uniquement mon réseau local, j’ai même envie de pousser plus loin, je vais restreindre uniquement à l’IP de mon ordinateur personnel.

Ce sera la même logique pour les autres services, c’est fermé par défaut et s’ils ont besoin d’ouvrir des ports, ce sera sur mon réseau local voire limité à certains appareils. Il y a d’ailleurs très peu de chance que j’ouvre à l’extérieur (à internet) un port, ce sera vraiment si le monde extérieur a besoin d’y accéder.

Si c’est seulement moi ou mon foyer qui veut accéder depuis l’extérieur, je privilégierai des solutions plus sécurisées qui ne nécessite pas d’ouvrir des ports. Par exemple, tailscale que l’on verra ensemble juste après.

Attention, il faut ajouter les règles pour autoriser nos IPs sur les ports concernés avant d’activer le firewall global, sinon on peut risquer de se retrouver bloquer à l’extérieur. (Proxmox empêche normalement cela en local, mais on ne sait jamais, et on n’est pas à l’abri que cela change sur une future version).

Au passage, je parlais du pare-feu de Proxmox mais je vérifie aussi comment est configuré ma box FAI : j’active le firewall si ce n’est pas le cas, et je n’ouvre a priori aucun port.

Second admin

À cette étape, il y a déjà un utilisateur qui existe sur Proxmox et sur l’environnement Linux : root. Je pourrais tout faire avec, sans problème, mais je vais tout de même créer un second utilisateur que j’utiliserais pour me connecter plutôt que de passer par root. Attention, il faut le faire sur Proxmox ET sur le système, puis donner les privilèges.

D’un point de vue sécurité, on s’ajoute une barrière. L’utilisateur root a les pleins pouvoirs, on peut faire une mauvaise manipulation sans le vouloir ou exécuter un script malveillant. En passant par un autre utilisateur, on sera obligé d’élever explicitement les privilèges (sudo) lorsqu’il y en a besoin. On sera donc plus conscient de nos actions. Chaque élévation de privilège est en plus inscrit dans les logs, on pourra tracer.

On va aussi pouvoir mieux se protéger des tentatives d’intrusions extérieurs. Cet utilisateur est connu de tous, on pourra lui interdire l’accès SSH. Notre second admin, lui est inconnu. Il faudra trouver le couple username + pwd. Tant qu’à faire, je prendrais au passage un username qu’on ne peut pas déduire en me connaissant.

L’authentification multifacteur

Un mot de passe, c’est bien. J’ai d’ailleurs opté pour des mots de passe avec une très grande entropie. (Les password de longueur 8 avec caractères spéciaux, chiffres, maj/min, c’est nul)

Une authentification à multiples facteurs, c’est encore mieux. Proxmox propose nativement depuis son interface la possibilité d’activer le 2FA sur un utilisateur. Je vais le faire tout de suite, pour root et mon second admin.

Durcir le SSH

Le SSH, c’est très puissant et donc très dangereux si quelqu’un arrive à se connecter avec, il peut arriver à prendre le contrôle de notre machine. C’est aussi la porte d’entrée principale vers notre serveur, et il doit y avoir d’innombrable robots qui scannent internet en continu pour se connecter via SSH à des machines. Ça me semble vitale de durcir les règles et de ne pas me reposer sur celles générées par défaut.

Je ne veux pas de connexion via l’utilisateur root et je veux forcer l’utilisation des clés SSH (désactivation de l’authentification par password), par exemple. Changer le port par défaut (22) est une option à envisager pour rendre la tâche un peu plus difficile.

Bannir automatiquement des IPs

Je commence à avoir plusieurs couches de sécurité, c’est bien. Pour autant, je n’empêche pas un bourrin de toquer en continu à mes portes avec des scripts automatiques ou des robots. C’est là qu’un système de bannissement par IP pourrait être intéressant.

S’il y a plusieurs échecs de connexions, je veux empêcher cette personne de recommencer. Fail2ban est très efficace pour cela. Je l’installe avec apt install fail2ban et je configure les prisons pour protéger mes services sshd et proxmox.

Le piège de l’IPV6

J’ai grandi avec un Internet qui avait des IPV4 (et aussi des modem bruyants, mais ça c’est autre chose :)). Nos box FAI avaient un bouclier, le NAT, pour rendre par défaut nos appareils inaccessibles depuis le monde extérieur. Aujourd’hui, on a de l’IPV6 et nos box peuvent en attribuer à nos machines… et celles-ci peuvent être publiques.

Dit plus explicitement, tout internet peut venir parler directement à une machine ayant une adresse IPV6 publique. Il y a largement assez d’adresse pour attribuer une IPV6 à chaque PC, objets connectés, ou tout autre appareil en ayant besoin.

Pour réduire la surface d’attaque et l’exposition, je coupe l’IPV6 sur mon serveur. Je ne l’activerais que si nécessaire, voire uniquement pour la/les machines virtuelles qui en auraient besoin.

Accès à distance sécurisé

Avec toutes mes configurations actuelles, j’ai mis énormément de barrières pour empêcher un accès depuis l’extérieur. Mais si je veux moi-même y accéder sans être sur mon réseau local ? Premièrement, j’y réfléchirai. Je me dis que l’administration de mon serveur est plutôt une tâche que je ferais de chez moi, donc sur mon réseau local.

Mais si j’ai quand même envie de le faire ? Ou si j’ai envie d’accéder à des services depuis l’extérieur ? Comme Home Assistant pour la domotique, ça pourrait faire sens. Historiquement, on ouvrait des ports sur notre box, mais ce n’est pas l’option la plus sécurisée aujourd’hui.

Je vais préférer passer par Tailscale qui ne nécessite aucune ouverture de port et ne rends pas mon serveur davantage sur internet. Je l’installe dans un container LXC si je veux isoler au maximum, ou directement sur l’hôte.

J’ai vu aussi qu’il y avait la possibilité de configurer un serveur WireGuard sur certaines box FAI, ça me semble être une alternative intéressante pour accéder à notre réseau local de manière sécurisée et sans augmenter la visibilité de notre serveur.

nginx reverse proxy

Quand on commence à avoir plusieurs services et qu’on a envie de partager l’accès à ses proches, l’ajout d’un reverse proxy est une option intéressante. On pourra avoir des adresses nommées, mais surtout, on aura une seule porte d’entrée et un seul port ouvert. Elle sera d’ailleurs sécurisée même si les services derrière ne le sont pas.

On peut également en profiter pour ajouter des règles globales (c’est notre point d’entrée, donc tous les services en profiteront) comme forcer le HTTPS et le 2FA partout. Un autre avantage : on cache l’architecture de notre serveur. On voit d’abord nginx, sans savoir ce qu’il y a derrière.

Certificat valide

L’alerte « Votre connexion n’est pas privée / sécurisée » que le navigateur affiche quand on accède à l’interface web, c’est chiant non ? Oui, et ce n’est pas qu’esthétique.

J’ai envie d’ajouter un certificat valide pour garantir une connexion chiffrée entre mon navigateur et le service. On aura la capacité de voir s’il y a une tentative d’attaque de type « Man-in-the-Middle », et puis, ce n’est pas très bon de s’habituer à ignorer des alertes de sécurité :)

Plusieurs options en fonction de notre configuration : via Let’s Encrypt avec un nom de domaine, via le reverse proxy, ou via Tailscale MagicDNS.

VLAN

Je n’ai pas la même confiance et la même exposition entre tous mes services et appareils (ex: mon PC, un service ouvert sur internet, ma console, des objets connectés, ….). Je ne veux pas qu’un appareil compromis sur mon réseau local puisse accéder à tout le reste de mon réseau.

En fonction de cette configuration d’appareils/services, je peux avoir envie de compartimenter au niveau du réseau en créant plusieurs VLANs. Par exemple, un VLAN IOT pour les objets connectés qui ont besoin d’accéder à leur cloud propriétaire douteux / auquel on a peu de confiance. Un VLAN pour les appareils sensibles. Un autre VLAN pour les services exposés sur internet, qui ne pourront pas rebondir sur les appareils sensibles s’il y a une intrusion.

La longévité

Un serveur n’est jamais en retard, ni en avance d’ailleurs. Il est toujours là quand on a besoin de lui. — Gandalf le Gris, mage du temps depuis 1970.

J’ai envie que mon serveur dure le plus longtemps possible. D’une part en chouchoutant le plus possible chaque composant matériel pour allonger sa durée de vie ; je veux donc limiter au mieux l’usure. Et d’autre part en réglant les problèmes avant que le serveur ne tombe pour maximiser son uptime ; je veux donc être prévenu avant que les catastrophes arrivent.

Le SSD est le maillon faible de notre serveur. C’est le composant qui peut s’user le plus vite et sur lequel on peut drastiquement réduire ou accélérer la chute. Pire encore si le stockage se fait sur une clé USB ou une carte SD (Raspberry Pi). Avec Proxmox et nos services, on va potentiellement écrire très fréquemment. C’est pour cela que la plupart de mes points ci-dessous se concentrent sur la réduction d’écriture.

Faire tampon avec la RAM

Certains services et particulièrement les logs vont écrire très fréquemment de toutes petites données sur le SSD. J’ai envie de préserver mon disque en regroupant ces données dans de plus gros paquets en mémoire (une sorte de tampon / buffer) pour les écrire plus tard en une fois. On pourrait imaginer écrire toutes les heures ou toutes les six heures par exemple.

Attention à un effet de bord : s’il y a une coupure de courant brutale, les logs en tampon seront perdus. Il faut l’avoir en tête quand on choisit cette option et la fréquence d’écriture du tampon.

Certains services peuvent être configurés nativement pour faire tampon, comme RRDCached pour les graphiques/statistiques de Proxmox. Et pour ceux qui ne proposent pas cette possibilité, on peut se servir de tmpfs, Log2Ram, ou Folder2Ram. On peut aller encore plus loin en regardant du côté du paramètre commit sur /etc/fstab.

Diminuer la quantité de logs

En plus de les grouper par paquets, on peut aussi tout simplement réduire les logs à écrire. Certains ne m’intéressent pas (comme High Availability et Corosync, potentiellement aussi le datetime des accès fichier avec noatime / relatime dans /etc/fstab), je vais donc simplement les désactiver. D’autres sont utiles mais trop bavards, je peux adapter la verbosité pour garder uniquement l’essentiel (journald, fail2ban, smartd, …).

Je peux aussi diminuer la profondeur de l’historique en ne gardant par exemple que 7 jours plutôt que 30. Sur journald, on a deux paramètres intéressants : la durée max et la taille max.

SWAP

Un système peut utiliser de l’espace sur le disque lorsqu’il n’y a pas assez de RAM disponible. En fonction de notre quantité de RAM et de l’usage de notre PC, on peut configurer à quel point le système va recourir au SWAP. De mon côté, j’ai envie de limiter au maximum son usage pour préserver le SSD, sachant que j’ai 16Go de RAM et très peu de services, eux-mêmes souvent en IDLE.

On peut régler ça avec le paramètre swappiness (agressivité du SWAP) dans /etc/sysctl.conf. C’est souvent à 60 par défaut, je peux le diminuer à 10 pour fortement limiter le SWAP. Il est conseillé de ne pas totalement couper le SWAP si on veut éviter un plantage (ex: un pic de consommation de RAM par une VM).

Compresser la RAM

Et si on n’est parfois court en RAM et qu’on veut éviter le SWAP (ou en supplément) ? On peut installer et configurer zRam pour compresser une portion de notre RAM. C’est intéressant car avec un bon processeur, c’est toujours plus rapide que du SWAP sur SSD, et ça évite des écritures.

A priori, je n’en ai pas besoin avec mon contexte, tout comme le SWAP. Mais c’est une option intéressante à avoir en tête.

TRIM

C’est normalement actif par défaut, mais autant en être sûr. Je vais vérifier que le service TRIM est bien actif sur Proxmox afin de faire le ménage sur les blocs à supprimer. Attention à également bien rendre possible le TRIM dans les options de disque de chaque future VM (option discard pour que l’ordre de nettoyage soit bien transmis à l’hôte).

Déporter vers un autre disque

Je parle beaucoup d’écriture sur le SSD depuis le début, mais ce n’est pas obligatoire. On peut avoir un second disque interne (SSD ou HDD), ou un disque externe en USB, ou même du stockage distant type NAS ou cloud. Et pourquoi pas un mix de tout ça.

Avec ce type de configuration, j’ai envie de préserver mon SSD principal qui contient le système en déportant des données de type logs, stats et backups sur un autre disque. Ce qui ne m’empêche pas d’optimiser les écritures de ses autres disques ; c’est complémentaire.

Monitoring température

Quittons l’univers des SSD pour aller vers le processeur, un autre composant que l’on peut préserver. Son ennemi principal est la température, ou plus précisément, une température trop élevée ; chaque processeur ayant ses propres limites. J’ai envie de surveiller cette valeur pour agir avant que le composant n’encaisse trop.

Ce n’est pas visible par défaut sur Proxmox, je vais donc installer lm-sensors pour obtenir des informations sur la température, et ajouter des valeurs dans un graphique pour suivre l’évolution dans le temps.

Et si jamais la température est trop élevée ? Je vais vérifier s’il y a un usage trop intensif, si le ventilateur tourne assez vite et assez tôt, s’il est temps de dépoussiérer l’intérieur du boîtier, et si un changement de pâte thermique devient nécessaire.

Alertes

Autant d’un point de vue de la longévité (matériel et uptime) que de la sécurité, j’ai envie d’être alerté s’il y a un problème (et même avant qu’il y ait ce problème lorsque c’est possible). Je ne serai pas toujours devant la page du dashboard, ni devant les logs. Je préfère être automatiquement prévenu.

Proxmox, propose un système d’alertes par envoi d’emails ou par notifications (via Gotify par exemple, ou webhooks) pour certains événements critiques (échec de sauvegarde, santé des disques, saturation d’espace, …). Si j’ai envie d’avoir d’autres alertes, je devrais regarder du côté du service concerné (ex: Fail2Ban le propose) ou créer moi-même un cron pour surveiller un événement (ex: la température).

Backups

Une catastrophe arrivera forcément un jour, c’est impossible de l’éviter. Il me faut donc une stratégie de récupération des données pour ce jour là. Je n’ai pas envie de tout recommencer à la main si mon disque principal rend l’âme. J’ai donc envie d’avoir une sauvegarde de l’hôte (la configuration même de Proxmox), et des containers/VMs.

Pour l’hôte, il est recommandé de sauvegarder les fichiers de configuration et refaire une installation propre. Pour les containers/VMs, on a deux solutions : créer des archives compressées ou utiliser Proxmox Backup Server qui a l’avantage de générer des sauvegardes incrémentielles.

Pour être serein sur le stockage des backups, on peut s’appuyer sur la stratégie « 3-2-1 » : 3 backups, sur 2 supports différents, dont 1 hors de chez nous.

Redémarrer après une coupure de courant

Un dernier élément sur la longévité, pour garantir un meilleur uptime sans intervention manuelle. Il peut y avoir des coupures d’électricité chez soi, et plus fréquemment des micros coupures. Elles durent moins d’une seconde mais c’est suffisant pour que le serveur s’éteigne.

Pour un redémarrage automatique, je vais paramétrer le BIOS : il faut chercher une option qui se nomme Restore on AC/Power Loss, AC Power Recovery, After Power Loss, etc.

La sobriété

On m’a dit “coupe ce qui est inutile”. J’ai commencé par le Bluetooth, puis l’USB, puis la RAM. À la fin, j’ai même coupé le courant. C’est le premier serveur au monde qui fonctionne uniquement à la force de la pensée. — Perceval de Galles, chevalier des trucs à enlever.

Afin de réduire l’impact du serveur, je vais effectuer quelques derniers réglages. Globalement si quelque chose est purement inutile, je vais peut-être avoir envie de le virer ; ça économisera l’énergie (sobriété), et ça réduira peut-être aussi au passage l’usure matérielle (longévité) et/ou la surface d’attaque (sécurité). Un bon bonus quoi.

J’insiste sur le côté purement inutile. Je me renseigne avant pour m’assurer que ne soit pas essentiel pour la sécurité ou la stabilité du système.

Optimiser la consommation du processeur

Encore le BIOS, eh oui, ça regorge de configurations intéressantes. Dans un objectif de sobriété, j’ai repéré plusieurs changements autour du processeur pour grappiller quelques Watts : par exemple turbo mode, limites de consommation en Watt PL1/PL2, sommeil profond avec les C-State.

Désactiver l’inutile

On a potentiellement déjà désactivé certains services inutiles pour préserver le SSD (cluster, high availability), mais ce peut aussi être pour des raisons d’économie. On a de quoi allonger la liste. Je vais regarder du côté du Bluetooth, WiFi, des ports USB non utilisés, de la carte son, de l’éclairage LED/RGB, etc.

À explorer : l’outil powertop pour configurer du matériel en économie d’énergie.

Éteindre le serveur

Et si Perceval avait raison, et que le max de la sobriété était d’éteindre le serveur ? Selon notre usage et nos services, c’est envisageable. Quelques idées :

• Si on est plutôt en mode bidouille et services utilisés ponctuellement en étant chez soi, on peut l’allumer uniquement pendant qu’on l’utilise.
• Si on en a besoin régulièrement ou à l’extérieur mais qu’il y a tout de même des plages d’inactivités (ex: la nuit), on peut programmer son extinction.
• Si on a une prise connectée contrôlable à distance, on pourrait l’allumer sur demande puis l’éteindre à nouveau.

Rien ne nous oblige à avoir 100% d’uptime ! Chaque contexte est différent.

Matériel d’occasion

Je termine par une action qu’on peut faire dès le début : éviter d’acheter du neuf. Je peux recycler un vieux PC pour créer mon Homelab en fouillant dans les cartons de matos que l’on a chez soi ou chez des proches.

Et sinon je peux acheter d’occasion. C’est ce que j’ai fait en trouvant un vendeur proche de chez moi - même pas besoin de livraison :)

D’accord c’est bien cool tout ça, mais c’est quoi un homelab ? Grossièrement, c’est une petite infrastructure informatique, un serveur que l’on va installer chez soi pour héberger des services. Il y a un côté bac à sable et apprentissage très sympa là-dedans. (Et encore, je dis petit, mais sur les communautés, je vois parfois des personnes qui sortent l’artillerie lourde chez eux !).

On peut imaginer héberger des services comme Nextcloud, Pi-hole, Plex, n8n, Home Assistant, etc. C’est assez large : je peux reprendre le contrôle sur mes données, expérimenter rapidement, faire de la domotique, automatiser. Un peu ce qui me passe par la tête au final.

L’envie m’est venu en discutant avec un ami, Antoine. Ça faisait déjà un moment qu’il m’en parlait de temps en temps. Et puis un jour on est rentré un peu plus dans le détail du comment. Ce qui m’a accroché sur le moment, c’était sa facilité à ajouter/supprimer des services et à tout compartimenter.

Dans le même temps, IKEA venait de lancer sa nouvelle gamme domotique compatible avec les protocoles Matter et Thread. Une raison supplémentaire pour me lancer dans l’aventure.

L’infrastructure

Avant tout, il me fallait une machine pour créer le serveur. J’ai d’abord fouillé dans mes cartons pour voir si j’avais du vieux matos à recycler. Pas de chance, ce qu’il me restait était beaucoup trop vieux. Donc j’ai fouillé Leboncoin et j’ai fini par trouver un voisin qui m’a vendu un mini PC idéal. La machine avait servi seulement 15 heures en tant que secours de son noeud Ethereum.

Pour s’amuser avec son premier homelab, pas besoin d’une bête de compétition ; un ancien PC ou un Raspberry Pi suffit. J’ai fait le choix de partir sur un mini PC avec un processeur N100. Mon besoin était d’avoir quelque chose de très économe en énergie et de durable dans le temps. 16Go de RAM pour être tranquille et un SSD avec un « vrai NVMe » (pas caché derrière du SATA) pour garantir la rapidité.

Côté domotique, j’avais déjà le nécessaire sans le savoir. Certains objets parlent en wi-fi, mais la plupart utilisent des protocoles radio (Thread, Zigbee, …). Il faut donc un appareil capable d’émettre et de diffuser sur ce protocole, et qui fera l’intermédiaire sur notre réseau local. On appelle ça un routeur de bordure.

Ça peut être une clé USB qui fait office d’antenne ou un boîtier propriétaire qui vient avec d’autres objets (Philips, IKEA, …). Ou, et c’était mon cas, certains appareils connectés des GAFAM (Apple TV, Google TV Streamer, HomePod, Alexa, …) qui sont déjà compatible avec Thread et Matter.

Le système

C’est ici que j’étais le plus sur le cul quand j’ai découvert le système du serveur d’Antoine : Proxmox. C’est un hyperviseur de type 1 (« bare metal », installé directement sur la machine comme on pourrait installer un Windows) basé sur Linux/Debian. Cela permet de créer et gérer facilement un ensemble de machines virtuelles et de containers. C’est puissant pour virtualiser et isoler un ensemble de différents services et systèmes sur une même machine.

Une autre de ses forces, c’est son interface web. On peut gérer notre serveur en SSH, mais aussi via une GUI puisque Proxmox peut être piloté depuis n’importe quel navigateur. Gestion du firewall, installation d’une nouvelle VM, gestion des ressources… une fois que le système est installé, on peut ranger cette machine dans un coin et on n’y accédera depuis n’importe quel autre PC.

En parlant de l’installation, elle est facile :

• On récupère l’ISO sur https://www.proxmox.com/en/downloads.
• On créé une clé USB bootable avec l’ISO (en ligne de commande ou avec un outil comme Balena Etcher).
• On la branche sur le PC puis on le démarre.
• Quelques vérifications à faire dans le BIOS (on martèle la touche Suuuuuuuupr.) : l’ordre de boot et l’activation de la virtualisation. Parfois, il peut être nécessaire de désactiver le Secure Boot.
• On se laisse guider par l’installation graphique de Proxmox. La plupart du temps, on garde ce qui est inscrit par défaut. On voudra par contre fixer l’adresse IP, car elle nous servira pour accéder à l’interface web.
• À la fin de l’installation, on redémarre, on accède au BIOS pour quelques derniers changements (ordre de boot des périphériques, ordre de boot du nvme, secure boot réactivé). On sauvegarde et on laisse Proxmox démarrer.
• On peut maintenant y accéder sur https://<ip_renseignée>:8006 !

J’ajoute quelques conseils qui peuvent aider :

• On vérifie les options du Firewall sur la box de notre FAI. Surtout sur les Freebox qui ont un Firewall IPV6 désactivé par défaut, et qui peuvent adresser une IPV6 publique à notre serveur. Le serveur devient alors accessible à tout internet, et ça, on n’en a peut-être pas envie.
• On fait un checksum une fois l’ISO téléchargé pour vérifier la bonne intégrité du fichier.
• On utilise une bonne clé USB. S’il y a une erreur pendant l’installation (type “package failed during install”), c’est probablement parce que la clé est naze. J’ai recommencé trois fois à cause de ça :)
• On fixe un bail sur notre box FAI pour que l’IP de notre serveur reste identique.

On a donc une première base de homelab pour jouer ! Les prochaines étapes (et probablement articles) ? Prendre un peu de temps à configurer et sécuriser notre serveur, puis ajouter nos premiers services/systèmes.