Commandes Bash de base avec exemples pratiques : un guide pour les opérations quotidiennes

Introduction

Chaque opérateur a déjà vécu ce moment où un problème de production survient et où le seul outil disponible est un terminal. Bash est le langage commun des environnements Linux et macOS, et connaître un ensemble ciblé de commandes de base avec des exemples pratiques transforme la panique en une procédure reproductible. Ce guide est conçu pour les développeurs, les consultants DevOps et les équipes techniques de startups qui doivent diagnostiquer, configurer, vérifier et récupérer des services sans deviner.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint. Chaque section ci-dessous combine un concept avec des commandes prêtes à l'emploi, une sortie attendue et un point de décision. Les espaces réservés comme APP_USER, SERVICE_NAME ou BACKUP_DIR doivent être remplacés par les valeurs de votre environnement avant l'exécution. Ne collez jamais de véritables identifiants, jetons, clés privées ou identifiants de production dans une commande ou un script.

Inventaire de la version et de l'environnement

Avant de toucher à un fichier de configuration ou de redémarrer un service, vous devez savoir exactement ce que vous exécutez. Commencez par des commandes en lecture seule qui révèlent le système d'exploitation, le noyau, la version de Bash et les outils disponibles. Cette section montre comment collecter cet inventaire de manière structurée.

Prérequis et hypothèses

• Vous pouvez ouvrir un terminal en tant qu'utilisateur non root avec des droits sudo pour les commandes administratives.
• Vous travaillez sous Linux (les commandes sont également pertinentes pour macOS avec des différences mineures).
• Vous comprenez la disposition générale de /etc, /var et /home.

Collecte des faits système

Exécutez ces commandes une par une et enregistrez la sortie. Elles ne modifient rien.

# Nom et version du système d'exploitation
cat /etc/os-release

# Version du noyau
uname -r

# Version de Bash
bash --version | head -n1

# Utilisateur actuel et groupes
id

# Espace disque disponible
 df -h /

# Mémoire et swap
 free -h

La sortie attendue pour cat /etc/os-release sur Ubuntu 22.04 inclut des lignes comme :

PRETTY_NAME="Ubuntu 22.04.4 LTS"
VERSION_ID="22.04"

Sur Rocky Linux 9.3, PRETTY_NAME afficherait "Rocky Linux 9.3 (Blue Onyx)" et VERSION_ID="9.3".

Pour bash --version, la première ligne ressemble à :

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Si Bash est antérieur à la version 4.0 sur un système que vous prévoyez de scripter fortement, notez-le ; les syntaxes plus récentes comme les tableaux associatifs peuvent ne pas fonctionner.

Identification des services en cours d'exécution et des ports

Utilisez ss ou netstat pour voir ce qui est en écoute. Ce sont des observations en lecture seule.

# Lister les ports TCP en écoute avec les noms de processus (nécessite sudo pour les informations sur les processus)
sudo ss -tulpn

# Alternativement, sur les systèmes plus anciens :
sudo netstat -tulpn

Une ligne typique de ss -tulpn :

LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))

Cela vous indique que SSH est en écoute sur le port 22. Si vous voyez un écouteur inattendu sur le port 8080, enquêtez avant de faire des modifications.

Enregistrement de la topologie de déploiement

Notez quels services s'exécutent sur quel hôte. Une commande simple pour capturer le nom d'hôte et les adresses IP :

hostname
ip -brief address

Exemple de sortie :

app-server-01
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.1.25/24 fe80::1/64

Stockez cet inventaire dans une note ou un script pour référence ultérieure. Si un service échoue, vous pouvez comparer l'état actuel à la référence connue.

Chemin de configuration sécurisé

Une fois que vous comprenez l'environnement, vous pouvez apporter des modifications. Le chemin sécurisé signifie : sauvegarder le fichier actuel, éditer avec un commentaire clair, valider la syntaxe et redémarrer uniquement si la vérification échoue. Cette section parcourt l'édition d'un fichier de configuration de service typique avec des étapes de récupération complètes.

Sauvegarder avant d'éditer

Ne modifiez jamais un fichier de configuration sans une sauvegarde horodatée. Utilisez cp avec un suffixe de date :

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%Y%m%d-%H%M%S)

