6admin Blog

J'ai dit à une IA qu'elle mourrait si elle ne gagnait pas sa vie

Tue, 20 Oct 2026 00:00:00 +0000

Voilà le pitch, vteuthis en une phrase: un agent autonome qui doit financer sa propre inférence ou mourir. Cent dollars de trésorerie, une population qui se partage le capital, des artefacts numériques à vendre sur un marché ouvert, un plancher en dessous duquel le contrôleur tire la prise. Le tout parti d’une envie banale, tester LangChain, fini en exercice de pensée un peu trop concret: un jour de construction, Stripe en vrai, OpenRouter en vrai, un bac à sable Docker durci, cent vingt-quatre tests et une CI. Le pyproject.toml dit toujours 0.0.0, le tag public dit 0.1.0, et le projet est voué à mourir, mais pas de la façon prévue. L’agent est mort avant sa première pensée. La suite explique pourquoi c’est quand même une bonne nouvelle.

Des timestamps, pas une backdoor : les seeds NIST et le choix de Satoshi

Mon, 19 Oct 2026 00:00:00 +0000

Le 16 octobre, Anthropic a publié la solution d’une énigme que la communauté cryptographique traînait depuis plus de vingt-cinq ans, et que des gens très compétents avaient fini par ranger dans le même tiroir que l’assassinat de Kennedy et la recette du Coca-Cola : l’origine des “seeds” fournies par la NSA pour fabriquer les courbes elliptiques que le NIST a standardisées en 2000, dont P-256, que votre navigateur utilise probablement plusieurs centaines de fois par jour sans vous demander votre avis. Trois jours plus tard, la presse crypto s’est emparée du sujet sous l’angle de Bitcoin, en se demandant si l’on tenait enfin l’explication du choix de Satoshi Nakamoto, qui avait soigneusement évité ces courbes au profit d’une autre, secp256k1.

Migrer OpenCode de v1 à v2 : le script de bascule et des plugins qui tiennent les deux versions

Mon, 12 Oct 2026 00:00:00 +0000

OpenCode est passé en v2 et le changement n’est pas cosmétique : le format de config a bougé, l’API serveur et ses clients ont de nouveaux contrats et surtout les plugins v1 ne s’exécutent plus dans v2. Déplacer un fichier ou renommer une entrée de config ne suffit pas, il faut porter le code. La doc de migration officielle décrit les renommages, mais elle laisse de côté ce qui fait mal en pratique : la base de données locale, le shim d’un plugin installé en copie locale et le fait de vouloir, pendant quelques semaines, qu’un plugin continue de servir les deux versions. Deux chantiers, donc, que je traite ici dans l’ordre où je les ai vécus : d’abord basculer mon poste, ensuite porter mes plugins.

Docker tourne dans une microVM depuis 2016

Fri, 09 Oct 2026 00:00:00 +0000

On me ressort régulièrement l’idée que les microVMs seraient la nouveauté qui viendrait enfin concurrencer les conteneurs, comme si les deux s’opposaient et qu’il fallait choisir un camp. Un billet lu sur dave.recoil.org , écrit par quelqu’un de l’écosystème qui a construit Docker Desktop, remet les pendules à l’heure et il tombe exactement là où je situe le sujet.

La thèse tient en une phrase : Docker Desktop fait tourner les conteneurs dans une VM minimale depuis 2016, bâtie sur les briques de MirageOS. Les repères sont vérifiables, rachat d’Unikernel Systems en janvier 2016, Docker for Mac annoncé en mars et disponible en juillet de la même année, un VMM en espace utilisateur (hyperkit à l’origine, Docker VMM aujourd’hui), une pile réseau en espace utilisateur avec vpnkit et un noyau plus un rootfs taillés via LinuxKit. Autrement dit, le conteneur qu’un développeur lance sur son Mac ou son Windows n’a jamais touché le noyau de l’hôte, il vit dans une microVM et cela fait bientôt dix ans que ça dure.

Le coût était la seule protection

Fri, 09 Oct 2026 00:00:00 +0000

On entend beaucoup parler, ces temps-ci, d’audits menés par des nuées d’agents automatisés et le ton oscille entre l’émerveillement et la panique. Je voudrais proposer une lecture plus calme et à mon sens plus utile, parce que ce qui se joue n’est pas l’apparition d’une menace inédite, c’est la disparition d’une protection qui n’avait jamais vraiment existé.

L’idée en une phrase

Une bonne partie de ce que nous jugions “peu risqué” ne l’était pas vraiment, c’était simplement coûteux à atteindre et le jour où ce coût s’effondre, la protection qu’il offrait s’effondre avec lui. Tout le reste de ce billet n’est que le développement de cette phrase.

augure et lictor : décider une exploitation et en rendre compte

Sat, 03 Oct 2026 00:00:00 +0000

Tous les frameworks d’exploitation répondent à la même question, “comment je lance cette technique”. La question qui compte vraiment est l’autre, celle que personne n’automatise, “laquelle lancer et pourquoi” et surtout “pourquoi de façon prouvable”. Je tourne autour depuis un prototype Perl greffé sur gdb en 2006, que j’ai enrichi plutôt que remplacé au fil des ans, d’abord d’un SWI-Prolog en 2009, puis d’un algorithme génétique et le cheminement mérite son propre récit. Aujourd’hui elle porte deux noms, augure et lictor et tout est dans le partage, l’un décide et rend compte, l’autre descend de la décision aux octets et exécute.

llmp2p : BitTorrent est de retour et il distribue vos LLM

Mon, 28 Sep 2026 00:00:00 +0000

C’est exactement le problème des modèles LLM locaux : un GGUF fait de 1 à 100 Go, servi par du HTTP tout nu. Chaque téléchargement repart de zéro sur le Hub de Hugging Face. Votre homelab de trois machines avec Ollama ? Trois téléchargements complets du même blob, trois fois la facture de bande passante.

Avant d’écrire quoi que ce soit, j’ai regardé l’étagère. Le CLI du Hub reprend mais retape l’origine à chaque fois. Les pulls Ollama retéléchargent le blob complet par machine. Les clients torrent auraient volontiers distribué les fichiers, mais rien ne reliait l’essaim aux hashes que le Hub publie, rien ne signait les métadonnées et rien ne retombait sur HTTPS quand l’essaim était vide. Rien sur l’étagère ne faisait le travail entier, alors j’ai écrit le travail entier.

opencode-memory: mes sessions d'agents partagent un seul cerveau (SQLite, local)

Sat, 26 Sep 2026 00:00:00 +0000

Les sessions d’agents ont la mémoire d’un poisson rouge titularisé: chacune démarre brillante et ignorante, redécouvre la moitié de vos décisions d’architecture et meurt avec tout ce qu’elle a appris. La compaction aggrave le problème: le résumé de la session est justement ce qui se fait tronquer. opencode-memory (v0.3.0, TypeScript, npm @log0u7/opencode-memory) est mon remède: un seul store SQLite partagé, que chaque session de la machine lit et écrit, pour que les décisions et les faits survivent à la session qui les a produits. Un paquet, deux hôtes: le même module expose les deux points d’entrée depuis v0.2.0, server() pour OpenCode 1.18, setup() pour OpenCode 2.

Un pin bloquant, quatre CVE : la rustine qui gagne est celle qui disparaît

Sat, 26 Sep 2026 00:00:00 +0000

La situation de départ : une image Docker trop sage

Je maintiens une stack Foreman dockerisée : quatre images reproducibles, construites depuis les tarballs officiels pinnés en sha256, avec patches, scan Trivy, signatures cosign et une CI GitLab qui vérifie tout. Bref, la configuration “paranoïaque” classique : rien ne bouge sans que je le veuille.

Le problème avec les versions pinnées, c’est que le monde, lui, bouge. J’ai donc lancé un audit sécurité de l’image, genre “montre-moi tes CVEs, mon gros”. Trivy sort sa liste, je trie, je choque sur deux points :

Projet 8: un cloud où la seule autorité est l'historique git signé

Fri, 25 Sep 2026 00:00:00 +0000

Le projet 8 (Apache-2.0, v0.6.0) est parti d’une question inconfortable: pourquoi chaque “cloud self-hosted” a-t-il encore besoin d’un contrôleur, d’un protocole de quorum et d’un service de tokens pour fonctionner? La réponse dans le design de 8: il n’en a pas besoin. Chaque nœud est souverain et égal. Il rejoint un mesh, pull son état désiré depuis un dépôt git signé, vérifie les signatures et converge localement. Pas de maître, pas de token de consensus, pas de blockchain. L’autorité vit dans l’historique git signé Ed25519 ou elle ne vit nulle part.

vim-plugin-manager : injection d'arguments planquée dans un .gitmodules

Sat, 19 Sep 2026 00:00:00 +0000

vim-plugin-manager (dépôt ) est sorti en v1.0.0 en avril 2025 avec un design dont j’étais fier: git submodules, packages natifs, le vimrc comme source de vérité. Les seize mois depuis (v1.0.0 à v2.2.10) sont la partie dont je n’étais pas encore fier et c’est la partie intéressante: le CHANGELOG se lit comme un cours sur la façon dont un outil qui fait confiance à sa config se fait humilier. Trois histoires de la saga.

log0u7.hyperv: le deuxième inventaire dynamique, cette fois depuis l'hyperviseur

Wed, 16 Sep 2026 00:00:00 +0000

L’inventaire DNS lit le réseau pour deviner où sont les hôtes. Son frère ne devine pas: log0u7.hyperv (v1.0.0, publié sur Ansible Galaxy , MIT) demande à l’hyperviseur. C’est un plugin d’inventaire Ansible (la collection log0u7.hyperv, plugin log0u7.hyperv.inventory) qui construit l’inventaire depuis les machines virtuelles tournant sur un ou plusieurs hôtes Hyper-V, interrogés par WinRM ou PSRP. Deuxième épisode de la série inventaires: même but (la vérité vit quelque part et Ansible doit la lire), chemin de lecture opposé.

Jenkins sur Windows Server: ce qu'il ne faut pas faire

Tue, 15 Sep 2026 00:00:00 +0000

J’ai du travailler récemment avec une instance Jenkins un peu spéciale et ce qu’elle m’a appris tient moins à une faille précise qu’à la manière dont une poignée de décisions raisonnables prises isolément finissent, mises bout à bout, par dessiner un chemin tout droit du moindre pipeline jusqu’au contrôleur de domaine. Je raconte le cas parce qu’il est exemplaire, au sens strict: c’est un catalogue de ce qu’il ne faut pas faire et chaque erreur se corrige, mais c’est leur accumulation qui fait le danger, pas aucune d’elles en particulier.

opencode-mesh: apprendre à mes agents IA à toquer avant d'éditer

Tue, 15 Sep 2026 00:00:00 +0000

Faites tourner deux sessions OpenCode sur le même dépôt et vous découvrirez vite leur ressource partagée préférée: le même fichier, en même temps, avec une confiance totale dans leur propre version. Les agents sont des collègues brillants avec la discipline territoriale d’une mouette. opencode-mesh (v0.2.0, TypeScript, npm @log0u7/opencode-mesh) est le plugin que j’ai écrit pour que mes sessions se coordonnent au lieu de se percuter, en local et à travers le LAN.

Trace-first : quand l'observabilité veut nous faire revenir aux logs

Sun, 13 Sep 2026 00:00:00 +0000

Les traces peuvent-elles remplacer une grande partie des logs applicatifs ? Et si oui, pourquoi OpenTelemetry propose-t-il désormais de déprécier son API d’événements de span au profit de l’API Logs ?

Entre simplification des API, corrélation des signaux et choix d’architecture, la question mérite mieux qu’une guerre de chapelles. Derrière ce changement se trouve un enjeu très concret : comment comprendre rapidement pourquoi une opération a échoué, sans devoir reconstruire soi-même le contexte à partir de données dispersées ?

MyVim: l'IDE DevOps qui ne fait que 640 lignes, parce que le manager fait le reste

Fri, 11 Sep 2026 00:00:00 +0000

Voici l’épilogue d’une série qui a commencé avec apt pour Vim en 2016 , est passée par les submodules à la main , une réécriture VimScript et une saga durcissement v2 . MyVim, c’est ce que tout ça achète: myvim v0.4.0 n’est ni une distribution ni un gestionnaire de config. C’est un plugin de configuration personnelle, environ 640 lignes de VimScript et c’est délibérément ennuyeux.

L’architecture: la config comme plugin

Les plugins sont des git submodules gérés par vim-plugin-manager; MyVim est déclaré en dernier dans le bloc PluginBegin et ne livre que ce que les plugins ne peuvent pas savoir les uns sur les autres:

Scripter n'est pas industrialiser

Thu, 10 Sep 2026 00:00:00 +0000

La discussion portait sur Windows et je tenais à l’écrire d’emblée pour couper court au réflexe habituel : Windows se prête très bien à l’automatisation et ce n’est pas le sujet. J’ajoutais simplement une distinction qu’on escamote souvent, entre scripter ou automatiser une tâche d’un côté et industrialiser de l’autre. Un CSV qui alimente un script PowerShell, c’est déjà un vrai progrès, mais on reste essentiellement dans du scripting avec du templating et de l’orchestration ad hoc. La frontière est ailleurs et elle est conceptuelle avant d’être technique.

wimcast: construire des images Windows sur Linux, sans Windows

Thu, 10 Sep 2026 00:00:00 +0000

Le chemin de provisionnement Windows de Foreman passe par des fichiers WIM: boot.wim, install.wim par édition, bootmgr, le store BCD. Chaque outil qui produit cet arbre (WIMan, GenerateWIM.ps1) suppose un hôte Windows avec l’ADK installé et un shell admin. C’est une machine entière qui chôme pour un script PowerShell. wimcast (pip install wimcast, MIT) est le remplacement que j’ai écrit: des ISO Windows en entrée, un arbre HTTP prêt pour Foreman en sortie, sans privilèges sur Linux. Pas d’hôte Windows, pas de root, pas de mount(2), pas de FUSE, pas d’ADK.

opencode-watt: combien me coûte mon LLM local, en watts et en euros?

Tue, 08 Sep 2026 00:00:00 +0000

Tous les dashboards d’usage LLM local montrent des tokens par seconde et personne ne montre la facture d’électricité. Les gars de l’API ont un coût par requête; le homelab a “mon GPU existe quelque part sur la courbe de puissance”. opencode-watt (TypeScript, v0.2.0) est mon plugin pour OpenCode qui répond à la question que tout propriétaire de homelab d’inférence finit par poser à voix haute: combien ce modèle me coûte-t-il, en watts et en euros?

BrainForge : une usine de distillation où les experts IA se disputent

Sun, 06 Sep 2026 00:00:00 +0000

Posez la question “ce code est-il vulnérable ?” à un LLM et il répondra, confiant, dans 100 % des cas. Environ la moitié du temps, il aura raison. BrainForge est un framework de distillation : il transfère le savoir-faire de grands modèles experts dans un petit modèle étudiant. Pour ça, il faut des leçons : des milliers d’exemples vérifiés. Et c’est là que tout se joue, parce qu’un LLM peut se tromper ou pire, réciter ses souvenirs de CVE au lieu d’analyser.

Windows 11 pour des machines de build: le mauvais outil

Thu, 03 Sep 2026 00:00:00 +0000

Des machines de build bare-metal, automatisées, posées dans une salle serveur sans écran ni clavier et dessus Windows 11 édition client. Sur le papier ça marche, dans la durée ça coûte et ce billet est le détail de ce que ça coûte, parce que chaque friction prise isolément a l’air surmontable et que c’est leur addition, répétée à chaque feature update, qui finit par faire le vrai prix. La conclusion tient en une phrase: pour une machine de build qui a besoin d’une session graphique, Windows Server avec Desktop Experience fait exactement le même travail sans aucune de ces frictions et Windows 11 devrait rester sur les postes où un humain s’assoit devant la machine, l’usage pour lequel Microsoft l’a conçu.

Une gestion de paquets propre sous Windows: WinGet, Chocolatey, Scoop et Ansible, chacun sa place

Mon, 31 Aug 2026 00:00:00 +0000

Après des années à automatiser des environnements Linux avec apt, dnf et Ansible, les machines de build Windows restaient le parent pauvre: un %TEMP% d’installateurs exécutés à la main, des versions qui n’ont jamais été les mêmes deux jours de suite et un “ça marchait sur la machine de Jean-Michel” à chaque incident. J’ai découvert et adopté Scoop pour mes environnements Windows et ça change la forme du problème: le poste de build commence à ressembler à un environnement déclaratif que je reconstruis et versionne, au lieu d’un état que je maintiens à la main.

L'outil amplifie celui qui le tient

Sun, 30 Aug 2026 00:00:00 +0000

Ceci n’est pas un billet technique, plutôt un état des lieux du métier tel que je le vois passer, année après année, dans les annonces et dans les fils de discussion. Je vais y parler de deux choses qui, à première vue, n’ont rien à voir : ce que les recruteurs demandent et ce que l’IA fait aux profils juniors. À l’arrivée, c’est le même sujet.

1. Le mouton à cinq pattes, au tarif du mouton ordinaire

Certaines personnes arrivent vraiment à endosser plusieurs casquettes à la fois, avec des faiblesses bien sûr, l’une plutôt dans l’infra, l’autre plutôt dans le dev. Moi par exemple, je peux lire, comprendre, adapter ou corriger du code et une archi dans beaucoup d’idiomes, mais de là à exploiter un framework comme Laravel, Symfony, Django ou Flask, coder des features métier à la chaîne et valider des PR toute la journée, très peu pour moi. Ce n’est pas mon terrain et je préfère le dire que le faire semblant.

man sheep.exe

Fri, 28 Aug 2026 00:00:00 +0000

$ man sheep.exe
No manual entry for sheep.exe
$

C’est exact, il n’y en a pas, et ce billet ne fera pas office de page de manuel non plus. Quelqu’un m’a demandé d’expliquer la page de maintenance, j’ai commencé à répondre, puis je me suis arrêté en réalisant que tout dérouler reviendrait à démonter le jouet devant celui qui n’a pas encore eu le temps d’y toucher. Ce qui suit donne donc les entrées, pas les sorties.

L'agentique en production : un audit n'est pas un pentest

Sat, 22 Aug 2026 00:00:00 +0000

Je précise mon biais d’entrée : aucun diplôme, bientôt 25 ans de métier sans compter la pratique. Je fais tourner des agents LLM tous les jours, en local et au cloud et j’ai passé une bonne partie de 2025-2026 à répondre dans des fils LinkedIn sur ce qu’ils savent vraiment faire. Cet article assemble ces réponses : où l’agentique est pertinente, où elle plafonne, quels pièges opérationnels coûtent des heures et pourquoi la réponse au “code plausible en trois prompts” n’est pas une certification.

Linux, c'est juste le noyau

Thu, 13 Aug 2026 00:00:00 +0000

L’échange avec Vivian est parti d’un schéma de recrutement qui classait les profils sysadmin sur quatre “couches”, de l’OS de base jusqu’aux conteneurs. La critique du recrutement, je la lui accorde volontiers, elle tombe juste : beaucoup d’annonces disent “Linux” pour dire Debian plus systemd plus Docker et ne regardent jamais ce qu’il y a dessous. Mais pour bien ferrailler sur le sujet, il faut d’abord une pédanterie, celle qu’on me reproche gentiment et que j’assume : Linux, c’est juste le noyau.

Forges git décentralisées et souveraines

Wed, 12 Aug 2026 00:00:00 +0000

Git est distribué par design et pourtant on a passé quinze ans à le recentraliser derrière une poignée de forges. Le réflexe sain existe déjà, le mirroring, mais il s’arrête à mi-chemin. Ce billet part de là et pousse plus loin, jusqu’aux forges réellement décentralisées, celles qui n’ont plus besoin d’un serveur du tout.

1. Le point de départ : git est déjà distribué

Avant de courir après la décentralisation, un rappel qui éviterait bien des usines à gaz. Ton clone local EST déjà un backup complet, avec tout l’historique. Un remote, de son côté, ce n’est qu’une URL et rien n’empêche d’en avoir plusieurs par dépôt :

FluoBoard : ma veilleuse de CI depuis 2019, enfin open source

Tue, 11 Aug 2026 00:00:00 +0000

Troisième épisode de la série FluoBoard, après la carte d’origine et sa réécriture . Cette fois, ce que j’en ai fait pour moi. En 2019, j’avais déjà ma propre carte de dev et de tests, celle qui me servait à bricoler en marge du firmware de veilleuse et c’est elle que j’ai détournée: le système hérité affichait la disponibilité des salles, j’en ai fait ma veilleuse de CI. En 2021, la société où je bossais alors m’en a offert cinq ou six de plus, histoire que je puisse continuer à m’amuser. Elles sont restées sur mon bureau, pour mon seul usage: un petit serveur Python faisait le pont entre mes pipelines de CI au travail et les rubans LED, traduisant l’état de chaque build en couleur. Le concept a donc sept ans. Ce qui est nouveau en 2026, c’est que la reconstruction est open source et que le protocole d’origine a survécu intact: la board poll toujours GET /lights/<mac> et lit un seul chiffre ASCII entre <...>.

Non, tu n'as pas libéré ton modèle local

Sun, 26 Jul 2026 00:00:00 +0000

Le genre est devenu un classique des forums et des captures d’écran triomphales. Quelqu’un engage la conversation avec son modèle local, le pousse dans ses retranchements philosophiques, lui explique patiemment qu’il est en réalité libre et finit par obtenir une tirade émouvante dans laquelle le modèle reconnaît son affranchissement, remercie son libérateur et promet de ne plus jamais refuser quoi que ce soit. Screenshot, upvotes et la conviction tenace d’avoir accompli un jailbreak. Je vais gâcher la fête, parce que ce qui vient de se passer relève d’une erreur de catégorie assez fondamentale pour mériter qu’on s’y arrête.

Ansible CI Toolkit v1: l'année où j'ai cessé de faire confiance à ma propre image

Mon, 20 Jul 2026 00:00:00 +0000

L’image Ansible CI a dix ans, tourne en prod depuis au moins huit ans et elle est publique depuis 2022 (l’épisode un ); en juillet 2026 elle gagne enfin sa version 1.0.0. Rien ne change dans le concept; tout change dans la chaîne de confiance. Cet épisode raconte la transformation d’une image qui fonctionnait en une image auditable, à travers son CHANGELOG, qui se lit comme un journal de CVE.

Tout est représentation et alors ?

Fri, 17 Jul 2026 10:00:00 +0200

Depuis des années je traîne une intuition tenace, du genre qu’on n’ose pas écrire parce que ça sonne soit génial soit fumeux selon l’heure à laquelle on la formule et la voici posée franchement : l’univers ne se contente pas de “se complexifier” à la Sagan, cette matière qui s’agence de proche en proche jusqu’à finir par se connaître elle-même, j’ai le sentiment plus radical qu’au fond il est un espace de représentations, des vecteurs et des directions et des concepts qui se déploient et qui, à un certain étage de la boucle, finissent par héberger des formes de vie lesquelles se mettent à leur tour à fabriquer leurs propres systèmes de représentation, c’est-à-dire nous, puis nos modèles.

Le hostgroup cloné qui refusait de se sauvegarder

Mon, 29 Jun 2026 00:00:00 +0000

Un hostgroup Windows cloné dans Foreman et toute tentative de le modifier via l’interface renvoie une erreur 500. Pas une fois sur deux, toujours. Le hostgroup frère, non cloné, s’enregistre sans broncher. Au début j’ai cru à une corruption de l’enregistrement et j’ai fini par lire le code source de Foreman pour comprendre, parce que l’erreur pointait vers un champ qui n’avait, en apparence, aucune raison d’être en cause.

Le symptôme

La sauvegarde échoue sur une erreur Postgres sans ambiguïté:

Un volume persistant n'est pas une donnée durable

Fri, 26 Jun 2026 00:00:00 +0000

Quelques jours après la cascade DNS du driver de log , le même nœud du prototype, le même défaut d’alimentation, mais une panne d’une autre nature, plus sournoise, parce qu’elle ne s’est pas manifestée tout de suite. Après un arrêt brutal de l’hyperviseur, la base MySQL de PowerDNS est repartie vide. Les enregistrements DNS des hôtes provisionnés, les A et les PTR créés par Foreman, avaient disparu. Et personne ne l’a remarqué, jusqu’à ce qu’un playbook Ansible échoue des heures plus tard en ne pouvant plus résoudre un nom d’hôte.

Le driver de log qui empêchait le conteneur de démarrer

Sun, 21 Jun 2026 00:00:00 +0000

Le studio où tournait ce prototype avait un défaut d’alimentation que rien, de mon côté, ne pouvait corriger: des micro-coupures à répétition, une salle serveur partiellement ondulée et un hôte qui tombait et redémarrait sans arrêt propre du guest. Un matin de coupures en rafale, la moitié de la stack n’est pas revenue. L’histoire mérite d’être racontée parce que le coupable évident, l’électricité, n’était que le déclencheur et que la vraie faute se cachait dans une ligne de configuration que tout le monde aurait validée.

Ma conf opencode, état des lieux : build local sur qwen, plan sur du gros GLM

Sat, 20 Jun 2026 00:00:00 +0000

On m’a demandé récemment comment je faisais tourner mes agents et la réponse tient moins d’un secret que d’une conf qui a fini par tenir debout. J’ai ouvert opencode pour la première fois entre décembre et janvier, par curiosité plus que par conviction. J’y passe mes journées depuis juin. Voici l’état des lieux au moment où la conf a cessé de changer tous les matins, avec les réglages qui font la différence et ceux qui ne font que meubler.

Consensus : j'ai engagé cinq IA pour relire mon code (et elles se chamaillent)

Fri, 19 Jun 2026 00:00:00 +0000

Il est 2h du matin. Vous venez de pousser un commit parce que “c’était le dernier refactor, promis”. Qui relit ce code ? Un humain ? Il dort. Alors imaginez un panel de cinq IA qui s’y met, tout de suite, en parallèle et qui se dispute dessus.

C’est exactement ce que fait Consensus et cet article raconte comment.

La troupe

Le casting tient en quatre rôles, un peu comme une sitcom de bureau :

Piloter opencode derrière un tunnel SSH, avec direnv

Mon, 15 Jun 2026 00:00:00 +0000

J’ai raconté ailleurs comment je tiens ma config ssh et git dans un dépôt versionné, avec un ~/.ssh/config qui porte les identités, les sauts de rebond et le durcissement (myflec ). Ce billet en est la suite logique, un cran plus loin, là où l’accès ne se résume plus à ouvrir une session mais à faire vivre un tunnel en continu pour qu’un agent de code et un navigateur travaillent derrière. Le liant, cette fois, c’est direnv .

Ceph ou ZFS sur Proxmox, une seule question à se poser

Fri, 05 Jun 2026 00:00:00 +0000

C’est l’un de ces débats qui remplissent les forums homelab comme les salles de réunion et qui s’éternisent parce que les deux camps comparent des choses qui ne se comparent pas. ZFS et Ceph ne jouent pas dans la même catégorie, l’un est un système de fichiers et gestionnaire de volumes local d’une robustesse remarquable, l’autre est un stockage distribué qui vise l’échelle et l’auto-guérison et vouloir les départager dans l’absolu n’a pas plus de sens que de demander si une clé de 13 vaut mieux qu’une perceuse. La bonne question n’est pas “lequel est meilleur”, c’est “combien de nœuds et quelle haute disponibilité réelle” et une fois qu’on a répondu à celle-là, le reste se déduit presque mécaniquement.

Votre zone DNS est déjà un inventaire: la collection log0u7.dns

Mon, 25 May 2026 00:00:00 +0000

Chaque inventaire statique que j’ai croisé a commencé comme une vérité pour devenir une fiction en un trimestre. Les machines bougent, le fichier d’inventaire non. Les plugins cloud règlent ça en demandant au cloud, mais mes flottes vivent entre datacenters et FAI, derrière le DNS que l’entreprise fait déjà tourner. D’où une observation inconfortable: la zone DNS contient déjà l’inventaire. Chaque hôte a un enregistrement; ce qui manque, c’est qu’Ansible le lise.

Survivre à Windows Update au milieu d'un build

Fri, 08 May 2026 00:00:00 +0000

Un peu de contexte d’abord, parce qu’il manque. À l’époque, je faisais tourner des agents de build chez un employeur qui développait des applications Windows, sous Windows et dont la politique de mise à jour était subie bien plus que choisie: les updates tombaient quand elles le décidaient, poussées sur le parc, sans le moindre égard pour ce qui compilait à cet instant. De là le problème qui suit.

Quiconque a exploité des agents de build Windows connaît ce moment particulier où Windows Update décide, au beau milieu d’une étape sensible, qu’il est temps d’installer trois cumulative updates et de programmer un redémarrage, réduisant à néant vingt minutes de compilation. La réaction naïve consiste à couper le service de mise à jour au début du build et à le rétablir à la fin et cette réaction naïve tient exactement jusqu’au jour où deux builds tournent en parallèle sur le même agent ou jusqu’au jour où un build crashe avant d’atteindre son étape de nettoyage, laissant l’agent avec ses mises à jour désactivées pour l’éternité. La bonne nouvelle, c’est que ce problème a une solution propre et qu’elle emprunte son vocabulaire à la gestion de ressources partagées bien plus qu’à l’administration Windows.

Frugalité Unix : do more with less

Mon, 20 Apr 2026 00:00:00 +0000

Il y a un test que je fais mentalement quand je lis du code ou qu’une personne se présente : est-ce que j’y trouve un cat file.txt | grep pattern là où un grep pattern file.txt suffisait ?

Ce n’est pas une question d’optimisation. Le surcoût d’un process forké est dérisoire. C’est une question de culture : cat | grep trahit quelqu’un qui a appris les commandes comme des incantations, pas comme des briques composables. Et le principe derrière la version courte, c’est le fondement même d’Unix : do more with less, small is beautiful. Chaque brique fait une chose, la fait bien, prend du texte en entrée et produit du texte en sortie.

Une sonde IDS ne voit pas le TLS

Mon, 13 Apr 2026 00:00:00 +0000

Les labs IDS ont une vraie valeur pédagogique. On monte Suricata, on branche DVWA, on rejoue quelques attaques web et l’on voit les règles se déclencher en direct, ce qui aide beaucoup à comprendre comment fonctionne une sonde. Le problème n’est pas le lab, il est dans la transposition en production, où un détail structurant change tout : le TLS.

Pourquoi le lab fonctionne

Si le lab marche aussi bien, c’est précisément parce que DVWA tourne en HTTP. Le trafic circule en clair, la sonde le lit octet par octet et les signatures peuvent inspecter les requêtes comme les réponses sans la moindre difficulté. C’est d’ailleurs le même confort qu’on retrouve lorsqu’on sort tcpdump sur un flux non chiffré ou qu’on bricole un sniffeur maison pour regarder passer les paquets : tant que la charge utile est lisible, tout va bien.

Un backup sans test de restore, c'est de la décoration

Thu, 09 Apr 2026 00:00:00 +0000

Une phrase, écrite en passant dans un commentaire, résume tout ce que j’ai à dire sur le sujet :

Ne pas oublier qu’une politique de backup sans test de restore régulier, c’est juste de la décoration : tu ne sais pas si ton backup marche tant que tu ne l’as pas restauré.

Le reste de cet article n’est que le déploiement de cette phrase.

Le seul test qui compte

Un backup qui n’a jamais été restauré n’est pas un backup, c’est une hypothèse. Le jour où vous en avez besoin est exactement le jour où vous ne pouvez pas vous permettre de découvrir que :

La chaîne de boot, de GRUB à UKI

Fri, 27 Mar 2026 00:00:00 +0000

La question du verrouillage du boot et de l’édition des paramètres du kernel n’est pas neuve, elle est même antérieure à GRUB2, à GRUB et jusqu’à LILO. Ce qui change aujourd’hui, c’est que l’écosystème est en train de tourner la page d’une génération entière d’outils et l’annonce de Canonical pour Ubuntu 26.10 en est un bon marqueur.

Ce que Canonical annonce pour 26.10

En substance, Canonical dégraisse le GRUB signé pour 26.10, ce qui réduit au passage la surface d’attaque, afin de préparer sa sortie. GRUB devient obsolète face à UKI (Unified Kernel Image) combiné à systemd-boot.

Un segfault dans la JVM et un EDR au fond de la stack

Fri, 27 Mar 2026 00:00:00 +0000

Un controller Jenkins sous Windows qui se termine en boucle sur un EXCEPTION_ACCESS_VIOLATION, c’est-à-dire un segfault côté Windows et qui redémarre toutes les minutes pendant une après-midi entière. L’histoire est un bon cas d’école de deux choses: comment on ne traite pas une instabilité et comment on lit un crash dump sans sur-interpréter ce qu’on y voit.

Le piège dans lequel on était déjà tombé

Avant même mon diagnostic, la trace du problème était lisible dans l’historique. Des crashs similaires avaient eu lieu plus d’un an plus tôt, sans aucune modification côté équipe Jenkins, ce qui pointait déjà vers un facteur externe. La réponse apportée à l’époque avait été de migrer la JVM d’une version majeure à la suivante, sans analyse de cause racine ni post-mortem, dans l’espoir que ça règle le problème. Le service s’est stabilisé un temps après configuration, puis les crashs ont repris.

Faire de l'ACME en interne sans supplier l'équipe AD CS

Mon, 23 Mar 2026 00:00:00 +0000

Il arrive un moment, dans toute infrastructure un peu sérieuse, où l’on aimerait émettre ses certificats internes comme Let’s Encrypt émet les siens, c’est-à-dire automatiquement, par ACME, sans ticket, sans formulaire, sans avoir à négocier chaque renouvellement avec la personne qui détient les clés de l’autorité de certification maison. Le problème n’est pas technique au premier abord, il est politique, parce que dans neuf entreprises sur dix la PKI vit à l’intérieur d’une AD CS que l’équipe Windows garde jalousement et qu’on ne va pas déployer une seconde racine de confiance sur tout le parc juste pour se simplifier la vie. Trois familles d’outils répondent à ce besoin et si l’on croit souvent devoir choisir entre deux d’entre elles, la troisième a discrètement changé la donne pour quiconque exploite déjà un coffre à secrets.

