Fichiers, permissions et navigation

Tu sais naviguer dans un terminal et te repérer dans l’arborescence Linux — c’est acquis depuis le chapitre précédent. Maintenant, on passe aux gestes quotidiens d’un admin ou d’un DevOps : créer, copier, déplacer, supprimer des fichiers, comprendre qui a le droit de faire quoi, et configurer son environnement de travail. Ce sont les fondations sur lesquelles tout le reste repose — du scripting Bash au déploiement en production.

Pourquoi c’est important

Sur un serveur Linux, tout est fichier. Ta configuration Nginx ? Un fichier dans /etc/. Les logs de ton application ? Des fichiers dans /var/log/. Ta clé SSH privée ? Un fichier dans ~/.ssh/. Même les périphériques matériels sont représentés comme des fichiers dans /dev/.

Conséquence directe : si tu ne maîtrises pas la manipulation de fichiers et leurs permissions, tu ne maîtrises rien. Un chmod mal placé peut exposer une clé privée au monde entier. Un rm -rf avec le mauvais chemin peut raser un serveur de production en une seconde. Un utilisateur mal configuré peut donner un accès root à quelqu’un qui ne devrait pas l’avoir.

🔥 Cas réel : En 2017, GitLab a perdu 300 Go de données de production parce qu’un admin a lancé un rm -rf sur le mauvais répertoire pendant une opération de maintenance. Le backup ? Corrompu. Six heures de données perdues. Tout ça parce que la manipulation de fichiers a été prise à la légère.

Comprendre le modèle de permissions

Avant de toucher aux commandes, il faut comprendre comment Linux gère les droits d’accès. Chaque fichier a trois niveaux de permissions : le propriétaire (user), le groupe (group), et tous les autres (others). Pour chaque niveau, trois actions sont possibles : lire (r), écrire (w), exécuter (x).

Quand tu lances ls -la, voici comment lire la sortie :

# Exemple de sortie de ls -la
-rw-r--r-- 1 dany devops 4096 Mar 20 10:30 config.yaml
drwxr-xr-x 3 dany devops 4096 Mar 20 10:30 scripts/
#│ │   │   │
#│ │   │   └── others : r-- (lecture seule)
#│ │   └────── group  : r-x (lecture + exécution)
#│ └────────── user   : rwx (lecture + écriture + exécution)
#└───────────── type  : d = dossier, - = fichier, l = lien

Le système octal traduit ces lettres en chiffres : r=4, w=2, x=1. Tu additionnes pour chaque catégorie. Donc rwxr-xr-- donne 7-5-4, soit 754.

🧠 À retenir : Les permissions les plus courantes en production — 755 pour les scripts et dossiers (exécutable par tous, modifiable par le propriétaire), 644 pour les fichiers de config (lisible par tous, modifiable par le propriétaire), 600 pour les clés SSH et secrets (accès exclusif au propriétaire).

💡 Tip DevOps : Sur un répertoire, le x ne signifie pas “exécuter” mais “traverser”. Sans x sur un dossier, tu ne peux pas y entrer avec cd, même si tu as r pour lister son contenu. C’est un piège classique.

Commandes essentielles

Voici les commandes que tu utiliseras tous les jours. Chacune est un outil fondamental — pas un luxe.

Pour créer des fichiers et des arborescences, touch et mkdir sont tes alliés. L’option -p de mkdir crée toute la chaîne de répertoires parents si nécessaire — indispensable pour scripter :

# Créer une arborescence de projet complète en une commande
mkdir -p ~/projet/{src,tests,config,docs}
touch ~/projet/config/app.yaml ~/projet/docs/README.md

Pour copier, déplacer et supprimer, tu as cp, mv et rm. Le flag -r (récursif) est nécessaire pour les dossiers. L’option -a de cp préserve les permissions, les dates et les liens symboliques — c’est celle que tu veux pour des copies fidèles :

# Copier un dossier en préservant tout (permissions, dates, liens)
cp -a /etc/nginx/ /tmp/nginx-backup/

# Déplacer et renommer (même commande mv)
mv ancien-nom.yaml nouveau-nom.yaml

# Supprimer un dossier et tout son contenu
rm -rf /tmp/vieux-projet/

⚠️ Attention : rm -rf est irréversible. Il n’y a pas de corbeille. Avant d’exécuter cette commande, vérifie deux fois le chemin. Mieux encore, utilise trash-cli sur tes machines pour envoyer à la corbeille au lieu de supprimer définitivement.

Pour lire le contenu des fichiers, tu as plusieurs outils selon le besoin. cat affiche tout d’un coup, head et tail montrent le début ou la fin, et less permet de naviguer dans un fichier long :

# Suivre un log en temps réel (Ctrl+C pour arrêter)
tail -f /var/log/nginx/access.log

# Afficher les 20 premières lignes d'un fichier
head -n 20 /etc/passwd

# Écrire dans un fichier (> écrase, >> ajoute)
echo "APP_PORT=8080" > .env
echo "APP_DEBUG=false" >> .env

Pour modifier les permissions et la propriété, chmod et chown sont incontournables. Tu peux utiliser la syntaxe symbolique (plus lisible) ou octale (plus rapide) :

