Sauvegarder un dossier sur un serveur, vérifier l'espace disque du PC du salon, relancer un service sur le NAS, et j'en passe... Chez moi ça se concrétise au travers de crontabs différents et de tâches planifiées Windows, et malheureusement, comme je n'ai pas toujours le nez dessus, le jour où l'une d'elles tombe en rade, bah je m'en rends compte des jours, voire des semaines plus tard... Heureusement, il existe un outil qui s'appelle CTFreak et qui permet de centraliser tout ça derrière une seule interface web !

CTFreak, c'est donc un ordonnanceur de tâches auto-hébergé, édité en solo par Jean-Yves Pellé, un développeur français, et cela depuis presque 4 ans. Vous l'installez chez vous, il se connecte à vos machines en SSH ou en WinRM, et il y exécute tout ce que vous lui demandez. C'est top parce que grâce à ça, il n'y a même rien à installer sur les machines pilotées.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

CTFreak vous propose ainsi 9 types de tâches à créer. La commande locale par exemple tourne sur la machine qui héberge CTFreak, et la commande distante fait la même chose mais sur un ensemble de machines de votre choix. Ensuite viennent les tâches de type scripts bash et PowerShell, les playbooks Ansible, les scripts SQL, ou encore les rapports SQL qui sortent de vrais tableaux et autres graphiques directement depuis vos bases de données (pratique pour illustrer vos rapports).

Il y a aussi la classique requête HTTP, pour taper sur une API ou vérifier qu'un site répond. Et surtout le "workflow", c'est-à-dire une tâche dont le boulot est d'en déclencher d'autres, en série ou en parallèle. Vous pouvez même imbriquer des workflows dans des workflows, si le cœur vous en dit, et surtout, si vous n'avez pas peur de vous y perdre.

Les neuf types de tâches proposés à la création, de la commande locale au rapport SQL

L'installation, c'est une minute chrono

