Installer Nginx : master, workers et contextes

Installer Nginx, c'est obtenir un serveur web et reverse proxy dont on sait dire quelle version tourne, quels modules il porte, quels fichiers il lit, et comment on lui applique un changement sans couper les visiteurs. Cette leçon ouvre le module Nginx de la formation. Elle s'adresse à une personne qui a déjà suivi le trajet d'une requête jusqu'à un backend et qui n'a jamais configuré Nginx. Elle couvre l'installation de Nginx 1.31.8 sur Debian 13 depuis le dépôt de l'éditeur (la voie rejouée en machine), la vérification de ce dépôt, le modèle du processus maître et des workers, les contextes qui rangent les directives, puis les trois gestes nginx -t, reload et restart.

Ce que vous allez apprendre

La leçon suit l'ordre d'une prise en main réelle : installer, lire, comprendre, puis exploiter.

• Installer Nginx depuis le dépôt de l'éditeur et vérifier ce dépôt avant de lui faire confiance.
• Relever la version, les modules compilés et les fichiers de configuration en service.
• Expliquer le rôle du processus maître et des workers.
• Placer une directive dans le bon contexte.
• Distinguer valider, recharger et redémarrer, et choisir le bon geste.
• Prouver que le service revient seul après un redémarrage de la machine.

Prérequis

La leçon suppose que vous connaissez le trajet d'une requête et que vous savez piloter un service avec systemctl.

• Le trajet du nom DNS jusqu'au backend : Publier un service web.
• Le vocabulaire HTTP (méthode, en-tête Host, code de statut) : Lire HTTP avant de configurer un proxy.
• Démarrer, arrêter et activer un service : systemctl : lister, démarrer et diagnostiquer les services Linux.
• Savoir déclarer un dépôt apt signé : Administrer les paquets avec APT.
• Un compte avec sudo sur une machine Linux. Le lab de cette leçon tourne sur Debian 13 (trixie) : c'est la voie rejouée. La voie RHEL, Rocky, AlmaLinux, Fedora est décrite plus bas, sans avoir été rejouée.

Comment installer Nginx : paquet, dépôt officiel ou image ?

Cette formation installe Nginx depuis le dépôt officiel de nginx.org : l'éditeur y publie ses paquets pour Debian 13, et la version se choisit et s'épingle, au lieu de dépendre de celle que la distribution a figée. Le dépôt propose deux branches : stable et mainline (la branche de développement, plus récente). Le lab installe la 1.31.8, de la branche mainline.

Le paquet de la distribution (apt-get install nginx sans dépôt supplémentaire) reste possible, mais il pose une disposition de fichiers propre à Debian (sites-available/, sites-enabled/) et des workers sous un autre compte, www-data. Les leçons de ce module décrivent la disposition du paquet de l'éditeur : mélanger les deux fait chercher des fichiers qui n'existent pas.

La troisième voie est l'image de conteneur nginx, qui convient quand le serveur vit dans Docker ou Kubernetes. Vous en choisissez alors la version par un tag, qu'il faut épingler par digest comme toute image.

Comment installer Nginx 1.31.8 sur Debian 13 depuis nginx.org ?

L'installation tient en quatre gestes : récupérer la clé de signature, vérifier le fichier entier, déclarer le dépôt, puis installer la version épinglée. La clé est ce qui permet à apt de refuser un paquet qui ne vient pas de l'éditeur ; la vérifier avant de la déclarer est donc le geste qui compte.

Commencez par télécharger le fichier de clés et afficher l'empreinte de chaque clé qu'il contient :

sudo apt-get update
sudo apt-get install -y curl gnupg ca-certificates
curl -fsSL https://nginx.org/keys/nginx_signing.key -o /tmp/nginx_signing.key
gpg --show-keys --fingerprint /tmp/nginx_signing.key