# Rendre un script exécutable
chmod u+x deploy.sh      # symbolique : +x pour le user
chmod 755 deploy.sh       # octale : rwxr-xr-x

# Changer propriétaire et groupe d'un dossier web
sudo chown -R www-data:www-data /var/www/html/

# Sécuriser une clé SSH (obligatoire, sinon SSH refuse de l'utiliser)
chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh/

Cas concret : déployer une app en entreprise

Imagine que tu arrives dans une boîte et qu’on te demande de préparer un serveur pour une nouvelle application web. Voici le workflow réel, étape par étape.

D’abord, tu crées un utilisateur dédié à l’application (jamais faire tourner une app en root), tu crées le groupe associé, et tu prépares l’arborescence avec les bonnes permissions :

# Créer l'utilisateur applicatif et son groupe
sudo useradd -m -s /bin/bash appuser
sudo groupadd webteam
sudo usermod -aG webteam appuser

# Créer l'arborescence applicative
sudo mkdir -p /opt/webapp/{releases,shared/config,shared/logs}
sudo chown -R appuser:webteam /opt/webapp/
sudo chmod -R 2775 /opt/webapp/

# Le "2" en tête active le setgid : tout fichier créé dans ce
# dossier héritera automatiquement du groupe webteam

Ensuite, tu configures les variables d’environnement pour l’application. En production, on ne hardcode jamais les secrets dans le code — on les passe via l’environnement :

# Créer le fichier d'environnement de l'app
sudo -u appuser bash -c 'cat > /opt/webapp/shared/config/.env << EOF
APP_NAME=monapp
APP_ENV=production
APP_PORT=3000
DATABASE_URL=postgres://db:5432/monapp
EOF'

# Sécuriser le fichier (seul appuser peut le lire)
sudo chmod 600 /opt/webapp/shared/config/.env

🔥 Cas réel : Le flag setgid (2775) est utilisé en entreprise pour que tous les développeurs d’une équipe puissent travailler dans le même dossier sans problèmes de permissions. Sans ça, chaque fichier créé appartient au groupe primaire du créateur, et les collègues ne peuvent pas le modifier.

Pièges fréquents

Le -a oublié dans usermod — Sans le flag -a (append), usermod -G docker dany remplace tous les groupes secondaires de l’utilisateur par docker uniquement. Tu perds l’accès sudo, et potentiellement l’accès au serveur. Toujours utiliser usermod -aG.

Les permissions récursives aveugles — Lancer chmod -R 755 sur un dossier donne le droit d’exécution à tous les fichiers, pas seulement aux scripts. En production, utilise find pour cibler : find /var/www -type f -exec chmod 644 {} \; pour les fichiers, et find /var/www -type d -exec chmod 755 {} \; pour les dossiers.

Le source oublié — Après avoir modifié ~/.bashrc, les changements ne prennent effet que dans les nouveaux shells. Pour la session courante, il faut source ~/.bashrc. Pareil après avoir ajouté un utilisateur à un groupe : il faut se reconnecter ou utiliser newgrp.

⚠️ Attention : Ne jamais éditer /etc/sudoers directement avec nano ou vim. Utilise toujours sudo visudo — il vérifie la syntaxe avant de sauvegarder. Une erreur de syntaxe dans sudoers peut te bloquer l’accès root au serveur.

💡 Tip DevOps : Avant un rm -rf en production, prends l’habitude de d’abord lister avec ls le même chemin. ls /opt/webapp/old-release/ avant rm -rf /opt/webapp/old-release/. Ça prend deux secondes et ça peut sauver ta soirée.

Exercice et points clés

Exercice — Simule un environnement de production

Reproduis ce scénario sur ta machine ou un VPS :

1. Crée un utilisateur deploy et un groupe devteam
2. Crée l’arborescence /opt/monapp/{releases,shared/{config,logs}} avec mkdir -p
3. Applique les permissions 2775 et le propriétaire deploy:devteam sur /opt/monapp
4. En tant que deploy, crée un fichier .env dans shared/config/ avec les variables APP_ENV=staging et APP_PORT=8080
5. Vérifie avec ls -la que le groupe est bien hérité (grâce au setgid)
6. Sécurise le .env en 600 et vérifie qu’un autre utilisateur ne peut pas le lire

Si tout fonctionne, tu as les bases pour préparer n’importe quel serveur applicatif.

🧠 À retenir :

• Tout est fichier sous Linux — configuration, logs, périphériques, processus
• Les permissions (rwx) se lisent en trois blocs : propriétaire, groupe, autres
• La notation octale (755, 644, 600) est le standard en production
• chmod change les droits, chown change le propriétaire — les deux acceptent -R pour le récursif
• Les variables d’environnement configurent les applications sans toucher au code — c’est un pilier du 12-Factor App
• sudo donne les droits root ponctuellement — ne jamais travailler en root permanent

Prochain chapitre : le scripting Bash — automatiser les tâches répétitives avec des variables, des conditions et des boucles. Parce que taper les mêmes commandes cinquante fois, c’est le travail d’un script, pas le tien.