Linux & système, en installant un vrai service

L’idée reçue

« Pour apprendre Linux, il faut d’abord lire des dizaines de commandes par cœur. »

Non. On apprend Linux en faisant tourner quelque chose de réel dessus. On va donc installer un vrai service — Jenkins — et, chemin faisant, découvrir les paquets, les services, les droits, les journaux, le réseau. Jenkins n’est pas là pour le CI/CD aujourd’hui : il est là parce qu’il est utile au projet plus tard, donc rien de ce que tu apprends n’est du temps perdu.

À la fin de la Phase 0, tu as deux machines : debian-cli (serveur, sans écran) et debian-gui (avec un bureau). C’est exactement l’architecture du monde réel : les services tournent sur des serveurs sans écran, et on s’y connecte depuis une autre machine. On va le vivre.

À la fin de cette phase, tu sauras…

Te connecter à un serveur à distance en SSH
Gérer les paquets et ajouter un dépôt officiel vérifié (apt, clé GPG)
Comprendre les dépendances (installer Java pour Jenkins)
Piloter un service avec systemd (démarrer, activer, lire les journaux)
Distinguer serveur et client : accéder depuis une machine à un service hébergé sur une autre

01Rejoindre le serveur à distance (SSH)

Expérience 1

Depuis debian-gui, connecte-toi à debian-cli

D’abord, trouve l’adresse IP du serveur. Dans la console de debian-cli (via Proxmox) :

Manipule

ip -brief address

Observe

lo     UNKNOWN   127.0.0.1/8
ens18  UP        192.168.1.50/24

Note l’adresse de ens18 (ici 192.168.1.50). C’est l’adresse de ton serveur sur le réseau local.

Maintenant, ouvre un terminal dans debian-gui et connecte-toi à distance :

Manipule

ssh ton-utilisateur@192.168.1.50

Comprends que vient-il de se passer ?

SSH (Secure Shell) ouvre un terminal sur une machine distante, de façon chiffrée. Tu es physiquement sur debian-gui, mais ton terminal exécute maintenant des commandes sur debian-cli. C’est ainsi qu’on administre tous les serveurs du monde : sans écran, à distance. Vérifie où tu es avec hostname — il répond debian-cli.

02Préparer le système

Expérience 2

Mettre à jour et comprendre les paquets

Manipule

sudo apt update &amp;&amp; sudo apt upgrade -y

Comprends c’est quoi un « paquet », un « dépôt » ?

Sous Linux, on n’installe pas des logiciels en téléchargeant des .exe au hasard. Un gestionnaire de paquets (apt) récupère les logiciels depuis des dépôts de confiance, gère leurs dépendances, et les met à jour. C’est plus sûr et plus propre. apt update rafraîchit la liste ; apt upgrade applique les mises à jour.

03Installer Java (la dépendance)

Expérience 3

Jenkins a besoin de Java — installe-le d’abord

Manipule

sudo apt install -y fontconfig openjdk-17-jre
java -version

Observe

openjdk version "17.0.x" ...

Jenkins est écrit en Java : sans Java, il ne peut pas démarrer. On installe donc sa dépendance avant lui.

Comprends une dépendance, c’est quoi ?

Un logiciel a souvent besoin d’autres logiciels pour fonctionner : ce sont ses dépendances. Jenkins dépend de Java. Bonne nouvelle : apt gère la plupart des dépendances tout seul — mais ici on installe Java à la main pour bien voir le mécanisme.

04Ajouter le dépôt officiel Jenkins

Expérience 4

La même chaîne de confiance que pour tout logiciel sérieux

Jenkins n’est pas dans les dépôts Debian par défaut. On ajoute son dépôt officiel, en vérifiant sa signature — exactement la logique « clé GPG + source officielle + HTTPS » vue ailleurs dans le projet.

Manipule

sudo wget -O /usr/share/keyrings/jenkins-keyring.asc https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

Puis déclare le dépôt, lié à cette clé :

Manipule

echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list

Comprends pourquoi cette clé, encore ?

C’est le même réflexe de sécurité que partout : la clé GPG garantit que les paquets viennent bien du vrai projet Jenkins, et signed-by lie le dépôt à cette clé. Ce réflexe — une source officielle, vérifiée, en HTTPS — te suivra dans tout le projet.

05Installer Jenkins et le piloter avec systemd

Expérience 5

Installer, puis apprendre à gérer un service

Manipule

sudo apt update
sudo apt install -y jenkins

Jenkins s’installe comme un service. On le pilote avec systemd :

Manipule

sudo systemctl status jenkins

Observe

● jenkins.service - Jenkins Continuous Integration Server
   Loaded: loaded (/lib/systemd/system/jenkins.service; enabled; ...)
   Active: active (running) since ...

active (running) = le service tourne. enabled = il redémarrera tout seul au prochain démarrage de la machine.

Comprends systemd, systemctl, journalctl

systemd est le chef d’orchestre des services sous Linux. On lui parle avec systemctl : start / stop (démarrer, arrêter), enable / disable (au démarrage ou non), status (état). Et pour lire les journaux d’un service : journalctl -u jenkins. Un service, c’est un programme qui tourne en arrière-plan, en permanence — comme Jenkins.

Essaie de lire les journaux, puis de rendre le service persistant :

Manipule

