HAProxy 3.4.4 Documentation on PIG.CENTER

Guide de démarrage

Mon, 01 Jan 0001 00:00:00 +0000

Fundamentaux de la répartition de charge

Mon, 01 Jan 0001 00:00:00 +0000

Ce document présente HAProxy à l’intention de tous ceux qui ne le connaissent pas, ainsi que de ceux qui souhaitent le redécouvrir après avoir utilisé des versions antérieures. Son objectif principal est de fournir à l’utilisateur toutes les informations nécessaires pour décider si HAProxy correspond ou non à ses besoins. Les utilisateurs avancés pourront y trouver certaines solutions à des idées qu’ils avaient eues, simplement parce qu’ils ignoraient une fonctionnalité récente. Des indications de dimensionnement sont également fournies, le cycle de vie du produit est expliqué, ainsi que des comparaisons avec des produits partiellement similaires.

Qu'est-ce qu'HAProxy et comment il fonctionne

Mon, 01 Jan 0001 00:00:00 +0000

La graphie « HAProxy » désigne le produit, tandis que « haproxy » désigne le programme exécutable, le paquet logiciel ou un processus. Ces graphies sont toutefois couramment utilisées dans chaque contexte et se prononcent H-A-Proxy. À l’origine, « haproxy » signifiait « high availability proxy » et le nom s’écrivait en deux mots distincts ; aujourd’hui, il ne signifie plus rien d’autre que « HAProxy ».

Fonctionnalités de base

Mon, 01 Jan 0001 00:00:00 +0000

Cette section énumère un certain nombre de fonctionnalités implémentées par HAProxy, certaines étant généralement attendues d’un répartiteur de charge moderne, et d’autres constituant un avantage direct de l’architecture d’HAProxy. Les fonctionnalités avancées seront détaillées dans la section suivante.

3.3.1. Fonctionnalités de base : Proxys

Le proxy consiste à transférer des données entre un client et un serveur via deux connexions indépendantes. Les fonctionnalités de base suivantes sont prises en charge par HAProxy en matière de proxy et de gestion des connexions :

Fonctionnalités standard

Mon, 01 Jan 0001 00:00:00 +0000

Dans cette section, sont énumérées certaines fonctionnalités très couramment utilisées avec HAProxy mais qui ne sont pas nécessairement disponibles sur d’autres répartiteurs de charge.

3.4.1. Fonctionnalités standard : Échantillonnage et conversion d’informations

HAProxy prend en charge l’extraction d’échantillons à l’aide d’une large gamme de « fonctions d’extraction d’échantillon ». Le principe consiste à extraire des éléments d’information appelés échantillons, destinés à une utilisation immédiate. Cela est utilisé pour la persistance de session, la création de conditions, la génération d’informations dans les journaux ou l’enrichissement des en-têtes HTTP.

Fonctionnalités avancées

Mon, 01 Jan 0001 00:00:00 +0000

3.5.1. Fonctionnalités avancées : Gestion

HAProxy est conçu pour rester extrêmement stable et sécurisé à gérer dans un environnement de production classique. Il est fourni sous forme d’un seul fichier exécutable ne nécessitant aucun processus d’installation. Plusieurs versions peuvent coexister facilement, ce qui permet (et est recommandé) de mettre à jour les instances progressivement, par ordre de priorité, plutôt que de les migrer toutes en même temps. Les fichiers de configuration sont facilement versionnés. La vérification de configuration se fait hors ligne, sans nécessiter de redémarrer un service susceptible de échouer. Pendant la vérification de configuration, un certain nombre d’erreurs avancées peuvent être détectées (par exemple, une règle masquant une autre, ou une persistance qui ne fonctionnera pas), et des avertissements détaillés ainsi que des suggestions de configuration sont proposés pour les corriger. La compatibilité des fichiers de configuration avec les versions antérieures s’étend très loin dans le temps : la version 1.5 supporte encore entièrement les configurations écrites pour les versions 1.1, il y a 13 ans, et la version 1.6 n’a abandonné le support que pour des mots-clés presque inutilisés et obsolètes, pouvant être remplacés autrement. Le mécanisme de mise à jour de la configuration et du logiciel est fluide et non disruptif, car il permet à des processus anciens et nouveaux de coexister sur le système, chacun gérant ses propres connexions. L’état du système, les options de compilation et la compatibilité des bibliothèques sont rapportés au démarrage.

