Créez un labo Bash local sécurisé : configuration étape par étape et exemples pratiques

Apprenez à mettre en place un labo Bash local sûr et reproductible pour tester, dépanner et apprendre. Ce guide couvre les prérequis d’environnement, la configuration à portée limitée, les étapes de vérification, la récupération après échec et une checklist d’exploitation avec des exemples de commandes concrets.

Intro

Bash est le shell par défaut sur la plupart des distributions Linux et sur macOS, et il est facile à utiliser sous Windows via WSL, Git Bash ou Cygwin. Un labo Bash local vous offre un espace propre et isolé pour expérimenter des commandes et des scripts sans risquer vos fichiers importants ni encombrer votre système. Dans cet article, vous allez construire un labo fonctionnel avec :

• Une arborescence de répertoires isolée et un fichier d’environnement
• Des valeurs par défaut sûres pour les scripts (set -euo pipefail, traps et un IFS raisonnable)
• Des scripts de diagnostic pour vérifier votre installation
• Des exemples pratiques pour les opérations sur fichiers et la gestion des erreurs
• Des playbooks de récupération pour les pannes courantes
• Une checklist d’exploitation concise à utiliser au quotidien

À la fin, vous disposerez d’un espace de travail reproductible pour apprendre et expérimenter sous Linux, macOS ou WSL.

Inventaire des versions et de l’environnement

Commencez par confirmer les détails de votre version de Bash et de votre OS. Ces vérifications indiquent les fonctionnalités disponibles et l’endroit où vous exécutez vos commandes.

Vérifier la version de Bash (Bash 4.0+ recommandé) :

bash --version

Exemple de sortie :

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

Vérifier votre système d’exploitation et votre architecture :

uname -a
whoami
pwd

Notes selon la plateforme :

• Linux : utilisez le gestionnaire de paquets de votre distribution pour mettre à jour Bash si nécessaire (apt, dnf, pacman, zypper).
• macOS : les versions récentes de macOS incluent Bash 3.x. Si vous avez besoin de fonctionnalités de Bash 4+, installez via Homebrew (brew install bash) et exécutez les scripts explicitement via /usr/local/bin/bash ou /opt/homebrew/bin/bash sur Apple Silicon.
• Windows : privilégiez WSL (Ubuntu est courant). Git Bash fonctionne pour la plupart des exemples ; certains chemins et outils peuvent différer.

Outils recommandés pour le labo :

• Utilitaires de base (ls, mkdir, cp, mv, rm, find, grep, awk, sed, diff)
• Un éditeur de texte (vim, nano, VS Code)
• git pour versionner vos expériences (facultatif mais utile)
• shellcheck pour l’analyse statique (facultatif)

Créer un espace de travail isolé

Créez un espace unique avec des sous-répertoires prévisibles afin d’éviter que vos expériences ne fuient vers votre répertoire personnel.

mkdir -p "$HOME/bash-lab" && cd "$HOME/bash-lab"

Optionnel : initialiser git pour suivre les changements :

git init
printf "# Ignorer le contenu généré\nlogs/\n*.log\ntmp/\n*.tmp\n*.tar.gz\n" > .gitignore

Créer des répertoires standard :

mkdir -p bin data logs tmp

Créer un fichier d’environnement du labo avec des variables exportées à sourcer lorsque vous travaillez dans ce labo :

cat > lab.env << 'EOF'
# Environnement limité au labo
export LAB_BASE="$HOME/bash-lab"
export LAB_BIN="$LAB_BASE/bin"
export LAB_DATA="$LAB_BASE/data"
export LAB_LOGS="$LAB_BASE/logs"
export LAB_TMP="$LAB_BASE/tmp"

# Mettre le bin du labo en tête pour plus de commodité
export PATH="$LAB_BIN:$PATH"

# Permissions conservatrices pour les fichiers créés
umask 077
EOF

Charger l’environnement pour votre session shell courante et vérifier :

source lab.env
printf "%s\n" "$LAB_BASE" "$LAB_BIN" "$LAB_DATA" "$LAB_LOGS" "$LAB_TMP"

Attendu : des chemins absolus sous votre répertoire personnel. Tous les exercices ci-dessous supposent que vous avez sourcé lab.env et que vous êtes dans $LAB_BASE.

Un modèle de script sûr et réutilisable

Utilisez un modèle strict et réutilisable pour éviter les pièges courants. Ce modèle active des options sûres, ajoute un mini journaliseur et des crochets de nettoyage.

cat > bin/template.sh << 'EOF'
#!/usr/bin/env bash
# Modèle Bash sécurisé pour les scripts du labo
set -Eeuo pipefail
IFS=$'\n\t'

# Journaliser sur stderr avec horodatage
log() { printf "%s %s\n" "$(date +%F' '%T)" "$*" >&2; }

# Nettoyage à la sortie normale ou sur erreur
cleanup() {
  # Exemple : supprimer les fichiers temporaires suivis dans TMP_FILES
  if [[ -n "${TMP_FILES:-}" ]]; then rm -f $TMP_FILES || true; fi
}
trap cleanup EXIT
trap 'log "Erreur à la ligne $LINENO"' ERR

usage() {
  cat <<USAGE
Usage : ${0##*/} [-n NOM]
  -n NOM   Nom à saluer (par défaut : world)
USAGE
}

name="world"
while getopts ":n:h" opt; do
  case "$opt" in
    n) name="$OPTARG" ;;
    h) usage; exit 0 ;;
    *) usage; exit 2 ;;
  esac
done

main() {
  log "Exécution sous : $(whoami)"
  log "Base du labo : ${LAB_BASE:-unset}"
  echo "Hello, $name"  # la sortie normale va sur stdout
}

main "$@"
EOF
chmod +x bin/template.sh

Lancer le script :

template.sh -n testeur

Attendu : quelques lignes de journal sur stderr et la ligne "Hello, testeur" sur stdout. Essayez echo $? pour confirmer un code de sortie zéro.

Vérifier le labo avec des diagnostics

Créez un script de diagnostic qui vérifie les variables d’environnement, les répertoires et les opérations de base sur fichiers.

cat > bin/check-lab.sh << 'EOF'
#!/usr/bin/env bash
set -euo pipefail

# Vérifier les attentes de base
printf "Version de Bash : %s\n" "$BASH_VERSION"
printf "Base du labo : %s\n" "${LAB_BASE:-unset}"
printf "Répertoire courant : %s\n" "$(pwd)"

[[ -d "${LAB_DATA:-/nonexistent}" ]] && echo "OK : le répertoire data existe" || echo "FAIL : répertoire data manquant"
[[ -w . ]] && echo "OK : le répertoire de travail est accessible en écriture" || echo "FAIL : impossible d'écrire dans le répertoire courant"

# Créer et supprimer un fichier temporaire pour valider permissions et nettoyage
f="$LAB_TMP/check.$RANDOM.tmp"
: > "$f"
[[ -f "$f" ]] && echo "OK : fichier tmp créé $f"
rm -f "$f"
[[ ! -e "$f" ]] && echo "OK : fichier tmp nettoyé"
EOF
chmod +x bin/check-lab.sh

Exécutez-le après avoir sourcé lab.env :

source lab.env
check-lab.sh

Tous les contrôles doivent afficher OK. Si un FAIL apparaît, revérifiez la création des répertoires et que vous avez bien sourcé lab.env.

Expériences pratiques à exécuter en sécurité

Ces courts exercices démontrent des comportements sûrs dans votre labo.

1. Bac à sable d’opérations sur fichiers :

cd "$LAB_DATA"

# Créer, copier, déplacer et comparer
printf "sample\n" > a.txt
cp a.txt b.txt
mv b.txt c.txt

diff -u a.txt c.txt  # attendu : pas de sortie (fichiers identiques)
rm -f a.txt c.txt
cd - >/dev/null

1. pipefail en action :

cat > bin/pipefail-demo.sh << 'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail
# La première commande échoue (grep sur un fichier manquant) mais wc la masquerait sans pipefail
grep pattern /no/such/file.txt | wc -l
EOF
chmod +x bin/pipefail-demo.sh

# Avec pipefail (dans le script), ceci renvoie un statut non nul
pipefail-demo.sh || echo "Code de sortie non nul comme prévu"

1. Les variables non liées sont des erreurs :

