Chapitre 2.1 — Qu’est-ce que Linux

⏱️ TL;DR — Linux, ce n’est pas un logiciel : c’est un noyau (le programme qui parle au matériel) qu’une distribution (Ubuntu, Debian…) empaquette avec des outils pour en faire un système utilisable. Tu pilotes ce système avec un shell (bash, le plus souvent) via un terminal. Le shell t’attend derrière un prompt : user@host:~$ en utilisateur normal, # quand tu es root (le tout-puissant). Les serveurs tournent sous Linux parce qu’il est stable, gratuit, scriptable et fait pour tourner des années sans écran. Et derrière tout ça, une philosophie : des petits outils qui font une chose bien, qu’on combine. Ton meilleur réflexe dès aujourd’hui : man <commande> pour lire la doc.

🎯 Objectifs

• Distinguer le noyau Linux de la distribution qui l’entoure.
• Comprendre ce qu’est un shell (bash / zsh) et à quoi il sert.
• Savoir pourquoi les serveurs du monde entier tournent sous Linux.
• Lire le prompt du terminal : où tu es, qui tu es, et si tu es root.
• Répondre à « où suis-je ? » avec whoami, hostname, pwd.
• Adopter le réflexe doc : man et --help avant de deviner.

Noyau, distribution : deux choses différentes

On dit « Linux » un peu à tort et à travers. Soyons précis, ça évite bien des confusions.

• Le noyau (kernel) est le programme central. Son travail : parler au matériel (processeur, mémoire, disque, carte réseau) et distribuer ces ressources aux programmes. Seul, il ne fait rien de visible : pas de commandes, pas d’interface. C’est un moteur sans carrosserie.
• Une distribution (« distro ») prend ce noyau et l’empaquette avec tout le reste : les commandes de base (ls, cp, cd…), un shell, un gestionnaire de paquets pour installer des logiciels, des outils système. C’est ça qu’on installe réellement sur un serveur.

Les distributions qu’on vise dans ce cours : Ubuntu Server LTS et Debian stable. Toutes deux utilisent le même gestionnaire de paquets (APT, la commande apt) et le même système de démarrage (systemd) — tout ce cours s’applique aux deux à l’identique.

💡 Réflexe — Quand quelqu’un dit « je suis sous Linux », demande-toi quelle distribution. C’est elle qui détermine le gestionnaire de paquets (apt sur Debian/Ubuntu, dnf sur Fedora/RHEL…) et parfois l’emplacement de certains fichiers. Le noyau, lui, est le même socle partout.

Le shell : ton interlocuteur

Une fois connecté au serveur, tu ne parles pas directement au noyau. Tu parles à un shell : un programme qui lit tes commandes, les fait exécuter, et t’affiche le résultat. C’est l’interpréteur de la ligne de commande.

Le shell le plus répandu s’appelle bash (Bourne Again SHell), le défaut sur Ubuntu et Debian. Tu croiseras aussi zsh (populaire sur les Mac et pour les configs personnalisées). Pour ce cours, bash suffit largement — et ce que tu apprends marche dans les deux.

Le shell fait bien plus qu’exécuter des commandes une par une : il gère des variables, un historique, la complétion, et surtout il enchaîne les commandes (on verra les pipes au chapitre 2.5). C’est un vrai langage.

Pourquoi les serveurs tournent sous Linux

Ce n’est pas une mode. Les raisons sont concrètes :

• Stable et endurant : un serveur Linux tourne des mois, des années, sans redémarrer. C’est fait pour ça.
• Sans interface graphique : pas de bureau, pas d’écran. Tout se pilote au terminal (et à distance, en SSH). Moins de logiciels = moins de surface d’attaque et moins de RAM gaspillée.
• Gratuit et libre : pas de licence à payer par serveur. Tu peux en démarrer dix sans facture logicielle.
• Scriptable et automatisable : tout est commande, donc tout est automatisable (déploiement, sauvegardes, monitoring). C’est le socle du CI/CD qu’on verra plus tard.
• L’écosystème est là : Nginx, PostgreSQL, Node, Docker, systemd… tout le monde développe pour Linux d’abord.

🧭 Sur FormaCampus — FormaCampus quitte son PaaS pour un VPS Ubuntu LTS. Concrètement, l’équipe reçoit un e-mail avec une IP, un identifiant et un mot de passe (ou une clé). Pas d’écran, pas de bureau : juste une machine Linux qui attend, quelque part dans un datacenter en Europe. Tout ce que l’équipe fera dessus — installer Nginx, lancer Next.js, sauvegarder Postgres — passera par le terminal. D’où l’importance de ce chapitre : c’est la langue dans laquelle on va parler à cette machine pendant tout le reste du cours.

Lire le prompt du terminal

Quand tu te connectes, le shell affiche un prompt et attend. Ce prompt n’est pas décoratif : il te dit qui tu es et où tu es. Sur Ubuntu/Debian, il ressemble à ça :

deploy@vps-formacampus:~$

Décortiquons, de gauche à droite :

Le tout dernier caractère est capital :

• Un $ signifie que tu es un utilisateur ordinaire (droits limités).
• Un # signifie que tu es root — le super-utilisateur, qui peut tout faire, y compris tout casser.

root@vps-formacampus:~#     ← le # : tu es root, attention à chaque commande
deploy@vps-formacampus:~$   ← le $ : utilisateur normal, plus sûr