journalctl -u jenkins --no-pager | tail -n 20
sudo systemctl enable jenkins

06Qui fait tourner Jenkins ? (utilisateurs & droits)

Expérience 6

Un service tourne sous son propre utilisateur

Manipule

ps -u jenkins -o user,pid,comm | head
id jenkins

Observe

jenkins  623  java
uid=110(jenkins) gid=115(jenkins) groups=115(jenkins)

L’installation a créé un utilisateur système dédié, jenkins, et le service tourne sous cette identité — pas en tant que root.

Comprends pourquoi un utilisateur dédié ?

Principe de sécurité fondamental sous Linux : le moindre privilège. Chaque service a son propre utilisateur, avec juste les droits nécessaires. Si Jenkins est compromis, l’attaquant n’a que les droits de l’utilisateur jenkins, pas ceux de root. C’est pour ça qu’on ne fait pas tourner les services en root.

07Le service écoute — sur quel port ?

Expérience 7

Voir Jenkins sur le réseau

Manipule

sudo ss -tlnp | grep 8080

Observe

LISTEN  0  50  *:8080  *:*  users:(("java",pid=623,...))

Jenkins écoute sur le port 8080, ouvert à tout le réseau (*:8080). Vérifie qu’il répond, en local d’abord :

Manipule

curl -I http://localhost:8080

Comprends un port, c’est quoi ?

Une machine a une seule adresse IP, mais peut faire tourner plusieurs services. Les ports les distinguent : le web classique sur 80/443, Jenkins sur 8080… ss -tlnp liste ce qui « écoute » et sur quel port. C’est un premier contact avec le réseau — qu’on approfondira à la Phase 2.

08Le moment client/serveur

Expérience 8

Depuis debian-gui, ouvre l’interface de Jenkins

Jenkins tourne sur debian-cli (sans écran). Pour voir son interface web, on s’y connecte depuis une autre machine : debian-gui et son navigateur.

D’abord, prouve que les deux machines se voient. Dans debian-gui :

Manipule

ping -c 2 192.168.1.50
curl -I http://192.168.1.50:8080

Observe

Le ping répond, et curl reçoit une réponse HTTP : les deux VMs communiquent sur le réseau local. Ouvre maintenant le navigateur de debian-gui sur http://192.168.1.50:8080 — la page de déverrouillage de Jenkins apparaît.

Comprends c’est ça, le modèle client/serveur

Le serveur (Jenkins sur debian-cli) héberge le service ; le client (le navigateur sur debian-gui) s’y connecte par le réseau. Ils sont sur deux machines différentes. C’est le schéma de toute infrastructure — et tu le reverras partout dans le projet : Kubernetes, reverse proxy, applications web.

Pour déverrouiller Jenkins, récupère le mot de passe initial (retour en SSH sur debian-cli) :

Manipule

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Colle ce mot de passe dans la page de déverrouillage. Jenkins est en marche, et accessible. On s’arrête ici : configurer des pipelines viendra bien plus tard, quand le projet aura besoin de CI/CD.

✓Ce que tu retiens

En installant un seul service, tu as touché à l’essentiel de l’administration Linux : SSH (accès distant), apt & dépôts (installer proprement), dépendances (Java), systemd (piloter un service), utilisateurs & droits (moindre privilège), ports & réseau (ss, curl), et le modèle client/serveur. Tout cela sur une brique — Jenkins — qui resservira plus tard dans le projet.

Mini-projet

Rends le service à toi

Approprie-toi ce que tu viens de faire, et laisse une trace propre.

À faire

Termine l’assistant Jenkins (crée ton compte administrateur).
Arrête puis redémarre le service (sudo systemctl stop jenkins, puis start), et vérifie l’état à chaque fois.
Lis les 30 dernières lignes de journal du service et repère la ligne indiquant qu’il est prêt.
Prends un snapshot de debian-cli nommé phase1-ok.
Dans BookStack, écris une page « Phase 1 » : explique avec tes mots SSH, un service systemd, et le modèle client/serveur.

Critères de réussite

Jenkins accessible depuis debian-gui, avec ton compte admin.
Le service redémarre bien et repart en active (running).
Snapshot phase1-ok présent (point de reprise).
Page BookStack claire sur les trois notions.

Fil rouge — Tu as touché le réseau du bout des doigts (ping, ports, une IP en dur). À la Phase 2, on prend le réseau au sérieux : un pare-feu OPNsense, un vrai LAN, et la maîtrise de qui parle à qui. Tes machines vont enfin avoir une architecture réseau digne d’une production.

?Auto-évaluation

1. À quoi sert SSH ?

À ouvrir un terminal chiffré sur une machine distante — pour administrer un serveur sans écran, depuis une autre machine.

2. Que font systemctl enable et systemctl status ?

enable fait démarrer le service automatiquement au boot ; status affiche son état (actif, en échec…).

3. Pourquoi Jenkins tourne-t-il sous un utilisateur dédié plutôt qu’en root ?

Par principe de moindre privilège : si le service est compromis, les dégâts sont limités aux droits de cet utilisateur, pas à ceux de root.

4. Dans l’Expérience 8, qui est le serveur et qui est le client ?

Le serveur = Jenkins sur debian-cli (il héberge le service). Le client = le navigateur sur debian-gui (il se connecte).