Installer HAProxy et lire ses sections de configuration

Installer HAProxy, c'est obtenir un répartiteur dont on sait dire quelle version tourne, quelles sections de configuration il lit, dans quel mode il traite chaque port, et ce qu'il laisse joignable depuis le réseau. Cette leçon ouvre le module HAProxy. Elle s'adresse à une personne qui a déjà vu un reverse proxy et qui n'a jamais configuré HAProxy. Elle couvre l'installation par paquet, la lecture de global, defaults, frontend et backend, la différence entre le mode tcp et le mode http, puis la page d'état (une page web qui liste les backends et leur santé) et le socket d'administration (un point d'accès local pour interroger et piloter HAProxy en direct), qui ne doivent pas sortir de la machine.

Ce que vous allez apprendre

La leçon va du paquet installé à la preuve que rien n'est exposé par erreur.

• Installer HAProxy et relever la version du binaire que systemd exécute vraiment.
• Lire les sections global, defaults, frontend, backend et listen, et leur héritage.
• Distinguer le mode tcp, qui relaie sans comprendre, du mode http, qui lit chaque requête.
• Retenir la page d'état et le socket d'administration sur la machine, et le mesurer.
• Valider une configuration avec haproxy -c et vérifier qu'elle revient après un redémarrage.

Prérequis

La leçon suppose que vous savez ce qu'est un reverse proxy et que vous lisez une sortie de systemctl ou de ss.

• Comprendre le rôle d'un reverse proxy : Reverse proxy : définition, rôle et quel outil choisir.
• Lire une requête HTTP, ses en-têtes et son statut : Lire HTTP avant de configurer un proxy.
• Un compte avec sudo sur une machine Debian 13 (trixie), celle du lab. HAProxy 3.4 ne s'installe pas sur Ubuntu 24.04, la section suivante explique pourquoi.

La leçon Linux HAProxy : load balancing et haute disponibilité garde le périmètre de la certification LFCS. Celle-ci en est la version « publier un service » : elle ne la redit pas, elle s'appuie sur la même base.

Comment installer HAProxy : paquet, dépôt ou compilation ?

Trois voies existent, et elles se départagent sur une seule question : quelle branche de HAProxy voulez-vous exécuter, et qui la tient à jour ? Le paquet de la distribution suit le calendrier du système et vous laisse sur la branche figée à sa sortie ; le dépôt de l'éditeur donne la branche de votre choix, tenue par le mainteneur du paquet ; la compilation donne la maîtrise totale et la charge de chaque correctif. Cette leçon installe la deuxième, parce que la formation enseigne la branche courante.

La branche de référence de cette formation est HAProxy 3.4 LTS, et c'est celle que le lab installe : la version 3.4.7. Une branche LTS (long-term support) reçoit des correctifs pendant plusieurs années ; la 3.4 est maintenue jusqu'au deuxième trimestre 2031.

Le vocabulaire des branches a un sens précis chez HAProxy, relevé le 2026-10-26 sur haproxy.org. La branche marquée « stable » est la 3.3, non LTS, maintenue jusqu'au premier trimestre 2027. Les autres branches LTS sont la 3.2 et la 3.0. La 2.8, ancienne branche LTS, n'est plus qu'en « critical fixes only » : seuls les défauts critiques y sont corrigés. Avant de choisir une branche, lisez donc sa ligne Status plutôt que de vous fier au mot « stable ».

La branche choisie impose la distribution, et c'est le point contre-intuitif de cette installation. Le paquet haproxy de la 3.4 dépend de libssl3t64 en version 3.5.1 ou plus, ce qu'Ubuntu 24.04 ne fournit pas : il ne s'y installe pas, et aucune option d'apt n'y change rien. C'est la raison pour laquelle cette formation est sur Debian 13, où le dépôt de l'éditeur publie trixie-backports-3.4. Sur Ubuntu 24.04, la branche la plus haute atteignable reste la 3.3.

Debian 13

Voie rejouée en machine sur Debian 13 (trixie), celle du lab : Debian GNU/Linux 13 (trixie) et HAProxy version 3.4.7-1~bpo13+1. Le dépôt est celui du projet Debian de HAProxy, décrit sur haproxy.debian.net. Trois gestes : récupérer sa clé de signature, vérifier son empreinte, puis déclarer le dépôt de la branche voulue.