La dernière commande affiche trois clés, pas une. Celle qui signe réellement les paquets a pour empreinte 8540A6F18833A80E9C1653A42FD21310B49F6B46 (RSA 4096, créée en 2024, identité signing-key-2@nginx.com) ; gpg l'affiche par groupes de quatre caractères, sans changer les chiffres. Les deux autres sont l'ancienne clé RSA 2048 de 2011, qui expire le 2027-05-24, et une troisième clé de 2024. Relevé le 2026-10-26 sur le fichier publié.

La page d'installation de nginx.org ne cite que l'ancienne clé de 2011, d'empreinte 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62. Un lecteur qui ne compare que cette empreinte croit avoir vérifié son dépôt alors qu'il n'a pas regardé la clé qui signe. Cherchez donc l'empreinte active parmi toutes celles de votre sortie, sans supposer que la première est la bonne. Si elle manque, arrêtez-vous et ne déclarez pas le dépôt.

Une fois l'empreinte trouvée, convertissez le fichier en trousseau, déclarez le dépôt de la branche mainline et installez la version du lab :

sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg /tmp/nginx_signing.key
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/debian trixie nginx" \
  | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt-get update
sudo apt-get install -y nginx=1.31.8-*

L'option signed-by limite la confiance de ce trousseau à ce dépôt seul. Épingler nginx=1.31.8-* empêche le dépôt, qui publie une version mainline environ une fois par mois, de vous installer une autre version que celle que la leçon décrit. Le geste de montée de version a sa propre leçon : Mettre à jour, revenir en arrière et redémarrer Nginx.

Comparer une empreinte n'est pas vérifier un dépôt. L'empreinte dit seulement que vous détenez le fichier de clé attendu. Ce qui prouve quelque chose, c'est que la signature du dépôt se vérifie contre cette clé :

curl -fsSL http://nginx.org/packages/mainline/debian/dists/trixie/InRelease -o /tmp/InRelease
gpg --no-default-keyring --keyring /usr/share/keyrings/nginx-archive-keyring.gpg --verify /tmp/InRelease

La sortie doit annoncer Good signature ; sans le trousseau, gpg répondrait No public key. apt fait la même vérification à chaque apt-get update : un update qui réussit sans avertissement de signature sur ce dépôt est votre preuve. Le dépôt de HAProxy offre le contraste : sa clé est unique et correspond à la page de l'éditeur, comme le montre Installer HAProxy et lire ses sections de configuration.

Il reste à retirer le site de démonstration, à activer le service et à relever la version :

sudo rm /etc/nginx/conf.d/default.conf
sudo systemctl enable --now nginx
nginx -v
systemctl is-active nginx
systemctl is-enabled nginx

Le paquet de l'éditeur livre un default.conf qui répond sur le port 80 : laissé en place, il fait passer sans travail un premier contrôle de réponse, et masque l'erreur de celui qui n'a rien configuré. nginx -v doit afficher nginx/1.31.8. enable --now est sans effet sur un service déjà actif et activé ; lancez-le dans tous les cas, puis contrôlez avec les deux dernières commandes, qui posent deux questions différentes : is-active demande si le processus tourne maintenant, is-enabled s'il sera relancé au prochain démarrage de la machine. Un service peut être l'un sans l'autre, et cette différence décide de la dernière section de cette leçon.

Et sur RHEL, Rocky, AlmaLinux ou Fedora ?

Voie décrite d'après la documentation des distributions, non rejouée dans le lab. Le paquet de la distribution s'appelle aussi nginx et n'est pas celui du lab : il ne livre pas la 1.31.8. Il n'active pas le service, et sans enable --now le serveur n'écoute pas.

sudo dnf install -y nginx
sudo systemctl enable --now nginx

Sur RHEL 8 et 9, dnf install nginx n'impose pas de choisir un flux de module : la documentation de Red Hat décrit dnf module enable nginx:<version> seulement pour obtenir une version autre que celle par défaut (dnf module list nginx liste les flux). RHEL 10 ne livre plus de modules.