Taille et performance

Mon, 01 Jan 0001 00:00:00 +0000

Les valeurs typiques d’utilisation du processeur montrent que 15 % du temps de traitement sont consacrés à HAProxy contre 85 % au noyau en mode TCP ou HTTP fermé, et environ 30 % pour HAProxy contre 70 % pour le noyau en mode HTTP keep-alive. Cela signifie que le système d’exploitation et son réglage ont une influence forte sur les performances globales.

Versions, Paquets et Mises à jour

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est un projet open source soumis à la licence GPLv2, ce qui signifie que toute personne est autorisée à le redistribuer à condition de fournir l’accès au code source sur demande, notamment si des modifications ont été apportées.

HAProxy évolue via une branche de développement principale appelée « master » ou « mainline », à partir de laquelle de nouvelles branches sont créées une fois que le code est jugé stable. De nombreux sites web exécutent des branches de développement en production de manière volontaire, soit pour participer au projet, soit parce qu’ils ont besoin d’une fonctionnalité de pointe, et leurs retours sont précieux pour corriger les bogues et évaluer la qualité et la stabilité globales de la version en développement.

Produits complémentaires et alternatives

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy s’intègre assez bien avec certains produits listés ci-dessous, ce qui justifie leur mention ici, même s’ils ne sont pas directement liés à HAProxy.

4.1. Serveur HTTP Apache

Apache est le serveur HTTP de facto. Il s’agit d’un projet très complet et modulaire, capable de servir des fichiers ainsi que du contenu dynamique. Il peut agir de front-end pour certains serveurs d’applications. Il peut même acheminer des requêtes et mettre en mémoire tampon les réponses. Dans tous ces cas d’utilisation, un répartiteur de charge frontal est généralement nécessaire. Apache peut fonctionner dans divers modes, certains étant plus lourds que d’autres. Certains modules nécessitent encore le modèle pré-forké plus lourd, ce qui empêche Apache de bien évoluer avec un grand nombre de connexions. Dans ce cas, HAProxy peut apporter une aide considérable en imposant des limites de connexion par serveur à une valeur sûre, ce qui accélère significativement le serveur et préserve ses ressources, qui seront mieux utilisées par l’application.

Documentation et communauté

Mon, 01 Jan 0001 00:00:00 +0000

1. Documentation disponible

La documentation complète de HAProxy est contenue dans les documents suivants. Veuillez vous assurer de consulter la documentation pertinente afin d’économiser du temps et d’obtenir la réponse la plus précise à vos besoins. Veuillez également vous abstenir d’envoyer des questions à la liste de diffusion dont les réponses sont déjà disponibles dans ces documents.

Documentation de configuration

Mon, 01 Jan 0001 00:00:00 +0000

1. Petit rappel sur HTTP

Mon, 01 Jan 0001 00:00:00 +0000

Ce document traite du langage de configuration tel qu’il est implémenté dans la version indiquée ci-dessus. Il ne fournit aucune indication, exemple ou conseil. Pour ce type de documentation, veuillez vous référer au Manuel de référence ou au Manuel d’architecture. Les chapitres numérotés sont ordonnés dans la barre latérale plate de HAProxy pour une navigation directe.

Lorsque HAProxy fonctionne en mode HTTP, la requête et la réponse sont entièrement analysées et indexées, ce qui permet de définir des critères de correspondance sur presque tout élément présent dans leur contenu.

2. Configuration de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

2.1. Format du fichier de configuration

Le processus de configuration d’HAProxy repose sur 3 sources majeures de paramètres :

les arguments en ligne de commande, qui ont toujours la priorité
le(s) fichier(s) de configuration, dont le format est décrit ici
l’environnement du processus en cours d’exécution, en cas de référence explicite à certaines variables d’environnement

Le fichier de configuration suit un format hiérarchique assez simple qui obéit à quelques règles fondamentales :

3. Section globale

Mon, 01 Jan 0001 00:00:00 +0000

Les paramètres de la section « global » sont applicables à l’ensemble du processus et souvent spécifiques au système d’exploitation. Ils sont généralement définis une fois pour toutes et n’exigent pas de modification une fois correctement configurés. Certains d’entre eux ont des équivalents en ligne de commande.

Les mots-clés suivants sont pris en charge dans la section « global » :