sudo apt-get install -y curl gnupg ca-certificates socat
sudo curl -fsSL https://haproxy.debian.net/haproxy-archive-keyring.gpg \
  -o /usr/share/keyrings/haproxy.debian.net.gpg
gpg --show-keys --fingerprint /usr/share/keyrings/haproxy.debian.net.gpg

La dernière commande affiche l'empreinte de chaque clé du fichier. Au 2026-10-26, relevé sur le fichier publié, celui-ci n'en contient qu'une : une clé RSA 4096 créée en 2012 au nom de Vincent Bernat, mainteneur du paquet, sans date d'expiration (seule sa sous-clé de chiffrement expire, en juin 2027, ce que votre sortie montre). Son empreinte est AEF2348766F371C689A7360095A42FE8353525F9. Cherchez-la quand même parmi toutes celles qu'affiche votre sortie, sans supposer que la première est la bonne : un trousseau peut en porter plusieurs, et rien ne garantit l'ordre dans lequel elles sortent. Si elle est absente, arrêtez-vous et ne déclarez pas le dépôt.

Cette empreinte et la signature ne prouvent pas la même chose. L'empreinte dit seulement que vous détenez le fichier de clé attendu. Ce qui prouve que les paquets viennent bien de l'éditeur, c'est que la signature du dépôt se vérifie contre cette clé : apt le fait à chaque apt-get update grâce à signed-by, et refuse le dépôt avec une erreur de clé publique manquante ou de signature invalide si elle ne correspond pas. Sans le trousseau, gpg --verify sur le fichier InRelease du dépôt annonce la clé AEF2…25F9 mais répond No public key ; avec lui, il répond Good signature au nom de Vincent Bernat. Un apt-get update qui réussit sans avertissement sur ce dépôt est donc votre preuve.

Une fois l'empreinte acceptée, déclarez le dépôt de la branche 3.4 et installez le paquet :

echo "deb [signed-by=/usr/share/keyrings/haproxy.debian.net.gpg] http://haproxy.debian.net trixie-backports-3.4 main" \
  | sudo tee /etc/apt/sources.list.d/haproxy.list
sudo apt-get update
apt-cache policy haproxy
sudo apt-get install -y haproxy

apt-cache policy haproxy donne la version candidate avant l'installation : elle doit commencer par 3.4. Le dépôt est en http parce que la signature des index, vérifiée par signed-by, porte la confiance, pas le transport. Le paquet démarre le service avec sa propre configuration. socat sert à parler au socket d'administration depuis un terminal.

Le paquet pose déjà l'essentiel, ce qui évite de le refaire. La configuration est /etc/haproxy/haproxy.cfg, et le répertoire /etc/haproxy/conf.d est également chargé : l'unité systemd lance /usr/sbin/haproxy -Ws -f $CONFIG -f $CFGDIR, donc un fragment posé dans conf.d est lu sans rien changer à l'unité. Le paquet fournit les pages d'erreur, un chroot dans /var/lib/haproxy, l'utilisateur et le groupe haproxy, un socket d'administration déjà déclaré, et les outils haproxy-reload, haproxy-dump-certs et halog.

RHEL / Rocky / Alma / Fedora

Voie décrite d'après la documentation des distributions, non rejouée dans le lab : rien de ce qui suit n'a été testé sur cette famille. Le paquet s'appelle aussi haproxy. D'après cette documentation, il ne démarre pas le service à l'installation, point non vérifié : enable --now l'active et le lance dans tous les cas.

sudo dnf install -y haproxy socat
sudo systemctl enable --now haproxy

Deux pièges propres à cette famille, à vérifier sur votre machine. SELinux peut refuser à HAProxy de joindre un backend sur un port non standard : le booléen concerné s'appelle haproxy_connect_any, il est désactivé par défaut, et getsebool haproxy_connect_any donne son état sur votre machine. Nous n'avons pas pu confirmer qu'il existe sous ce nom sur RHEL 9 ou 10 : contrôlez-le avant de l'activer. Et la version du paquet varie avec la version majeure de la distribution : relevez-la, ne la supposez pas.

