Terminal et Linux

Tôt ou tard, il faut se connecter à un serveur : lire un log pendant une panne, vérifier qu'un service tourne, comprendre pourquoi Symfony ne peut pas écrire dans var/. Sur un serveur, il n'y a pas d'interface graphique : seulement un terminal.

Bonne nouvelle : une trentaine de commandes couvrent l'essentiel du quotidien. Cette fiche les présente par besoin, avec les pièges qui coûtent cher. Personne ne retient toutes les options par cœur : tout le monde passe son temps dans man et --help.

1.Le terminal et le shell

Le terminal est la fenêtre. Le shell est le programme qui lit ce que tu tapes et lance les commandes : Bash sur la plupart des serveurs, Zsh sur beaucoup de postes de développement. Une commande suit toujours la même forme :

# Une commande : le programme, des options (souvent avec - ou --), des arguments
ls -l --human-readable var/log
#  │   │        │         └─ argument : sur quoi agir
#  │   │        └─ option longue
#  │   └─ option courte
#  └─ programme

man ls          # le manuel complet (q pour quitter, / pour chercher)
ls --help       # l'aide courte

Trois réflexes font gagner un temps énorme :

1. La touche Tab complète les noms de commandes et de fichiers. Deux appuis affichent les possibilités.
2. Ctrl+R cherche dans l'historique des commandes déjà tapées.
3. Ctrl+C interrompt la commande en cours.

2.Fichiers et dossiers

Sous Linux, tout part de la racine /. Un chemin qui commence par / est absolu (/var/www/shop), les autres sont relatifs au dossier courant. ~ désigne ton dossier personnel, . le dossier courant, .. le dossier parent.

pwd                          # où suis-je ? (print working directory)
ls -la                       # le contenu du dossier, fichiers cachés compris
cd /var/www/shop             # aller dans un dossier (chemin absolu, depuis la racine)
cd ..                        # remonter d'un niveau
cd -                         # revenir au dossier précédent

mkdir -p var/exports/2026    # créer un dossier, et ses parents si besoin
cp .env .env.backup          # copier
mv export.csv var/exports/   # déplacer, ou renommer
rm var/exports/old.csv       # supprimer : PAS de corbeille, c'est définitif

less var/log/prod.log        # lire un fichier page par page (q pour quitter)
head -n 20 composer.json     # les 20 premières lignes
tail -n 50 var/log/prod.log  # les 50 dernières

find src -name '*Controller.php'      # chercher des fichiers par leur nom
grep -rn 'OrderPlaced' src/           # chercher un texte, avec le n° de ligne

Sur un serveur web, quelques dossiers reviennent toujours : /var/www (les sites), /var/log (les logs du système et de nginx), /etc (la configuration : /etc/nginx, /etc/php/8.4), /tmp (les fichiers temporaires, vidés au redémarrage).

3.Tubes et redirections

La force du terminal, c'est de combiner de petits outils. Chaque commande lit une entrée et produit deux sorties : la sortie normale (numéro 1) et la sortie d'erreur (numéro 2). On peut les rediriger vers un fichier, ou les brancher sur une autre commande avec un tube (|) :

# Redirections : où va la sortie d'une commande
php bin/console app:export > export.csv        # écrit dans un fichier (l'écrase)
php bin/console app:export >> export.csv       # ajoute à la fin du fichier
php bin/console app:import 2> errors.log       # seulement les erreurs (sortie n° 2)
php bin/console app:import > all.log 2>&1      # sortie normale ET erreurs dans le même fichier

# Tube (|) : la sortie d'une commande devient l'entrée de la suivante
grep 'CRITICAL' var/log/prod.log | tail -n 20

# Les 10 adresses IP qui font le plus de requêtes, dans le log d'accès de nginx
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 10
#   awk     : garde la 1re colonne (l'IP)
#   sort    : trie, pour regrouper les IP identiques
#   uniq -c : compte chaque groupe
#   sort -rn: trie par nombre, du plus grand au plus petit
#   head    : garde les 10 premières lignes

La dernière commande répond en une ligne à une vraie question de production : « qui bombarde le serveur ? ». Chaque outil ne fait qu'une chose, et le tube les enchaîne. C'est la même idée que les petites fonctions de la fiche 2.

Chaque commande se termine aussi par un code de sortie, que les scripts utilisent pour enchaîner les étapes :

# Chaque commande se termine par un code : 0 = succès, autre chose = échec
php bin/phpunit
echo $?                              # affiche le code de la dernière commande

# && : la suite ne s'exécute QUE si la commande précédente a réussi
composer install --no-dev && php bin/console cache:clear