Deux obstacles sont propres à cette famille. D'abord le pare-feu firewalld, qui peut bloquer le port 80 depuis l'extérieur (sudo firewall-cmd --permanent --add-service=http puis sudo firewall-cmd --reload ; la documentation de Red Hat ouvre plutôt les ports par --add-port={80/tcp,443/tcp}, ce qui revient au même pour le résultat). Ensuite SELinux, le contrôle d'accès de cette famille qui limite ce que chaque processus a le droit de faire : il peut refuser à Nginx de joindre un backend, et la documentation de Red Hat règle ce cas pour un reverse proxy Nginx par le booléen httpd_can_network_connect (sudo setsebool -P httpd_can_network_connect on, utile à partir de la leçon sur les upstreams, c'est-à-dire les serveurs en amont). Le paquet sépare aussi certains modules (stream, mail) dans des paquets à part, à installer au besoin.

Quelle version et quels modules tournent vraiment ?

La version et les modules se lisent sur le binaire en service, jamais sur une documentation ou dans un fichier de notes. Un README dit ce qu'on avait prévu, nginx -V dit ce qui a été compilé. Deux commandes suffisent.

nginx -v
nginx -V 2>&1 | tr ' ' '\n' | grep -E '^--with-http_(ssl|v2|realip|stub_status)'

La première commande affiche la version. La seconde, avec un V majuscule, affiche aussi les options de compilation (configure arguments). Nginx écrit ces informations sur la sortie d'erreur, d'où le 2>&1 qui les ramène dans le tube. Le tr met une option par ligne, et le grep ne garde que quelques modules courants. Vous y cherchez par exemple --with-http_ssl_module, sans lequel aucun listen 443 ssl ne fonctionne.

Retenez une conséquence pratique : une directive reconnue par une édition peut être absente d'une autre. Une directive est une instruction de configuration, par exemple listen 80;. Celles d'un module non compilé produisent l'erreur unknown directive. Certaines fonctions, comme les sondes de santé actives des serveurs en amont, n'existent que dans l'édition commerciale NGINX Plus : une configuration copiée depuis un article qui la suppose sera refusée par la version open source. La version et les modules du binaire sont donc le premier fait à relever avant de copier une configuration.

Où sont les fichiers de configuration après l'installation ?

Le point d'entrée est /etc/nginx/nginx.conf, et il inclut les fichiers de /etc/nginx/conf.d/ : un site s'écrit dans un fichier .conf de ce répertoire, et il n'y a rien d'autre à activer. Cette organisation évite d'éditer un seul fichier géant. Le tableau décrit la disposition du paquet de l'éditeur.