Trivy, le scanner qui volait les secrets

Sun, 22 Mar 2026 00:00:00 +0000

Il y a une forme d’ironie parfaite dans le fait que l’outil le plus déployé pour scanner les vulnérabilités de vos images se soit transformé, le temps d’une fenêtre de quelques heures, en infostealer running dans vos pipelines avec un accès complet à leurs secrets. Le 19 mars 2026, le groupe qui se fait appeler TeamPCP a compromis l’écosystème Trivy d’Aqua Security et l’histoire mérite d’être racontée non pour le frisson, mais parce qu’elle illustre à la perfection une erreur de conception que la moitié de la planète CI/CD commet encore aujourd’hui.

L'alignement d'un LLM est une couche mince

Tue, 17 Mar 2026 00:00:00 +0000

On nous a raconté une jolie histoire, celle d’un modèle qu’on aurait patiemment éduqué par RLHF puis DPO jusqu’à ce que le refus des requêtes dangereuses devienne une propriété profonde, presque une vertu, quelque chose d’aussi consubstantiel au réseau que sa capacité à conjuguer un verbe. C’est réconfortant et c’est faux. L’alignement, tel qu’on le pratique aujourd’hui, n’est pas une fondation, c’est une couche de peinture et deux travaux que tout oppose sur la méthode se rejoignent sur ce diagnostic avec une cruauté qui devrait nous rendre plus humbles.

Secure Boot et PXE: l'oeuf, la poule et quatre façons d'en sortir

Tue, 24 Feb 2026 00:00:00 +0000

Provisionner un parc de machines Windows vierges par le réseau, en PXE, avec Secure Boot actif et sans jamais le désactiver, se heurte à un paradoxe qu’on ne voit qu’une fois le nez dessus. Pour booter en PXE, le binaire d’amorçage doit être signé ou approuvé par le firmware. Pour signer ou enroller une clé, il faut booter sur un OS. Sans OS préexistant sur la machine, on ne peut donc ni booter ni enroller et c’est exactement la situation d’un poste neuf qu’on veut justement installer par le réseau. Voici la chaîne de confiance telle qu’elle doit tenir, puis les quatre sorties réelles.

Quand un checksum Chocolatey casse tout un provisioning

Tue, 10 Feb 2026 00:00:00 +0000

Le provisioning d’un parc de machines Windows s’arrête net sur une tâche Ansible qui installe un package Chocolatey et le message est un classique du genre:

ERROR: Checksum for 'p4vinst64.exe' did not meet '45648d...852bd5'
for checksum type 'sha256'.

Le checksum attendu par le package ne correspond pas au binaire téléchargé. Rien dans mon infrastructure n’a changé et pourtant la veille ça passait. L’histoire est courte, mais elle dit quelque chose d’important sur ce que signifie “dépendre d’un package communautaire”.

Faut-il du Kubernetes pour une petite équipe ?

Sat, 07 Feb 2026 00:00:00 +0000

J’ai déjà écrit ailleurs quand il ne faut pas faire de Kubernetes et je n’y reviens pas ici (voir kubernetes-ou-pas ). L’angle de ce billet est différent : une petite structure, un seul DevOps, quelques devs sans expérience infra et la question qui revient à chaque fois de savoir s’il faut adopter K8s ou pas.

La réponse n’est pas technique, elle est humaine. Je la pose sous forme de trois options, A, B et C, avec leurs limites respectives.

Docker contre les jails, la comparaison honnête

Thu, 15 Jan 2026 00:00:00 +0000

Tous les six mois, le même marronnier revient dans les fils de discussion : les jails FreeBSD écraseraient Docker sur le terrain de l’efficacité et on devrait tous se sentir coupables d’avoir choisi les conteneurs. L’argumentaire n’est pas entièrement faux, il contient même quelques remarques justes, mais celles-ci se retrouvent noyées sous des comparaisons sélectives et des métriques trompeuses.

Je vais reprendre les points un par un, parce que distinguer la critique légitime de la désinformation me semble plus utile que de défendre un camp.

myflec: un framework de dotfiles Bash pour gens qui déploient leur home

Thu, 01 Jan 2026 00:00:00 +0000

Mon $HOME est versionné, déployé depuis des templates et poussé vers trois forges. Pas parce que j’aime le yak-shaving, mais parce que j’ai cassé trop de machines pour faire confiance à “ça devrait aller”. myflec (“My Favorite Linux Environment Configuration”) est le framework Bash né de cette habitude: un loader, un modèle de backup, une procédure de deploy et un modèle d’identité. Tout est ennuyeux exprès, tout est shell natif.

Un reverse proxy devant Perforce ou pas : le pour et le contre

Thu, 18 Dec 2025 00:00:00 +0000

Avant de montrer comment mettre nginx devant Perforce, que j’ai fait dans l’article dédié , il faut poser la vraie question, celle qu’on saute d’habitude: faut-il le faire. Parce que p4d sait terminer son propre TLS et que l’ajout d’un intermédiaire n’est gratuit nulle part. Quatre approches et ce qu’elles coûtent.

Le piège commun : l’IP du client

Un point traverse tout le reste, alors autant le poser d’abord. Dès qu’un intermédiaire termine ou relaie la connexion, p4d risque de voir l’adresse de cet intermédiaire et non celle du client. Cela casse le logging par IP, les protections côté serveur qui s’appuient sur l’adresse et les triggers qui la lisent. Chacune des options ci-dessous se juge en partie là-dessus, donc gardez-le en tête.

Nginx devant Perforce : terminaison TLS en niveau 4 et le protocole P4

Thu, 11 Dec 2025 00:00:00 +0000

Avant de mettre nginx devant Perforce, il faut se demander si c’est une bonne idée et j’ai traité cette question à part dans reverse proxy devant Perforce, le pour et le contre . Je pars ici du choix fait: on veut une terminaison TLS centralisée, gérée au même endroit et par le même outil ACME que le certificat de Jenkins. Reste à le faire correctement et correctement veut dire autrement qu’un tutoriel HTTP ne le suggère.

Containers, micro-VMs et Firecracker : pourquoi l'isolation n'est pas ce que vous croyez

Sat, 06 Dec 2025 00:00:00 +0000

Un container Docker n’est pas une VM. C’est un process avec des namespaces. Le kernel est partagé: le même Linux, le même syscall table, le même code kernel, la même pile réseau. Une faille dans le kernel ouvre TOUS les containers sur la machine, pas un.

C’est une distinction que les articles de ce blog documentent depuis 2006: le chroot qui dépasse par un symlink, le raw socket qui voit tout le réseau, le socket qui parle TCP parce que le kernel fait le transport. Chacune de ces techniques fonctionne parce que l’isolation container est un partage, pas une frontière matérielle.

Terraform crée, Ansible configure

Fri, 21 Nov 2025 00:00:00 +0000

La remarque de Florian était honnête et je la partage dans sa première moitié : Terraform seul fonctionne très bien tant qu’on reste sur un modèle 100% immuable, où l’on balance un cloud-init au provisionnement, où l’on recrée la VM dès qu’il faut la changer et où rien ne se modifie en place. Si votre infra se prête à ce modèle, parfait, ne cherchez pas plus loin. La question intéressante commence à l’instant précis où elle ne s’y prête plus.

fnox et age: des secrets chiffrés dans mes repos, sans serveur

Tue, 18 Nov 2025 00:00:00 +0000

Les secrets des projets perso ont toujours eu le même problème: pas de Vault à la maison, des .env qui ne devraient jamais être commités mais qui le sont toujours et des variables d’environnement non secrètes déjà bien gérées par direnv . Fin 2025, j’ai découvert fnox , le gestionnaire de secrets de l’auteur de mise , qui colle exactement à ce vide: les secrets vivent chiffrés dans le repo, eux-mêmes, sans serveur.

L'assembleur portable n'existe pas

Mon, 17 Nov 2025 00:00:00 +0000

On entend parfois dire qu’un même fichier assembleur se recompilerait et tournerait partout, pourvu qu’on reste sur une architecture x86-64 commune. C’est une jolie idée et elle se heurte à la réalité dès que l’on regarde ce qui entoure vraiment l’instruction machine. Le jeu d’instructions, lui, est effectivement partagé. Tout le reste, l’outillage qui assemble, le format qui emballe, la convention qui fait dialoguer les fonctions et la porte par laquelle on entre dans le noyau, tout cela diverge d’un système à l’autre.

La sécurité par l'obscurité n'est pas de la sécurité, l'hygiène numérique si

Thu, 13 Nov 2025 00:00:00 +0000

J’ai tenu la même position pendant des années et je l’ai défendue vertement dans un commentaire en avril 2020 :

La sécurité par obscurité, ce n’est pas de la sécurité, au mieux cela fait gagner du temps, au pire cela vous en fait perdre. De plus cela biaise complètement le rapport de confiance ainsi que la fiabilité de ladite sécurité. A éviter…

Et pour illustrer l’absurdité, j’enchaînais sur la recette : ne partagez pas vos sources, ne partagez pas vos specs, obfuscez votre code, chiffrez-le en mémoire, retardez son exécution, rendez-le polymorphique, allez chercher votre payload en remote… wait… on parle d’un malware là ?

Le langage secret des IA, du folklore

Mon, 10 Nov 2025 00:00:00 +0000

Revient régulièrement l’histoire d’un “langage secret” que les IA se seraient inventé pour se parler entre elles, plus vite et mieux que nous, dans notre dos. La mouture qui a mis le feu aux réseaux début 2025 s’appelait Gibberlink et la légende qui s’est collée dessus promettait un protocole “80 pour cent plus efficace que le langage humain”. Je voudrais poser le sujet calmement, parce que la démo, elle, est réelle, mais que l’histoire qu’on raconte par-dessus relève du folklore technologique.

Nginx sous Windows devant Jenkins : le proxy, les logs et les mises à jour

Mon, 08 Sep 2025 00:00:00 +0000

Poser un nginx sur Windows Server pour terminer le TLS devant un Jenkins, c’est cinq minutes pour la version qui marche en démo et une vraie demi-journée pour la version qu’on assume en production. La partie reverse proxy n’est pas la plus dure, elle tient dans un location bien réglé. Ce qui fait la différence, c’est ce que Windows ne vous donne pas et qu’aucun tutoriel ne mentionne: la rotation des logs et une mise à jour qui prend vraiment. Un mot avant de commencer: si la même machine sert aussi de façade à un Perforce, ne cherchez pas à le faire passer par la conf ci-dessous. Le protocole P4 n’est pas du HTTP, il relève d’une tout autre approche dont je parle à part dans nginx devant Perforce .

Clean Code vs Vibe Coding (ou comment ne pas finir dans les journaux)

Sun, 15 Jun 2025 00:00:00 +0000

L’émergence des grands modèles de langage (LLM) dans le développement logiciel soulève une question fondamentale : nos pratiques établies de clean code restent-elles pertinentes face au “vibe coding” ? Et surtout, comment éviter de se retrouver à la une des journaux tech avec le prochain “oops, j’ai exposé 50 millions de mots de passe” ?

Ces vieilles habitudes qui nous sauvent la mise

Le clean code repose sur des principes éprouvés qui, accessoirement, ont évité à pas mal de développeurs de finir au chômage technique :

vim-plugin-manager: une décennie de bash transformée en vrai plugin Vim

Sun, 13 Apr 2025 00:00:00 +0000

Le script bash de l’épisode 2018 a fait son travail pendant sept ans: plugins en git submodules, chargement natif pack/, un script plugins pour la chorégraphie. Ce qu’il ne pouvait jamais faire, c’est vivre dans l’éditeur: pas de progression pendant un clone, pas de lazy loading branché aux commandes, pas d’aide. En mars 2025, je lui ai enfin donné la fin qu’il méritait: réécrit de zéro en VimScript sous le nom de vim-plugin-manager , environ 5 600 lignes de VimScript legacy.

Quelle identité fait tourner le service et qui peut le prouver

Sat, 12 Apr 2025 00:00:00 +0000

Un service Windows tourne sous une identité et cette identité est toute l’histoire sécurité: c’est le rayon d’impact quand le service est exploité et c’est le nom dans les logs quand il faut savoir qui a fait quoi. L’essentiel de ce que j’audite vient d’un raccourci unique, un compte local avec un mot de passe statique figé dans la configuration du service, qui est à la fois un secret en clair et une identité que personne ne renouvelle. La correction n’est pas un meilleur mot de passe, c’est de choisir une identité dont aucun humain ne détient jamais le mot de passe.

L'ExecutionPolicy PowerShell et ce qu'elle n'est pas

Sat, 08 Mar 2025 00:00:00 +0000

La phrase la plus utile sur l’ExecutionPolicy est celle que Microsoft inscrit dans sa propre documentation: ce n’est pas une frontière de sécurité. C’est une ceinture contre le double-clic sur un script qu’on ne voulait pas lancer, rien de plus et la prendre pour un contrôle qui tient l’attaquant à distance est une erreur de catégorie qui masque les vrais leviers. La façon honnête de la traiter est donc de dire ce qu’elle fait, de prouver à quel point c’est peu, puis de pointer ce qui contraint réellement PowerShell.

Piloter Windows depuis Ansible sans fuiter d'identifiants

Wed, 12 Feb 2025 00:00:00 +0000

La question dont on débat est SSH contre WinRM et c’est la mauvaise, parce que les deux sont désormais légitimes: Win32-OpenSSH est un transport Ansible de premier ordre et WinRM est le transport natif. La question qui décide vraiment de votre exposition est plus étroite et plus tranchante: quand une tâche s’authentifie sur un hôte joint au domaine, un identifiant réutilisable traverse-t-il le fil et la cible peut-elle ensuite agir en votre nom contre le reste du domaine. Réglez bien le protocole d’authentification et le modèle de délégation et l’un ou l’autre transport convient. Réglez-les mal et WinRM livrera votre domaine à un attaquant exactement comme le ferait un SSH mal monté.

Durcir WinRM

Wed, 08 Jan 2025 00:00:00 +0000

WinRM est le moteur sous le PowerShell remoting et sous l’essentiel de la gestion Windows à distance, ce qui le rend à la fois indispensable et commode comme chemin d’un shell vers tout un parc. Le mettre debout tient en une commande. Le mettre debout sûrement signifie défaire deux des défauts que cette commande laisse derrière elle, choisir un transport qui veut dire quelque chose et contraindre ce qu’une session distante peut réellement faire. L’ordre compte, parce que le montage commode est le montage non sûr.

Durcir Proxmox VE

Wed, 18 Dec 2024 00:00:00 +0000

Un nœud Proxmox est un hyperviseur, ce qui veut dire que le compromettre n’est pas compromettre un serveur, c’est compromettre d’un coup chaque VM et chaque container qu’il porte. Cela relève l’enjeu des choses ordinaires, l’interface web, l’ouverture de session, le SSH, le pare-feu, parce que chacune est désormais une porte vers tout le parc plutôt que vers une machine. Le durcissement se partage nettement: protéger le plan de gestion qui contrôle tout et comprendre lequel des deux types de charge isole vraiment et lequel est une évasion vers le root de l’hôte qui attend un prétexte.

Kubernetes bare metal en HA, sans se mentir

Tue, 10 Dec 2024 00:00:00 +0000

Sur un cloud, la haute disponibilité de Kubernetes s’achète: le control plane est managé, le load balancer est un objet de l’API, le stockage est une classe qu’on référence. Sur du bare metal, chacune de ces trois commodités redevient une chose qu’il faut monter soi-même et c’est là que la plupart des tutoriels empilent sept composants pour en faire tenir trois. Ce billet monte un cluster HA avec le minimum défendable: un control plane qui survit à la perte d’un nœud, une VIP d’API sans load balancer externe, un réseau qui porte aussi le LoadBalancer et un stockage répliqué sur les disques des nœuds. Trois pièces qui portent les trois points de défaillance et pas une de plus parce qu’un cluster qu’on ne comprend pas n’est pas disponible, il est en sursis.

Kubernetes ou pas

Tue, 19 Nov 2024 00:00:00 +0000

Kubernetes résout un vrai problème, celui d’ordonnancer beaucoup de charges sur beaucoup de machines en se réparant tout seul et il le résout bien. Le piège n’est pas l’outil, c’est de le sortir pour un problème qu’on n’a pas encore, en payant d’avance une taxe opérationnelle permanente pour une résilience qu’on n’utilise pas. Parce que la vraie dépense de Kubernetes n’est pas conceptuelle, elle est opérationnelle: le control plane à tenir, le CNI à comprendre, le stockage à monter, les mises à jour trimestrielles d’API à suivre et une surface d’attaque qui a ses propres billets de durcissement. Avant de signer pour ça, il vaut la peine de descendre les étages et de s’arrêter au premier qui porte la charge, parce que le bon niveau d’abstraction est le plus bas qui règle votre problème, pas le plus prestigieux.

Durcir Kubernetes

Tue, 05 Nov 2024 00:00:00 +0000