# || : la suite ne s'exécute que si la commande précédente a échoué
php bin/console doctrine:migrations:migrate --no-interaction || echo 'Migration échouée'

C'est ce code que lit git bisect run (fiche 4), et ce code que regarde l'intégration continue pour savoir si les tests ont réussi.

4.Processus et services

Un processus est un programme en cours d'exécution, avec un numéro (le PID). Un service est un processus qui tourne en permanence en arrière-plan : nginx, PHP-FPM, PostgreSQL. Sur la plupart des distributions, les services sont gérés par systemd, avec la commande systemctl.

ps aux | grep php-fpm            # les processus en cours, filtrés
top                              # l'activité en direct : CPU, mémoire (q pour quitter)

kill 12345                       # demande poliment au processus 12345 de s'arrêter
kill -9 12345                    # le tue sur-le-champ : en dernier recours

# Un service (nginx, PHP-FPM, PostgreSQL) est géré par systemd
systemctl status php8.4-fpm      # est-il démarré ? depuis quand ? dernières lignes de log
sudo systemctl restart nginx     # le redémarrer
sudo systemctl reload nginx      # relire sa configuration, sans couper les connexions
sudo nginx -t                    # vérifier la configuration de nginx AVANT de recharger

• reload plutôt que restart quand c'est possible : le service relit sa configuration sans couper les requêtes en cours.
• Vérifie avant de recharger : nginx -t teste la configuration. Une faute de frappe dans un fichier de configuration, rechargée sans test, peut arrêter le site.
• kill -9 en dernier recours : le processus est tué sur-le-champ, sans finir d'écrire ses fichiers ni fermer ses connexions.

5.Utilisateurs et permissions

Linux est multi-utilisateur. Chaque fichier appartient à un propriétaire et à un groupe, et a trois séries de droits : pour le propriétaire, pour le groupe, et pour les autres.

$ ls -l
-rw-r----- 1 deploy www-data  1820 nov.  3 10:12 .env.local
drwxrwxr-x 5 deploy www-data  4096 nov.  3 10:12 var

  -rw-r-----   type et permissions
  │└┬┘└┬┘└┬┘
  │ │  │  └─ les autres         : ---  aucun droit
  │ │  └──── le groupe www-data : r--  lire
  │ └─────── le propriétaire    : rw-  lire et écrire
  └───────── - fichier, d dossier

  r = lire (4)   w = écrire (2)   x = exécuter, ou entrer dans un dossier (1)
  rw-r----- = 6 4 0  →  chmod 640

chmod 640 .env.local                  # propriétaire : rw ; groupe : r ; autres : rien
chmod u+x bin/deploy.sh               # ajouter le droit d'exécution au propriétaire
sudo chown -R deploy:www-data var/    # changer le propriétaire et le groupe, récursivement

whoami                                # quel utilisateur suis-je ?
id                                    # et dans quels groupes ?
sudo -u www-data php bin/console cache:clear   # lancer une commande en tant que www-data

Sur un serveur web, PHP-FPM tourne en général sous l'utilisateur www-data. C'est lui qui doit pouvoir écrire dans var/ (le cache et les logs de Symfony), et seulement lire le code. Le code lui-même appartient à un utilisateur de déploiement (ici deploy).

6.Variables d'environnement

Une variable d'environnement est une valeur nommée que chaque processus hérite de celui qui l'a lancé. C'est par elles que Symfony reçoit APP_ENV, DATABASE_URL ou ses secrets en production (fiche 10).

echo $HOME                          # afficher une variable
printenv | grep APP_                # lister les variables qui commencent par APP_
export APP_ENV=prod                 # définir une variable pour ce terminal et ses enfants
APP_ENV=test php bin/phpunit        # la définir pour UNE seule commande

echo $PATH                          # les dossiers où le shell cherche les programmes
# Les réglages permanents de ton terminal se mettent dans ~/.bashrc (ou ~/.zshrc)

7.Lire les logs