Reste la troisième voie annoncée plus haut, compiler depuis les sources officielles. La leçon Linux HAProxy : load balancing et haute disponibilité la détaille pas à pas, pour une branche 3.2 : cette leçon-ci ne la rejoue pas. Elle a un intérêt réel, activer une option absente du paquet, et un coût que personne n'annonce : vous devenez responsable de chaque correctif de sécurité, sans apt pour vous prévenir. Pour un premier déploiement, le dépôt de l'éditeur suffit.

Quelle version tourne vraiment ?

La version qui tourne est celle du binaire que systemd a lancé, relevée par /proc/<pid>/exe, pas celle du premier haproxy que votre PATH propose. Les deux peuvent différer dès qu'une version compilée à la main cohabite avec le paquet, et c'est le cas qu'on ne voit qu'après coup.

La démarche tient en trois gestes. On demande à systemd le PID principal du service, on résout le binaire qui porte ce PID, puis on l'interroge avec -v.

pid=$(systemctl show -p MainPID --value haproxy)
binaire=$(sudo readlink -f /proc/${pid}/exe)
sudo "${binaire}" -v

La première ligne de haproxy -v donne HAProxy version .... La ligne suivante, Status, s'affiche sur toutes les branches, LTS ou non : elle dit de quel type de branche il s'agit et la fin de support prévue. C'est la donnée de maintenance à relever avant de choisir une branche. Pour les options de compilation et les modules présents (TLS, PCRE2, Lua, exporteur Prometheus), haproxy -vv les liste : un module absent du binaire ne se rattrape pas par la configuration.

Les réglages, eux, se lisent sur l'instance vivante : haproxy -v n'a aucune idée de la configuration chargée, il décrit le binaire, pas le processus. Le socket d'administration répond à la commande show info, qui rapporte entre autres Maxconn et Nbthread :

echo 'show info' | sudo socat -t2 stdio /run/haproxy/admin.sock

Cette lecture compte parce qu'une valeur écrite dans haproxy.cfg et jamais chargée n'est pas une valeur appliquée. Le contrôle du lab refuse justement de lire le fichier : il interroge le socket. Une configuration modifiée sans rechargement se démasque ici.

Comment HAProxy tourne-t-il : processus, threads et systemd ?

HAProxy tourne comme un processus maître qui supervise un worker, lequel traite les connexions avec plusieurs threads ; systemd ne voit que le processus maître. Le maître (master) relit la configuration et relance un worker neuf lors d'un rechargement. Le worker est celui qui écoute les ports et sert le trafic.

Deux directives de global bornent ce worker. maxconn plafonne le nombre de connexions simultanées ; au-delà, HAProxy met les connexions en attente au lieu de saturer la machine. nbthread fixe le nombre de threads, c'est-à-dire de fils d'exécution qui partagent le même processus. Sans directive nbthread, HAProxy choisit lui-même ce nombre d'après la machine : la valeur réellement appliquée se lit par show info, comme vu plus haut, et c'est ce que fait le contrôle du lab plutôt que de l'écrire en dur.

Pour voir ce que lance réellement le paquet, systemctl cat haproxy affiche l'unité. Sur Debian 13, la ligne ExecStart est /usr/sbin/haproxy -Ws -f $CONFIG -f $CFGDIR … : -Ws démarre en mode maître-worker et prévient systemd quand le service est prêt, $CONFIG est haproxy.cfg et $CFGDIR est le répertoire conf.d. Lisez-la plutôt que de la supposer.

Comment lire global, defaults, frontend et backend ?

Un fichier haproxy.cfg est une suite de sections, chacune ouverte par un mot-clé en début de ligne ; les directives indentées qui suivent lui appartiennent jusqu'à la section suivante. Il y en a cinq à connaître.

Section	Ce qu'elle porte	Ce qu'elle ne fait pas
global	Le processus : utilisateur, chroot, maxconn, nbthread, socket d'administration, journal	Elle ne traite aucune requête
defaults	Les réglages communs : mode, délais timeout, log	Elle n'écoute rien
frontend	Ce qui écoute : un ou plusieurs bind, et les règles qui choisissent un backend	Elle ne parle à aucun serveur
backend	Les serveurs d'une application, l'algorithme de répartition, les sondes	Elle n'écoute rien
listen	Un frontend et un backend réunis dans une seule section	Elle sert aux cas simples, comme une page d'état

Glissez pour voir

Voici un exemple volontairement différent de celui du lab : un seul nom, un seul serveur, un port de test. Il sert à lire la forme, pas à copier une solution.

global
    log /dev/log local0
    maxconn 2048
    stats socket /run/haproxy/admin.sock mode 660 level admin

defaults
    mode    http
    log     global
    timeout connect 5s
    timeout client  30s
    timeout server  30s

frontend catalogue
    bind :8080
    default_backend appli

backend appli
    server appli1 127.0.0.1:9000

Lisez ce fichier de haut en bas, comme HAProxy. global règle le processus et ouvre le socket d'administration en mode 660 : seuls le propriétaire et le groupe y accèdent. defaults pose le mode http et les trois délais, qui valent pour toutes les sections qui suivent. Le frontend écoute le port 8080 et renvoie tout vers le backend appli, qui désigne un serveur.

L'héritage est le point qui surprend. Une section frontend ou backend reprend les réglages de la section defaults qui la précède, et peut en redéfinir un seul. Un frontend qui doit travailler dans un autre mode que celui des defaults écrit sa propre ligne mode. Un délai oublié dans defaults est un délai que chaque section hérite sans que vous le voyiez.

Le paquet Debian 13 déclare déjà ce socket dans son haproxy.cfg, et le répertoire /run/haproxy existe : vous n'avez rien à créer. Mais deux sockets coexistent, et il faut les distinguer. /run/haproxy/admin.sock est celui d'administration, qui répond à show info. /run/haproxy-master.sock est celui du processus maître, ouvert par l'option -S que l'unité passe via EXTRAOPTS. Pour interroger le worker, c'est le premier.

Un piège de lecture : HAProxy ne supprime pas son socket UNIX en s'arrêtant. Après un systemctl stop haproxy, ls -l /run/haproxy/ montre encore srw-rw---- 1 root haproxy 0 Oct 26 09:20 admin.sock (relevé sur Debian 13) : le fichier est là, le service est arrêté, il ne reste qu'une inode. C'est ce qui a fait échouer le premier passage du lab, dont la précondition testait la présence du fichier et concluait à tort qu'un service tournait. Pour savoir si HAProxy tourne, interrogez le socket (echo 'show info' | sudo socat -t2 stdio /run/haproxy/admin.sock) : sans processus derrière, la connexion est refusée, ce qu'un test -S ne verrait pas. Tout contrôle de supervision que vous écrivez doit poser la question, pas regarder si le fichier existe.

Que dit HAProxy d'une configuration sans listener ?

HAProxy refuse de démarrer sur une configuration qui ne déclare aucune section d'écoute, et son code de sortie suivi de son message sont la première chose à savoir lire. Un listener est une section qui ouvre un port d'écoute : un frontend ou un listen. Le lab part précisément de là : le fichier de départ contient un global et un defaults, et rien d'autre, donc aucun listener.

Le geste est de valider avant de charger, comme nginx -t pour Nginx, vu dans Installer Nginx :

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Le code de sortie est 0 si la configuration est valide, non nul sinon, et le message nomme ce qui manque ou la ligne fautive. Je ne reproduis pas le texte exact : il varie d'une version à l'autre, et c'est le vôtre qui compte. systemctl status haproxy puis journalctl -u haproxy complètent le diagnostic quand le service refuse de démarrer.

Prenez l'habitude de lancer haproxy -c avant chaque reload. Un rechargement sur une configuration invalide ne coupe pas le service en cours, mais il n'applique pas non plus ce que vous attendiez, et vous croyez le contraire.

Mode tcp ou mode http : quelle différence en pratique ?

En mode tcp, HAProxy relaie des octets sans les interpréter ; en mode http, il lit chaque requête, la valide, peut la modifier, puis choisit un backend. Tout le reste du module découle de cette différence.

Même instance, deux modes : le frontend HTTP comprend ce qu'il transporte, le frontend TCP non. Source · SVG

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

Le lab pose trois services sur la boucle locale pour le montrer. Deux parlent HTTP et renvoient leur nom, le Host reçu et l'adresse que le proxy leur a transmise. Le troisième ne parle pas HTTP : il répond à toute ligne en la renvoyant préfixée, y compris à une ligne de requête HTTP. On publie les deux premiers sur le port 80 en mode http, le troisième sur le port 7001 en mode tcp.

Le test envoie la même ligne volontairement invalide, GET / HTTP/9.9, sur les deux ports. Sur le port 7001, elle doit revenir en écho : le relais ne la lit pas, il la transporte. Sur le port 80, HAProxy la refuse avant d'atteindre un backend, avec un statut que le test accepte en 400 ou en 505. Si les deux ports se comportaient pareil, les deux frontends seraient dans le même mode, quelles que soient les directives écrites. C'est une preuve par le comportement, pas par le fichier.

Ce que le mode http permet, le mode tcp l'interdit. En http, HAProxy peut router par nom de domaine ou par chemin, ajouter ou retirer des en-têtes, journaliser la requête, refuser une méthode. En tcp, il ne voit ni nom HTTP, ni chemin, ni en-tête : il ne lit aucune requête HTTP et décide surtout sur l'adresse source ou le port. Il peut aussi inspecter le début d'un flux TLS pour lire le nom demandé par le client (le SNI, Server Name Indication) avec une règle tcp-request content, mais jamais un chemin ni un en-tête HTTP. Le mode tcp convient donc aux protocoles que HAProxy ne comprend pas (une base de données, un protocole de lignes, un flux TLS qu'on ne veut pas ouvrir) et le mode http à tout ce qui est web.

Une conséquence demande une attention particulière : l'adresse du client. En mode http, le backend ne voit que le proxy, sauf si HAProxy ajoute l'en-tête X-Forwarded-For avec la directive option forwardfor. Le contrôle du lab le vérifie du côté du backend : le service affiche l'en-tête reçu et le test le compare à l'adresse réelle du client. Un en-tête que le proxy se déclarerait à lui-même ne prouverait rien, c'est le témoin en aval qui compte. En mode tcp, il n'y a pas d'en-tête à ajouter : conserver l'adresse source passe par un autre mécanisme, le protocole PROXY (send-proxy sur la ligne server), que le backend doit comprendre.

Comment garder la page d'état et le socket hors du réseau ?

La page d'état et le socket d'administration doivent exister et répondre depuis la machine, et depuis elle seule : un bind limité à 127.0.0.1 pour la page, un socket UNIX sans droits pour les autres comptes. La page d'état dit quels backends existent, lesquels sont tombés et quel trafic ils prennent. Le socket d'administration, lui, permet de désactiver des serveurs et de lire la configuration : exposé en TCP, c'est un interpréteur à distance sur le proxy.

Pour la page, tout se joue dans l'adresse du bind. bind :8404 écoute sur toutes les interfaces ; bind 127.0.0.1:8404 n'écoute que sur la boucle locale. La différence d'un préfixe est la différence entre une page publique et une page privée. Une section listen suffit, avec stats enable et stats uri /. La page n'affiche pas la version de HAProxy, stats show-version étant désactivé par défaut en 3.4 : ne comptez pas sur elle pour relever la version. Pour le socket, stats socket /run/haproxy/admin.sock mode 660 level admin crée un socket UNIX (un fichier, pas un port) dont les droits 660 écartent tout compte qui n'est ni propriétaire ni dans le groupe.

Le contrôle du lab ne lit aucun fichier de configuration. Il énumère les sockets sur lesquels le processus écoute réellement, avec ss, et n'accepte hors boucle locale que les ports publiés, 80 et 7001. Vous pouvez faire la même mesure :

sudo ss -ltnpH | grep haproxy

Chaque ligne donne l'adresse d'écoute en quatrième colonne. Celles qui commencent par 127. ou [::1] sont privées ; toute autre, sur un port qui n'est pas publié, est une fuite. Le fichier dit l'intention, le noyau dit ce qui est réel : un bind que l'on croit restreint et qui écoute partout ne se voit qu'ici.

