Fichiers sous Linux

Sur un nœud du lab, la configuration et les journaux sont des fichiers. Savoir où ils vivent, les lire sans les écraser par accident, et corriger un droit trop ouvert évite une bonne partie des incidents « mystérieux » — service qui ne démarre pas, script lancé par le mauvais utilisateur, log qu’on ne trouve pas. Cette page reprend l’arborescence utile au quotidien, les commandes de lecture, et le minimum sur les permissions, dans le même esprit que le terminal : concrètement, sur Debian/Proxmox, pas un cours FHS exhaustif.

Où vivent les choses

Linux organise le disque selon la Filesystem Hierarchy Standard, avec des variations selon les distributions. En pratique, sur mes machines, je passe mon temps dans quelques chemins : /etc pour la config, /var/log pour les logs, /home et /root pour les espaces utilisateurs, /usr et /usr/local pour les binaires (y compris les scripts que je dépose dans /usr/local/bin). /proc et /sys ne sont pas de « vrais » fichiers sur disque : le noyau y expose l’état du système et du matériel — pratique pour du diagnostic, dangereux si on écrit n’importe où.

Un chemin absolu commence par / et part de la racine. Un chemin relatif part du répertoire courant (. pour ici, .. pour le parent). Avant de coller une commande copiée d’un guide, un pwd et un ls évitent d’éditer le mauvais fichier.

pwd
cd /etc
ls -la

Lire sans casser

cat affiche tout d’un coup — bien pour un petit fichier, illisible pour un gros log. less (quitter avec q, chercher avec /) et tail -f pour suivre un journal en direct sont le combo que j’utilise le plus sur le lab. head coupe le début quand on veut juste vérifier un en-tête.

cat petit.conf
less /var/log/syslog
tail -f /var/log/auth.log
head -n 50 fichier

Les redirections complètent le tableau : > écrase, >> ajoute, 2> capture stderr, | enchaîne vers grep ou awk. C’est exactement le même réflexe que dans les scripts d’arrêt Proxmox ou quand on filtre un journalctl.

Éditer et permissions

Pour modifier une config, j’utilise nano ou vim selon le contexte. Après un changement dans /etc, je redémarre le service concerné (systemctl restart …) plutôt que de rebooter « pour voir ». Les permissions se lisent avec ls -l (propriétaire, groupe, mode rwx) et se corrigent avec chmod / chown. La règle simple sur le lab : pas de 777 « pour que ça marche ». Un partage SMB, un secret Vault, un script lancé par cron root — chacun a un user et un mode adaptés ; trop ouvert, et le problème n’est plus technique, il est de confiance.

chmod 640 fichier
chown user:group fichier

Suite naturelle : le réseau sous Linux, parce qu’une fois les fichiers et les droits en place, le souci suivant est souvent « pourquoi cette IP / ce DNS / ce SSH ne répond pas ».