Gestion des processus et sécurité

4. Proxies

Mon, 01 Jan 0001 00:00:00 +0000

La configuration du proxy peut être située dans un ensemble de sections :

defaults [<name>] [ depuis <defaults_name> ]
frontal <name> [ depuis <defaults_name> ]
backend <name> [ depuis <defaults_name> ]
écouter <name> [ depuis <defaults_name> ]

Une section « frontend » décrit un ensemble de sockets d’écoute acceptant les connexions clientes.

Une section « backend » décrit un ensemble de serveurs auxquels le proxy se connectera pour acheminer les connexions entrantes.

5. Options de liaison et de serveur

Mon, 01 Jan 0001 00:00:00 +0000

Les mots-clés « bind », « server » et « default-server » prennent en charge un certain nombre de paramètres, selon certains options de compilation et le système sur lequel HAProxy a été compilé. Ces paramètres sont généralement composés d’un mot, parfois suivi d’une valeur, écrits sur la même ligne que la directive « bind » ou « server ». Tous ces paramètres sont décrits dans cette section.

6. Mise en cache

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy fournit un cache, conçu pour effectuer le mise en mémoire tampon de petits objets (favicon, fichiers CSS…). Il s’agit d’un cache minimaliste, à faible maintenance, qui s’exécute en mémoire RAM.

Le cache repose sur une zone mémoire partagée entre tous les threads, divisée en blocs de 1 ko.

Si un objet n’est plus utilisé, il peut être supprimé afin de stocker un nouvel objet indépendamment de sa date d’expiration. Les objets les plus anciens sont supprimés en premier lorsque l’on tente d’allouer un nouvel objet.

7. Listes de contrôle d'accès et extraction d'échantillon

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est capable d’extraire des données des flux de requêtes ou de réponses, des informations client ou serveur, des tables, des informations environnementales, etc. L’opération d’extraction de ces données est appelée « récupération d’un échantillon ». Une fois récupérés, ces échantillons peuvent être utilisés à diverses fins, par exemple comme clé dans une table de persistance, mais les usages les plus courants consistent à les comparer à des données constantes prédéfinies appelées modèles.

8. Journalisation

Mon, 01 Jan 0001 00:00:00 +0000

L’un des points forts d’HAProxy réside certainement dans ses journaux précis. Il fournit probablement le niveau d’information le plus poussé disponible pour un tel produit, ce qui est essentiel pour le dépannage des environnements complexes. Les informations standard fournies dans les journaux incluent les ports clients, les compteurs d’état TCP/HTTP, l’état précis du flux à la terminaison et la cause précise de la terminaison, des informations sur les décisions visant à acheminer le trafic vers un serveur, ainsi que, bien entendu, la capacité à capturer des en-têtes arbitraires.

9. Filtres pris en charge

Mon, 01 Jan 0001 00:00:00 +0000

Voici la liste des filtres officiellement pris en charge, accompagnée de la liste des paramètres qu’ils acceptent. En fonction des options de compilation, certains de ces filtres pourraient être indisponibles. La liste des filtres disponibles est indiquée dans HAProxy -vv.

Voir aussi : « filter »

9.1. Trace

filtre trace [nom <name>] [redirection aléatoire] [nombre maximal de redirections <max>] [affichage hexadécimal]

10. Applications FastCGI

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est capable d’envoyer des requêtes HTTP vers des applications FastCGI Responder. Cette fonctionnalité a été ajoutée à HAProxy 2.1. Pour cela, les serveurs doivent être configurés pour utiliser le protocole FastCGI (en utilisant le mot-clé « proto fcgi » dans la ligne du serveur) et une application FastCGI doit être configurée et utilisée par le backend gérant ces serveurs (en utilisant le mot-clé « use-fcgi-app » dans la section proxy). Plusieurs applications FastCGI peuvent être définies, mais un seul peut être utilisé à la fois par un backend.

11. Tables de persistance et pairs

Mon, 01 Jan 0001 00:00:00 +0000

Les tables de persistance dans HAProxy sont un mécanisme qui permet d’associer un certain nombre d’informations et de métriques à une clé d’un type donné, pendant une durée déterminée après la dernière mise à jour. Cela peut être vu comme une ligne à plusieurs colonnes dans un tableau, où le numéro de ligne est défini par la valeur de la clé, et chaque colonne représente un critère distinct.