Le test exige aussi que la page réponde depuis la machine, avec un 200 ou un 401 sur la boucle locale, et que le client distant obtienne 000, c'est-à-dire aucune réponse. Les deux moitiés sont indispensables : « pas publique » se satisfait trivialement en n'ayant rien du tout, mais « pas publique » n'est pas « pas là ». Pour protéger la page par un mot de passe, limiter le débit ou exposer les métriques à Prometheus, voir Protéger et observer HAProxy.

Comment appliquer un changement et prouver qu'il survit au redémarrage ?

Un changement appliqué proprement suit trois temps : valider avec haproxy -c, recharger avec systemctl reload haproxy, puis vérifier le comportement ; et le service ne compte comme installé que s'il revient après un redémarrage de la machine. Le rechargement relance un worker neuf avec la nouvelle configuration, sans refuser les connexions qui arrivent pendant ce temps.

Le dernier test du lab redémarre la machine, puis rejoue les contrôles HTTP, TCP et d'exposition. Il vérifie ce qu'une session de travail masque : un service lancé à la main répond aujourd'hui et ne revient pas demain. Deux causes dominent. Le service n'est pas activé au démarrage (systemctl enable haproxy), ou la configuration n'a été appliquée qu'en mémoire au lieu d'être écrite sur le disque. Le lab part d'ailleurs d'un service arrêté et non activé, pour que ce geste soit à faire.

Le rechargement relit le fichier : un changement fait à chaud par le socket d'administration ne lui survit pas, ce que Router par noms et chemins avec ACL et maps mesure sur une table de routage. Quand un rechargement ne suffit pas, systemctl restart haproxy coupe les connexions en cours : réservez-le aux cas où le rechargement ne prend pas en compte le changement.

Mettre en pratique

Le lab vous donne un HAProxy 3.4.7 installé depuis le dépôt de l'éditeur sur Debian 13, trois services sur la boucle locale et une configuration sans listener. Vous publiez deux noms HTTP sur le port 80 et un protocole de lignes en relais TCP sur le port 7001, vous ouvrez la page d'état et le socket d'administration, et vous les gardez hors du réseau. La validation mesure : la version, maxconn et nbthread lus sur l'instance vivante, le routage des deux noms avec X-Forwarded-For vu du backend, le relais TCP face au refus HTTP, et l'absence d'écoute publique inattendue, le tout rejoué après un redémarrage.

Lab guidé Pratique

Apprendre à faire

Installer HAProxy et distinguer ses modes HTTP et TCP

$ dsoxlab run pub-haproxy-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-haproxy-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-haproxy-installation
dsoxlab check pub-haproxy-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

• La branche de référence est HAProxy 3.4 LTS, installée depuis haproxy.debian.net sur Debian 13 : son paquet ne s'installe pas sur Ubuntu 24.04. « Stable » désigne la 3.3 chez HAProxy, pas la 3.4. Relevez la version avec haproxy -v sur le binaire que systemd exécute (/proc/<pid>/exe), pas sur le PATH. L'empreinte de la clé prouve que vous détenez le bon fichier ; c'est la signature du dépôt, vérifiée par apt à chaque mise à jour, qui prouve l'origine des paquets.
• maxconn et nbthread se lisent par show info sur le socket d'administration, donc sur l'instance vivante, jamais dans le fichier seul.
• Cinq sections : global pour le processus, defaults pour les réglages communs hérités, frontend pour l'écoute, backend pour les serveurs, listen pour les deux réunis.
• haproxy -c -f /etc/haproxy/haproxy.cfg se lance avant chaque rechargement ; une configuration sans listener est refusée.
• Le mode tcp relaie sans comprendre ; le mode http lit, valide et peut router, ce que le test prouve par une ligne HTTP invalide relayée sur un port et refusée sur l'autre.
• Le backend ne voit le client que par X-Forwarded-For en mode http (option forwardfor) ; en mode tcp, il faut le protocole PROXY.
• La page d'état et le socket restent sur la machine : bind 127.0.0.1, socket UNIX en mode 660, vérifié par ss -ltnp et non par le fichier.
• Un service n'est installé que s'il est activé au démarrage et revient avec la même configuration après un redémarrage.

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 →