Linux sans magie #35 — Du terminal au premier script : ce que vous savez déjà faire, et la suite

Depuis le premier article de cette série, nous avons accumulé des commandes, des notions et des méthodes. À ce stade, le risque est de ne voir qu'une succession de sujets : permissions, processus, grep, find, variables Bash, boucles…

Pourtant, ces 34 étapes forment déjà un ensemble cohérent.

Vous savez désormais vous repérer dans un système Linux, comprendre qui peut faire quoi, observer ce qui tourne, lire les journaux, rechercher et filtrer de l'information, puis automatiser une partie de ces vérifications.

Ce #35 sert donc de point de repère. Il ne cherche pas à ajouter une nouvelle commande importante. Son objectif est de montrer comment les briques déjà vues s'assemblent, ce que vous êtes déjà capable de faire et quels grands domaines restent à explorer.

De la commande isolée à une méthode d'administration

Au début, une commande Linux ressemble souvent à une réponse ponctuelle :

pwd

pour savoir où l'on se trouve,

ls

pour voir des fichiers,

ou :

cat fichier.txt

pour lire un contenu.

Mais administrer un système ne consiste pas à mémoriser le plus grand nombre possible de commandes.

Le vrai progrès apparaît lorsque l'on sait enchaîner plusieurs questions :

Qu'est-ce que j'observe ?
Qui possède la ressource et avec quels droits ?
Quel processus ou service est concerné ?
Où trouver l'information utile ?
Comment filtrer ce qui m'intéresse ?
Comment vérifier le résultat ?
Puis-je automatiser cette vérification sans masquer les erreurs ?

C'est précisément le chemin construit depuis le #1.

Premier bloc : se repérer et manipuler les fichiers

Les quatre premiers articles ont posé le vocabulaire de base :

Linux n'est pas réservé aux experts ;
le terminal est une interface de travail, pas une fin en soi ;
fichiers et répertoires forment une arborescence ;
les fichiers texte sont une source centrale de configuration et d'information.

Cette première étape paraît élémentaire, mais elle conditionne tout le reste.

Une grande partie de l'administration Linux revient à répondre à des questions liées à des chemins et à des fichiers :

où suis-je ?
où se trouve cette configuration ?
quel fichier dois-je lire ?
quel répertoire contient les données ?
quelle commande a créé ou modifié ce fichier ?

La suite de la série n'a jamais vraiment quitté cette base. Les permissions s'appliquent à des fichiers et répertoires. Les services lisent des configurations et écrivent des journaux. Les outils grep, sed, awk ou find travaillent eux aussi sur des textes, des chemins ou des flux.

Deuxième bloc : comprendre les permissions avant d'utiliser sudo

Du #5 au #15, la série s'est concentrée sur les droits :

permissions rwx ;
propriétaire, groupe et autres utilisateurs ;
script exécutable ;
chmod symbolique et octal ;
diagnostic d'un Permission denied ;
umask ;
ACL classiques et ACL par défaut ;
SUID, SGID et Sticky Bit ;
Linux capabilities ;
sudo.

Le fil conducteur est important : un refus d'accès n'implique pas automatiquement qu'il faut utiliser sudo.

Avant d'élever les privilèges, vous savez maintenant vérifier le propriétaire, le groupe, les bits de permission et les mécanismes complémentaires pouvant intervenir.

Cette manière de raisonner est plus importante que la mémorisation d'une valeur octale.

Lorsqu'une commande échoue avec un problème de droits, votre première réaction peut désormais être :

identifier précisément la ressource ;
regarder ses permissions ;
comprendre sous quel utilisateur la commande s'exécute ;
déterminer si le groupe ou une ACL intervient ;
n'utiliser une élévation de privilèges que lorsqu'elle est réellement nécessaire.

C'est déjà une démarche d'administration et de sécurité.

Troisième bloc : comprendre ce qui tourne sur la machine

Du #16 au #23, nous sommes passés des fichiers aux processus et aux services.

Nous avons vu :

processus et PID ;
passage historique de System V à systemd ;
systemctl ;
journalctl ;
premier plan, arrière-plan et jobs du shell ;
nice et renice ;
nohup et disown ;
screen et tmux.

Le système n'est donc plus seulement une arborescence de fichiers. C'est aussi un ensemble de programmes en cours d'exécution, avec des états, des priorités, des journaux et des cycles de vie.

Vous savez désormais distinguer plusieurs questions qui étaient faciles à mélanger au départ :