Chemin	Rôle
/etc/nginx/nginx.conf	Point d'entrée : réglages globaux, puis l'include de conf.d/
/etc/nginx/conf.d/*.conf	Un fichier par site, chargé dans le contexte http
/usr/lib/nginx/modules/	Modules dynamiques, des extensions chargées au démarrage au lieu d'être compilées dans le binaire
/usr/share/nginx/html/	Racine du site de démonstration
/var/log/nginx/	Journaux access.log et error.log

Glissez pour voir

Le motif *.conf fait toute l'activation. Activer un site consiste à écrire son fichier dans conf.d/ puis à recharger ; le désactiver consiste à le supprimer ou à le renommer sans l'extension .conf (par exemple boutique.conf.off), ce qui le fait sortir du motif sans perdre son contenu.

sudo ls /etc/nginx/conf.d/

Si un article parle de sites-available/ et de sites-enabled/, avec un ln -s pour activer un site, il décrit le paquet que Debian fabrique lui-même : c'est une convention de ce paquet, pas du logiciel, et le paquet de l'éditeur ne la fournit pas. Créer ces répertoires à la main ne sert à rien, puisque nginx.conf ne les inclut pas. La famille RHEL passe par conf.d/ elle aussi : sur les deux familles, un site est un fichier .conf de ce répertoire, et les workers tournent sous le compte nginx. Ce qui diffère est l'installation et, côté RHEL, la couche de sécurité (pare-feu, SELinux).

Pour savoir quels fichiers sont réellement lus, ne vous fiez pas à l'arborescence : demandez à Nginx de se relire lui-même avec nginx -T. Cette commande valide la configuration, puis affiche toute la configuration résultante, fichiers inclus, chacun précédé d'un commentaire qui donne son chemin. Un fichier absent de cette sortie n'est pas chargé, quoi qu'il contienne.

sudo nginx -T | grep -E '^# configuration file'

Que sont le processus maître et les workers ?

Nginx tourne en deux sortes de processus : un processus maître qui ne sert aucune requête, et des workers qui servent tout le trafic. Le maître lit la configuration, ouvre les ports d'écoute et supervise les workers ; il tourne en root, parce qu'ouvrir un port inférieur à 1024, comme le 80 ou le 443, exige ce privilège. Les workers sont des processus non privilégiés, sous un compte dédié : nginx, créé par le paquet, que désigne la directive user nginx; en tête de nginx.conf.

Chaque worker est événementiel : au lieu de créer un fil par connexion, il surveille des milliers de connexions à la fois et ne travaille que sur celles qui ont quelque chose à lire ou à écrire. C'est pourquoi quelques workers suffisent. Leur nombre se règle par worker_processes (la valeur auto en met un par cœur de processeur) et le nombre de connexions simultanées de chacun par worker_connections.

ps -o pid,user,cmd -C nginx
systemctl show -p MainPID --value nginx

La première commande liste les processus nommés nginx : une ligne master process sous root, et plusieurs lignes worker process sous nginx. La seconde donne le PID du maître, celui que systemd suit. Notez-le : c'est lui qui permet de prouver, dans la section sur le rechargement, qu'un changement a été appliqué sans remplacer le processus.

La répartition en deux rôles a une conséquence de sécurité utile pour la leçon sur les fichiers statiques : un worker compromis ne dispose que des droits du compte des workers, nginx, et ne peut lire que ce que ce compte peut lire. Les permissions des fichiers servis deviennent donc un réglage de sécurité, pas un détail.

Comment lire un nginx.conf : que sont les contextes ?

Un fichier Nginx est un arbre de blocs emboîtés, appelés contextes, et chaque directive n'est valide que dans certains d'entre eux. Les contextes à connaître sont cinq : le contexte principal (le haut du fichier, hors de tout bloc), events, http, server et location.

Regardez le schéma de l'extérieur vers l'intérieur : plus le bloc est profond, plus sa portée est étroite. Une directive posée dans http vaut pour tous les sites, une directive posée dans un server pour ce site seulement, et une directive posée dans un location pour un seul chemin d'URL.

Les contextes de Nginx : une directive n'est valide que dans les contextes que sa documentation indique. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Voici un fichier minimal commenté. Il est illustratif : il n'est pas celui du lab, et vous pouvez en reconnaître chaque bloc.

# Contexte principal : hors de tout bloc
user nginx;                   # compte des workers
worker_processes auto;        # un worker par cœur
pid /run/nginx.pid;

events {                      # contexte events : le moteur de connexions
    worker_connections 768;   # valeur illustrative, pas une valeur par défaut
}

http {                        # contexte http : tout le trafic web
    include /etc/nginx/mime.types;
    include /etc/nginx/conf.d/*.conf;       # fragments chargés ICI, dans http

    server {                  # contexte server : un site
        listen 80;                # port d'écoute
        server_name boutique.lab.test;   # nom de site auquel ce bloc répond

        location / {          # contexte location : un chemin
            return 200 "boutique\n";
        }
    }
}

Deux points se lisent dans ce fichier. D'abord, chaque directive se termine par un point-virgule, et un oubli provoque une erreur de syntaxe à la ligne suivante. Ensuite, la directive include insère le contenu d'autres fichiers à l'endroit où elle se trouve : un fichier de conf.d/ est donc lu comme s'il était écrit dans http. C'est la source de l'erreur de la section suivante.

Que se passe-t-il quand une directive est au mauvais contexte ?

Nginx refuse toute la configuration : une seule directive mal placée suffit à invalider le fichier entier, et le message nomme la directive fautive avec son fichier et sa ligne. Prenons worker_connections, qui règle le nombre de connexions d'un worker : sa place est dans events. Posée dans un fichier de conf.d/, donc dans http, elle est refusée.

# /etc/nginx/conf.d/faute.conf : à ne pas reproduire
worker_connections 42;

La commande sudo nginx -t (test) relit la configuration complète, vérifie la syntaxe et le placement de chaque directive, puis rend un code de retour non nul. Le message annonce que la directive « is not allowed here » et indique le fichier et la ligne : lisez-le de gauche à droite, il porte tout le diagnostic. Le texte exact varie selon la version, comparez-le donc avec celui que votre machine affiche.

Le point essentiel est ce qui n'arrive pas : tant que vous ne rechargez pas, le service en marche continue de répondre avec l'ancienne configuration, parce que Nginx ne relit les fichiers qu'à la demande. Le fichier fautif traîne sur le disque, et il ne devient dangereux qu'au geste suivant : un rechargement, un redémarrage du service ou un reboot de la machine. Le piège inverse existe aussi : nginx -t peut dire « test is successful » et le site servir quand même la mauvaise chose. Valide ne veut pas dire correct : la syntaxe est juste, mais le bon server n'est pas forcément celui qui répond, ce que la leçon suivante sur la sélection du server et du location traite en détail.

Valider, recharger ou redémarrer : quel geste choisir ?

Pour appliquer un changement, on valide avec nginx -t, puis on recharge avec systemctl reload nginx ; le redémarrage est réservé aux cas où un reload ne suffit pas. Les trois gestes diffèrent par leur effet sur le service en marche, et les confondre est une cause classique de coupure évitable.

Geste	Commande	Effet
Valider	sudo nginx -t	Lit et vérifie les fichiers, ne touche pas au service
Recharger	sudo systemctl reload nginx	Le maître relit la configuration, garde son PID, remplace les workers en douceur
Redémarrer	sudo systemctl restart nginx	Arrête puis relance : nouveau maître, connexions en cours coupées

Glissez pour voir

Le schéma suivant montre ce qui se passe pendant un rechargement. Suivez les flèches de haut en bas : le maître valide la nouvelle configuration, démarre de nouveaux workers, puis demande aux anciens de finir leurs requêtes en cours avant de s'arrêter. Le visiteur qui télécharge un fichier à ce moment ne remarque rien.

Un reload conserve le processus maître : seul le PID inchangé le prouve. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Si la nouvelle configuration est invalide, le maître refuse le rechargement et conserve les anciens workers, ce qui laisse le service en place et une erreur dans le journal (comportement décrit par la documentation de Nginx sur les signaux : le maître vérifie la syntaxe, tente d'appliquer la configuration, et en cas d'échec revient en arrière).

Selon l'unité systemd, la commande systemctl reload peut rendre la main avant que le maître ait jugé la configuration : elle n'est donc pas un verdict, et c'est une raison de plus de passer d'abord par nginx -t. Un restart, lui, arrête d'abord l'ancien service : si la configuration est fautive, le nouveau ne démarre pas, et le site est en panne. Le test du lab distingue les deux gestes par le PID du maître, comparé avant et après : s'il a changé, c'est qu'un redémarrage a eu lieu.

sudo nginx -t && sudo systemctl reload nginx
systemctl show -p MainPID --value nginx

L'opérateur && n'enchaîne le rechargement que si la validation a réussi : c'est la forme à prendre comme réflexe. Lancez la commande systemctl show avant, puis après le rechargement : un PID identique prouve un reload.

Quand le redémarrage est nécessaire

Un reload relit la configuration, pas le binaire ni les paramètres du processus maître. Après une mise à jour du paquet ou un changement d'options propres au maître, un redémarrage peut être nécessaire : prévoyez-le alors comme une coupure.

Pour comprendre un échec de rechargement, lisez le journal de l'unité avec journalctl -u nginx, puis les journaux propres à Nginx : /var/log/nginx/error.log pour les erreurs et /var/log/nginx/access.log pour les requêtes servies.

Comment prouver que le service revient après un redémarrage de la machine ?

Un service qui répond aujourd'hui et ne revient pas demain n'est pas installé, il est seulement lancé. Deux conditions doivent être remplies : le service est activé au démarrage, et sa configuration est écrite sur le disque, pas appliquée à la main dans une session.

La première condition se règle par sudo systemctl enable --now nginx, que la section d'installation a déjà lancée et que la famille RHEL exige de toute façon. La commande enable crée l'activation au démarrage, --now démarre aussi le service tout de suite. La seconde se contrôle en lisant les fichiers : tout ce que le site doit servir est dans conf.d/, jamais seulement dans la mémoire d'un processus. Vérifiez la première avec systemctl is-enabled nginx, qui doit répondre enabled. La preuve complète consiste à redémarrer la machine et à interroger le service : un contrôle qui ne redémarre pas ne mesure que l'état du moment.

Cette exigence explique l'ordre du lab : la validation du redémarrage passe en dernier, parce qu'elle coupe la machine et que tout ce qui la suivrait mesurerait un autre état.

Mettre en pratique

Le lab tourne sur Debian 13 uniquement : c'est la seule voie validée en machine, et la famille RHEL décrite plus haut n'est pas éprouvée par lui. Il installe Nginx 1.31.8 depuis le dépôt de l'éditeur, en épinglant la version, et retire le site de démonstration conf.d/default.conf. Vous publiez un nom vers un backend local en suivant un manifeste, puis vous montrez que vous distinguez valider, recharger et redémarrer. La validation porte sur quatre contrôles : la version et les modules lus sur le binaire en service comparés au manifeste, le refus d'une directive mal placée sans coupure du service, l'application d'un changement valide par un reload qui conserve le PID du maître, et le retour du service après un redémarrage réel de la machine.

Lab guidé Pratique

Apprendre à faire

Installer Nginx et maîtriser validation et reload

$ dsoxlab run pub-nginx-installation

Environnement : VM·Durée : ~50 min

Vérification : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start pub-nginx-installation vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/publier-service-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run pub-nginx-installation
dsoxlab check pub-nginx-installation

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• nginx -v et nginx -V donnent la version et les modules du binaire réellement en service : ils font foi, pas la documentation.
• Le paquet de l'éditeur nginx.org installe la version choisie, ici la 1.31.8 ; sa clé de signature contient trois clés, et celle qui signe est 8540A6F18833A80E9C1653A42FD21310B49F6B46.
• Comparer une empreinte n'est pas vérifier un dépôt : c'est la signature de InRelease, contrôlée par gpg --verify ou par apt-get update, qui prouve l'origine des paquets.
• Un site est un fichier .conf dans /etc/nginx/conf.d/, sans lien symbolique à créer ; nginx -T montre ce qui est réellement chargé, et conf.d/default.conf, le site de démonstration, se retire.
• Sur la famille RHEL, le paquet de la distribution n'active pas le service (enable --now) : cette voie est décrite, non rejouée.
• Le processus maître lit la configuration et supervise ; les workers, sous le compte nginx, servent tout le trafic.
• Une directive n'est valide que dans certains contextes (principal, events, http, server, location), et include insère un fichier à l'endroit où il se trouve.
• nginx -t refuse une directive mal placée sans toucher au service en marche.
• reload conserve le PID du maître et laisse finir les requêtes en cours ; restart coupe les connexions et tombe en panne sur une configuration fautive.
• Le réflexe est sudo nginx -t && sudo systemctl reload nginx.
• Un service n'est installé que s'il est activé au démarrage et configuré sur le disque : seul un vrai redémarrage le prouve.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →