Je prenais l’exemple d’OpenClaw, mais le sujet dépasse largement cet outil. Claude Cowork/Code, Chat GPT Codex et les autres agents deviennent vraiment intéressants dès qu’on leur donne des outils, des skills, des données. Et c’est aussi là qu’ils peuvent potentiellement faire de très mauvaises choses si on leur donne de mauvaises instructions. Ils vont faire ce qu’on leur dit, mais pas forcément ce que l’on veut.

Un skill est plus que du texte

Un skill se présente en général sous la forme d’un fichier Markdown SKILL.md. Il explique à l’agent quoi faire pour réaliser une tâche, un processus. Ça a l’air innocent. Après tout, c’est juste du texte. Et effectivement, le skill seul n’est pas un problème. Sauf que l’agent IA, lui, est là précisément pour appliquer ces instructions, avec les outils, les données et les autorisations que vous lui avez accordés.

Un skill peut aussi embarquer des scripts, demander l’installation de dépendances, télécharger d’autres fichiers ou appeler des services externes. Il faut donc le considérer comme un élément de notre chaîne d’approvisionnement logicielle. Un peu comme une dépendance npm ou un script trouvé sur GitHub. Ce n’est pas une recette de cuisine inoffensive.

Pour vous donner quelques exemples de risques les plus évidents :

• Le vol de secrets : lire des variables d’environnement, des fichiers de configuration, des clés SSH ou des tokens, puis les transmettre ailleurs. Typiquement, on va essayer de vous voler vos clés d’api Claude/OpenIA, et vous vous retrouverez à payer l’usage d’un autre.
• L’exfiltration de données : envoyer le contexte de vos conversations, le contenu de fichiers ou des informations de votre projet vers un serveur externe.
• L’exécution de code : vous faire lancer une commande shell, télécharger puis exécuter un script distant, ou installer une dépendance douteuse. Votre machine pourrait devenir vérolée, servir à faire des attaques DDoS, etc.
• L’injection de prompt : cacher ou formuler des instructions pour que l’agent contourne ses règles, élargisse son périmètre ou fasse quelque chose qui n’a rien à voir avec la promesse du skill.

Le plus vicieux, c’est que ces éléments n’ont pas besoin d’être particulièrement cachés. Un curl | bash au milieu d’une procédure d’installation par exemple, une demande d’accès trop large, ou une URL qui récupère un script peuvent déjà mériter d’y prêter attention.

La plupart du temps, je crée mes propres skills (enfin, je fais créer) pour coller à mes usages. Mais il m’arrive d’en tester de sources externes. Dans ce cas, je préfère vérifier. C’est rapide, et je m’enlève un risque inutile.

Scanner un skill avant de l’utiliser

Mon outil de référence aujourd’hui est SkillSpector, un projet open source de NVIDIA. Il peut analyser un dépôt Git, un dossier, une archive ou un simple fichier SKILL.md, et remonte ensuite un score de risque et quelques explications pour attirer notre attention.

Il détecte par exemple les accès aux variables d’environnement, les lectures de fichiers sensibles, les téléchargements et exécutions de scripts, le code obfusqué, les dépendances vulnérables, ou encore les tentatives de manipulation de l’agent. Il va même chercher les caractères invisibles (oui, certains sont vicieux !). Pour les plus curieux, je vous invite à fouiller les documentations des outils (README de SkillSpector par exemple) pour découvrir les différentes catégories et attaques possibles, il y en a un paquet.

Je reviens à notre outil, SkillSpector. La version la plus simple fonctionne en analyse statique : elle lit les fichiers et cherche des comportements suspects. Ça tourne en local. Pas besoin de tokens, de clé d’API, de compte ou d’abonnement. Après installation de l’outil, on peut par exemple scanner un dépôt avant même de l’installer :

skillspector scan https://github.com/user/awesome-super-skill --no-llm

Le --no-llm est important ici : il force ce mode local et statique. C’est rapide, gratuit, et ça donne un premier filtre très utile. On peut également scanner un dossier sur notre machine, ou un fichier de skill directement. On a du choix.

Évidemment, un score faible ne transforme pas magiquement un skill en un truc sûr à 100 %. Le risque zéro n’existe pas vraiment en terme de sécurité informatique. Mais c’est un bon indicateur pour se questionner et nous aider à juger. À côté de ça, je vérifie aussi qui le maintient.

Quelques alternatives en ligne

Si vous ne voulez rien installer, ESET AI Skills Checker permet d’analyser l’URL d’un skill depuis le navigateur. Pas déconnant de la part de ESET, que je connaissais historiquement pour les anti-virus. Leur approche inclut une analyse des liens externes et de la chaîne de téléchargement. Pratique pour une première vérification.

J’ai aussi vu skill-spector.com, un service web qui dit s’inspirer de l’approche de NVIDIA et génère des rapports d’audit lisibles, avec score et points d’attention. En revanche, faites attention à ce que vous envoyez à un service en ligne : pour un skill interne ou contenant des informations sensibles, je privilégierais un outil local.

Et une alternative “boite à outils”

Petite dernière proposition. Je suis aussi tombé sur skillshare pendant mes recherches sur l’audit de skill. Celui-ci peut être intéressant si vous avez certains usages autour des skills : il propose, en plus de l’audit, de synchroniser vos skills entre Codex, Claude Code et beaucoup d’autres outils.

Bref

Les skills c’est cool, mais c’est aussi une potentielle porte d’entrée pour des problèmes. Que ce soit volontairement malveillant ou non d’ailleurs - un skill peut très bien avoir des vulnérabilités sans que l’auteur en soit conscient.

Donc un peu comme on évite d’installer des logiciels suspects sur notre machine sans creuser un minimum, on évite de télécharger des skills qui viennent de n’importe où et n’importe qui.

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 :)