⚠️ Piège — Voir un # et ne pas y prêter attention. En root, il n’y a pas de garde-fou : une commande de suppression malheureuse efface le système sans confirmation. On ne travaille jamais en root au quotidien — on utilise un compte normal et on demande les droits ponctuellement avec sudo. On construira ce compte deploy propre en Partie 3. Pour l’instant, retiens juste : # = danger, réfléchis avant de taper.

« Où suis-je ? » — trois commandes qui rassurent

Perdu dans le terminal ? Trois commandes répondent aux trois questions de base. Tape-les sans crainte : elles ne modifient rien, elles ne font que te renseigner.

🐚 Au terminal

whoami     # affiche ton nom d'utilisateur (qui suis-je ?)
hostname   # affiche le nom de la machine (sur quel serveur suis-je ?)
pwd        # print working directory : affiche le dossier où tu te trouves

Exemple de session :

deploy@vps-formacampus:~$ whoami
deploy
deploy@vps-formacampus:~$ hostname
vps-formacampus
deploy@vps-formacampus:~$ pwd
/home/deploy

Ces trois commandes sont ta boussole. Avant toute action risquée (supprimer, écraser, redémarrer un service), le réflexe pro est de vérifier qui tu es et où tu es. On y reviendra sans cesse.

La philosophie Unix : petit, simple, composable

Linux hérite d’Unix une façon de penser qui explique pourquoi les commandes sont si nombreuses et si courtes. L’idée tient en une phrase : chaque outil fait une seule chose, mais la fait bien — et on combine ces outils pour résoudre des problèmes complexes.

• ls liste des fichiers. C’est tout.
• grep filtre des lignes qui contiennent un motif. C’est tout.
• wc compte des lignes ou des mots. C’est tout.

Pris séparément, chacun est modeste. Mais tu peux brancher la sortie de l’un sur l’entrée de l’autre (le fameux pipe |, chapitre 2.5) et obtenir, en une ligne, « combien de fois l’erreur 404 apparaît dans ce log ? ». Cette composabilité est le super-pouvoir de la ligne de commande. Tu n’apprends pas des centaines d’outils géants : tu apprends des dizaines de petits, et surtout à les assembler.

💡 Réflexe — Face à un problème, ne cherche pas « la grosse commande qui fait tout ». Décompose : « je veux lire ce fichier, en filtrer telles lignes, puis les compter ». Trois petits outils, un pipe entre chaque. C’est la mentalité Unix, et c’est celle qui rend efficace.

Le réflexe qui change tout : lire la doc

Personne ne connaît toutes les options de toutes les commandes par cœur — personne. Ce que les gens compétents savent faire, c’est lire la doc rapidement. Deux outils pour ça, disponibles partout :

• man <commande> ouvre le manuel complet d’une commande (description, toutes les options, exemples). On navigue avec les flèches ou Espace, on cherche avec /motif, et on quitte avec q.
• <commande> --help affiche un résumé court des options, directement dans le terminal. Plus rapide quand tu veux juste rafraîchir ta mémoire.

man ls        # le manuel complet de ls (q pour quitter)
ls --help     # le résumé des options de ls, plus court

📚 La doc — man man t’explique… comment lire les pages man. Les manuels sont organisés en sections (1 = commandes, 5 = formats de fichiers/config, 8 = commandes d’administration). D’où des notations comme man 5 crontab (le format du fichier) vs man 1 crontab (la commande). En cas de doute sur une option ou un chemin, le man fait autorité — plus qu’un tutoriel trouvé au hasard, qui peut être périmé.

🔒 Sécurité — Prends l’habitude de lire ce qu’une commande fait avant de la copier-coller depuis Internet. Un tutoriel peut contenir une commande dangereuse (ou malveillante). --help ou man te disent en dix secondes ce qu’une option fait vraiment. Coller aveuglément une commande trouvée en ligne, surtout en root, est l’une des façons les plus courantes de saborder un serveur.

Le terminal se démystifie

Un dernier mot, parce qu’il compte. Le terminal fait peur au début : l’écran est vide, austère, et on a l’impression qu’une faute de frappe va tout détruire. Ce n’est pas le cas. La plupart des commandes ne font que lire (ls, cat, pwd, whoami) : elles ne changent rien. On peut les taper toute la journée sans risque. Les commandes qui modifient sont peu nombreuses, et on apprendra à les manier avec des filets de sécurité.

Le terminal, c’est comme conduire : intimidant le premier jour, naturel au bout d’une semaine. On avance une commande à la fois, en comprenant ce que fait chacune. À la fin de cette partie, deploy@vps:~$ ne sera plus une menace — ce sera chez toi.

✏️ Exercices

Exercice 1 — Lis le prompt. Tu vois ce prompt à l’écran : root@db-01:/etc/nginx#. Réponds à trois questions : (a) quel utilisateur es-tu ? (b) sur quelle machine ? (c) dans quel dossier ? Et surtout : qu’est-ce qui doit t’alerter ici ?

Exercice 2 — Noyau ou distribution ? Classe chacun de ces éléments : (A) le programme qui gère la mémoire et le processeur ; (B) la commande apt ; (C) ls et cp ; (D) ce qui parle directement à la carte réseau.

Exercice 3 — Trouve la doc. Tu veux savoir ce que fait l’option -h de la commande ls, mais tu n’as pas accès à Internet sur le serveur. Quelles sont deux façons de le découvrir directement au terminal ?

🧠 Quiz de révision

Chapitre suivant : Le système de fichiers — où l’on découvre que sous Linux, tout part d’un seul point : la racine /.