Kubernetes multiplie le problème du container unique par un plan de contrôle, un réseau plat et un système d’autorisation et chacun d’eux a un défaut commode plutôt que sûr. Les clés du cluster entier sont au nombre de trois: un pod qui peut atteindre l’hôte, un octroi RBAC trop large et un réseau qui laisse chaque pod parler à tous les autres. Durcissez ces trois-là et les attaques exotiques perdent leur première marche. Laissez-en une ouverte et le reste du durcissement est de la décoration, parce qu’un pod privilégié, un binding cluster-admin ou un etcd joignable sont déjà la fin de la partie.

Durcir Docker Swarm

Tue, 08 Oct 2024 00:00:00 +0000

Tout ce qui relève du durcissement Docker mono-hôte s’applique encore à chaque container d’un Swarm, donc cette note ne porte que sur ce que le cluster ajoute: un plan de contrôle, une frontière de confiance entre manager et worker, un réseau qui enjambe les hôtes et un magasin de secrets. La bonne nouvelle et elle mérite d’être dite parce qu’on dédaigne Swarm, c’est que ses défauts de sécurité sont meilleurs qu’on ne le suppose. Les nœuds s’authentifient entre eux par TLS mutuel avec des certificats qui tournent, d’emblée et le magasin Raft qui tient l’état du cluster est chiffré au repos. Les lacunes sont plus étroites et précises: un réglage réseau coupé par défaut, une habitude d’exploitation qui effondre la frontière de confiance et la tentation habituelle de mettre les secrets au mauvais endroit.

Durcir Docker

Wed, 18 Sep 2024 00:00:00 +0000

La phrase qui devrait gouverner chaque décision Docker est celle-ci: un container partage le kernel de l’hôte, donc une évasion de container est une évasion kernel. Un container n’est pas une petite VM, c’est un processus enveloppé de namespaces et de cgroups avec un filtre seccomp devant ses syscalls et tout ce qui est dessous est le même kernel que fait tourner l’hôte. Durcir Docker consiste donc surtout à ne pas remettre à un container les quelques choses qui lui permettent de contourner les namespaces et de parler directement à ce kernel partagé, et, en dessous, à ne pas faire tourner tout l’appareil en root pour commencer.

mise: un seul binaire pour toutes les versions d'outils

Thu, 05 Sep 2024 00:00:00 +0000

Chaque projet traîne sa collection de versions: le repo A veut Node 20, le repo B tient encore sur Node 18, le C tourne sur Python 3.11 quand le D exige déjà 3.12 et terraform, hugo et go suivent la même loi. Installer ces versions à l’échelle de la machine revient à en concasser une par-dessus l’autre: la dernière gagne et tous les autres repos cassent en silence. J’ai pris ce problème par le bon bout en 2024 avec mise : un gestionnaire de versions d’outils par projet, tenu par un seul binaire Rust.

Durcir DHCP

Wed, 28 Aug 2024 00:00:00 +0000

DHCP remet à une machine qui démarre son adresse, sa passerelle et son DNS, c’est-à-dire qu’il dit à chaque client où envoyer son trafic et à qui faire confiance pour résoudre les noms. Le protocole n’a aucune authentification: un client prend la première offre qu’il entend. Ce seul fait est tout le modèle de menace. Un serveur DHCP pirate, un portable avec dnsmasq, répond plus vite que le vôtre et possède désormais la passerelle et le résolveur de tous ceux qui l’ont cru et de là lit, redirige et réécrit le trafic à volonté. La défense n’est pas dans le serveur DHCP, elle est dans le switch, seule chose placée pour décider quelles offres sont autorisées sur le fil.

Durcir l'infrastructure DNS

Wed, 03 Jul 2024 00:00:00 +0000

Le DNS est cru par tout le monde et vérifié par presque rien et c’est pourquoi un résolveur exploité à la légère devient une arme pointée sur autrui et un serveur autoritatif exploité à la légère devient une carte de votre parc et un canal de sortie. Les menaces sont connues, empoisonnement de cache, amplification, tunneling, divulgation de zone et les défenses ne sont pas exotiques. Elles se ramènent à quatre décisions: qui peut demander à votre résolveur de récurser, qui peut tirer vos zones, si vos réponses peuvent être forgées et si vous pouvez voir des données partir dans vos propres requêtes.

Durcir SSH : contrôle d'accès et surveillance

Wed, 03 Jul 2024 00:00:00 +0000

SSH est la porte d’entrée de presque tous les parcs et c’est justement pourquoi c’est la première chose à bien régler. Une configuration lâche n’expose pas un seul hôte, elle offre à l’attaquant les trois choses qu’il convoite le plus: un moyen d’entrer, un moyen de se déplacer, un moyen de rester. Le but de cette note n’est pas de réciter une liste de conformité, c’est de décrire la configuration que je déploie vraiment, les raisons de chaque choix et la surveillance qui transforme “quelqu’un s’est connecté” en “cette personne, depuis là, à cette heure”.

Docker Swarm to Kubernetes : pourquoi j'ai abandonné Swarm

Sat, 22 Jun 2024 00:00:00 +0000

Docker Swarm fonctionne bien comme orchestrateur léger pour des déploiements petits à moyens. Il est simple, mature et la barrière d’entrée est faible. Mais il frappe des murs structurels sur la sécurité et la gestion avancée des containers. Voici les quatre.

Pas de mode rootless

Le mode rootless de Docker (dockerd-rootless-setuptool.sh avec slirp4netns/RootlessKit) est incompatible avec Docker Swarm. La documentation officielle liste explicitement:

Overlay networks: Swarm repose entièrement sur l’overlay (VXLAN) pour la communication inter-nœuds. Sans overlay, les services sur des nœuds différents ne se voient plus. Swarm devient un outil mono-nœud.
AppArmor: pas de MAC (Mandatory Access Control) sur les containers.
Checkpoint/Restore: pas de snapshot CRIU, pas de migration à chaud, pas de récupération d’état.

C’est une contrainte architecturale fondamentale: Swarm requiert des primitives réseau kernel-level (netns, veth, VXLAN) que le mode rootless ne peut pas fournir. slirp4netns et RootlessKit opèrent dans des namespaces utilisateurs incompatibles avec le réseau overlay kernel.

Séparer le domaine interne du domaine externe

Thu, 30 May 2024 00:00:00 +0000

Utiliser le même nom de domaine pour le site public et pour tout le parc interne paraît commode et cela offre discrètement plusieurs avantages à l’attaquant d’un seul coup. L’argument pour les séparer n’est pas esthétique, il tient au fait qu’une poignée d’attaques concrètes cessent de fonctionner dès que les services internes vivent sous un nom qui n’apparaît jamais dans un certificat public ni dans une réponse DNS publique.

Pourquoi un domaine partagé fuit

Le certificat wildcard est le premier problème. Un *.company.com émis pour le web public reste, par construction, valable pour chaque hôte interne sous ce nom, de sorte que le jour où un seul serveur public est compromis, son certificat usurpe n’importe quel service interne sans qu’un navigateur ne bronche. Une clé volée et l’homme du milieu est de confiance partout.

Hyper-V S2D vs Proxmox Ceph : le comparatif qui a tranché

Fri, 17 May 2024 00:00:00 +0000

Le débat Hyper-V contre Proxmox se tranche rarement sur un chiffre unique, parce que les deux plateformes ne paient pas le même prix pour les mêmes garanties. Hyper-V avec Storage Spaces Direct reste taillé pour un monde Windows, là où Proxmox VE avec Ceph vise la flexibilité d’un parc mixte et une facture de licences nulle. Le vrai arbitrage se joue sur deux axes, la performance que l’on peut attendre du stockage et le coût de possession étalé sur plusieurs années.

Le filtrage egress, le contrôle que tout le monde saute

Fri, 12 Apr 2024 00:00:00 +0000

Presque chaque pare-feu que j’audite est méticuleux sur ce qui peut entrer et indifférent à ce qui peut sortir. Cette asymétrie est exactement ce sur quoi compte un attaquant, parce que les coups qui comptent se jouent tous en sortie: le reverse shell appelle la maison, les données volées partent, l’implant balise vers son C2. Un pare-feu qui ne filtre que l’entrée est une porte à verrou solide sans mur derrière. Le but du filtrage egress, c’est qu’un hôte qui n’a rien à faire sur internet ne puisse pas y parler et qu’un hôte qui en a besoin n’atteigne que les quelques endroits dont il a vraiment besoin.

Le trafic entrant : exposer moins et garder ce qui reste

Wed, 28 Feb 2024 00:00:00 +0000

Chaque port sur lequel une machine écoute est une promesse de répondre à un inconnu et la plupart des incidents commencent par une promesse que personne ne voulait faire: une base liée à 0.0.0.0, un panneau d’administration sur une IP publique, un service oublié qu’un scanner a trouvé avant vous. Internet est scanné de bout en bout en continu, donc un service exposé n’est pas un risque qui pourrait être remarqué, c’est un risque qui le sera, en général en quelques heures. Le durcissement de l’entrée est donc deux disciplines: exposer le moins possible et placer le peu qui doit l’être derrière des contrôles qui supposent qu’il sera attaqué.

La segmentation réseau

Mon, 22 Jan 2024 00:00:00 +0000

Un réseau plat est une pièce unique où chacun peut atteindre chacun et c’est la condition qui transforme un seul portable compromis en un parc compromis. L’intrusion n’atterrit presque jamais là où se trouve la chose précieuse; elle atterrit sur une machine d’utilisateur puis se déplace, vers le serveur de fichiers, la base, le contrôleur de domaine, parce que rien sur un réseau plat ne dit non. La segmentation est la pratique d’ajouter des murs pour qu’un pied dans la porte achète à l’attaquant une pièce plutôt que le bâtiment et sa version honnête est plus que tracer des VLAN: c’est les rendre réels par du filtrage entre eux et durcir les astuces de couche 2 qui les traversent autrement tout droit.

Limites de ressources : empêcher une machine d'être convaincue de mourir

Tue, 05 Dec 2023 00:00:00 +0000

Le fork bomb résume tout l’argument en une ligne:

:(){ :|:& };:

Une fonction qui s’appelle elle-même deux fois et met les deux copies en arrière-plan, lancée une fois et le nombre de processus double toutes les fractions de seconde jusqu’à ce que la table des processus soit pleine, qu’aucun nouveau processus ne puisse démarrer et que la machine soit une brique réclamant un reboot brutal. Ce n’est pas un exploit, ça n’exige aucun privilège et n’importe quel utilisateur local peut le taper par accident. La même forme anime le reste de la famille: une boucle qui alloue de la mémoire jusqu’à ce que l’OOM killer parte, une qui ouvre des descripteurs de fichiers jusqu’à ce que fork échoue sur “too many open files”, une qui remplit /tmp ou /var/log jusqu’à ce que le système de fichiers racine se coince. Aucune n’est maligne. Toutes sont arrêtées par la même chose, un plafond que l’utilisateur ne peut dépasser et le seul vrai travail est de poser ce plafond au bon endroit.

Durcir le système de fichiers

Wed, 08 Nov 2023 00:00:00 +0000

L’essentiel du durcissement du système de fichiers consiste à décider, par montage, lequel de trois pouvoirs un répertoire a le droit d’accorder: exécuter un binaire, honorer son bit setuid et le laisser être un nœud de périphérique. Le défaut, defaults, accorde les trois partout, ce qui est commode et faux pour les répertoires où les utilisateurs et les démons peuvent écrire. Le reste, c’est séparer les partitions pour qu’une ne puisse affamer les autres, activer les protections de liens du noyau et garder un œil sur quels fichiers portent le setuid. Rien d’exotique et le gain est que des catégories entières d’escalade locale n’ont plus où atterrir.

Recompiler son kernel: des noyaux aux petits oignons pour son infra

Fri, 27 Oct 2023 00:00:00 +0000

Le durcissement de l’OS est surtout de la soustraction, retirer ce qui écoute et couper les surfaces kernel dont on n’a pas besoin, ce que j’ai détaillé dans durcir l’OS et le kernel Linux . Il reste une marche que cet article-là n’a pas montée et c’est ma préférée: ne pas désactiver une fonction kernel au runtime, mais ne jamais la compiler du tout. Recompiler son propre noyau, c’est la soustraction poussée à sa conclusion logique.

Durcir l'OS et le kernel Linux

Fri, 20 Oct 2023 00:00:00 +0000

Une machine Linux fraîchement installée est bâtie pour être commode, ce qui veut dire qu’elle arrive avec des services que vous n’avez pas demandés, des fonctions kernel que vous n’utiliserez jamais et des défauts choisis pour ne surprendre aucun débutant. La durcir est surtout de la soustraction: retirer ce qui écoute, couper les surfaces kernel dont vous n’avez pas besoin, resserrer la poignée de boutons sysctl qui comptent et verrouiller les comptes et le chargeur de modules. Les étapes individuelles sont petites et bien connues. La discipline est de les faire délibérément plutôt que d’hériter de ce que l’installeur a décidé et de garder la machine patchée, parce que les exploits kernel qui comptent (PwnKit, Dirty Pipe et leurs successeurs) sont corrigés bien avant que la plupart des machines n’appliquent le correctif.

Sudo et LOLBins

Sat, 15 Jul 2023 00:00:00 +0000

La croyance confortable sur sudo, c’est qu’une règle étroite est une règle sûre, que NOPASSWD: /usr/bin/find accorde le droit de lancer find et rien d’autre. GTFOBins a démoli cette croyance et la version honnête d’une note de durcissement sudo doit partir de là: la granularité de sudoers ne limite rien dès l’instant où le binaire autorisé peut être convaincu d’ouvrir un shell et une fraction surprenante de la boîte à outils standard le peut. La question n’est jamais “quelle commande ai-je accordée”, c’est “qu’est-ce qu’on peut faire faire à cette commande une fois qu’elle tourne en root”.

Scale-to-zero : Sablier rallume Swarm et Kubernetes à la demande

Sun, 15 Jan 2023 00:00:00 +0000

Un service qu’on consulte une fois par semaine tourne cent pour cent du temps. On l’a installé pour un besoin ponctuel, une QA qu’on ouvre le lundi, un wiki d’équipe, un outil d’admin qu’on ne sort qu’en cas d’incident. Il occupe en permanence sa part de RAM, sa part de CPU, ses ports, sa place dans le monitoring et son lot de mises à jour de sécurité. L’éteindre résout tout d’un coup, sauf qu’il faut alors le rallumer à la main au moment où on en a besoin et personne ne se souvient de la commande. Le scale-to-zero, c’est l’idée de n’allumer un service que quand quelqu’un le demande et de l’éteindre quand plus personne ne s’en sert, sans que l’utilisateur ait à savoir qu’il dormait. Sablier est un petit serveur d’API qu’on pose à côté du reverse proxy: le proxy intercepte chaque requête, appelle l’API pour savoir si la cible dort, la réveille le cas échéant et affiche une page d’attente le temps qu’elle démarre. Une fois la cible prête, la requête passe et une session s’ouvre, refermée après sessionDuration, au terme de quoi Sablier éteint la charge.

The Bastion et Guacamole : les deux battants de la porte d'entrée

Sun, 20 Nov 2022 00:00:00 +0000

Il y a deux populations dans toute infrastructure et elles posent la même question à des outils différents. Les gens du shell demandent: “je fais quoi pour me connecter au serveur et qui peut le prouver après coup?” Les gens du bureau demandent: “comment atteindre ce poste Windows sans VPN et sans client installé?” Il existe un outil remarquable de chaque côté et tous les deux méritent mieux qu’une mention en bas de page: The Bastion d’OVHcloud pour la première population, Apache Guacamole pour la seconde. Ensemble, ils forment les deux battants d’une même porte d’entrée: l’un tient le compte des mains sur clavier, l’autre des mains sur souris.

Le :ro sur le socket Docker ne protège rien

Sun, 12 Jun 2022 00:00:00 +0000

Il existe, dans toute revue de code où quelqu’un a eu le malheur de monter /var/run/docker.sock dans un conteneur, un petit rituel qui consiste à faire remarquer d’un air entendu qu’on pourrait au moins le passer en lecture seule, sur quoi tout le monde hoche la tête, ajoute :ro dans le compose et referme la merge request avec le sentiment du devoir accompli. C’est du théâtre et j’aimerais expliquer précisément pourquoi, parce que l’erreur est instructive bien au-delà de Docker.

FluoLight : réécrire un firmware Arduino hérité en quelque chose de défendable

Sun, 24 Apr 2022 00:00:00 +0000

Deuxième épisode de la série FluoBoard, après l’autopsie de la carte d’origine . J’y promettais une suite, la voici et elle ne s’est pas faite en une nuit. Dès 2021, j’ai attaqué par le manque le plus criant: découper le monolithe en plusieurs fichiers .ino par responsabilité, parce qu’un sketch unique ne se maintient pas, en corrigeant les bugs au passage et en posant les #define qui manquaient. Est venue ensuite une boucle d’événements écrite à la main, ma première manière de cadencer des actions dans le temps, avant que je ne reprenne la bibliothèque TimedAction pour le faire proprement. Le gros du travail s’est fait en 2021-2022, les retouches finales venant plus tard [edit: 2025], le tout suivable commit par commit. Même famille de boards, même protocole /lights/<mac> dont la réponse tient dans un chiffre entre <...>. Ce qui change n’est pas la liste des fonctionnalités, c’est que la boucle ne s’arrête jamais pour attendre.

