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.