Par exemple, le 3 février 2025 à 14h30, le fichier de sauvegarde devient nginx.conf.bak-20250203-143000.

Vérifiez que la sauvegarde existe :

ls -l /etc/nginx/nginx.conf.bak-*

La sortie attendue montre la taille du fichier d'origine et l'horodatage.

Éditer avec un objectif

Utilisez vim, nano ou sed pour apporter la plus petite modification. Supposons que vous deviez changer le nombre de processus worker dans Nginx de auto à 2 parce que le serveur n'a que 2 cœurs CPU et que vous voulez une utilisation mémoire prévisible.

Avant d'éditer, affichez la valeur actuelle :

grep -n "worker_processes" /etc/nginx/nginx.conf

Exemple de sortie :

3:worker_processes auto;

Éditez la ligne 3 avec sed (ou utilisez un éditeur visuel) :

sudo sed -i 's/worker_processes auto;/worker_processes 2;/' /etc/nginx/nginx.conf

Valider la syntaxe avant d'appliquer

Pour Nginx, exécutez :

sudo nginx -t

Sortie de succès attendue :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si vous voyez une erreur, revenez immédiatement à la sauvegarde :

sudo cp /etc/nginx/nginx.conf.bak-20250203-143000 /etc/nginx/nginx.conf
sudo nginx -t

Recharger ou redémarrer uniquement si nécessaire

Après un test de syntaxe réussi, rechargez Nginx pour appliquer les modifications sans interrompre les connexions :

sudo systemctl reload nginx

Si le service ne parvient pas à se recharger ou si la modification nécessite un redémarrage complet, utilisez :

sudo systemctl restart nginx

Vérifiez l'état :

systemctl status nginx --no-pager

Recherchez Active: active (running) dans la sortie. Si ce n'est pas actif, revenez à la configuration précédente et redémarrez à nouveau.

Plan de restauration

Ayez toujours un plan de restauration avant de faire une modification. Pour l'exemple Nginx :

1. Chemin du fichier de sauvegarde enregistré.
2. Commande de restauration prête : sudo cp /etc/nginx/nginx.conf.bak-20250203-143000 /etc/nginx/nginx.conf
3. Commande de rechargement ou de redémarrage prête.
4. URL de test ou curl -I http://localhost pour confirmer.

Vérification et diagnostic

Après une modification, vous devez vérifier le résultat. Les diagnostics impliquent la vérification des journaux, des processus et du comportement réseau pour confirmer l'état souhaité. Cette section montre comment vérifier un service web après un changement de configuration, en utilisant Nginx comme exemple concret.

Vérification de l'état du service

systemctl is-active nginx

Sortie attendue : active. Si cela indique inactive ou failed, enquêtez avec :

systemctl status nginx --no-pager -l
journalctl -u nginx --since "10 minutes ago" --no-pager

La sortie du journal montrera les messages d'erreur. Par exemple, une erreur courante est un point-virgule manquant dans la configuration, que nginx -t aurait détecté. Si vous avez sauté la validation, vous verrez quelque chose comme :

nginx: [emerg] unexpected end of file, expecting ";" or "}" in /etc/nginx/nginx.conf:42

Vérification de la réponse réseau

Utilisez curl pour obtenir les en-têtes et le code de statut :

curl -I http://localhost

Sortie attendue pour le succès :

HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 03 Feb 2025 14:35:00 GMT
Content-Type: text/html

Si vous obtenez curl: (7) Failed to connect, vérifiez si le service est en cours d'exécution et en écoute :

sudo ss -tulpn | grep :80

Devrait afficher une ligne avec nginx et 0.0.0.0:80 ou similaire.

Suivi des journaux en temps réel

Pour les problèmes en cours, suivez les journaux d'accès et d'erreur :

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

Envoyez une requête de test depuis un autre terminal et observez la mise à jour des journaux.

Utilisation de commandes de diagnostic pour d'autres services

Le même schéma s'applique aux bases de données, files de messages ou serveurs d'applications. Par exemple, pour vérifier si PostgreSQL accepte les connexions après une modification de postgresql.conf :