cat > bin/unbound-demo.sh << 'EOF'
#!/usr/bin/env bash
set -u
# Accéder à une variable non définie doit échouer
echo "$MISSING_VAR"
EOF
chmod +x bin/unbound-demo.sh
unbound-demo.sh || echo "Variable non liée capturée comme prévu"

1. Journalisation et nettoyage avec traps :

cat > bin/trap-demo.sh << 'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail
TMP=$(mktemp "$LAB_TMP/trap.XXXXXX")
trap 'rm -f "$TMP"' EXIT
printf "temp\n" > "$TMP"
# Simuler une erreur
false
EOF
chmod +x bin/trap-demo.sh
trap-demo.sh || echo "Nettoyage effectué après l'erreur"

# Vérifier que le temp a disparu
ls -l "$LAB_TMP" | grep trap || echo "Aucun fichier temporaire 'trap' restant"

Pannes courantes et comment récupérer

• Permission refusée lors de l’exécution d’un script
• Symptôme : bash: ./script.sh: Permission denied
• Cause : script non exécutable ou options de montage incorrectes
• Correctif : chmod +x script.sh ; sous WSL, vérifiez que le répertoire n’est pas monté avec noexec

• Commande introuvable
• Symptôme : bash: tool: command not found
• Cause : paquet manquant ou PATH non configuré
• Correctif : installez le paquet (par exemple, sudo apt install curl) ou assurez-vous que PATH inclut $LAB_BIN (source lab.env)

• Le script s’arrête tôt à cause de set -e
• Symptôme : le script s’interrompt à la première commande en échec
• Correctif : gérez explicitement les échecs attendus : cmd || true, ou mieux, testez avant usage :

if grep -q pattern file.txt; then echo "trouvé"; else echo "non trouvé"; fi

• Erreur de variable non liée avec set -u
• Symptôme : VAR: unbound variable
• Correctif : fournissez des valeurs par défaut si approprié : ${VAR:-default}

• Ciblage accidentel du mauvais chemin
• Symptôme : des fichiers hors du labo ont été modifiés ou supprimés
• Correctif : utilisez des chemins absolus à partir de $LAB_BASE. Dans le labo, vérifiez avec pwd avant les commandes destructrices. Si vous utilisez git dans le labo :

git status
git restore --staged . && git checkout -- .   # annuler les changements suivis

• Fins de ligne mixtes (sauts de ligne Windows)
• Symptôme : $'\r': command not found ou comportements étranges
• Correctif : convertir en fins de ligne Unix : dos2unix bin/*.sh (installez dos2unix si nécessaire)

• Variables d’environnement manquantes après l’ouverture d’un nouveau shell
• Symptôme : $LAB_BASE est vide
• Correctif : sourcez "$HOME/bash-lab/lab.env" à chaque démarrage de session dans le labo. Évitez de l’ajouter à votre profil global sauf si vous le souhaitez partout.

Réinitialisation, sauvegardes et entretien

Sauvegardez les artefacts clés avant des changements risqués :

cd "$LAB_BASE"
tar czf "backup-$(date +%Y%m%d).tar.gz" bin data

Nettoyez les fichiers temporaires créés pendant les expériences :

find "$LAB_TMP" -type f -name '*.tmp' -delete

Repartir de zéro en supprimant totalement le labo (irréversible) :

cd ~
rm -rf "$HOME/bash-lab"

Checklist d’exploitation

Utilisez cette checklist rapide avant et après chaque session dans le labo.

Astuce : pensez à ajouter de petits alias d’assistance dans lab.env, par exemple alias lab='cd "$LAB_BASE"' et alias logs='ls -lt "$LAB_LOGS"'.

Conclusion

Vous disposez maintenant d’un labo Bash sûr et reproductible avec des valeurs par défaut strictes, une arborescence propre et des diagnostics fiables. Vous avez appris à configurer des chemins isolés, charger un environnement limité, créer un modèle de script robuste avec traps et journalisation, valider le fonctionnement avec des vérifications et récupérer des pannes courantes. Gardez la checklist à portée de main pour de bonnes pratiques, puis étendez progressivement votre labo avec des expériences versionnées, shellcheck pour le linting, et de petits tests avec des outils comme bats. Bon script !