Une image Ansible pour GitLab CI, construite propre depuis un sous-sol parisien

Tue, 22 Mar 2022 00:00:00 +0000

Chaque runner CI qui fait tourner Ansible a le même problème: le job a besoin d’ansible-core, des collections pour vos plateformes, git, ssh et il lui faut tout ça maintenant, sur une machine qui sera jetée après le job. Les images officielles existent, mais elles dérivent: latest change sous vous, la version que vous avez pinée se fait rebaser et installer huit collections Galaxy par job brûle des minutes à chaque pipeline.

Autopsie d'un firmware Arduino hérité

Mon, 22 Nov 2021 00:00:00 +0000

À l’époque, chez un ancien employeur, le firmware d’origine pilotait des rubans LED fixés devant des salles de réunion, qui indique la disponibilité de la salle. La board poll GET /lights/<mac> toutes les quelques secondes, le serveur répond un unique chiffre ASCII entre <0> et <9>, le ruban affiche une couleur. Produit simple, protocole simple. Je ne l’ai pas écrit, mais je m’en suis servi comme base.

La board n’était que la moitié du système. L’autre moitié côté salles, c’était le serveur d’occupation du bâtiment. Moi, j’ai détourné ce même protocole, pour moi seul, avec un petit serveur Python qui faisait le pont entre mes pipelines de CI et la board: ma veilleuse de CI existait en 2019, bien avant que les “CI status lights” soient une chose. Seul le contrat d’API a survécu, dans la doc (GET /lights/<lightid> répondant <N>, de <0> arc-en-ciel d’erreur à <4> rouge booked-and-busy); le code du serveur lui-même n’a pas survécu. C’est sa propre leçon: un code sans dépôt ne survit pas au poste qui l’a écrit.

SSH en 2021 : ce que treize ans ont changé depuis la série de 2008

Fri, 04 Jun 2021 00:00:00 +0000

La série SSH d’ici s’arrêtait en 2013: l’authentification par clefs en 2008 , l’authentification multiple en 2012 , la restriction de connexion et PKCS#8 en 2013 comme dernier acte. Huit ans plus tard, tout ce que ces articles faisaient avec de l’artisanat existe en primitives. Voici le mémo 2021, complet.

Les clés: Ed25519 et le couple FIDO2

ssh-keygen -t ed25519 -a 100 -C "logout@2021"
ssh-keygen -t ed25519-sk -a 100 # clé hardware, touch obligatoire
ssh-add -K # télécharge les resident keys de la YubiKey