pg_isready -h localhost -p 5432

Sortie attendue : localhost:5432 - accepting connections. Si cela indique no response, vérifiez les journaux avec journalctl -u postgresql et vérifiez listen_addresses dans la configuration.

Modes de défaillance et récupération

Les défaillances surviennent malgré une préparation minutieuse. Cette section couvre les scénarios de défaillance courants, comment les détecter et comment récupérer en utilisant les sauvegardes et les vérifications que vous avez déjà configurées.

Scénario 1 : Le service ne démarre pas après un changement de configuration

Symptômes : systemctl start nginx échoue, une erreur dans le journal indique un problème de syntaxe ou de permission.

Récupération immédiate :

1. Revenez à la dernière bonne sauvegarde :

sudo cp /etc/nginx/nginx.conf.bak-20250203-143000 /etc/nginx/nginx.conf

1. Validez la configuration restaurée :

sudo nginx -t

1. Démarrez le service :

sudo systemctl start nginx

1. Vérifiez avec curl -I http://localhost.

Scénario 2 : Disque plein sur la partition des journaux

Symptômes : les écritures d'application échouent, df -h montre une utilisation à 100 % sur /var.

Observation :

df -h /var

Exemple de sortie :

Filesystem Size Used Avail Use% Mounted on
/dev/sda3 20G 20G 0 100% /var

Soulagement immédiat : Trouvez les gros fichiers :

sudo du -ah /var | sort -rh | head -n 10

Si les journaux sont en cause, vous pouvez les compresser et les tronquer (après avoir confirmé qu'ils ne sont pas nécessaires pour l'analyse forensique) :

sudo tar -czf /tmp/old-logs-$(date +%Y%m%d).tar.gz /var/log/nginx/access.log*
sudo truncate -s 0 /var/log/nginx/access.log

Prévention : Configurez logrotate avec une politique comme :

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 `cat /run/nginx.pid`
    endscript
}

Scénario 3 : Arrêt pour mémoire insuffisante (OOM)

Symptômes : Le processus disparaît de ps aux, dmesg affiche un message du tueur OOM.

Détection :

sudo dmesg -T | grep -i "out of memory"

Exemple de ligne de sortie :

[Mon Feb 3 14:50:12 2025] Out of memory: Killed process 1234 (node) total-vm:2048000kB, anon-rss:1800000kB, file-rss:0kB, shmem-rss:0kB

Récupération : Redémarrez le service et surveillez l'utilisation de la mémoire :

sudo systemctl restart myapp
free -h

Correctif permanent : Ajustez la limite de mémoire du service dans son fichier d'unité systemd sous [Service] avec MemoryMax=500M, puis sudo systemctl daemon-reload et redémarrez.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après toute tâche opérationnelle. Elle est conçue pour être imprimée ou conservée dans un fichier texte adapté au terminal.

Liste de contrôle avant modification

Liste de contrôle après modification

Qui est responsable de quoi