Pendant une panne, les logs sont la première source d'information. Il en existe trois sortes sur un serveur Symfony : ceux de l'application (var/log/prod.log, ou la sortie d'erreur selon la configuration), ceux de nginx (/var/log/nginx/), et ceux des services gérés par systemd.

tail -f var/log/prod.log                      # suivre en direct (Ctrl+C pour arrêter)
tail -f var/log/prod.log | grep --line-buffered ERROR   # en direct, seulement les erreurs

journalctl -u nginx --since '1 hour ago'      # les logs d'un service systemd, depuis une heure
journalctl -u php8.4-fpm -f                   # en direct

less +G /var/log/nginx/error.log              # ouvrir directement à la fin du fichier

1. Commence par l'heure : quand le problème a-t-il commencé ? Cherche les premières erreurs autour de ce moment, pas les dernières.
2. Remonte la chaîne : une erreur 502 dans le log de nginx renvoie au log de PHP-FPM, qui renvoie au log de Symfony.
3. Garde tail -f ouvert dans un terminal pendant que tu reproduis le problème dans le navigateur.

La fiche 13 revient sur ce qu'il faut écrire dans les logs, et sur leur centralisation.

8.SSH : se connecter à un serveur

SSH ouvre un terminal sur une machine distante, à travers une connexion chiffrée. On s'authentifie avec une paire de clés plutôt qu'avec un mot de passe :

1. La clé privée reste sur ta machine. C'est elle qui prouve ton identité : elle ne se partage jamais, ne s'envoie jamais par e-mail, et ne se commite jamais.
2. La clé publique se dépose sur chaque serveur, dans ~/.ssh/authorized_keys. Elle peut être vue par tout le monde sans danger.

# 1. Sur TA machine : créer une paire de clés (protège-la par une phrase de passe)
ssh-keygen -t ed25519 -C "prenom@poste-portable"
#    ~/.ssh/id_ed25519      la clé PRIVÉE : ne quitte jamais ta machine
#    ~/.ssh/id_ed25519.pub  la clé PUBLIQUE : celle qu'on dépose sur les serveurs

# 2. Déposer la clé publique sur le serveur
ssh-copy-id deploy@203.0.113.10

# 3. Se connecter, puis copier des fichiers
ssh deploy@203.0.113.10
scp backup.sql deploy@203.0.113.10:/tmp/
rsync -avz --delete public/build/ deploy@203.0.113.10:/var/www/shop/public/build/

Un fichier de configuration évite de retaper l'adresse et l'utilisateur :

# ~/.ssh/config sur TA machine : un alias par serveur
Host shop-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519

# Ensuite, il suffit de taper : ssh shop-prod

Côté serveur, une fois les clés en place, on désactive les connexions par mot de passe et la connexion directe en root :

# /etc/ssh/sshd_config sur le SERVEUR (extrait)
PermitRootLogin no              # pas de connexion directe en root
PasswordAuthentication no       # clés uniquement : plus de mot de passe à deviner
KbdInteractiveAuthentication no

9.Le pare-feu

Un serveur ne devrait accepter des connexions que sur les ports dont il a besoin : 22 pour SSH, 80 et 443 pour le web. Tout le reste (la base de données, Redis, les outils d'administration) doit rester inaccessible depuis Internet. Sur Ubuntu, ufw simplifie la configuration du pare-feu :

# L'ORDRE COMPTE : autorise SSH AVANT d'activer le pare-feu, sinon tu te bloques dehors
sudo ufw default deny incoming     # tout refuser en entrée par défaut
sudo ufw default allow outgoing    # autoriser le serveur à sortir (mises à jour, API)
sudo ufw allow OpenSSH             # port 22
sudo ufw allow 80/tcp              # HTTP (pour rediriger vers HTTPS)
sudo ufw allow 443/tcp             # HTTPS
sudo ufw enable                    # activer
sudo ufw status verbose            # vérifier

Pièges fréquents

Checklist sur un serveur

• Je sais sur quel serveur et dans quel dossier je suis (hostname, pwd) avant de lancer une commande qui modifie quelque chose.
• Les connexions SSH se font par clé uniquement, sans root direct.
• Le pare-feu n'ouvre que les ports 22, 80 et 443.
• Le code appartient à un utilisateur de déploiement, et www-data n'écrit que dans var/.
• Aucun fichier contenant un secret n'est lisible par « les autres ».
• Je sais où trouver les logs de nginx, de PHP-FPM et de Symfony.
• J'ai testé la configuration avant de recharger un service.

Conseils

1. Pratique sur ta machine. Un terminal sous Linux, macOS, ou WSL sous Windows suffit. Lire tes propres logs de développement avec tail, grep et des tubes est un bon entraînement, sans aucun risque.
2. Lis la commande avant d'appuyer sur Entrée, surtout en production, et surtout si elle vient d'un copier-coller.
3. Ne lance jamais un script téléchargé sans le lire, en particulier les fameux curl … | bash : ils exécutent avec tes droits un code que tu n'as pas vu.
4. Note ce que tu fais en production, dans un ticket ou un document partagé. En cas de problème, l'équipe saura ce qui a changé.
5. Utilise man sans complexe. Les développeurs expérimentés le consultent tous les jours.

Documentation officielle

• Le manuel de Bash et les outils de base GNU (coreutils)
• systemctl et journalctl
• Le manuel d'OpenSSH
• ufw (Ubuntu)
• Les permissions de fichiers dans Symfony