Cartographie du Système de Fichiers Linux : Guide pour Dompter Unix
Le Système de Fichiers Linux : Un Fondamental Trop Souvent Négligé
Après 15 ans à travailler sur des systèmes Linux -- des décodeurs TV chez SFR avec un Linux embarqué Gentoo aux clusters Kubernetes en production -- je peux affirmer que la maîtrise du système de fichiers Linux est ce qui sépare un bon ops d'un excellent ops. Cette connaissance fait la différence quand il faut diagnostiquer un problème à 3h du matin sur un serveur en production.
/bin et /sbin : Les Outils de Survie
/bin contient les commandes essentielles accessibles à tous les utilisateurs : ls, cp, mv, cat, grep. /sbin contient les outils d'administration système : iptables, fdisk, reboot. Sur les distributions modernes, ces répertoires sont souvent des liens symboliques vers /usr/bin et /usr/sbin.
Anecdote terrain : chez SFR, sur le firmware Linux embarqué des décodeurs TV, nous avions un /bin minimaliste avec BusyBox qui fournissait toutes les commandes de base dans un seul binaire. Chaque kilo-octet comptait sur ces appareils avec 64 Mo de flash.
/etc : Le Cerveau de la Configuration
C'est le répertoire que je passe le plus de temps à configurer. /etc/nginx/, /etc/ssh/sshd_config, /etc/hosts, /etc/resolv.conf... Tout ce qui définit le comportement d'un système est là.
En contexte Kubernetes, ce répertoire est moins critique car la configuration est injectée via ConfigMaps et Secrets. Mais quand vous déboguez un noeud K8s qui ne démarre pas, c'est dans /etc/containerd/config.toml ou /etc/kubernetes/ que vous trouverez la réponse.
/dev : L'Interface avec le Matériel
/dev contient les fichiers de périphériques. /dev/sda pour le disque, /dev/null pour jeter la sortie, /dev/urandom pour la génération de données aléatoires.
Cas pratique que j'ai rencontré chez un client : des pods Kubernetes qui crashaient parce que le device mapper du noeud était saturé. Le diagnostic est passé par l'examen de /dev/mapper/ et des logs du driver de stockage. Sans comprendre la hiérarchie /dev, impossible de résoudre ce type de problème.
/proc et /sys : Les Fenêtres sur le Kernel
/proc est un système de fichiers virtuel qui expose les informations du noyau. /proc/cpuinfo, /proc/meminfo, /proc/loadavg sont mes premiers réflexes quand je diagnostique un serveur. /sys expose les paramètres matériels et les drivers.
Un exemple concret : sur un cluster de production, les pods étaient OOMKilled alors que le noeud avait encore de la mémoire disponible. L'examen de /proc/sys/vm/overcommit_memory a révélé un paramètre kernel restrictif hérité d'un hardening trop agressif.
/var : Le Répertoire Qui Déborde
/var/log pour les logs, /var/lib pour les données des services (dont Docker et containerd), /var/cache pour les caches. C'est le répertoire qui cause le plus de pannes par saturation de disque.
Mon conseil : toujours monitorer /var séparément. Chez un client, un /var/log non rotationné a rempli le disque du noeud master Kubernetes, rendant etcd indisponible et crashant tout le cluster. Depuis, je mets systématiquement en place une rotation des logs et un alerting sur l'espace disque.
/usr : Les Applications
/usr/bin et /usr/lib contiennent les programmes et bibliothèques installés. /usr/local est réservé aux installations manuelles. En contexte conteneurisé, /usr est souvent en lecture seule dans les images Docker pour des raisons de sécurité.
/home et /root : Les Espaces Personnels
/home pour les utilisateurs, /root pour l'administrateur. En production, ces répertoires ne devraient contenir que le strict minimum : clés SSH, fichiers de configuration shell, et c'est tout. J'ai vu des développeurs stocker des dumps de base de données dans leur /home sur des serveurs de production. Ne faites pas ça.
Maîtriser le système de fichiers Linux, c'est avoir une carte mentale de votre système. Et quand l'incident arrive, cette carte vous guide directement vers la solution.