le programme existe-t-il sur disque ?
un processus correspondant est-il en cours d'exécution ?
est-il géré par systemd ?
le service est-il actif ?
que disent ses logs ?
la commande a-t-elle été lancée depuis votre shell ou par un gestionnaire de services ?

Cette distinction devient essentielle pour le troubleshooting.

Quatrième bloc : transformer de l'information brute en réponse utile

Du #24 au #29, nous avons construit une boîte à outils de traitement de données en ligne de commande :

stdin, stdout et stderr ;
redirections et pipes ;
grep, cut, sort, uniq, wc ;
sed ;
awk ;
find ;
find avec xargs.

C'est probablement le moment où le terminal commence à devenir un véritable outil d'analyse.

Une commande peut produire beaucoup d'informations. L'objectif n'est pas forcément de tout lire, mais de construire progressivement la réponse recherchée.

Par exemple :

journalctl -u <SERVICE>

peut produire un grand volume de lignes.

Un pipe permet ensuite de transmettre cette sortie à un outil de filtrage :

journalctl -u <SERVICE> | grep 'error'

Cet exemple ne signifie pas que toutes les erreurs contiennent littéralement le mot error. Il montre la méthode : produire une information, puis la réduire selon un critère explicite.

La même logique s'applique aux fichiers avec find, ou aux données structurées en colonnes avec awk.

Cinquième bloc : passer de l'analyse manuelle à l'automatisation

Les articles #30 à #34 ont assemblé les fondamentaux Bash nécessaires pour commencer à automatiser :

codes de retour et $? ;
variables et quoting ;
"$VAR", guillemets simples et doubles ;
conditions avec test, [ ], [[ ]] et if ;
boucles for et while ;
break et continue ;
paramètres positionnels ;
"$@" ;
fonctions ;
return et exit ;
gestion explicite des erreurs.

C'est un changement important.

Vous n'êtes plus limité à exécuter une suite de commandes à la main. Vous pouvez commencer à écrire un petit outil qui :

reçoit une cible ;
vérifie ses arguments ;
exécute plusieurs contrôles ;
teste leur réussite ;
affiche un résultat compréhensible ;
retourne un statut exploitable par un autre outil.

Nous nous arrêtons volontairement ici pour le bloc Bash.

Il existe beaucoup d'autres sujets : getopts, tableaux, trap, options comme set -e ou pipefail, tests automatisés, ShellCheck…

Ils pourront être abordés lorsqu'un besoin opérationnel les justifiera. L'objectif de la série n'est pas de devenir un cours exhaustif de programmation Bash, mais de donner les outils nécessaires à l'administration Linux.

Un scénario de synthèse : diagnostiquer avant d'agir

Prenons un cas volontairement générique : un service systemd appelé <SERVICE> ne semble pas fonctionner comme prévu.

La mauvaise approche serait de commencer immédiatement à modifier sa configuration ou à le redémarrer au hasard.

Les acquis de la série permettent une démarche plus structurée.

1. Observer l'état du service

systemctl status <SERVICE>

Vous cherchez d'abord à connaître son état et les informations immédiatement disponibles.

2. Lire les journaux associés

journalctl -u <SERVICE> -n 50

Vous passez ensuite de l'état général aux événements enregistrés.

3. Filtrer une information précise

Si vous recherchez un terme identifié dans le message d'erreur :

journalctl -u <SERVICE> -n 200 | grep '<MOTIF>'

Le pipe relie ici deux compétences vues séparément : journalisation et traitement de texte.

4. Vérifier les fichiers concernés avant toute modification

Si le diagnostic vous conduit vers un fichier de configuration connu :

ls -l <FICHIER>

Vous pouvez vérifier ses droits avant de conclure à un problème de permission.

Si vous devez retrouver un fichier dont vous connaissez le nom dans un périmètre précis :

find <REPERTOIRE> -type f -name '<NOM>'

5. Automatiser seulement ce qui est suffisamment compris

Si la même vérification doit être répétée, vous pouvez ensuite l'encapsuler dans un script qui reçoit le service en argument, appelle les commandes nécessaires et contrôle leurs codes de retour.

Le point important est l'ordre :

comprendre d'abord, automatiser ensuite.

Un script ne corrige pas une méthode de diagnostic mal comprise. Il la répète simplement plus vite.

La carte mentale à retenir

Après ces 34 étapes, vous pouvez résumer votre méthode avec six verbes :

Observer → Comprendre → Filtrer → Agir → Vérifier → Automatiser

Observer : fichiers, processus, état d'un service, logs.

Comprendre : droits, propriétaire, groupe, PID, statut, code de retour.