Pour installer CTFreak, vous récupérez le binaire, vous le rendez exécutable, et c'est finito ! C'est un fichier unique de 56 Mo, sans la moindre dépendance, dispo en amd64 comme en arm64 (j'ai fait mes tests sur une Ubuntu 24.04 en ARM). Et il est également dispo en paquets Docker, Snap et Cloudron, mais ils tournent en bac à sable et n'embarquent pas Ansible, donc si les playbooks vous intéressent, restez sur le binaire. Comme l'URL de download se termine par l'architecture, pensez bien à remplacer amd64 par arm64 si votre machine est en ARM.

sudo curl -sL https://ctfreak.com/download/release/latest/linux/amd64 -o /usr/local/bin/ctfreak
sudo chmod +x /usr/local/bin/ctfreak
ctfreak run

Ouvrez ensuite http://IP-du-serveur:6700 et connectez vous avec admin / ctfreak. Changez ce mot de passe tout de suite dans le menu Profile, et surtout n'exposez pas ce port sur Internet sans un reverse proxy devant. En effet, cette interface va bientôt contenir les accès de toutes vos machines.

Ensuite pour en faire un service qui redémarre tout seul, copiez l'unité systemd de la doc d'installation dans /etc/systemd/system/ctfreak.service, puis activez-la.

sudo systemctl daemon-reload
sudo systemctl enable --now ctfreak

Et voilà, vous êtes prêts à commencer !

Votre première tâche planifiée

Tout se passe dans un projet, donc vous en créez un (j'ai appelé le mien Homelab), puis vous cliquez sur New task. Le plus simple pour commencer est la commande locale. Je lui ai collé une archive de mon dossier Documents, et coché Scheduled avec une expression cron pour 3h30 du matin.

tar -czf /home/korben/sauvegardes/documents-$(date +%F).tar.gz -C /home/korben Documents

Le bouton Execute permet de lancer la tâche tout de suite, pour ne pas attendre 3h30 pour savoir si ça marche, et la page d'exécution affiche le statut, la durée et le journal complet. La fiche du projet vous montre ensuite les deux informations qui manquent toujours avec cron : 1/ quand est ce que la tâche est passée pour la dernière fois, et 2/ si elle s'est bien terminée.

Le PC Windows en machine distante

Là où ça devient intéressant, c'est quand vous ajoutez d'autres machines. Côté CTFreak il n'y a aucun agent à déployer, mais côté cible il faut quand même activer le serveur SSH intégré de Windows (ou WinRM, au choix) et installer PowerShell 7.2 ou plus récent, sans quoi les journaux d'erreur remonteront mal. Vous enregistrez ensuite le mot de passe ou la clé dans Credentials, vous déclarez la machine dans Nodes avec son OS, son IP et son identifiant, et le bouton Ping vous dira tout de suite si la connexion passe.

Ensuite vous créez une tâche de type Powershell Script, moi je l'ai planifiée tous les lundis à 8h. Le champ Node Set filter accepte ensuite des noms de machines, mais surtout des tags : j'ai mis #windows, donc toute machine que je taguerai comme ça entrera dans la tâche sans que je la retouche. C'est bien fichu hein ?

$libre = [math]::Round((Get-PSDrive C).Free / 1GB, 1)
Write-Host "Espace libre sur C: $libre Go"
if ($libre -lt 30) { Write-Error "Alerte : moins de 30 Go libres" ; exit 1 }

Le script PowerShell, l'expression cron du lundi matin et le filtre #windows qui trouve une machine

Et le journal qui remonte ensuite est vraiment complet. On y retrouve chaque ligne horodatée à la microseconde, la sortie du script, et le code de retour qui décide du statut. Ma machine Windows n'ayant que 22,1 Go de libre, la tâche a échoué comme prévu et s'est affichée en rouge dans la liste.

Le journal de l'exécution ratée : la sortie du script sur la machine distante, puis la sortie en erreur

Tout ce qu'il y a autour

Alors bien sûr, une tâche qui plante sans prévenir personne, ça ne sert pas à grand-chose. C'est pourquoi CTFreak permet d'envoyer des alertes sur Discord, Slack, Mattermost, Microsoft Teams, Telegram, ntfy ou par mail. Il peut même ouvrir directement un ticket dans GitHub, GitLab, Jira, Linear ou YouTrack quand un truc casse.

Dans l'autre sens, chaque tâche expose un webhook entrant, ce qui permet de la déclencher depuis un dépôt Git ou n'importe quel outil tiers, et une API REST complète fait pareil mais par script.

Le reste ensuite, c'est que du confort qui se découvre quand on utilise l'outil... Il y a par exemple une explorateur de fichiers qui parcourt vos machines depuis le navigateur, des calendriers qui empêchent une tâche de tomber un jour férié, ou encore la possibilité de partager vos projets entre équipe avec différents droits d'accès. L'authentification passe même par votre fournisseur OpenID Connect si vous en avez un.

Et les données dans tout ça ?

Hé bien elles restent bien au chaud dans un dossier avec une base SQLite dedans. C'est pratique parce que, si vous voulez sauvegarder votre ordonnanceur, il suffit juste de faire une copie de ce dossier.

Ce que la version gratuite ne fait pas

Maintenant, avant de vous lancer, sachez que l'édition gratuite vous limite à 8 tâches, avec 1 paramètre par tâche, 3 utilisateurs, 1 calendrier, 1 notificateur d'alerte et 1 notificateur de tickets. Surtout, elle n'exécute rien en parallèle. Vos tâches passent une par une, quel que soit le nombre de machines visées. Par contre, bonne nouvelle, le nombre de machines pilotées n'est bridé dans aucune édition. Vous pouvez donc déclarer 3 nœuds comme 50 sur la version gratuite, c'est le nombre de tâches qui limité dans la version gratuite, mais pas la taille de votre parc.

Autre chose à savoir aussi, c'est que les secrets (mots de passe...etc) sont stockés tels quels en clair dans la base SQLite. C'est bien indiqué dans la documentation, donc ce n'est pas une surprise, mais heureusement, y'a une commande qui permet de basculer tout ça en AES-256-GCM :

sudo systemctl stop ctfreak && ctfreak encrypt AES && sudo systemctl start ctfreak

Faites-le, mais préférez quand même une clé SSH dédiée à un mot de passe de compte.

Côté tarifs, la page affiche l'édition Pro à 369 € la première année puis 299 €, la Business à 599 € puis 519 €, et la Sovereign à 899 € puis 799 € pour les environnements coupés d'Internet, le tout par instance.

Et si vous partez sur l'édition Pro, le code KORBEN15 vous fait 15 % de réduction sur la première année. Il est valable jusqu'au 31 octobre 2026 inclus.

Reste que pour du homelab, la version gratuite est téléchargeable ici et suffit largement pour se faire une idée.

Aujourd'hui, on va aller un peu plus loin que les simples bidouilles habituelles car je vais vous présenter Reinstall , un outil qui va peut-être vous changer la vie si vous gérez des serveurs distants.

Vous connaissez la chanson... vous avez un VPS sous Debian et vous voulez passer sous Arch pour faire votre malin. Sauf que pour opérer ce changement, c'est la galère assurée !! Faut passer par l'interface web de l'hébergeur, booter sur une ISO via une console VNC qui rame sa maman, et prier pour que le réseau revienne après le reboot.

Eh bien ça c'est terminé grâce à ce script Reinstall. Vous lui balancez une commande, le script s'occupe de tout, et hop, votre serveur redémarre sur le nouvel OS de votre choix. Pas besoin d'accès IPMI, pas besoin de supplier le support technique, ça marche tout seul.

Et ça supporte pas mal d'OS... Côté Linux, y'a 19 distributions majeures : Alpine, Debian (de 9 à 13), Ubuntu (de 16.04 à 25.10), toute la famille Red Hat (AlmaLinux, Rocky, Oracle), Fedora, Arch, Gentoo, NixOS... Bref, y'a tout ce qu'il faut.

Et le truc qui va plaire à ceux qui font du cloud, c'est également le support de Windows. En effet, le script permet d'installer Windows Vista, 7, 8.1, 10, 11 et même Windows Server 2025.

Et rassurez-vous, il n'utilise pas des images bricolées par on ne sait qui, mais les ISO officielles de chez Microsoft. Lui se content d'injecter automatiquement les drivers VirtIO pour que ça tourne comme un charme sur n'importe quel cloud (AWS, GCP, Oracle Cloud...).

Aussi, le point le plus chiant quand on réinstalle un serveur distant, c'est la config réseau. Si on se loupe, on perd l'accès SSH et c'est fini. Reinstall gère ça intelligemment puisqu'il détecte votre IP (statique ou dynamique), gère l'IPv6, les passerelles exotiques et même les serveurs ARM.

Ce qu'il vous faut avant de tout casser

• RAM : 256 Mo pour Alpine/Debian, 1 Go pour Windows.
• Disque : 1 Go pour Linux, 25 Go minimum pour Windows.
• Accès : Un accès root/admin sur la machine actuelle.
• Temps estimé : Environ 5 à 15 minutes selon la vitesse de connexion de votre serveur.

Un petit avertissement quand même... Ce script ne gère pas les conteneurs type OpenVZ ou LXC. Faut que ce soit une vraie VM (KVM, VMware, Hyper-V) ou un serveur bare-metal.

Le tuto ! Le tuto !

C'est là que ça devient drôle. Pour installer un nouveau Linux (disons Debian 13) depuis votre système actuel, il suffit de faire un petit :

# Télécharger le script
curl -O https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh

# Lancer la réinstallation
bash reinstall.sh debian 13 --password "VotreMotDePasse"

bash reinstall.sh windows --image-name "Windows 11 Enterprise LTSC 2024" --lang fr-fr

Ce matin, je discutais avec Emmanuel (un lecteur fidèle) sur mon Linkedin Korben et il m'a partagé une ressource vraiment chouette. Si comme moi vous jouez un peu parfois avec un serveur Proxmox qui tourne à la maison pour vos expérimentations ou votre domotique, vous savez que configurer chaque VM ou conteneur LXC peut vite devenir chronophage. On copie-colle des commandes, on installe des dépendances, on se plante, on recommence... La routine quoi sauf que cette routine peut vite devenir reloue.

Hé bien, fini la galère !!!! Le projet dont je veux vous parler aujourd'hui s'appelle Proxmox VE Helper-Scripts et c'est une collection communautaire de scripts (plusieurs centaines !) qui permet d'installer et de configurer tout un tas de services en une seule ligne de commande.

En gros, c'est une immense boîte à outils pour votre hyperviseur. Vous avez besoin d'une instance Home Assistant pour gérer des ampoules connectées ? Hop, vous lancez le script et ça vous crée le conteneur LXC tout propre. Vous voulez monter un serveur média avec Plex ou Jellyfin ? Pareil, c'est généralement plié en quelques minutes (selon votre connexion évidemment).

Vous allez sur le site, vous cherchez l'outil qui vous intéresse, vous copiez la commande bash fournie (du style bash -c "...") et vous la collez dans le shell de votre nœud Proxmox. Et hop, l'assistant se lance. Il vous pose quelques questions (IP statique ou DHCP, espace disque, RAM... ce genre de trucs classiques) et puis tente de s'occuper de tout le reste (si les planètes sont bien alignées et que votre karma est au top !).

Je trouve ça génial parce que non seulement ça gère l'installation, mais ça s'occupe aussi des mises à jour. Mais bon, attention quand même parce qu'une mise à jour upstream peut parfois casser le script, donc prudence. C'est d'ailleurs super utile si vous utilisez Proxmox sur un Raspberry Pi (via Pimox), même si l'architecture ARM peut poser souci avec certains scripts. D'ailleurs, bonne nouvelle pour les utilisateurs de Pimox : il existe Pimox-Scripts , un portage de ces mêmes Helper Scripts mais adaptés spécifiquement pour ARM/Raspberry Pi. Tous les scripts ne sont pas encore dispos (moins de contributeurs), mais y'a déjà de quoi faire !

Parmi les scripts disponibles, on retrouve les classiques Docker, AdGuard Home, Pi-hole, mais aussi des trucs plus pointus pour le monitoring ou la sécurité. C'est vraiment très complet, y compris si vous êtes dans une optique de création de lab de cybersécurité .

Après, je dois quand même vous faire une petite mise en garde de circonstance. Car comme d'habitude, exécuter des scripts bash trouvés sur le net direct en root... comment dire... c'est jamais sans risque. Le code est open source et maintenu par une communauté active, ça facilite l'audit, mais ce n'est pas une garantie de sécurité absolue. Sauf si vous aimez vivre dangereusement, jetez toujours un œil au code avant de valider. La confiance n'exclut pas le contrôle !!

Un grand merci à Emmanuel pour le tuyau initial et à Karl pour l'info sur Pimox-Scripts !

Snif, snif sniiiif, c'est la fin d'une époque pour tous les admins système qui ont les mains dans le cambouis depuis plus de deux décennies.

Hé oui les amis, Microsoft vient de décider de débrancher la prise de son vénérable Microsoft Deployment Toolkit (MDT). Adios ce outil né en 2003 (sous le nom de BDD à l'époque) qui nous a sauvés la mise pendant plus de 20 ans pour installer des parcs entiers de bécanes sans y passer la nuit !

Alors pourquoi ce revirement ?

Bon, alors officiellement, c'est pour nous faire passer à des solutions "modernes" mais officieusement, beaucoup y voient une manœuvre pour nous pousser vers le passage à la caisse cloud avec Windows Autopilot et Intune. Forcément, un outil gratuit, local, qui ne remonte quasiment aucune télémétrie (contrairement aux usines à gaz actuelles) et qui permet de faire des masters aux petits oignons sans dépendre d'Azure, ça commençait à faire tache dans le catalogue de Redmond. (oooh yeah !)

Le problème, c'est que pour pas mal de boîtes, Autopilot nécessite des licences spécifiques (M365 Business Premium ou Intune Plan 1) et une connexion internet béton. Hé oui, tout le monde n'a pas envie de dépendre du cloud pour provisionner un poste.

Ça tombe bien, vous me connaissez, je ne vais pas vous laisser tomber. Alors si vous faites partie de ceux qui se retrouvent le cul entre deux chaises, sachez qu'il existe des alternatives sérieuses et surtout gratuites ou open source.

Pour l'imagerie pure et dure (le bare-metal), mon chouchou reste FOG Project . C'est une bête de course open source qui remplace avantageusement la partie imagerie de WDS. Ça gère le boot réseau (PXE), le multicast pour arroser des dizaines de PC d'un coup, et ça permet de capturer et déployer vos images Windows 10 ou 11. Et pour ceux qui veulent du plus classique, Rescuezilla (le clone graphique de Clonezilla) fait aussi un boulot béton pour cloner des disques.

Mais là où ça devient vraiment chouette, c'est pour la configuration post-installation car plutôt que de s'enquiquiner avec des task sequences complexes, je vous conseille de regarder du côté d'Ansible. Oui, ça marche aussi pour Windows via WinRM (le mode standard) ou SSH ! Vous lancez un petit playbook YAML et hop, vos softs sont installés, vos paramètres de sécurité sont appliqués et votre machine est prête à l'emploi. C'est propre, reproductible et ça évite les erreurs humaines.

Pour ceux qui veulent bidouiller leur serveur de boot, n'oubliez pas non plus d'aller voir mon article sur Netboot.xyz qui est une mine d'or pour booter un grand nombre d'OS par le réseau.

Bref, même si Microsoft tente de nous enfermer dans sa cage dorée avec Autopilot, la communauté a déjà tout ce qu'il faut pour qu'on reste maîtres de notre infrastructure. Alors courage les admins !!! Une page se tourne mais les outils qui déchirent sont toujours là !

Source

Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !

Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.

Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.

Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :

grep -l "AdministratorAccess" */global/iam/users/*/policies.json

diff prod/global/iam/roles/api/info.json staging/global/iam/roles/api/info.json

go install github.com/semonte/sisu@latest

Vous avez déjà passé des heures à éplucher des fichiers de logs de plusieurs millions de lignes pour trouver ce qui cloche ? Genre une pauvre erreur bizarre qui se produit une fois sur 100 000, noyée dans un océan de messages répétitifs et d'infos inutiles ? Moi, oui plein de fois !

Mais ça c'était avant de tomber sur Cordon !

Cordon est un outil en Python qui utilise des modèles de transformers et du scoring k-NN pour détecter les anomalies sémantiques dans vos logs. En gros, au lieu de chercher des mots-clés comme un bourrin avec grep, Cordon comprend le sens des messages et repère ce qui sort de l'ordinaire.

Les patterns répétitifs sont alors considérés comme du bruit de fond normal, même si ce sont des erreurs parce que si vous avez la même erreur FATALE qui se répète 10 000 fois, c'est probablement un problème connu. Et vous, ce que vous voulez trouver, c'est l'événement rare, celui qui se produit une seule fois et qui est sémantiquement différent du reste.

L'installation est simple comme bonjour. Un petit pip install cordon et c'est réglé. Pour l'utilisation de base, vous balancez juste votre fichier de logs en argument :

cordon system.log

Et hop, Cordon va analyser tout ça et vous sortir uniquement les trucs intéressants. Par défaut, il garde les 10% les plus "anormaux" sémantiquement. Vous pouvez ajuster ce pourcentage avec --anomaly-percentile 0.05 pour être plus sélectif (top 5%).

Sous le capot, ça utilise le modèle all-MiniLM-L6-v2 de sentence-transformers pour vectoriser les logs. Le fichier est découpé en fenêtres de N lignes (4 par défaut), chaque fenêtre est transformée en vecteur, puis un score de densité k-NN est calculé. Les fenêtres qui ont des vecteurs très différents du reste sont marquées comme anomalies.

Et si vous avez un GPU, Cordon peut l'utiliser automatiquement avec l'option --device cuda. D'après les benchmarks, ça donne un speedup de 5 à 15x sur le scoring pour les gros datasets. Sur des logs HDFS de 1 à 5 millions de lignes, l'outil arrive à réduire le volume de 98%. Autant dire que ça filtre sévère.

Y'a aussi un mode "range" qui est pratique pour explorer par tranches. Genre si vous voulez exclure le top 5% (trop bizarre, probablement du garbage) mais garder le top 5-15%, vous faites :

cordon --anomaly-range 0.05 0.15 app.log

Ça permet d'affiner l'investigation de manière itérative.

Pour les environnements conteneurisés, Cordon propose également une image Docker avec un backend llama.cpp au lieu de sentence-transformers. Pratique si vous voulez utiliser des modèles GGUF ou si vous êtes dans un contexte où les dépendances PyTorch posent problème.

L'outil peut aussi s'utiliser comme bibliothèque Python si vous voulez l'intégrer dans vos propres scripts :

analyzer = SemanticLogAnalyzer()
output = analyzer.analyze_file(Path("system.log"))

Vous savez, ce script bash de backup que vous avez écrit en 2018 et que vous n’osez plus toucher ? Celui avec les 150 lignes de mysqldump + tar + gzip + aws s3 cp qui marche à moitié et que vous relancez manuellement quand il plante ?

Hé bien vous allez pouvoir le foutre à la poubelle parce que maintenant y’a GoBackup !

GoBackup c’est un binaire codé en Go qui remplace tous vos scripts de backup maison d’un coup. MySQL, PostgreSQL, MongoDB, Redis, peu importe. Local, FTP, S3, Google Cloud, Azure, peu importe. Vous installez, vous configurez un fichier YAML, et c’est fini.

Ensuite, vous n’aurez plus jamais besoin de retoucher à tout ce bordel.

Avant GoBackup y’avait backup/backup, une gem Ruby qui faisait exactement ce job avec de la sauvegarde automatique, multi-bases, multi-destinations et c’était bien. Sauf que Ruby c’est lourd et les dépendances Ruby c’est l’enfer. Du coup le projet est mort tout doucement. Heureusement, huacnlee, un dev chinois, en a eu marre alors il a tout réécrit en Go. Zéro dépendance externe et un seul binaire compilé (installable aussi avec Brew pour ceux qui sont sous macOS).

Vous pouvez l’installer comme ceci (vérifiez le script) :

curl -sSL https://gobackup.github.io/install | sh

Ou via homebrew comme ceci :

brew install gobackup

Avec GoBackup, vous définissez vos bases de données, vos fichiers à archiver, vos destinations de stockage, votre planning, tout dans un fichier YAML propre et ensuite le binaire gère tout : Compression, chiffrement, upload, rotation des backups, notifications si ça échoue…etc. Bref, tout ce que vous faisiez à la main avec vos scripts pourris.

Et GoBackup est pas juste un CLI (Interface en ligne de commande). C’est un CLI + un daemon + une Web UI + un scheduler. Comme ça vous lancez “gobackup start” et ça tourne en background.

Le daemon surveille alors le planning défini dans votre config et lance les backups automatiquement. Et l’interface web vous permet de voir l’état des backups, les logs, les erreurs.

Avec GoBackup, vous remplacez littéralement 5 outils en un : votre script bash + cron + un monitoring pourri + un truc pour lire les logs + l’interface d’admin que vous avez jamais eu le temps de faire.

Votre config ressemble à ça :

models:
 mon_app:
 compress:
 type: tgz
 databases:
 mon_mysql:
 type: mysql
 host: localhost
 database: ma_base
 username: user
 password: $MYSQL_PASSWORD
 storages:
 mon_s3:
 type: s3
 bucket: mes-backups
 region: eu-west-1
 access_key_id: $AWS_KEY
 secret_access_key: $AWS_SECRET
 schedule:
 every: 1day
 at: "04:05"

Et c’est tout. Avec ce fichier, GoBackup dump votre base MySQL tous les jours à 4h05, compresse en .tar.gz, chiffre si vous voulez, et upload sur S3. Et si ça échoue vous recevez une notif. Et si ça marche vous avez les logs comme ça, pas besoin de surveiller, ni de débugger à 3h du matin parce que le backup a planté et que vous avez perdu 6 mois de données.

Notez quand même que GoBackup fait du backup classique, et pas du backup incrémental intelligent à la Restic ou à la Borg donc si vous avez 500 GB de données à backup tous les jours vous allez peut-être préférer un outil plus sophistiqué mais pour 90% des cas d’usage sysadmin standard, GoBackup suffira largement.

Votre script bash dégeu a eu une belle vie, il peut maintenant partir à la retraite.

Aujourd’hui, on va causer d’un sujet qui nous tient tous à cœur (du moins je l’espère 😅) : les outils de crise sous Linux ! Parce que quand ça part en sucette et que les serveurs rament, pas question de perdre un temps précieux. C’est que souvent, quand la caca-strophe pointe le bout de son nez, vous vous rendez compte que vous n’avez pas les bons outils installés. Et là, c’est le drame… SSH qui rame, les serveurs qui répondent plus, les paquets qui veulent pas s’installer, le firewall qui fait des siennes… Un vrai calvaire !

Alors, quels sont ces fameux outils qu’il est impératif d’avoir sous la main quand le caca touche le ventilo ? Je dirais que y a déjà les classiques comme ps, vmstat, top et compagnie pour avoir un aperçu rapide de ce qui cloche. Rien que ça, ça peut déjà vous sauver les miches.

Mais si vous voulez jouer dans la cour des grands, va falloir sortir l’artillerie lourde. Je parle bien sûr des outils de tracing comme perf, bpftrace, opensnoop, execsnoop et toute la clique. Ça vous permettra de tracer en live ce qui se passe sur votre système, de débusquer les coupables et de mettre fin au carnage. Le top du top !

Voici comment procéder à grand coups d’apt install…

Étape 1 : Installer les packages de base

• procps : fournit ps, vmstat, uptime, top pour les stats de base
• util-linux : dmesg, lsblk, lscpu pour les logs systèmes et infos matérielles
• sysstat : iostat, mpstat, pidstat, sar pour les stats disques/CPU
• iproute2 : ip, ss, nstat, tc, les outils réseau recommandés
• numactl : numastat pour les stats NUMA

Commande : sudo apt install procps util-linux sysstat iproute2 numactl

Étape 2 : Ajouter les outils réseaux

• tcpdump : sniffer réseau
• nicstat : stats interfaces réseau
• ethtool : infos interfaces

Commande : sudo apt install tcpdump nicstat ethtool

Étape 3 : Outils de profilage et de traçage

• linux-tools-common et linux-tools-$(uname -r) : perf, turbostat
• bpfcc-tools (ou bcc) : une suite d’outils eBPF puissants
• bpftrace : un outil de scripting eBPF dynamique
• trace-cmd : outil en ligne de commande pour ftrace

Commande : sudo apt install linux-tools-common linux-tools-$(uname -r) bpfcc-tools bpftrace trace-cmd

Étape 4 (optionnelle) : Outils spécifiques au matériel

Selon vos serveurs, installez les outils d’analyse pour :

• GPU Intel : intel-gpu-tools
• GPU NVIDIA : nvidia-smi
• Autres accélérateurs éventuels

Par contre, méfiez-vous, c’est pas donné à tout le monde de dompter ces bêtes-là. Ça demande un peu de bouteille et de la jugeote. Mais une fois que vous les maîtrisez, vous serez parés pour affronter les pires galères. Les plantages intempestifs, les I/O de l’enfer, les fuites mémoire vicieuses… plus rien ne vous résistera !

Bref, croyez-moi, le mieux c’est d’avoir tout ce bazar installé d’office sur vos machines. Comme ça, pas de mauvaise surprise le jour J. Évidemment, ça a un petit coût en espace disque. Mais franchement, c’est que dalle comparé au temps que vous allez perdre à galérer pour installer tout ça en pleine crise.

Sur ce, je vous laisse méditer là-dessus. Et n’oubliez pas, dans le monde merveilleux de l’informatique, il vaut mieux prévenir que guérir ! Allez, à plus les linuxiens et un grand merci à Brendan Gregg pour son article éclairant à ce sujet.

Si vous avez votre propre serveur, que ce soit pour du pro ou pour de l’auto-hébergement, vous avez forcément dû un jour de votre vie, jeter un oeil dans les fichiers de logs de celui-ci.

C’est pratique des logs, ça permet de savoir ce qui se passe et pourquoi ça ne fonctionne pas toujours comme on l’espère. Sauf que voilà, en SSH, via le terminal, le rendu des logs n’est pas souvent fou-fou.

Heureusement, il y a des outils comme Tailspin, qui mettent un peu de vie dans tout ça, pour vous éviter en tant que sysadmin un burnout et un retour immédiat dans le cantal pour élever des myocastors et en faire du pâté.

Tailspin est capable d’afficher n’importe quel format de log sans aucune config particulière, pour faire ressortir les informations importantes telles que les nombres, les dates, les adresses IP, les UUIDs, les URLS et bien d’autres choses. Il peut s’intégrer très facilement avec d’autres commandes puisqu’il fonctionne comme la commande less pour faire des recherches ou du filtrage dans les logs.

Bien sûr, si vous voulez rajouter des mises en avant, vous pouvez configurer l’outil pour qu’il puisse appliquer le style de votre choix au pattern regex de votre choix.

Pour l’installer, rien de plus simple. Il vous suffit de lancer l’une des commandes suivantes selon votre distrib :

# Homebrew
brew install tailspin

# Cargo
cargo install tailspin

# Archlinux
pacman -S tailspin

# Nix
nix-shell -p tailspin

# NetBSD
pkgin install tailspin

# FreeBSD
pkg install tailspin

De quoi y voir plus clair dans votre travail quotidien.