12. Autres sections

Mon, 01 Jan 0001 00:00:00 +0000

Les sections décrites ci-dessous sont moins couramment utilisées et ne prennent généralement en charge qu’un petit nombre de paramètres. Il n’existe aucune relation implicite entre elles. Elles sont toutes initiales à l’aide d’un mot-clé unique. Aucune d’entre elles n’est autorisée avant une section « global ». Le support de certaines d’entre elles peut être conditionné par des options de compilation (par exemple, tout ce qui est lié au SSL).

Guide de gestion

Mon, 01 Jan 0001 00:00:00 +0000

1. Prérequis

Mon, 01 Jan 0001 00:00:00 +0000

Ce document décrit comment démarrer, arrêter, gérer et dépanner HAProxy, ainsi que certaines limitations connues et pièges à éviter. Il ne décrit pas comment le configurer (pour cela, veuillez consulter configuration.txt ).

Dans ce document, il est supposé que le lecteur possède des compétences suffisantes en administration sur un système d’exploitation de type UNIX, utilise quotidiennement l’interpréteur de commandes et maîtrise les outils de dépannage tels que strace et tcpdump.

2. HAProxy Architecture

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est un démon multithreadé, basé sur des événements et non bloquant. Cela signifie qu’il utilise la multiplexion d’événements pour planifier toutes ses activités, plutôt que de dépendre du système pour planifier entre plusieurs activités. La plupart du temps, il s’exécute sous la forme d’un seul processus, de sorte que la sortie de la commande « ps aux » sur un système ne répertorie qu’un seul processus « HAProxy », sauf en cas de rechargement doux en cours, auquel cas un processus ancien peut encore s’exécuter en parallèle du nouveau. Il est donc toujours facile de suivre son activité à l’aide de l’outil strace. Pour s’adapter au nombre de processeurs disponibles, HAProxy démarre, par défaut, un thread worker par processeur sur lequel il est autorisé à s’exécuter. À moins d’être configuré autrement, le trafic entrant est réparti entre tous ces threads, chacun exécutant la même boucle d’événements. Une grande attention est portée à limiter les dépendances entre threads au strict minimum, afin de tenter d’obtenir une scalabilité quasi linéaire. Cela a certaines conséquences, notamment le fait qu’une connexion donnée soit servie par un seul thread. Ainsi, pour utiliser toute la capacité de traitement disponible, il faut disposer d’au moins autant de connexions que de threads, ce qui est presque toujours le cas.

3. Démarrage de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est lancé en exécutant le programme « HAProxy » avec un certain nombre d’arguments passés en ligne de commande. La syntaxe réelle est :

$ haproxy [<options>]*

où [<options>]* est un nombre quelconque d’options. Une option commence toujours par ‘-’ suivi d’une ou plusieurs lettres, et peut être suivie d’un ou plusieurs arguments supplémentaires. Sans option, HAProxy affiche la page d’aide avec un rappel des options prises en charge. Les options disponibles peuvent varier légèrement selon le système d’exploitation. Un nombre important de ces options se chevauchent avec une option équivalente dans la section « global ». Dans ce cas, la ligne de commande a toujours priorité sur le fichier de configuration, de sorte que la ligne de commande peut être utilisée pour imposer rapidement certains paramètres sans modifier les fichiers de configuration. La liste actuelle des options est :

4. Arrêt et redémarrage de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy prend en charge une interruption douce et une interruption brutale. L’interruption brutale est simple : lorsqu’un signal SIGTERM est envoyé au processus HAProxy, celui-ci quitte immédiatement et toutes les connexions établies sont fermées. L’interruption douce est déclenchée lorsqu’un signal SIGUSR1 est envoyé au processus HAProxy. Elle consiste à ne plus se lier aux ports d’écoute, tout en continuant à traiter les connexions existantes jusqu’à leur fermeture. Une fois la dernière connexion fermée, le processus se termine.

5. Limites des descripteurs de fichiers

Mon, 01 Jan 0001 00:00:00 +0000