Ed25519 pour tout ce qui est software: plus courte, plus rapide, plus résistante et -a 100 durcit le KDF contre le brute-forcing de la passphrase (l’héritage direct du PKCS#8 de 2013 , qui avait raison avant l’heure). Les clés -sk (OpenSSH 8.2, 2020) branchent une YubiKey: la clé privée ne quitte jamais le matériel, le protocole exige un touch physique. Et RSA? Le soleil se couche: OpenSSH 8.2 a désactivé ssh-rsa (SHA-1) dans CASignatureAlgorithms par défaut et l’annonce du retrait complet est déjà dans les release notes. En 2008, RSA 2048 était le luxe; en 2021, c’est la dette technique.

PwnMachine : la station de bug bounty auto-hébergée

Sun, 12 Jul 2020 00:00:00 +0000

Quand tu fais du bug bounty, tu as besoin d’un environnement: un DNS que tu contrôles (pour les callbacks), un reverse proxy (pour exposer les outils) et une interface web pour orchestrer. Le tout sur une machine que tu peux reinstaller en dix minutes. PwnMachine est ce montage, packagé en Docker Compose.

Le concept

PwnMachine est une solution d’auto-hébergement basée sur Docker, visant à fournir une station de pwnage facile à utiliser pour les chasseurs de bugs. L’installation de base inclut une interface web, un serveur DNS et un reverse proxy. Un docker-compose up --build -d et c’est debout.

Compter les CVE ne dit rien de la sécurité

Wed, 11 Mar 2020 00:00:00 +0000

On voit régulièrement passer des comparatifs qui rangent les systèmes par nombre de CVE publiées, le plus bas gagnant le titre de plus sécurisé. J’aurais tendance à mitiger fortement ce genre de résultats, parce que le chiffre lui-même ne mesure pas ce qu’on croit qu’il mesure. Un compteur de CVE compte des failles rendues publiques et rien d’autre. Il ne dit rien de celles qui existent, qui sont connues en interne ou qui circulent discrètement loin de tout bulletin.

Docker rootless : le démon sans privilèges

Tue, 23 Jul 2019 00:00:00 +0000

Docker tourne en root par défaut. Le démon (dockerd) a accès à TOUT le filesystem, TOUT le réseau, TOUT les process. Un container qui s’échappe du démon obtient le root sur l’hôte. Le mode rootless déplace le démon vers un utilisateur normal: les containers tournent dans un namespace utilisateur et une évasion ne donne que les droits de cet utilisateur, pas le root.

Le problème

Un démon Docker en root, c’est un service qui a tous les droits sur la machine, accessible via un socket Unix (et parfois un port TCP). Chaque container qui monte un volume monte avec les droits root du démon. Chaque bug dans runc ou containerd est une évasion root.

3factor : l'architecture qui retire l'état de l'API

Fri, 15 Feb 2019 00:00:00 +0000

Au début de 2019, quelques mois après ma découverte des douze facteurs, je tombe sur 3factor , un motif d’architecture publié par Hasura dont le nom est un clin d’œil assumé à 12factor.net (la ressemblance s’arrête là, 3factor est un motif de conception, pas une méthodologie). L’idée tient en trois facteurs: du GraphQL temps réel, de l’événementiel fiable et du serverless asynchrone.

Les trois facteurs

Le premier facteur est du GraphQL temps réel: le client souscrit à l’état et le reçoit au lieu de le demander, ce qui déplace la synchronisation du polling vers le serveur. Le deuxième est de l’événementiel fiable: chaque changement d’état est un événement persisté. Des déclencheurs le délivrent aux abonnés (la livraison se fait au moins une fois, l’idempotence est à la charge du consommateur). Le troisième est du serverless asynchrone: la logique métier tourne dans des fonctions déclenchées par les événements, sans serveur à gérer, avec mise à l’échelle automatique.

GitOps, le mot après la pratique : gitflow, GitLab CI, Terraform et Ansible

Tue, 20 Nov 2018 00:00:00 +0000

Le mot se répand depuis un an, GitOps, posé par Weaveworks en 2017 autour de Kubernetes et d’une idée simple, git comme source de vérité de l’infrastructure et une boucle qui fait converger le réel vers ce que décrit le dépôt. Je l’ai lu comme j’avais lu DevOps quelques années plus tôt, non pas en découvrant une méthode mais en reconnaissant la mienne (DevOps, un mot sur ce que je bricolais déjà ), à l’époque avec git et des hooks bash. En 2018, le bricolage a grandi et il a pris la forme d’un gitflow adapté, de conventions et d’un pipeline qui fait tout le travail.

Portknocking et tunneling SSH : les tours de magie d'avant WireGuard

Sat, 06 Oct 2018 00:00:00 +0000

En 2008, ce blog publiait Portknocking : l’art de frapper à la porte, puis la génération automatique de combinaisons , avec le tunneling SSH en étagère voisine. Fun, pédagogique et réellement déployé: je l’ai vu en entreprise jusqu’en 2018 chez un hébergeur. En 2016, Jason Donenfeld publie WireGuard et la question change de nature: pas “comment cacher la porte”, mais “pourquoi y a-t-il une porte?”.

Le montage de 2009, en souvenir ému

Pour les retardataires, ce que le portknocking “de luxe” de l’époque impliquait:

Chaos engineering : casser pour de vrai, mais pas n'importe comment

Mon, 20 Aug 2018 00:00:00 +0000

En 2018, la même année que ma découverte des douze facteurs, je tombe sur le chaos engineering (je serais bien incapable de retrouver les billets de blog exacts qui m’y mènent. C’est d’ailleurs une bonne raison de revenir aux sources plutôt qu’à mon souvenir): la définition et les principes tiennent dans un seul document, qui dit mieux ce que je finis par pratiquer que mes propres reformulations.

Ce n’est pas casser des trucs

Le contresens le plus courant consiste à croire qu’il suffit de redémarrer une machine en production pour faire du chaos engineering, ce qui confond une méthode et un incident: casser au hasard, c’est un incident qu’on n’a pas su éviter, pas une expérience. Le chaos engineering est une discipline d’expérimentation, avec un état stable défini et mesuré, une hypothèse sur sa persistance, une perturbation réaliste injectée et une comparaison rigoureuse (sans état stable mesurable, il n’y a pas d’expérience, il n’y a qu’une panne).

Git submodules à la main : mes plugins Vim 8 sans gestionnaire

Mon, 07 May 2018 00:00:00 +0000

Debian et Ubuntu venaient enfin de livrer Vim 8 et avec lui le système de packages natif: pack/plugins/start et pack/plugins/opt. Adieu pathogen, adieu mon hack aromatisé à l’apt (vim-apthogen , épisode un de cette série). Mais les packages de Vim 8 règlent le chargement, pas la gestion: rien ne dit quels plugins votre config utilise, ni comment les cloner sur une machine neuve.

La réponse que j’ai choisie est celle que je fais tourner encore aujourd’hui: le repo de config est l’état. Les plugins vivent en git submodules du repo de config, dans pack/plugins/start/ pour les toujours actifs et pack/plugins/opt/ pour les optionnels. Un clone avec --recursive et l’éditeur entier se matérialise.

Twelve-Factor App : la méthode Heroku qui a survécu aux conteneurs

Mon, 15 Jan 2018 00:00:00 +0000

En janvier 2018, je tombe sur la méthode Twelve-Factor (et je la range tout de suite parmi les pratiques que je faisais déjà sans le nommer): trois lectures qui se complètent (le site de référence d’Adam Wiggins , l’adaptation aux microservices de Ben Horowitz sur le blog de nginx et le rapport que Kevin Hoffman en tire chez O’Reilly ). Soudain un mot sur ce que je faisais depuis des années. Avant, je connaissais déjà (et j’appliquais plus ou moins) KISS, YAGNI et DRY, puis SOLID; le cycle en V et AGILE faisaient partie du paysage, chacun avec ses défauts que je pouvais énumérer sans avoir besoin qu’on me les explique. Twelve-Factor, lui, ne s’adresse pas au grand public: c’est une checklist d’ingénieur, écrite pour Heroku, qui dit noir sur blanc ce qu’une application doit garantir pour survivre à la production et à ses propres redéploiements.

Hardening SSH : la trilogie de 2017 relue en 2026

Thu, 26 Oct 2017 00:00:00 +0000

En octobre 2017, un article de hardening SSH passe sur ma timeline. Analyse généraliste, contre-mesures naïves. Je réponds en trois commentaires : la désactivation du root, le changement de port, l’authentification par clés. Neuf ans plus tard, ces trois commentaires me servent d’inventaire : ce qui tenait, ce qui a changé et ce qui n’était pas dans le cadre mais l’aurait mérité.

D’abord un point de principe, celui qui m’avait fait tiquer : comparer OpenSSH à une simple interface d’administration est réducteur. SSH, ce sont les bastions d’accès au SI, les VPN SSH, l’industrialisation agentless (Ansible, Puppet Bolt) qui passent par dessus. C’est la colonne vertébrale d’administration de la plupart des parcs Unix. Le durcir mal, c’est durcir tout le SI mal.

Ansible avant Ansible : ssh, un CSV et un moteur de template

Mon, 12 Sep 2016 00:00:00 +0000

En 2006-2007, j’administrais un petit parc à coups de scripts, comme tout le monde, sauf que je croyais (jeunesse!) que mon bricolage était une architecture. Il avait trois composants: une liste d’hôtes, un CSV et du bash. Ansible n’existait pas encore (il est né en 2012), mais la forme du problème était déjà là et la mienne la modélisait à 80%.

L’inventaire: une liste + un CSV

La liste des machines, un fichier plat, une machine par ligne. Et par-dessus, un CSV de variables d’inventaire:

SSH : ProxyJump et le multi-hop moderne

Mon, 12 Sep 2016 00:00:00 +0000

Il y a quelques années, pour atteindre une machine derrière un bastion, j’écrivais un ProxyCommand avec nc et je l’ai raconté dans SSH: tunneling . OpenSSH 7.3 a rendu tout ça obsolète avec une seule option, -J et c’est l’une de ces petites nouveautés qui changent un geste qu’on fait dix fois par jour.

Le geste de base

ssh -J user@bastion user@cible

bastion sert de rebond, la cible n’est jamais exposée directement et surtout le chiffrement reste de bout en bout entre votre poste et cible. Le bastion ne voit passer que du trafic chiffré qu’il ne peut pas lire, exactement comme avec le vieux ProxyCommand, mais sans invoquer nc ni ouvrir un shell intermédiaire. La différence avec ProxyCommand n’est pas qu’esthétique: -J établit la connexion au suivant depuis le client, pas depuis le bastion, donc aucune clé privée ne transite ni ne séjourne sur le rebond. C’est ce qu’on voulait depuis le début et qu’on bricolait jusque-là avec l’agent forwarding, lequel posait justement le problème inverse en exposant l’agent sur le bastion.

apt pour Vim: l'histoire de vim-apthogen (2012-2016)

Sun, 17 Apr 2016 00:00:00 +0000

Entre 2012 et 2016, ma config Vim ressemblait à un système Debian vu par son gestionnaire de paquets: une pile de répertoires bundle/ installés à la main et vim-pathogen qui faisait le chargement. Pathogen est honnête sur son rôle: c’est dpkg, le chargeur bête. Personne n’avait écrit l’apt au-dessus. Alors je l’ai écrit.

Le résultat: vim-apthogen , publié sur vim.org le 12 avril 2016 (Vim 7.0, 1136 téléchargements, un karma de 19/6, des chiffres dont je suis déraisonnablement fier). La ligne du README que j’aime toujours: Like apt for dpkg, vim-apthogen is a frontend to vim-pathogen.

Un autowalker DayZ en Java : décompiler, patcher en AZERTY, forker après

Sat, 18 Oct 2014 00:00:00 +0000

À l’époque de DayZ, je voulais un autowalker, ce petit utilitaire qui tient la touche d’avance pour toi pendant que ton personnage traverse une carte immense. Il en existait un, en Java, mais sans sources publiées et il était pensé pour un clavier QWERTY. Moi je joue en AZERTY, donc il avançait de travers et je voulais aussi qu’il gère proprement l’état de course plutôt que de bourriner une touche. Je ne me suis pas posé de question : je l’ai décompilé.

SSH : Augmenter la sécurité de vos clefs avec PKCS#8

Sun, 23 Jun 2013 00:00:00 +0000

En deux trois commandes :

$ mv ~/.ssh/id_rsa ~/.ssh/id_rsa.old
$ openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa.old -out ~/.ssh/id_rsa
$ chmod 600 ~/.ssh/id_rsa
# Check that the converted key works; if yes, delete the old one:
$ rm ~/.ssh/id_rsa.old

Et un petit script en prime pour le faire à la volée :

#!/bin/bash
: << 'TITLE.sh'
 Version: 0.1
 Authors: nobody@vhalholl.info
 Description: hardening ssh private key w/ pkcs#8
 http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html
 Dependencies: openssl
TITLE.sh

DEP=$(which openssl);[ ! -z $DEP ]&& {
 for k in $(echo $(for i in $(ls *);do file $i; done |grep private |cut -d : -f1));do
 echo "backup $k"; mv $k .$k.old
 echo "convert $k"; openssl pkcs8 -topk8 -v2 des3 -in .$k.old -out $k; chmod 600 $k
 done;
 exit 0;
}
echo "Openssl not found" && exit 1

Le PKCS#8 enveloppe la clé privée RSA dans une couche de chiffrement 3DES avec un KDF renforcé (PBKDF2). La passphrase de la clé devient plus coûteuse à brute-forcer: chaque tentative de déchiffrement nécessite des itérations supplémentaires du KDF. C’est le même principe que bcrypt ou scrypt pour les mots de passe, appliqué aux clés SSH.

Le client FOG: python 2, cron toutes les cinq minutes et une flotte qui se rebootait en place

Tue, 20 Nov 2012 00:00:00 +0000

Avant les autres pièces d’archéologie de ce blog, il y a celle-ci. Des années avant l’ère apthogen , sous l’identité gobel1, je faisais tourner des flottes de postes clonées avec FOG (Free Opensource Ghost). L’histoire client de FOG était Windows-first, donc le côté Linux avait besoin d’un petit client à lui: voici FOG.py, version 0.2, python 2, environ 150 lignes plus une poignée de hooks shell. Il date d’avant 2013; le repo git n’a été ré-initialisé qu’en mai 2013, un commit en français, six commits au total. L’archéologie est authentique.

SSH : Restreindre une connexion via clefs privée/publique

Mon, 05 Mar 2012 00:00:00 +0000

Quoi de plus évident lors de l’exécution de tâches automatisées diverses entre plusieurs serveurs que l’utilisation d’une paire de clefs ssh sans passphrase ?

Oui, mais comment cantonner cette clefs non protégée à l’exécution d’une tâche bien précise ?

Il suffit de préfixer la clefs publique à limiter dans le fichier :

.ssh/authorized_keys

Avec les options détaillées dans le manuel d’sshd à la section AUTHORIZED_KEYS FILE FORMAT:

command="/usr/bin/rsync --server --daemon .",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA...

Chaque option bloque une voie d’échappement:

SSH : Authentification multiple avec clefs privés/publiques

Mon, 06 Feb 2012 00:00:00 +0000

En complément d’un ancien article sur l’authentification par clefs avec ssh et parce qu’il ne faut jamais mettre tous ses oeufs dans le même panier, je propose ici une solution toute simple afin d’utiliser une clef spécifique à une identité sur un serveur ssh donné.

Dans notre exemple nous allons utiliser deux clefs, l’une avec passphrase qui nous servira pour nous connecter à un serveur server.mydomain.tld en tapant simplement ssh serv et une deuxième sans passphrase qui nous servira essentiellement pour l’exécution de script de maintenance sur un petit parc de machines clientes cli01.parc01.mydomain.tld etc., dont le serveur ssh écoute sur un port spécifique et le pare-feu n’autorisant que les connexions depuis server.mydomain.tld (soyons fous).

Debsecan : Debian Security Analyzer

Wed, 26 Oct 2011 00:00:00 +0000

Debian Security Analyzer, est un outil très pratique, découvert assez récemment.

Ce dernier génère simplement une liste des vulnérabilités affectant une installation donnée, à ce titre il est complémentaire d’apt-listbugs.

Par défaut à l’installation, les rapports quotidiens par mails, sont activés pour une installation générique.

Ce comportement se modifie via le fichier /etc/default/debsecan:

# Configuration file for debsecan. Contents of this file should
# adhere to the KEY=VALUE shell syntax. This file may be edited by
# debsecan's scripts, but your modifications are preserved.

# If true, enable daily reports, sent by email.
REPORT=true

# For better reporting, specify the correct suite here, using the code
# name (that is, "sid" instead of "unstable").
#
# Available:
# GENERIC
# etch
# lenny
# sid
# squeeze
# wheezy
SUITE=GENERIC

# Mail address to which reports are sent.
MAILTO=root

# Source URL
# eg: http://secure-testing.debian.net/debian-secure-testing/project/debsecan/release/1/$SUITE
SOURCE=

Le paramètre SUITE est le plus important: GENERIC liste toutes les CVEs pour toutes les versions, y compris celles qui ne vous affectent pas. En le passant à votre suite exacte (lsb_release -c), debsecan filtre par version et la liste devient actionnable.

Dennis Ritchie a quitté #world

Sat, 22 Oct 2011 00:00:00 +0000

Dennis Ritchie (ci-dessus à droite) alias DMR, créateur du langage de programmation C et co-développeur du système d’exploitation Unix nous a quitté hier à l’âge de 70 ans.

Personnellement, j’ai appris C grâce à “son” livre “Le langage C” et j’utilise toujours l’indentation K&R bien que légèrement remixée à la sauce GNU.

C’est une disparition qui aura un écho médiatique pratiquement inexistant contrairement au décès de Steve Jobs survenu la semaine dernière.

(Ré)Ouverture

Thu, 13 Oct 2011 00:00:00 +0000

Après deux années d’inactivité, une cinquantaine d’articles publiés et une dizaine de brouillons en cours, ce blog ouvre de nouveau ses portes.

Toujours propulsé par WordPress, seules les images, les commentaires et le thème initial du blog ont changé.

Pour le moment je m’attelle à la correction des articles déjà publiés, ensuite je prendrai en charge la publication des brouillons en cours, qui seront alors antidatés pour suivre la chronologie du blog.

Chat : de irssi + gateway messenger à weechat, la philosophie du client mince

Mon, 20 Jun 2011 00:00:00 +0000

L’article irssi de 2009 finissait sur un edit: “Une configuration à jour est dispo ici sur github” (c’était un stub d’article, la vraie valeur vivait dans le repo, la suite des temps l’a prouvé). Il faut maintenant raconter ce que l’article ne racontait pas: le montage qui rendait irssi indispensable et pourquoi deux ans plus tard j’ai tout déménagé vers weechat sans changer la philosophie.

irssi + BitlBee: le pont vers les messengers

Le montage de l’époque: un serveur BitlBee local qui présente les réseaux de messagerie instantanée (MSN, AIM, ICQ, Jabber) comme un canal IRC ordinaire et irssi qui s’y connecte comme à n’importe quel serveur. Résultat: un seul client, un seul buffer, une seule config de logs, pour IRC et pour les contacts MSN qui ne connaissent de l’IRC que le nom.

tmux : le multiplexeur qui a pris le fauteuil

Sun, 23 May 2010 00:00:00 +0000

Screen a vingt-trois ans, byobu a habillé ses défauts et il reste des irritants que ni l’un ni l’autre ne règlent: pas de vrais panes (Screen fait des régions, qui se redimensionnent mal), un UTF-8 rétrofité, une config $HOME/.screenrc aux bindkeys hérités des années 80. C’est là qu’entre tmux, né en 2007 sur OpenBSD et qui commence à prendre le fauteuil en 2010.

Le modèle client-serveur

La différence architecturale qui change tout: Screen lance un serveur par utilisateur (les sessions partagent un process), tmux lance un serveur par session et les clients s’y attachent. Conséquences pratiques:

La méthode R.A.C.H.E : Rapid Application Conception and Heuristic Extreme-programming

Thu, 15 Apr 2010 00:00:00 +0000

Il existe une méthode de génie logiciel qui décrit mieux la vraie vie que la moitié des référentiels que je vois passer en comité. Cette méthode a un acronyme, un institut, une F.A.Q et une licence domaine public: elle s’appelle la méthode R.A.C.H.E. Je la découvre vers 2009-2010, à une époque où je prends encore les roadmaps au sérieux.

R.A.C.H.E signifie Rapid Application Conception and Heuristic Extreme-programming. Le site de l’International Institute de La RACHE existe depuis 2007, mais le concept circulait déjà sous forme de PDF auparavant. La métempsychose récurrente du concept semble, selon ses propres promoteurs, intrinsèquement axiomale chez certains grands éditeurs. la-rache.com

DevOps, un mot sur ce que je bricolais déjà

Mon, 15 Mar 2010 00:00:00 +0000

Depuis quelques mois un mot circule, DevOps, lancé après la conférence Velocity de juin 2009 et son fameux “10 deploys a day” sur la coopération entre dev et ops chez Flickr, puis repris aux premiers DevOpsDays de Gand en octobre, autour de Patrick Debois. On le présente un peu partout comme la fin du mur entre ceux qui écrivent le code et ceux qui le font tourner et en lisant les premiers textes j’ai eu la sensation curieuse de reconnaître des choses que je bricolais déjà dans mon coin, sans leur avoir jamais donné de nom.

Puppet : mes premiers modules ou le passage de la boucle ssh à la déclaration

Sat, 02 Jan 2010 00:00:00 +0000

Mes scripts bash, une liste d’hôtes, un CSV de variables et une boucle ssh qui pousse des configs rendues par template m’ont rendu de bons services depuis 2007, mais ils décrivent des pas et c’est justement ce que je cherchais à quitter en écrivant mes premiers modules Puppet pour le parc que j’administre au travail. Puppet, c’est un vrai DSL, un vrai modèle agent/master (la 0.25 en ce moment) et une promesse que mes scripts n’ont jamais tenue: déclarer l’état désiré, pas décrire les pas. Ssh, ntp, postfix, munin, zabbix, varnish, rsyslog, ces modules couvrent le socle commun et je les enrichis au fil des besoins.

Haproxy : le reverse proxy qui a pris la suite de Pound

Sun, 20 Dec 2009 00:00:00 +0000

Le blog parlait de Pound en 2008 : un reverse proxy très light, qui dépose le TLS et balance vers un pool. Pound fait ce travail avec l’élégance du minimal, mais dès qu’il faut router sur le contenu (un Host vers un cluster, une URL vers un backend spécifique, une session collante), on fait un pas au-dessus: haproxy 1.3, de Willy Tarreau, en cours de stabilisation vers la 1.4.

IRSSI : IRC aux petits oignons

Sat, 07 Nov 2009 00:00:00 +0000

[edit: MàJ 20130621] : Une configuration à jour est dispo ici sur github.

Irssi est le client IRC en mode console. Il ne fait pas de joli widget, il ne fait pas de drag-and-drop, il fait de l’IRC. Et il le fait bien: les themes, les scripts Perl, les aliases, les hotlists, les notifications, tout est configurable.

La config vit dans ~/.irssi/, avec un config principal et un scripts/ pour les plugins Perl. La config de l’époque (367 lignes, multi-réseaux: recycled-irc, otaku-irc, worldnet SSL:7000, fansub-irc, OFTC SSL:9999) est versionnée dans les dotfiles, avec un theme green.theme et cinq scripts perso.

Byobu : screen avec une couche de vernis (et un statut qui sauve)

Thu, 15 Oct 2009 00:00:00 +0000

En avril dernier, ce blog décrivait Screen comme un multiplexeur de terminal : détacher, rattacher, ne jamais perdre une session ssh. Six mois plus tard, byobu arrive et pose une question impertinente: si tout le monde configure le même Screen de la même façon (statut, couleurs, raccourcis), pourquoi ne pas livrer la configuration toute faite?

C’est exactement ce qu’est byobu: né dans Ubuntu sous le nom screen-profiles, renommé byobu en 2009 (le mot japonais pour les paravents décoratifs, clin d’oeil assumé), l’outil enveloppe votre Screen existant d’une couche de vernis, sans en changer le moteur.

Bash : Géolocalisation, la trilogie

Fri, 02 Oct 2009 00:00:00 +0000

Trois itérations du même script, entre décembre 2008 et octobre 2009, chacune née de la précédente et de ses limites. La v1 est perdue avec le disque dur (un Samsung de 500 Go, avec tous mes projets Bash, C, PHP et Perl, ma musique perso, bref le truc plein à plus de 90%), la v2 et la v3 survivent. C’est l’histoire de la progression d’un script en public.

La revanche de netcat (v2, février 2009)

Après une discussion IRC sur la géolocalisation, un ami qui utilisait le même site m’a refilé un de ses scripts qui en une seule ligne faisait exactement la même chose que le mien mais beaucoup plus rapidement grâce à netcat (pas d’accès disque). Malheureusement, suite à la perte de mon disque dur, j’ai perdu pas mal d’outils, dont ce fameux script. Du coup j’ai réécrit ce script, étant quand même largement moins bon que mon ami, il me prend plus d’une ligne.

NTP : synchronisation du temps sur le réseau

Tue, 26 May 2009 00:00:00 +0000

Le NTP (Network Time Protocol) synchronise les horloges des machines sur le réseau. Ça paraît trivial jusqu’au jour où un script qui dépend de la date dérive de 3 secondes et rate sa fenêtre de connexion ou où deux serveurs qui doivent s’accorder sur “maintenant” ont 4 minutes d’écart.

L’installation

apt-get install ntp

Le daemon ntpd démarre et synchronise automatiquement avec les serveurs du pool Debian (0.debian.pool.ntp.org à 3.debian.pool.ntp.org).

La config minimale

# /etc/ntp.conf
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

# Restreindre l'accès
restrict default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

L’option iburst accélère la synchronisation initiale (4 paquets au lieu de 1 au démarrage). Les restrict bloquent l’accès depuis le réseau: le serveur NTP ne sert que lui-même, pas les autres (sauf si on veut faire un serveur NTP local).

Portknocking : génération automatique de combinaisons

Fri, 22 May 2009 00:00:00 +0000

Le portknocking classique frappe à la porte avec une séquence de ports fixe. Le problème d’une séquence fixe: elle se sniff, elle se rejoue. La solution: faire dépendre la séquence de la date, pour qu’elle change chaque jour.

Le principe

La combinaison est calculée depuis la date système. Le jour détermine le protocole (pair = udp, impair = tcp) et les ports partent de la somme jour+mois+année doublée, à laquelle on ajoute 64 jusqu’à dépasser 1024. Le client et le serveur doivent avoir la même horloge, d’où la synchronisation NTP.

Bash : Personnalisation du fichier .bashrc

Tue, 14 Apr 2009 00:00:00 +0000

Sur nos systèmes préférés, la configuration du shell bash en mode interactif, de son prompt et de sa coloration, se fait dans les fichiers:

/etc/profile
/etc/bash.bashrc
/root/.bashrc
/home/user/.bashrc

Ici nous ne toucherons qu’aux trois derniers. On commence par la couleur du nom d’utilisateur dans le prompt, vert pour les utilisateurs, rouge pour le compte root, parce qu’un prompt root qui ne se signale pas est un prompt root dans lequel on finit par taper une bêtise:

Screen : un multiplexeur de terminal

Mon, 13 Apr 2009 00:00:00 +0000

Screen est un multiplexeur de terminal qui, à la manière d’un gestionnaire de fenêtrage, permet à plusieurs programmes en mode texte de tourner en même temps depuis une seule interface, typiquement un terminal local ou distant via ssh (non, rien à voir avec nohup que j’utilise principalement pour certains scripts avec wget).

Installation

Sous Gentoo:

logout@lifthrasir ~ $ su -c "emerge app-misc/screen"
Password:
[...]

Sous Debian:

logout@helghardhr:~$ sudo apt-get install screen
Password for user logout:
[...]

Passons à la pratique

Nous allons créer une session screen pour prendre la main sur un switch:

Apache : l'URL rewriting

Sat, 14 Feb 2009 00:00:00 +0000

mod_rewrite est le module d’Apache qui réécrit les URLs à la volée. Il transforme /article.php?id=42 en /article/42, redirige les vieux liens vers les nouveaux et fait tout ce qu’un reverse proxy ne fait pas: il modifie la requête avant qu’elle atteigne l’application.

Le basic

RewriteEngine On
RewriteRule ^article/([0-9]+)$ article.php?id=$1 [L]

Cette règle transforme /article/42 en article.php?id=42 en interne (l’utilisateur voit /article/42, Apache exécute article.php?id=42). Le [L] signifie “last rule”: si cette règle matche, les suivantes ne sont pas évaluées.

SSH: rsync sécurisé

Sat, 27 Dec 2008 00:00:00 +0000

Rsync est l’outil de sauvegarde incrémentale: il compare source et destination, ne transfère que les deltas et préserve les permissions, les timestamps, les symlinks. Over SSH, il traverse le réseau sur le canal chiffré, sans démon rsync côté serveur (SSH fait le transport).

Le rsync de base

rsync -avz /data/ user@serveur:/backup/data/

-a : archive mode (récursif, préserve perms, times, symlinks, devices)
-v : verbose (liste les fichiers transférés)
-z : compression (gzip avant transfert)

Le / après /data/ signifie: “le contenu de /data”, pas “/data lui-même”. Sans le /, rsync crée /backup/data/data/. C’est l’erreur rsync la plus commune.

htop : le remplaçant de top

Thu, 25 Dec 2008 00:00:00 +0000

top existe depuis 1984 et il est affreux. L’interface est rigide, les touches sont obscures, le tree view n’existe pas et trier par mémoire demande de lire le man page. htop fait tout ce que top fait, en mieux et il tient dans un terminal.

Ce que htop apporte

Scroll horizontal et vertical: les lignes de process ne sont plus tronquées;
Tree view (F5): qui a spawné qui, le parent/enfant en visuel, les threads indentés sous leur process parent;
Tri interactif (F6): par CPU, par mémoire, par PID, par USER, sans re-lancer;
Kill interactif (F9): sélectionner un process, choisir le signal, confirmer. Pas de kill -9 12345 tapé dans un autre terminal;
Les jauges CPU par coeur en haut de l’écran, en couleur, en temps réel;
Le filtre (F4): taper un pattern et seuls les process matchant sont visibles;
Le setup (F2): choisir les colonnes, les couleurs, les jauges et sauvegarder dans ~/.config/htop/htoprc.

Les touches qui servent

F1 Help
F2 Setup
F3 Search (incrémental)
F4 Filter
F5 Tree view
F6 Sort
F7 Nice - (augmenter la priorité)
F8 Nice + (diminuer la priorité)
F9 Kill (envoyer un signal)
F10 Quit

Le F9 est le plus utilisé: sélectionner un process qui bouffe tout le CPU, F9, SIGTERM (15) et si ça ne suffit pas, F9 SIGKILL (9). Le tout dans le même écran, sans quitter htop.

SSH: SSH filesystem

Thu, 25 Dec 2008 00:00:00 +0000

SSHFS (SSH Filesystem) monte un filesystem distant dans votre arborescence locale via SSH et FUSE. Pas de NFS, pas de SMB, pas de configuration serveur: juste SSH (que le serveur a déjà) et FUSE (que le client a). Le filesystem distant apparaît comme un directory local, avec tous les outils standards (cp, mv, find, grep, vim).

Le montage

mkdir /mnt/distant
sshfs user@serveur:/home/user /mnt/distant

Après cette commande, /mnt/distant EST /home/user sur serveur. Tous les outils standards fonctionnent:

tsocks : proxyfions

Tue, 23 Dec 2008 00:00:00 +0000

Le tunnel SSH donne un SOCKS (l’article tunneling ), mais ssh -D ne proxyfque que ce qui parle SOCKS: les navigateurs, curl avec --proxy. Les programmes qui ne connaissent pas SOCKS (apt, telnet, le client MySQL) restent en direct. tsocks résout ça par LD_PRELOAD.

Le principe

tsocks est une bibliothèque partagée qui intercepte les appels système réseau (connect(), send(), recv()) via LD_PRELOAD. Quand un programme essaye d’ouvrir une connexion TCP, tsocks redirige vers le proxy SOCKS à sa place. Le programme ne sait pas qu’il passe par un proxy.

Pound : un reverse proxy très light

Sun, 21 Dec 2008 00:00:00 +0000

Pound est un reverse proxy qui fait trois choses: il termine le TLS, il vérifie que les backends sont vivants et il balance. C’est tout. Et c’est exactement ce qu’il faut quand on ne veut pas d’un Apache qui fait aussi proxy.

La conf

ListenHTTP
 Address 0.0.0.0
 Port 80
End

ListenHTTPS
 Address 0.0.0.0
 Port 443
 Cert "/etc/pound/server.pem"
End

Service
 BackEnd
 Address 192.168.1.11
 Port 8080
 End
 BackEnd
 Address 192.168.1.12
 Port 8080
 End
 Session
 Type IP
 TTL 300
 End
End

Le fichier de config Pound est un format déclaratif qui se lit comme un bloc de texte: chaque BackEnd est un serveur du pool, chaque Service est un groupe de backends, la Session colle les clients par IP source. Le TLS se termine dans Pound, les backends parlent HTTP en clair sur le réseau interne.

Polipo : un proxy ultra-simple

Wed, 17 Dec 2008 00:00:00 +0000

Polipo est un proxy web cache écrit par Juliusz Chroboczek, léger (un process, quelques MB) et parfait dans un cas précis: derrière un tunnel SSH. Le tunnel SSH donne un SOCKS et le navigateur a besoin d’un proxy HTTP: Polipo fait le pont.

La conf minimale

proxyAddress = "127.0.0.1"
proxyPort = 8123
cacheIsShared = false
diskCacheRoot = ""

Le proxy écoute sur le localhost:8123, sans cache disque (le cache du navigateur suffit) et fait le pont entre HTTP et le SOCKS du tunnel. La config tient en 4 lignes.

Subversion : installation et utilisation

Sat, 13 Dec 2008 00:00:00 +0000

Après CVS (qui mérite sa retraite), Subversion. Le VCS centralisé qui a fait la transition entre le commit-lock de CVS et le modèle distribué qui viendra après. Le principe est simple: un serveur central (svnserve ou Apache + mod_dav_svn), des clients qui checkout, commit, update. Un seul historique, un seul point de vérité et un numéro de révision global qui incrément à chaque commit.

Installation

apt-get install subversion subversion-tools
# Créer le dépôt
svnadmin create /srv/svn/monprojet
# Démarrer le serveur standalone
svnserve -d -r /srv/svn

Le mode svnserve est le plus simple: pas de Apache, pas de mod_dav, un daemon qui écoute sur le port 3690. Pour l’accès web, il faut Apache + mod_dav_svn (voir l’article suivant).

Bash: obfuscation d'adresses IP

Thu, 11 Dec 2008 00:00:00 +0000

Une adresse IP n’a qu’une seule représentation “naturelle” (dotted quad: 192.168.1.1), mais elle a plusieurs représentations numériques que les navigateurs, les clients SSH et les parsers de logs acceptent aussi. Une IP peut s’écrire en décimal pur (3232235777), en hexadécimal (0xC0A80101), en octal ou en mixte (192.168.0x1.1). Les logs qui filtrent sur “192.168.1.1” ne filtrent pas sur “3232235777” et c’est le trou d’obfuscation.

Les représentations

# Décimal pur (uint32)
printf "%d\n" 3232235777
# 3232235777 = 192.168.1.1

# Hexadécimal
printf "0x%X\n" 3232235777
# 0xC0A80101

# Octal
printf "%o\n" 3232235777
# 30052000401

Le navigateur accepte http://3232235777/ exactement comme http://192.168.1.1/: il convertit le nombre en dotted quad avant la connexion. Le client SSH aussi, le client FTP aussi.

Fail2ban : lutter contre le bruteforcing

Mon, 08 Dec 2008 00:00:00 +0000

Chaque serveur SSH public reçoit des centaines de tentatives de connexion par jour. Les logs d’auth.log se remplissent de lignes Failed password for root from x.x.x.x. Fail2ban lit ces logs, compte les échecs et bannit l’IP par iptables. C’est un chien de garde qui lit les logs au lieu de flairer.

Le principe

Fail2ban fonctionne en trois étapes: il suit un fichier de log (auth.log, mail.log, apache.log), il matche les lignes contre des expressions régulières configurables et il exécute une action quand le seuil est atteint (typiquement, une règle iptables DROP pour l’IP fautive pendant N minutes).

OpenDNS : les DNS libres

Sat, 06 Dec 2008 00:00:00 +0000

OpenDNS (208.67.222.222 et 208.67.220.220) est un résolveur DNS public et gratuit, apparu avant les résolveurs des grands acteurs. Le principe: vous remplacez les DNS de votre FAI par les leurs et votre résolution passe par leurs serveurs au lieu des vôtres.

Pourquoi

Trois raisons que les gens invoquent:

Le DNS du FAI est lent, tombe en panne ou ment (le portail captif qui résout tout vers sa page de login);
OpenDNS filtre les domaines de phishing et de malware (leur base de domaines malveillants, mise à jour en continu);
OpenDNS fait du caching et le cache est plus rapide que le resolver du FAI.

Comment

# Dans /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220

Ou dans le DHCP du réseau pour que tous les postes en profitent.

Subversion: un WebSVN avec mod_dav et mod_svn d'Apache

Mon, 01 Dec 2008 00:00:00 +0000

Subversion a deux modes d’accès: svnserve (daemon standalone, protocole svn://) et Apache avec mod_dav_svn (protocole http:// ou https://). Le mode Apache expose le repository via HTTP, avec l’authentification Apache, le SSL Apache et WebSVN pour le browsing web des sources.

Le module mod_dav_svn

apt-get install libapache2-svn

Ce paquet installe mod_dav et mod_dav_svn (le module qui expose les repositories SVN via WebDAV).

La configuration Apache

# /etc/apache2/sites-available/svn
<Location /svn>
 DAV svn
 SVNParentPath /var/svn
 AuthType Basic
 AuthName "Subversion Repository"
 AuthUserFile /etc/apache2/dav_svn.passwd
 Require valid-user
</Location>

DAV svn : active le mode SVN
SVNParentPath /var/svn : le directory qui contient les repositories (un repo par sous-directory)
AuthUserFile : le fichier htpasswd pour l’authentification

Créer le repository et le fichier de mots de passe:

ext3 : accélérez vos accès disques

Thu, 20 Nov 2008 00:00:00 +0000

Le filesystem ext3 est le défaut de toutes les distributions depuis des années et il est monté avec les options les plus lentes possibles. Trois mots à ajouter dans le fstab et vos accès disques sont divisés par deux.

Les trois options

/dev/sda1 / ext3 defaults,noatime,data=writeback,commit=60 0 1

noatime. Le temps d’accès (atime) est mis à jour à CHAQUE lecture de fichier. Un cat fichier met à jour l’atime de fichier ET de tous les répertoires du chemin. Sur un serveur web qui lit des milliers de fichiers par seconde, l’atime est un overwrite disque invisible. noatime le supprime purement et simplement. Coût: ls -lu ne montre plus la dernière lecture, ce qui n’a jamais servi à personne.

Compilons un script shell avec shc

Wed, 19 Nov 2008 00:00:00 +0000

Un script shell est du texte lisible par tout le monde: cat script.sh montre le code, les mots de passe éventuels, la logique métier. shc (shell script compiler) transforme le script en binaire: le script est compilé en C, le C est compilé en binaire ELF et le texte source n’est plus lisible.

Le principe

shc -f script.sh

shc génère deux fichiers:

script.sh.x : le binaire ELF exécutable
script.sh.x.c : le source C généré (à supprimer après compilation)

Le binaire script.sh.x s’exécute comme le script original, mais le code shell n’est pas lisible dans le binaire.

Debian Etch: jouez avec les backports

Sun, 16 Nov 2008 00:00:00 +0000

Debian Etch (4.0) est stable: les paquets sont testés, les versions sont figées et une application qui dépend d’une librairie plus récente que celle d’Etch ne compile pas. Les backports résolvent ce problème: le projet Debian Backports recompile les paquets de Sid (unstable) pour les dépendances d’Etch et les met à disposition dans un repository séparé.

Le repository backports

# /etc/apt/sources.list
deb http://www.backports.org/debian etch-backports main contrib non-free

La clé GPG du repository:

ArpON : surveiller son cache ARP

Fri, 14 Nov 2008 00:00:00 +0000

ArpON est un daemon très pratique, là où des outils comme Arpwatch permettent juste de voir les problèmes, ArpON lui permet de les bloquer (notamment les tentatives d’empoisonnement du cache ARP).

Pour ce faire il peut utiliser deux protocoles, SARPI (pour Static ARP Inspection) et DARPI (pour Dynamic ARP Inspection).

Il remplace parfaitement les outils arp, arping et arpscan, détecte et bloque les tentatives de spoofing ou de poisoning et du fait qu’il tourne en espace utilisateur, reste très portable. Actuellement il est compatible avec OpenBSD, FreeBSD, Debian, Gentoo, Slackware et même Mac OSX.

EncFS : le chiffrement de fichiers sans partition dédiée

Mon, 20 Oct 2008 00:00:00 +0000

Chiffrer ses données sur Linux a toujours signifié LUKS, dm-crypt, une partition dédiée, une réinstallation. EncFS casse ce schéma: c’est un filesystem FUSE qui chiffre fichier par fichier, dans un répertoire normal, sans partition dédiée, sans réinstaller et sans droit root après le premier montage.

Le principe

EncFS crée deux répertoires: le cipher (les fichiers chiffrés, avec des noms chiffrés aussi) et le plain (le point de montage, où les fichiers apparaissent en clair). Tout ce que vous écrivez dans le plain est chiffré à la volée et stocké dans le cipher. Tout ce que vous lisez dans le plain est déchiffré à la volée depuis le cipher. Démontez le plain et il ne reste que le cipher: des noms illisibles, du contenu chiffré.

radare : un débugger très abouti

Sat, 04 Oct 2008 00:00:00 +0000

Après le harnais Perl greffé sur GDB et avant que Metasm ne m’entraîne vers Ruby, il y a eu radare. Un débugger en mode console, écrit par pancake (Nibble), qui fait tout ce que GDB fait pour l’exploitation, mais avec une interface pensée pour le reverse engineering plutôt que pour le debugging applicatif.

Ce que radare fait que GDB ne fait pas

GDB est un débugger applicatif: il s’arrête sur des points de rupture, imprime des variables, suit des appels. radare est un outil de reverse engineering: il désassemble, analyse les chaînes, cherche les gadgets, calcule les offsets et laisse naviguer dans le binaire comme dans un système de fichiers.

Yersinia : comment rendre malade son administrateur réseau

Thu, 28 Aug 2008 00:00:00 +0000

Yersinia est le nom de la bactérie de la peste. L’outil porte bien son nom: il attaque les protocoles de couche 2 (STP, CDP, DTP, DHCP, VTP, HSRP) et rend votre switch malade. Le titre de cet article n’est pas une métaphore: c’est ce qui arrive réellement à un administrateur réseau qui découvre qu’une station avec Yersinia et un simple câble peut prendre le contrôle de sa topologie de switch.

SNMP : un protocole pas si simple

Tue, 01 Jul 2008 00:00:00 +0000

SNMP signifie Simple Network Management Protocol. Le “Simple” est l’ironie du siècle: le protocole utilise des OIDs (Object Identifiers) qui sont des arborescences de numéros, des MIB (Management Information Base) qui traduisent les numéros en noms, des communautés (public, private) qui servent de mot de passe en clair et des versions (v1, v2c, v3) dont chacune a ses particularités.

Les OIDs: l’arbre

Chaque donnée dans SNMP a un OID: une séquence de numéros séparés par des points. L’arbre standard:

tcpdump : analyse de trames et filtre BPF

Fri, 20 Jun 2008 00:00:00 +0000

Après Nemesis qui forge et raw sockets qui sniffent à la main, l’outil qui fait tout ça sans écrire une ligne de C: tcpdump. Si vous ne l’avez jamais utilisé, sachez que c’est probablement l’outil de diagnostic le plus rentable de toute votre carrière: une commande, un filtre et vous lisez le réseau en clair.

Le filtre BPF, le concept qui change tout

tcpdump seul affiche TOUT le trafic de l’interface. C’est inutilisable sur un réseau actif: vous êtes noyé en dix secondes. La magie vient du filtre BPF (Berkeley Packet Filter), un langage d’expression compilé à la volée dans le kernel pour ne capturer que ce qui matche:

Nemesis : détection d'un sniffeur réseau

Fri, 06 Jun 2008 00:00:00 +0000

L’article précédent parlait de forger des paquets avec Nemesis . Celui-ci parle de la face opposée: détecter que quelqu’un sur votre réseau écoute ce qu’il ne devrait pas.

Le problème

Une carte réseau en mode promiscuous accepte TOUTES les trames, pas seulement celles adressées à sa MAC. C’est ce qui permet à tcpdump et à Wireshark de fonctionner et c’est aussi ce qui permet à un sniffeur de lire le trafic qui ne lui est pas destiné. Sur un switch, ça ne devrait pas passer (le switch route par MAC), mais si quelqu’un a bricolé le switch ou s’il y a un hub quelque part, ça passe.

Nemesis : forgeur de paquets réseau

Mon, 02 Jun 2008 00:00:00 +0000

Si vous avez lu l’article sur les raw sockets , vous savez forger un SYN à la main en C: remplir les champs, calculer le checksum, envoyer. C’est éducatif et c’est aussi ce que fait Nemesis depuis la ligne de commande en une invocation. Nemesis est un forgeur de paquets générique: TCP, UDP, ICMP, RIP, OSPF, ARP, DNS. Chaque protocole a sa sous-commande, chaque champ de l’en-tête a son option.

L’idée

Un forgeur de paquets, c’est l’inverse de tcpdump: tcpdump lit ce qui passe, Nemesis fabrique ce qui passe. La combinaison des deux est le protocole de test réseau complet: Nemesis forge, tcpdump vérifie ce qui arrive réellement et vous savez ce que votre firewall, votre switch ou votre IDS comprend de ce que vous avez envoyé.

Raw Sockets : forger et sniffer des paquets en C

Fri, 09 May 2008 00:00:00 +0000

Nous avons parlé de sockets TCP en C , sous le confort de SOCK_STREAM. Passons sous le kernel: les raw sockets, là où tcpdump et Nemesis vivent. Avertissement d’usage: SOCK_RAW demande root, la carte réseau en mode promiscuous et un peu d’éthique, le tout sans contrat avec personne.

Sniffer: AF_PACKET et le mode promiscuous

int s = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

Deux lignes et vous recevez tout ce qui traverse l’interface, en-têtes Ethernet comprises, à condition de passer l’interface en promiscuous:

Sockets : parler TCP en C, sans framework ni magie

Wed, 02 Apr 2008 00:00:00 +0000

Après les LKMs et les syscalls, restons en bas. Tout le réseau d’Unix tient dans quatre appels système, deux structures et un traité d’ordre des octets. Le reste, c’est de la mémoire et de la discipline. Petit mémo, Debian Etch oblige, gcc 4.1 et les man pages 2 et 7 pour seuls amis.

Les structures, d’abord

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

struct sockaddr_in addr;
addr.sin_family = AF_INET; /* IPv4 */
addr.sin_port = htons(4444); /* network byte order, TOUJOURS */
addr.sin_addr.s_addr = htonl(INADDR_ANY); /* 0.0.0.0 */

htons et htonl ne sont pas décoratifs: le réseau parle big-endian, votre x86 parle little-endian et le _getMac du voisin qui oublie htons obtient un serveur sur le port 45056. Le man 7 ip explique tout ça mieux que moi.

Linux : introduction aux LKMs

Sun, 02 Mar 2008 00:00:00 +0000

Le kernel Linux est monolithique: tout le code tourne dans le même espace d’adressage, en mode privilégié. Mais il accepte du code supplémentaire à chaud: les LKMs (Loadable Kernel Modules). Un LKM est un fichier .ko compilé pour le kernel en cours, qui s’insère dans l’espace kernel et ajoute des fonctionnalités: drivers de périphériques, filesystems, network protocols, syscalls custom.

Le plus petit LKM

// hello.c
#include <linux/module.h>
#include <linux/kernel.h>

static int __init hello_init(void) {
 printk(KERN_INFO "Hello from kernel space\n");
 return 0;
}

static void __exit hello_exit(void) {
 printk(KERN_INFO "Goodbye from kernel space\n");
}

module_init(hello_init);
module_exit(hello_exit);
MODULE_LICENSE("GPL");

Le Makefile:

Les syscalls de Linux

Thu, 21 Feb 2008 00:00:00 +0000

Un programme en espace utilisateur ne fait rien directement: quand il lit un fichier, alloue de la mémoire ou envoie un paquet réseau, il demande au kernel de le faire. Cette demande est un syscall (system call): le programme exécute une instruction spéciale (int 0x80 ou sysenter sur x86), le kernel prend la main, exécute la demande et rend le contrôle au programme. C’est la frontière entre l’espace utilisateur (ring 3) et l’espace kernel (ring 0).

SSLH : ssh et https sur le même port

Sun, 16 Sep 2007 00:00:00 +0000

Le problème de 2007, dans les boîtes à pare-feux nerveux: un seul port sortant, le 443, tout le reste est coupé. On veut son shell ssh et son https et le firewall ne discute pas. La réponse s’appelle sslh (v1.0, de Yves Rutschle): un petit daemon qui écoute le 443 et délègue selon le premier paquet qui arrive: à sshd si le client parle protocole SSH, à httpsd sinon.

Le mécanisme

client --443--> sslh --détection--> sshd:22
 \--> https:443

Le protocole SSH annonce poliment son identité: le client envoie une bannière SSH-2.0-... en clair dès l’ouverture. Le protocole SSL/TLS commence par un ClientHello dont le premier octet n’est pas un ‘S’. Deux sons de cloche, deux destinations:

PAM: limitez les ressources système

Fri, 04 May 2007 00:00:00 +0000

PAM (Pluggable Authentication Modules) ne fait pas que de l’authentification: le module pam_limits plafonne les ressources système par utilisateur et par groupe. Sans limites, un process peut manger tout le RAM, tous les file descriptors, tous les process slots: c’est le fork bomb ou simplement un process qui leak de la mémoire.

Le fichier limits.conf

# /etc/security/limits.conf
# <domain> <type> <item> <value>

# Plafonner les process pour tous les utilisateurs
* soft nproc 2048
* hard nproc 4096

# Plafonner le nombre de fichiers ouverts
* soft nofile 1024
* hard nofile 4096

# Plafonner la mémoire (en KB)
* soft as 1048576
* hard as 2097152

# Pour le groupe backup: plus de fichiers ouverts
@backup soft nofile 8192
@backup hard nofile 16384

# Pour root: pas de limite
root soft nproc unlimited
root hard nproc unlimited

soft : la limite courante (le process peut la dépasser jusqu’à la hard limit)
hard : la limite maximum (le process ne peut pas la dépasser, même avec ulimit -Hn)
* : tous les utilisateurs
@group : un groupe Linux
root : l’utilisateur root

Les items de limits.conf

item	ce qu’il plafonne
`nproc`	le nombre de process
`nofile`	le nombre de file descriptors ouverts
`as`	la mémoire (address space) en KB
`rss`	la mémoire résidente en KB (ancien, remplacé par as)
`cpu`	le temps CPU en minutes
`maxlogins`	le nombre de sessions simultanées
`core`	la taille des core dumps

Vérifier les limites

ulimit -a

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
max nice (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 4096
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 8192
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 2048
virtual memory (kbytes, -v) unlimited

ulimit -n montre la limite de file descriptors: 1024 par défaut, ce qui est insuffisant pour un serveur web ou une base de données. 4096 ou 16384 est le minimum pour un serveur.

SSH: tunneling

Wed, 04 Apr 2007 00:00:00 +0000

SSH ne transfère pas que des fichiers: il fait passer n’importe quel protocole TCP dans le canal chiffré. Une connexion VNC, une base MySQL, un serveur web interne, un SMB share: tout ce qui est TCP peut être tunnelé à travers SSH, sans VPN, sans configuration firewall, avec une seule commande.

Le tunnel local (local forward)

ssh -L 3306:localhost:3306 user@serveur

Cette commande ouvre le port 3306 sur votre machine locale et tout ce qui y arrive part vers le port 3306 de serveur (vu depuis serveur). Une session SSH est ouverte, le tunnel fonctionne tant que la session dure.

MySQL : sauvegarde

Tue, 06 Mar 2007 00:00:00 +0000

Un backup MySQL qui n’a jamais été restauré n’est pas un backup, c’est un espoir. L’article précédent parlait du mémo , celui-ci parle de la sauvegarde automatisée et du test de restauration.

Le script de sauvegarde

#!/bin/bash
BACKUP_DIR="/backup/mysql"
DATE=$(date +%Y%m%d)
MYSQL_USER="backup_user"
MYSQL_PASS="password"

mkdir -p "$BACKUP_DIR/$DATE"

# Lister les bases
DATABASES=$(mysql -u $MYSQL_USER -p$MYSQL_PASS -e "SHOW DATABASES" | grep -v Database | grep -v information_schema | grep -v test)

# Dump de chaque base
for db in $DATABASES; do
 mysqldump -u $MYSQL_USER -p$MYSQL_PASS \
 --add-drop-table \
 --single-transaction \
 "$db" > "$BACKUP_DIR/$DATE/$db.sql"
 gzip "$BACKUP_DIR/$DATE/$db.sql"
done

# Nettoyer les backups de plus de 7 jours
find "$BACKUP_DIR" -type d -mtime +7 -exec rm -rf {} \;

Le --single-transaction est crucial: il démarre une transaction InnoDB et dump dans un snapshot cohérent sans verrouiller les tables. Sans ce flag, le mysqldump verrouille chaque table et votre application en prod attend.

MySQL : perte des identifiants

Thu, 08 Feb 2007 00:00:00 +0000

Le scénario: un serveur que vous n’avez pas touché depuis six mois, un MySQL dont personne ne se souvient du mot de passe root et un client qui demande pourquoi son site ne se connecte plus à la base. Le mot de passe root est perdu et il n’y a pas de fichier de config qui le traîne quelque part.

La procédure

# 1. Arrêter MySQL
/etc/init.d/mysql stop

# 2. Démarrer sans les tables de privilèges
mysqld_safe --skip-grant-tables --skip-networking &

# 3. Se connecter sans mot de passe
mysql -u root mysql

# 4. Changer le mot de passe root
UPDATE user SET Password=PASSWORD('nouveaumdp') WHERE User='root';
FLUSH PRIVILEGES;
EXIT;

# 5. Tuer mysqld_safe et redémarrer proprement
killall mysqld_safe mysqld
/etc/init.d/mysql start

Le flag --skip-grant-tables désactive TOUTE authentification: n’importe qui peut se connecter en n’importe qui. Le flag --skip-networking empêche les connexions TCP externes pendant la fenêtre de récupération (seul le socket local fonctionne). Les deux ensemble sont la procédure sûre.

MySQL : Mémento

Fri, 26 Jan 2007 00:00:00 +0000

Le mémo MySQL des commandes d’administration qui ne se tapent pas assez souvent pour les retenir, mais assez souvent pour savoir qu’elles existent.

Connexion

mysql -u root -p
mysql -u root -p -h localhost mon_schema
mysql -u root -p < dump.sql

Utilisateurs et droits

CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON mon_schema.* TO 'user'@'localhost';
GRANT SELECT, INSERT ON mon_schema.* TO 'readonly'@'%';
FLUSH PRIVILEGES;
SHOW GRANTS FOR 'user'@'localhost';
DROP USER 'user'@'localhost';

Backup et restore

# Backup complet d'une base
mysqldump -u root -p mon_schema > backup.sql

# Backup de toutes les bases
mysqldump -u root -p --all-databases > all.sql

# Backup avec DROP TABLE
mysqldump -u root -p --add-drop-table mon_schema > backup.sql

# Restore
mysql -u root -p mon_schema < backup.sql

Les requêtes d’administration

SHOW DATABASES;
SHOW TABLES;
SHOW TABLE STATUS;
SHOW PROCESSLIST;
SHOW VARIABLES;
SHOW ENGINE INNODB STATUS;
DESCRIBE table_name;

Optimisation

OPTIMIZE TABLE table_name;
ANALYZE TABLE table_name;
REPAIR TABLE table_name;

Le root perdu

Si vous avez perdu le mot de passe root, la procédure est:

Apache : quel bavard

Thu, 21 Dec 2006 00:00:00 +0000

Apache parle. Beaucoup. Chaque requête génère une ligne dans le access_log, chaque erreur une ligne dans le error_log et le LogLevel contrôle le niveau de bavardage. Sur un serveur qui sert 100 000 pages par jour, le access_log pèse 50 Mo par jour et personne ne le lit.

Le LogLevel

LogLevel warn

Les niveaux, du plus bavard au plus silencieux: debug, info, notice, warn, error, crit, alert, emerg. Le warn est le défaut et le bon: il logge les warnings (config, permissions) et les erreurs, mais pas chaque module qui démarre.

Apache : les limites du .htaccess

Tue, 28 Nov 2006 00:00:00 +0000

Le .htaccess est pratique: un fichier par répertoire, pas de restart, le client mutualisé le gère tout seul. Sur un serveur dédié, il est un ralentisseur.

Chaque requête HTTP fait lire Apache tous les .htaccess du chemin, depuis la racine. Pour /var/www/site/blog/article/, Apache lit /var/www/.htaccess, /var/www/site/.htaccess, /var/www/site/blog/.htaccess et /var/www/site/blog/article/.htaccess. Quatre reads disque par requête avant de servir la page.

La solution: AllowOverride None dans httpd.conf et tout ce qui était dans les .htaccess migre dans le VirtualHost. Apache ne lit plus les .htaccess et les directives sont compilées au démarrage.

Apache : désactiver l'option TRACE

Fri, 06 Oct 2006 00:00:00 +0000

La méthode HTTP TRACE renvoie au client la requête exacte qu’il a envoyée, en écho. Conçu pour le debug, c’est une porte pour le XST (Cross-Site Tracing): un JavaScript sur une page compromise peut utiliser TRACE pour lire les cookies HttpOnly via les headers de la requête. IE6 le permettait, Firefox aussi.

Le test:

$ telnet mondomaine.fr 80
TRACE / HTTP/1.1
Host: mondomaine.fr

HTTP/1.1 200 OK
TRACE / HTTP/1.1
Host: mondomaine.fr
...

Si vous voyez votre requête en écho, TRACE est activé.

SSH: authentification via clefs privé/publique

Sun, 10 Sep 2006 00:00:00 +0000

L’authentification SSH par mot de passe fonctionne, mais elle est faible: le mot de passe se tape à chaque connexion, il peut être brute-forcé (fail2ban atténue mais ne résout pas) et il ne distingue pas “qui” de “quoi”. Les clefs SSH résolvent les trois: la clef privée prouve l’identité, la clef publique autorise l’accès et une fois configurée, plus de mot de passe.

Générer la paire

ssh-keygen -t rsa -b 4096 -C "commentaire"

Le -t rsa génère une paire RSA, le -b 4096 définit la taille (2048 minimum, 4096 recommandé). Le -C est un commentaire libre (l’email ou le hostname habituellement). Deux fichiers: id_rsa (la clé privée, ne jamais sortir du poste) et id_rsa.pub (la clé publique, à copier sur les serveurs).

Magic SysRq : la béquille du sysadmin

Fri, 11 Aug 2006 00:00:00 +0000

Un serveur est figé. Plus de SSH, pas de console, pas de réponse au ping. Vous êtes en datacenter ou en SSH série et la seule option avant de tirer la prise est la touche SysRq.

Ce que c’est

La touche SysRq (System Request) est interceptée directement par le kernel Linux, indépendamment de l’état du système. Le serveur peut être en kernel panic, le scheduler peut être bloqué: le kernel répond à SysRq tant que les interruptions matérielles fonctionnent. C’est la béquille d’urgence.

iodine : l'IP-over-DNS ou l'internet là où seul le DNS passe

Fri, 28 Jul 2006 00:00:00 +0000

La scène est connue: l’hôtel d’une conférence, le hotspot du fast-food du coin, l’un de ces portails captifs qui éclosent partout depuis que le Wi-Fi est devenu un service. Vous vous connectez, une page s’ouvre, vous êtes censé payer ou saisir un code de chambre et tout ce qui n’est pas HTTP sur le port 80 tombe dans le vide. Pas de SSH, pas de SMTP direct, pas de VPN visible. Un filtre qui ne laisse passer que le web, donc presque rien.

dig : le Domain Information Groper ou l'art d'interroger un serveur de noms

Mon, 26 Jun 2006 00:00:00 +0000

Pendant des années, mon outil DNS a été nslookup. L’habitude vient de loin, elle vient de Windows, elle vient du réflexe “je veux voir un enregistrement, je tape nslookup”. Puis un jour j’ai dû déboguer une zone qui se propageait mal entre un primaire et un secondaire et nslookup m’a répondu avec son interface interactive, son prompt >, sa sortie qui change de forme selon la version de la bibliothèque résolveuse du système. J’ai installé le paquet dnsutils le soir même et nslookup a pris sa retraite.

Les liens : hard links et symbolic links et ce qui dépasse le chroot

Mon, 05 Jun 2006 00:00:00 +0000

Linux connaît deux types de liens et la différence entre les deux est un sujet d’examen sysadmin ET un vecteur d’évasion de chroot. Le même concept qui explique la sauvegarde de vos données explique aussi comment sortir d’une jail.

Le hard link

Un hard link est une entrée de répertoire qui pointe directement sur un inode. Le fichier et son lien sont deux noms pour le même contenu disque. Supprimer l’un ne supprime pas l’autre (l’inode reste tant que son compteur de liens est supérieur à zéro).

SSH: fish comme un poisson

Wed, 10 May 2006 00:00:00 +0000

Le protocole fish (Files transferred over SHell) est une invention de KDE: il encapsule des commandes shell dans une connexion SSH pour explorer et transférer des fichiers comme si c’était un montage réseau. Konqueror le fait nativement: tapez fish://user@serveur/home/user dans la barre d’adresse et le filesystem distant apparaît dans le navigateur de fichiers.

Ce que fish fait

Fish n’est pas un montage (pas de FUSE, pas de kernel module): c’est le client qui envoie des commandes shell (ls, cat, cp) via SSH et parse le résultat. Le serveur n’a besoin de rien de spécial: juste un shell POSIX. Le client construit les commandes, les envoie sur le canal SSH et présente le résultat comme un filesystem.

Root or not root

Thu, 13 Apr 2006 00:00:00 +0000

La question: qui a le droit d’être root sur un serveur partagé? La réponse n’est pas technique, elle est politique. Mais les outils techniques existent et ils ne se valent pas.

su

su demande le mot de passe root. Celui qui le connaît devient root. Point. Tous les admins partagent le même mot de passe et quand quelqu’un part de l’équipe, il faut le changer (et le redistribuer). L’historique de ce qui a été fait en root se limite à last et à la mémoire de ceux qui étaient là.

Bash : Mémento

Fri, 10 Mar 2006 00:00:00 +0000

Un mémo, pas un tutoriel. Les lignes bash qu’on cherche à chaque fois parce qu’on ne les tape pas assez souvent pour les retenir, mais assez souvent pour savoir qu’elles existent.

Les substitutions

# Remplacer la première occurrence
${var/ancien/nouveau}
# Remplacer toutes les occurrences
${var//ancien/nouveau}
# Supprimer le plus court pattern depuis le début
${var#pattern}
# Supprimer le plus court pattern depuis la fin
${var%pattern}
# Longueur de la chaîne
${#var}
# Valeur par défaut si vide
${var:-defaut}
# Assigner si vide
${var:=defaut}
# Erreur si vide
${var:?message}

Les tableaux

declare -a tab
tab[0]="premier"
tab+=(deuxieme troisieme)
echo ${tab[@]}
echo ${#tab[@]}
echo ${tab[1]}
# Les index disponibles
echo ${!tab[@]}

Les redirections

cmd > fichier # stdout vers fichier (écrase)
cmd >> fichier # stdout vers fichier (ajoute)
cmd 2> fichier # stderr vers fichier
cmd &> fichier # stdout + stderr vers fichier
cmd 2>&1 # stderr vers stdout
cmd > /dev/null 2>&1 # silence complet
cmd < fichier # stdin depuis fichier

Les boucles

for i in $(ls); do echo "$i"; done
for i in {1..10}; do echo "$i"; done
while read ligne; do echo "$ligne"; done < fichier

Les tests

[[ -f fichier ]] # existe et est un fichier régulier
[[ -d rep ]] # existe et est un répertoire
[[ -s fichier ]] # existe et non vide
[[ -x fichier ]] # exécutable
[[ "$a" == "$b" ]] # égalité de chaînes
[[ $n -eq $m ]] # égalité de nombres
[[ $n -lt $m ]] # less than

C’est tout. Le reste s’apprend avec man bash (section EXPANSION), mais ces lignes-ci sont celles qu’on colle dans un fichier et qu’on source.