Filtrer : pipes, grep, sed, awk, find.

Agir : modifier un fichier, ajuster un droit, contrôler un processus ou un service lorsque l'action est justifiée.

Vérifier : relire l'état, le contenu, les permissions, les logs ou le code de retour.

Automatiser : seulement lorsque la séquence manuelle est comprise et reproductible.

Cette carte mentale est plus durable qu'une liste de commandes.

Ce qui vient ensuite : élargir l'administration Linux

Nous avons maintenant une base solide, mais plusieurs domaines centraux n'ont pas encore été traités en profondeur.

Le prochain grand bloc commencera par le stockage et les systèmes de fichiers.

Il faudra notamment apprendre à répondre à des questions telles que :

quel espace disque est réellement disponible ?
quelle différence existe entre un disque, une partition, un filesystem et un point de montage ?
quel répertoire consomme de l'espace ?
pourquoi deux outils peuvent-ils donner des chiffres qui semblent différents ?
comment comprendre les montages sans modifier le système au hasard ?

Ensuite, la série pourra progressivement élargir le terrain vers d'autres dimensions importantes de l'administration Linux :

réseau ;
gestion des paquets et logiciels ;
services et démarrage avec des cas plus complets ;
logs et diagnostic transversal ;
stockage et montages persistants ;
méthodes de troubleshooting combinant plusieurs couches du système.

L'objectif restera le même : introduire chaque nouveau bloc au moment où il devient utile, puis relier les concepts plutôt que d'empiler des commandes.

Bonnes pratiques pour continuer à progresser

Lorsque vous rencontrez une commande inconnue, ne cherchez pas seulement « quoi taper ».

Essayez d'abord de déterminer :

quelle question cette commande permet de résoudre ;
quelles données elle lit ;
ce qu'elle affiche sur stdout ou stderr ;
son code de retour ;
si elle modifie le système ;
comment vérifier son effet.

Conservez également l'habitude de travailler avec des commandes de lecture et de diagnostic avant les commandes de modification.

Cette discipline réduit les erreurs et facilite énormément le dépannage.

Sécurité

Les acquis sur les permissions, sudo, les capabilities et les scripts doivent rester liés.

Automatiser une commande privilégiée ne la rend pas moins privilégiée. Au contraire, une erreur placée dans une boucle ou un script peut être reproduite rapidement.

Avant d'exécuter une action avec des droits élevés :

vérifiez les arguments reçus ;
vérifiez les chemins manipulés ;
comprenez les effets de la commande ;
conservez une méthode de vérification ;
évitez d'utiliser sudo comme réponse automatique à un échec.

Coûts

Cet article n'utilise aucun service cloud ni ressource facturable. Les exemples reposent uniquement sur des outils locaux classiques d'un environnement Linux disposant de Bash et, pour les commandes systemd, d'un système utilisant systemd.

Limites et points de vigilance

Ce #35 est une synthèse, pas un remplacement des articles précédents.

Il ne redétaille pas la syntaxe complète de chmod, des ACL, de awk, de find ou des constructions Bash. Le rôle de cet article est de montrer comment ces outils prennent place dans une démarche globale.

Le scénario systemd utilise également des placeholders comme <SERVICE> et <FICHIER>. Il faut les remplacer par des valeurs correspondant au système réellement diagnostiqué.

Enfin, toutes les distributions Linux n'utilisent pas nécessairement la même pile de services ou les mêmes outils par défaut. Les prochains articles préciseront le contexte lorsque cette différence devient importante.

Rollback ou nettoyage

Le scénario présenté ici utilise uniquement des commandes de consultation. Il ne crée ni ne modifie de ressource et ne nécessite donc pas de rollback.

Si vous transformez cette méthode en script personnel, conservez d'abord des actions de lecture. Ajoutez des opérations de modification seulement lorsque leurs conséquences, leur vérification et leur méthode de retour arrière sont clairement définies.

Références officielles

Bash Reference Manual — GNU Project
systemctl — systemd
journalctl — systemd
GNU Grep Manual — GNU Project
GNU Findutils Manual — GNU Project
Linux man-pages project — kernel.org

Conclusion

Vous n'avez pas seulement appris 34 sujets Linux.

Vous avez commencé à construire une méthode : observer le système, comprendre ce que vous voyez, filtrer l'information, agir avec prudence, vérifier le résultat puis automatiser ce qui mérite de l'être.

La prochaine étape consiste maintenant à appliquer cette méthode à un nouveau territoire : le stockage et les systèmes de fichiers.