Afin de garantir que toutes les connexions entrantes soient correctement servies, HAProxy calcule au moment du chargement le nombre total de descripteurs de fichiers nécessaires durant la durée de vie du processus. Un processus Unix classique reçoit généralement 1024 descripteurs de fichiers par défaut, et un processus privilégié peut augmenter lui-même cette limite. C’est une des raisons de lancer HAProxy en tant que root et de lui permettre d’ajuster cette limite. La limite par défaut de 1024 descripteurs de fichiers permet approximativement 500 connexions simultanées. Ce calcul repose sur le paramètre global maxconn, qui limite le nombre total de connexions par processus, le nombre d’écouteurs, le nombre de serveurs ayant un contrôle d’état activé, les vérifications d’agent, les pairs, les enregistreurs et éventuellement quelques autres exigences techniques. Une estimation simple de ce nombre consiste à doubler la valeur de maxconn et à ajouter quelques dizaines pour obtenir une approximation du nombre de descripteurs de fichiers nécessaires.

6. Gestion de la mémoire

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy utilise une gestion mémoire basée sur des pools, simple et rapide. Étant donné qu’il repose sur un nombre réduit de types d’objets différents, il est bien plus efficace de tirer de nouveaux objets depuis un pool déjà contenant des objets de la taille appropriée que d’appeler malloc() pour chaque taille différente. Les pools sont organisés selon une structure de pile ou LIFO, de sorte que les objets nouvellement alloués proviennent d’objets récemment libérés, encore présents dans les caches CPU. Les pools de tailles similaires sont regroupés afin de limiter la fragmentation mémoire.

7. Utilisation du CPU

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy passe normalement la majeure partie de son temps en mode noyau et une part plus faible en mode utilisateur. Un processeur 3,5 GHz correctement optimisé peut supporter un débit d’environ 80 000 établissements et fermetures de connexions bout-en-bout par seconde à 100 % d’utilisation sur un seul cœur. Lorsqu’un cœur est saturé, les valeurs typiques sont :

95 % système, 5 % utilisateur pour des connexions TCP longues ou de grands objets HTTP
85 % système et 15 % utilisateur pour des connexions TCP courtes ou de petits objets HTTP en mode fermé
70 % système et 30 % utilisateur pour de petits objets HTTP en mode keep-alive

Le nombre de règles traitées et d’expressions régulières augmente la partie en espace utilisateur. La présence de règles de pare-feu, du suivi des connexions et de tables de routage complexes dans le système augmente quant à elle la partie noyau.

8. Journalisation

Mon, 01 Jan 0001 00:00:00 +0000

Pour la journalisation, HAProxy s’appuie toujours sur un serveur syslog, car il ne réalise aucune opération sur le système de fichiers. La méthode standard consiste à envoyer les journaux via UDP vers le serveur de journalisation (par défaut sur le port 514). Il est très courant de le configurer sur 127.0.0.1, où s’exécute le démon syslog local, mais il peut aussi être utilisé sur le réseau pour journaliser sur un serveur central. Ce dernier offre des avantages supplémentaires, notamment dans les scénarios actif-actif où il est souhaitable de conserver les journaux fusionnés dans l’ordre d’arrivée. HAProxy peut également utiliser une socket UNIX pour envoyer ses journaux au démon syslog local, mais cela n’est pas recommandé, car si le serveur syslog est redémarré pendant que HAProxy est en cours d’exécution, la socket sera remplacée et les nouveaux journaux seront perdus. Étant donné que HAProxy sera isolé dans une prison chroot, il ne pourra pas se reconnecter à la nouvelle socket. Des observations sur le terrain ont également montré que les tampons utilisés sur les sockets UNIX sont très petits et entraînent la perte de messages même à des charges très faibles. Cela peut toutefois convenir pour les tests.

9. Statistiques et surveillance

Mon, 01 Jan 0001 00:00:00 +0000

Il est possible de consulter l’état de HAProxy. Le mécanisme le plus couramment utilisé est la page de statistiques HTTP. Cette page expose également un format de sortie CSV alternatif destiné aux outils de surveillance. Le même format est disponible via le socket Unix.

Les statistiques sont regroupées par catégories désignées sous le nom de domaines, correspondant aux différents composants d’HAProxy. Deux domaines sont disponibles : proxy et resolvers. Si aucun domaine n’est précisé, le domaine proxy est sélectionné. Notez que seules les statistiques du proxy sont affichées sur la page HTTP.

10. Gestion de configuration simplifiée

Mon, 01 Jan 0001 00:00:00 +0000