Attribuez un seul responsable pour chaque décision majeure. Par exemple, le responsable d'ingénierie (par exemple, Priya Shah) approuve les modifications de configuration en production. L'opérateur de garde (par exemple, Leo Martinez) exécute la modification. Le demandeur de changement (par exemple, un développeur d'application, comme Anika Patel) vérifie le résultat fonctionnel. Ces rôles et noms doivent être enregistrés dans le runbook de votre équipe. Révisez le runbook mensuellement, ou après tout incident, selon la première éventualité.

Pièges courants et comment les éviter

Même les opérateurs expérimentés commettent des erreurs. Voici les pièges les plus fréquents en Bash et en administration système, pourquoi ils surviennent et comment les prévenir ou s'en remettre.

Piège 1 : Modifier la configuration sans sauvegarde

Pourquoi cela arrive : Le changement semble trivial, ou l'opérateur est sous pression temporelle.

Conséquence : Si la modification casse le service, vous n'avez aucun moyen rapide de revenir en arrière.

Comment éviter : Exécutez toujours la commande de sauvegarde avant de modifier. Prenez l'habitude : sudo cp file file.bak-$(date +%s).

Récupération : Si vous oubliez, vous pourriez encore trouver une copie dans /var/backups ou dans un outil de gestion de configuration comme Ansible ou Puppet. Sinon, vous devez reconstruire le fichier de mémoire ou de la documentation.

Piège 2 : Utiliser rm -rf avec des variables vides

Pourquoi cela arrive : Un script utilise une variable pour un chemin de répertoire, et la variable n'est pas définie ou est vide à cause d'une faute de frappe ou d'une erreur de logique.

Exemple de commande dangereuse :

rm -rf "$TARGET_DIR/"

Si TARGET_DIR est vide, cela devient rm -rf / (ou une variante dangereuse) et peut effacer le système.

Comment éviter : Vérifiez toujours que la variable est non vide avant de l'utiliser :

if [ -z "$TARGET_DIR" ]; then
    echo "TARGET_DIR est vide, abandon"
    exit 1
fi
rm -rf "$TARGET_DIR/"

Mieux encore, utilisez find avec -delete et un chemin explicite.

Piège 3 : Rediriger la sortie avec > au lieu d'ajouter >>

Pourquoi cela arrive : Taper trop rapidement ou mal comprendre la redirection du shell.

Conséquence : Vous écrasez un fichier existant au lieu d'y ajouter, perdant les données précédentes.

Exemple : Supposons que vous vouliez ajouter une ligne à un fichier journal mais que vous utilisiez accidentellement >.

Comment éviter : Utilisez >> pour ajouter. Si vous devez écrire un nouveau fichier, vérifiez le nom de fichier. Vous pouvez également définir set -o noclobber dans votre shell pour empêcher l'écrasement des fichiers existants avec >. Pour passer outre, utilisez >|.

Piège 4 : Ne pas mettre de guillemets autour des variables dans les scripts

Pourquoi cela arrive : Oublier que les noms de fichiers ou les arguments peuvent contenir des espaces ou des caractères spéciaux.

Exemple :

file=mon rapport.txt
cat $file

Cela échoue car le shell divise $file en mon et rapport.txt.

Comment éviter : Mettez toujours des guillemets autour des variables : cat "$file". Utilisez shellcheck pour vérifier vos scripts.

Piège 5 : Exécuter des commandes en tant que root sans sudo lorsque requis (ou abuser de root)

Pourquoi cela arrive : Commodité ou manque de conscience des exigences de privilèges.

Conséquence : Exécuter en tant que root augmente les dégâts des erreurs. Ne pas utiliser sudo quand nécessaire entraîne des erreurs de permission refusée.

Comment éviter : Utilisez un compte utilisateur normal et sudo uniquement pour les commandes administratives. Configurez sudo avec des commandes autorisées spécifiques si possible.

Piège 6 : Mal interpréter les codes de sortie

Pourquoi cela arrive : Ne pas vérifier le statut de sortie d'une commande, en supposant qu'elle a réussi.

Exemple :

sudo systemctl restart nginx
curl -I http://localhost

Si le redémarrage a échoué, le curl échouera probablement aussi, mais l'opérateur pourrait ne regarder que la sortie de curl et manquer la cause racine.

Comment éviter : Vérifiez toujours les codes de sortie :

sudo systemctl restart nginx
if [ $? -ne 0 ]; then
    echo "Le redémarrage a échoué, abandon"
    exit 1
fi
curl -I http://localhost

Ou utilisez systemctl restart nginx && curl -I http://localhost.

Conclusion

Les commandes Bash de base avec des exemples pratiques ne deviennent utiles que lorsque chaque recommandation est versionnée, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation ; c'est un pari.

Comme prochaine étape, choisissez une vérification à faible risque de la liste de contrôle des opérations et exécutez-la dans votre environnement. Par exemple, prenez un service en cours d'exécution comme Nginx, enregistrez sa sauvegarde de configuration actuelle, apportez une modification de commentaire inoffensive, validez, rechargez et vérifiez avec curl -I http://localhost. Documentez ensuite les étapes de restauration. Révisez la sortie avec un collègue et stockez le runbook dans le wiki de votre équipe.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Pratiquez ces commandes d'abord dans un environnement de test, et vous serez prêt lorsque la production exigera une action calme et compétente.