Il est très courant que deux nœuds HAProxy constituant un cluster partagent exactement la même configuration, à l’exception de quelques adresses. Au lieu de devoir maintenir une configuration dupliquée pour chaque nœud, ce qui entraînera inévitablement une divergence, il est possible d’inclure des variables d’environnement dans la configuration. Ainsi, plusieurs configurations peuvent partager exactement le même fichier, en ne modifiant que quelques variables d’environnement système. Cette fonctionnalité a été introduite à partir de la version 1.5, où seules les adresses pouvaient inclure des variables d’environnement, et la version 1.6 va plus loin en permettant l’utilisation de variables d’environnement partout. La syntaxe est identique à celle du shell UNIX : une variable commence par un signe dollar (’$’), suivi d’une accolade ouvrante (’{’), puis le nom de la variable, terminé par une accolade fermante (’}’). À l’exception des adresses, les variables d’environnement ne sont interprétées que dans les arguments entourés de guillemets doubles (ce qui était nécessaire pour ne pas rompre les configurations existantes utilisant des expressions régulières impliquant le symbole dollar).

11. Pièges courants à éviter

Mon, 01 Jan 0001 00:00:00 +0000

Parfois, une personne signale que, après un redémarrage du système, le service HAProxy n’est pas démarré automatiquement, et qu’une fois lancé manuellement, il fonctionne correctement. La plupart de ces utilisateurs exécutent un mécanisme d’adresse IP regroupée, comme keepalived, afin d’attribuer l’adresse IP du service uniquement au nœud principal, et alors qu’il fonctionnait auparavant lorsqu’ils liaient HAProxy à l’adresse 0.0.0.0, il a cessé de fonctionner après avoir lié celui-ci à l’adresse IP virtuelle. Ce qui se produit ici, c’est que, lors du démarrage du service, l’adresse IP virtuelle n’est pas encore détenu par le nœud local, si bien que lorsque HAProxy tente de se lier à cette adresse, le système la rejette car elle n’est pas une adresse locale. La solution ne consiste pas à retarder le démarrage du service HAProxy (car cela ne résisterait pas à un redémarrage), mais plutôt à configurer correctement le système afin de permettre la liaison à des adresses non locales. Cela peut être facilement réalisé sous Linux en définissant le paramètre sysctl net.ipv4.ip_nonlocal_bind à 1. Cette configuration est également nécessaire pour intercepter de manière transparente le trafic IP qui traverse HAProxy pour une adresse cible spécifique.

12. Problèmes de débogage et de performance

Mon, 01 Jan 0001 00:00:00 +0000

Lorsque HAProxy est lancé avec l’option “-d”, il reste en premier plan et affiche une ligne par événement, tel qu’une connexion entrante, la fin d’une connexion, ou chaque ligne d’en-tête de requête ou de réponse observée. Cette sortie de débogage est émise avant le traitement des contenus, aussi ne tiennent-elles pas compte des modifications locales. Son usage principal consiste à afficher les requêtes et réponses sans avoir à exécuter un analyseur réseau. La lecture de la sortie devient moins aisée lorsque plusieurs connexions sont gérées en parallèle, mais les scripts “debug2ansi” et “debug2html” présents dans le répertoire examples/ aident certainement dans ce cas en colorant la sortie.

13. Considérations de sécurité

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est conçu pour s’exécuter avec des privilèges très limités. La méthode standard consiste à l’isoler dans une prison chroot et à supprimer ses privilèges pour qu’il s’exécute en tant qu’utilisateur non root, sans aucun droit à l’intérieur de cette prison, afin qu’en cas de découverte d’une vulnérabilité future, son compromis n’affecte pas le reste du système.

Pour effectuer un chroot, il est d’abord nécessaire de le lancer en tant qu’utilisateur root. Il est inutile de créer manuellement des chroots afin de lancer le processus à l’intérieur ; ces environnements sont difficiles à mettre en place, jamais correctement maintenus et contiennent toujours bien plus de bogues que le système de fichiers principal. En cas de compromission, l’attaquant peut exploiter le système de fichiers spécifiquement conçu à cet effet. Malheureusement, de nombreux administrateurs confondent « lancer en tant que root » et « s’exécuter en tant que root », ce qui entraîne le changement d’UID avant le démarrage d’HAProxy, réduisant ainsi les restrictions de sécurité effectives.