Services Linux

Catalogue de référence par service/démon systemd : installation, fichiers de configuration, commandes, sécurisation, logs et dépannage.

Ces fiches couvrent l'angle opérationnel (gérer le service en tant que démon systemd). Pour l'usage applicatif approfondi d'un outil qui a déjà son propre cours ailleurs sur ce site (Docker, MariaDB, Ansible...), cette fiche reste volontairement courte et renvoie vers ce cours.

📄️ssh / sshd — Connexion distante sécurisée

sshd est le démon du protocole SSH (Secure Shell), fourni par le paquet openssh-server. Il permet l'administration distante chiffrée d'une machine (shell, transfert de fichiers, tunneling). C'est l'un des services les plus exposés d'un serveur — le port 22 subit en permanence des tentatives automatisées.

📄️cron — Tâches planifiées

cron (démon crond/cron) exécute des commandes à intervalles réguliers définis par une syntaxe de crontab. C'est le planificateur de tâches historique et le plus répandu sous Unix/Linux, alternative plus simple aux timers systemd pour la majorité des usages classiques (sauvegardes, rotation, scripts de maintenance).

📄️atd — Exécution différée de tâches

atd est le démon de la commande at « exécute ceci ce soir à 22h » sans avoir à créer puis supprimer une entrée cron.

📄️systemd-timesyncd — Synchronisation de l'heure

systemd-timesyncd est le client NTP léger intégré à systemd. Il synchronise l'horloge système via SNTP (une version simplifiée de NTP) auprès d'un ou plusieurs serveurs de temps. C'est la solution par défaut sur la plupart des distributions modernes pour un simple poste ou serveur qui n'a pas besoin de la précision ni des fonctions serveur de chrony/ntpd.

📄️chrony / chronyd — Synchronisation NTP

chrony est le paquet, chronyd le démon qu'il fournit : un client et serveur NTP plus précis et plus réactif que systemd-timesyncd, capable de bien gérer les connexions intermittentes (laptops, VM) et de servir l'heure à d'autres machines. C'est le choix par défaut sur RHEL/Fedora et une alternative fréquente à ntpd ailleurs.

📄️ntpd — Serveur NTP

ntpd est l'implémentation historique de référence du protocole NTP (Network Time Protocol), fournie par le paquet ntp. Elle a largement cédé la place à chrony sur les distributions modernes (plus simple à configurer, meilleure gestion des réseaux instables), mais reste présente sur des systèmes plus anciens ou dans des environnements où sa maturité et sa richesse fonctionnelle (authentification, broadcast, référence matérielle GPS/PPS) sont spécifiquement recherchées.

📄️NetworkManager — gestion réseau

Démon de gestion réseau (NetworkManager) orienté postes de travail et machines mobiles : il détecte les interfaces, gère Wi-Fi/Ethernet/VPN et bascule automatiquement entre connexions. Fourni par le paquet network-manager (Debian/Ubuntu) ou NetworkManager (Fedora/Arch), pilotable en CLI via nmcli ou en TUI via nmtui.

📄️systemd-networkd — gestion réseau

Démon de gestion réseau intégré à systemd, orienté serveurs et environnements headless (pas d'interface graphique). Plus léger que NetworkManager, configuré par de simples fichiers .network/.netdev/.link plutôt que via un outil interactif.

📄️systemd-resolved — résolution DNS

Résolveur DNS local de systemd : il centralise la résolution de noms pour tout le système, avec cache, et peut faire du DNS-over-TLS ou du DNSSEC. Il expose une interface D-Bus utilisée par resolvectl (anciennement systemd-resolve) et gère /etc/resolv.conf via un stub.

📄️networkd-dispatcher — actions réseau automatisées

Démon qui surveille les changements d'état réseau rapportés par systemd-networkd (via D-Bus) et exécute des scripts en réaction — l'équivalent, côté systemd-networkd, des scripts dispatcher.d de NetworkManager.

📄️avahi-daemon — découverte réseau mDNS

Implémentation libre de mDNS/DNS-SD (Zeroconf, équivalent de Bonjour d'Apple) mamachine.local) et des annonces multicast.

📄️bluetooth — gestion Bluetooth (BlueZ)

Démon bluetoothd, cœur de la pile BlueZ, la stack Bluetooth standard sous Linux. Gère l'appairage, la connexion et le profil des périphériques Bluetooth (audio, HID, PAN...), exposé via D-Bus et piloté en CLI par bluetoothctl.

📄️ufw — pare-feu simplifié

ufw (Uncomplicated Firewall) est une surcouche à iptables/nftables pensée pour une gestion rapide du pare-feu en ligne de commande, standard sur Debian/Ubuntu.

📄️firewalld — pare-feu dynamique

firewalld est le pare-feu par défaut sur RHEL/Fedora/CentOS. Contrairement à ufw (statique, rechargement complet à chaque changement), il gère les règles dynamiquement (application à chaud, sans couper les connexions existantes) et organise la configuration autour de zones (ensembles de règles associées à une interface ou une source).

📄️nftables — pare-feu Linux

nftables est le successeur moderne d'iptables, intégré au noyau Linux comme moteur de filtrage unifié (remplace aussi ip6tables, arptables, ebtables). C'est le moteur bas niveau que pilotent ufw et firewalld.

📄️fail2ban — protection contre les attaques

fail2ban surveille les fichiers de logs (SSH, HTTP, mail...) et bannit dynamiquement (via le pare-feu) les adresses IP qui multiplient les échecs d'authentification, en réponse au brute force automatisé.

📄️AppArmor — sécurité applicative

AppArmor est un module de sécurité du noyau (LSM) qui confine chaque application à un profil de permissions explicite (fichiers, capacités réseau...), en complément du contrôle d'accès Unix classique (DAC). Par défaut sur Ubuntu/Debian.

📄️SELinux — contrôle d'accès de sécurité

SELinux est, comme AppArmor, un contrôle d'accès obligatoire (MAC) intégré au noyau, mais basé sur un modèle d'étiquettes (contexte de sécurité) appliquées à chaque fichier et processus, plutôt que sur des chemins de fichiers. Standard sur RHEL/Fedora/CentOS.

📄️auditd — audit de sécurité

auditd est le démon d'audit du noyau Linux : il journalise des événements système précis (appels système, accès fichiers, authentifications) selon des règles configurables, indépendamment des logs applicatifs classiques. C'est la source que consultent SELinux (refus AVC) et les outils de conformité (PCI-DSS, CIS Benchmarks).

📄️rsyslog — centralisation des logs

rsyslog est le démon de journalisation syslog historique de la plupart des distributions Linux (successeur de sysklogd). Il reçoit les messages de log du noyau, des applications et de systemd-journald, les filtre/route selon des règles, et les écrit dans des fichiers locaux ou les transmet à un serveur de logs distant. C'est la brique classique de centralisation des logs sur une flotte de serveurs.

📄️systemd-journald — journalisation système

systemd-journald est le service de journalisation intégré à systemd. Il collecte les logs du noyau, des services démarrés par systemd (stdout/stderr inclus), et de l'authentification, dans un format binaire indexé (le journal), consultable avec journalctl. Sur la plupart des distributions modernes, il coexiste avec rsyslog (souvent en amont, rsyslog lisant le journal pour produire des fichiers texte classiques).

📄️logrotate — rotation des logs

logrotate gère la rotation, compression et purge des fichiers de logs texte, pour éviter qu'ils ne grossissent indéfiniment et ne remplissent le disque. Ce n'est pas un démon permanent : il s'exécute périodiquement via un timer systemd (ou une tâche cron), généralement une fois par jour.

📄️sysstat — statistiques système

sysstat est une suite d'outils de collecte et d'analyse de statistiques système (CPU, mémoire, disque, réseau) : sar, iostat, mpstat, pidstat, vmstat-like. Un composant (sadc) collecte les métriques périodiquement en arrière-plan via un timer, ce qui permet ensuite de consulter l'historique de charge d'une machine (pas seulement l'instant présent).

📄️acct (psacct) — comptabilité des processus

acct (nommé psacct sur les distributions RHEL-like) est la comptabilité des processus du noyau Linux : chaque commande exécutée par chaque utilisateur est enregistrée (nom, utilisateur, durée CPU, heure de fin), dans un fichier binaire consultable après coup. Utile en forensics/audit pour répondre à « qui a exécuté quoi et quand » sur une machine.

📄️dbus — Communication entre processus

D-Bus est un bus de messages inter-processus (IPC) qui permet aux applications et aux services système de communiquer entre eux et de s'exposer des méthodes/signaux. Il tourne via le démon dbus-daemon (ou dbus-broker, l'implémentation moderne compatible utilisée par défaut sur beaucoup de distributions récentes) et fait partie du socle sur lequel reposent systemd, polkit, NetworkManager et la plupart des environnements de bureau.

📄️polkit — Autorisation d'actions système

polkit (PolicyKit, démon polkitd) est le système d'autorisation qui décide si un processus non privilégié a le droit de réaliser une action privilégiée (monter un disque, redémarrer la machine, changer la configuration réseau...) sans passer par un sudo complet. Il communique via D-Bus et remplace l'ancien modèle « tout ou rien » de root.

📄️irqbalance — Optimisation des interruptions CPU

irqbalance répartit dynamiquement les interruptions matérielles (IRQ) entre les cœurs CPU disponibles, au lieu de les laisser toutes s'accumuler sur le CPU 0 par défaut. Sur un serveur avec beaucoup de trafic réseau ou d'I/O disque, ça évite qu'un seul cœur devienne un goulot d'étranglement pendant que les autres restent inactifs.

📄️haveged — Génération d'entropie

haveged est un démon qui alimente le pool d'entropie du noyau en exploitant les variations imprévisibles du timing d'exécution du CPU (jitter matériel), quand les sources d'entropie classiques (interruptions clavier/souris/disque) sont insuffisantes — typiquement sur des serveurs headless ou des VM/conteneurs, où le manque d'entropie peut ralentir voire bloquer des opérations cryptographiques au démarrage (génération de clés SSH, TLS...).

📄️rngd — Gestion d'entropie matérielle

rngd (rng-tools) alimente le pool d'entropie du noyau à partir d'une source matérielle de nombres aléatoires : TPM, instruction CPU RDRAND/RDSEED, ou générateur matériel dédié exposé via /dev/hwrng. Contrairement à haveged qui simule de l'aléa via le jitter d'exécution, rngd relaie une source physiquement conçue pour ça — quand elle est disponible et jugée fiable.

📄️tuned — Optimisation système

tuned est un démon d'optimisation système (principalement dans l'écosystème RHEL/Fedora) qui applique dynamiquement des profils de réglages — CPU governor, I/O scheduler, paramètres réseau/sysctl, gestion énergétique — selon le rôle de la machine (serveur, poste de travail, virtualisation, latence réseau...). Il évite de devoir régler manuellement des dizaines de paramètres kernel dispersés.

📄️thermald — Gestion thermique CPU

thermald (Linux Thermal Daemon, Intel) surveille la température du CPU et applique des politiques de limitation (throttling) avant que la protection matérielle d'urgence du processeur ne se déclenche brutalement. Il vise un compromis plus fin entre performance et température qu'une coupure thermique pure et dure — surtout utile sur laptops et machines fanless.

📄️tlp — Gestion énergie des laptops

TLP est un outil de gestion avancée de l'alimentation pour laptops sous Linux : il ajuste automatiquement des dizaines de paramètres (governor CPU, USB autosuspend, gestion PCIe ASPM, seuils de charge batterie...) selon que la machine est sur secteur ou sur batterie, pour maximiser l'autonomie sans intervention manuelle.

📄️cups — Serveur d'impression

CUPS (Common UNIX Printing System) est le système d'impression standard sur Linux/macOS. Il gère les files d'attente, les pilotes (drivers PPD/IPP) et expose une interface web d'administration sur le port 631. Paquet cupsd.

📄️smartmontools / smartd — Surveillance disques SMART

Le paquet smartmontools fournit deux outils : smartctl (interrogation ponctuelle en CLI) et smartd (démon de surveillance continue). Tous deux lisent les attributs S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) exposés par les disques durs et SSD pour anticiper les pannes matérielles.

📄️mdmonitor — Surveillance RAID logiciel (mdadm)

mdmonitor est le démon de surveillance de mdadm, l'outil de gestion du RAID logiciel Linux (md, multiple devices). Il surveille l'état des arrays RAID (dégradation, disque défaillant, reconstruction) et déclenche des alertes.

📄️lvm2-monitor — Surveillance LVM

lvm2-monitor est le service qui active la surveillance des volumes LVM (Logical Volume Manager) par dmeventd — notamment le suivi des volumes miroirs/thin provisionnés et le déclenchement d'actions automatiques (ex : extension d'un pool thin proche de la saturation).

📄️sanoid — Gestion et snapshots ZFS

Sanoid est un outil de politique de snapshots pour ZFS : il automatise la création, la rétention et la purge de snapshots selon des règles (horaire/journalier/hebdomadaire/mensuel), et s'accompagne de Syncoid pour la réplication de ces snapshots vers un autre pool ou une machine distante.

📄️zfs-zed — Événements ZFS

ZED (ZFS Event Daemon) surveille les événements émis par le module noyau ZFS (erreurs de checksum, disque dégradé/absent, fin de scrub/resilver) et déclenche des actions — typiquement l'envoi d'un mail d'alerte.

📄️multipathd — Multipath stockage

multipathd gère le Device Mapper Multipath (DM-Multipath) : quand un serveur accède à un même LUN de stockage (SAN, iSCSI, FC) via plusieurs chemins physiques redondants, multipathd les fusionne en un seul périphérique logique, avec bascule automatique en cas de panne d'un chemin.

📄️iscsid — Stockage iSCSI

iscsid est le démon client iSCSI (Internet SCSI) : il gère les sessions vers des cibles (targets) de stockage distantes exposées sur le réseau IP, faisant apparaître un LUN distant comme un disque local (/dev/sdX).

📄️autofs — Montage automatique

autofs monte automatiquement des systèmes de fichiers (NFS, CIFS/Samba, locaux) à la demande, lors du premier accès à leur point de montage, et les démonte après une période d'inactivité. Évite de garder tous les montages actifs en permanence dans /etc/fstab.

📄️docker / dockerd — Conteneurs Docker

dockerd est le démon (daemon) qui gère les conteneurs, images, réseaux et volumes Docker. Le client docker (CLI) communique avec lui via un socket Unix. Cette fiche couvre uniquement l'angle service systemd ; pour l'usage de Docker au quotidien (images, Dockerfile, Compose), voir les liens en fin de page.

📄️containerd — Runtime de conteneurs

containerd est un runtime de conteneurs bas niveau (projet CNCF), utilisé comme moteur sous-jacent par Docker Engine (depuis la 18.09) et par Kubernetes (via CRI). Cette fiche couvre l'angle service systemd ; pour le fonctionnement détaillé du runtime, voir le lien en fin de page.

📄️podman — Conteneurs sans démon central

Contrairement à Docker, Podman n'a pas de démon permanent : chaque commande podman lance directement les conteneurs via runc/crun, ce qui simplifie le modèle de sécurité (pas de processus root persistant à protéger) et facilite le mode rootless par défaut. Cette fiche couvre l'angle service/socket systemd (API REST optionnelle) ; pour l'usage courant, voir le lien en fin de page.

📄️kubelet — Agent de nœud Kubernetes

kubelet est l'agent qui tourne sur chaque nœud d'un cluster Kubernetes. Il reçoit des spécifications de Pods (via l'API server) et s'assure que les conteneurs correspondants tournent réellement, en pilotant un runtime de conteneurs (containerd, CRI-O) via l'interface CRI.

📄️k3s — Kubernetes léger

k3s (Rancher/SUSE) est une distribution Kubernetes allégée packagée en un unique binaire (< 100 Mo), pensée pour l'edge, l'IoT, le CI et les environnements où un cluster Kubernetes complet (kubeadm) est disproportionné. Il embarque control plane, kubelet et un runtime containerd dans un seul processus par nœud.

📄️lxd — Conteneurs système

LXD est un gestionnaire de conteneurs système (par opposition aux conteneurs applicatifs Docker) : chaque conteneur LXD fait tourner un OS complet avec son propre init, se comportant comme une VM légère mais avec les performances d'un conteneur (namespaces + cgroups, pas d'hyperviseur). Peut aussi gérer des VM via QEMU.

📄️incus — Conteneurs et VM

Incus est le fork communautaire de LXD (Linux Containers project), né en 2023 après le rachat de Canonical/LXD par une gouvernance jugée trop centralisée. Il conserve la même architecture : conteneurs système et VM légères via une API/CLI quasi identique à LXD, mais packagé nativement (pas de dépendance à snap) et maintenu par la communauté Linux Containers.

📄️nginx — Serveur web / reverse proxy

nginx est un serveur web et reverse proxy événementiel (architecture asynchrone, un petit nombre de workers pour un très grand nombre de connexions). Utilisé aussi bien pour servir du contenu statique que comme reverse proxy/load balancer devant des applications (PHP-FPM, Node.js, Gunicorn...).

📄️apache2 — Serveur web Apache

Apache HTTP Server (httpd) est un serveur web historique, à l'architecture modulaire (MPM prefork/worker/event + modules chargeables). Le nom du service et les chemins diffèrent selon la distribution : apache2 sous Debian/Ubuntu, httpd sous RHEL-like (voir httpd pour les spécificités RHEL).

📄️httpd — Apache sur RHEL-like

httpd est le même logiciel Apache HTTP Server que apache2, mais sous son nom de service et sa disposition de fichiers propres aux distributions RHEL-like (RHEL, Fedora, CentOS, Rocky, Alma). Cette fiche se limite aux différences ; pour le fonctionnement général d'Apache, voir la fiche apache2.

📄️haproxy — Load balancer / proxy

HAProxy est un répartiteur de charge et proxy TCP/HTTP haute performance, référence dans les infrastructures à haute disponibilité (répartition entre plusieurs backends, health checks, terminaison TLS).

📄️Traefik — Reverse proxy / ingress

Traefik est un reverse proxy moderne conçu pour les environnements dynamiques (Docker, Kubernetes) : il découvre automatiquement les services via des providers (Docker labels, fichiers, Kubernetes Ingress/CRD) et met à jour son routage sans redémarrage.

📄️Caddy — Serveur web / HTTPS automatique

Caddy est un serveur web/reverse proxy dont l'argument phare est le HTTPS automatique : il obtient et renouvelle seul des certificats Let's Encrypt (ou ZeroSSL) pour chaque domaine configuré, sans intervention manuelle (certbot intégré nativement).

📄️Squid — Proxy HTTP

Squid est un proxy HTTP/HTTPS sortant (forward proxy) : les clients d'un réseau passent par lui pour accéder à Internet. Sert au filtrage d'accès web, à la mise en cache de contenu, et à la journalisation centralisée du trafic web sortant en entreprise.

📄️Varnish — Cache HTTP

Varnish est un cache HTTP inverse (HTTP accelerator) placé devant un serveur web/applicatif : il met en cache les réponses en mémoire pour absorber le trafic répétitif et soulager le backend, avec un langage de configuration dédié (VCL, Varnish Configuration Language) très flexible.

📄️php-fpm — Exécution PHP

PHP-FPM (FastCGI Process Manager) est le gestionnaire de processus PHP utilisé pour exécuter du code PHP derrière un serveur web (Nginx, Apache). Il remplace l'ancien module mod_php en exécutant PHP dans des processus séparés, gérés par un pool, communiquant via FastCGI (socket Unix ou TCP). C'est le standard actuel pour servir des applications PHP (WordPress, Symfony, Laravel...).

📄️Node.js — Service applicatif

Node.js n'a pas de paquet "service" packagé comme php-fpm ou tomcat : une application Node.js (app.js, serveur Express...) tourne comme un simple processus. Pour la gérer proprement en production (démarrage au boot, redémarrage automatique, logs centralisés), on l'encapsule dans une unit systemd personnalisée.

📄️Gunicorn — Serveur Python WSGI

Gunicorn (Green Unicorn) est un serveur d'applications Python implémentant l'interface WSGI (Web Server Gateway Interface), utilisé pour exécuter des applications Django, Flask, etc. en production. Comme php-fpm pour PHP, il se place derrière un reverse proxy (nginx) qui gère TLS et le trafic statique.

📄️uWSGI — Serveur d'applications Python

uWSGI est un serveur d'applications multi-protocole et multi-langage, le plus souvent utilisé côté Python via l'interface WSGI — un concurrent direct de Gunicorn, plus riche en fonctionnalités (multi-langage, protocole uwsgi natif optimisé, gestion avancée des workers) mais aussi plus complexe à configurer.

📄️Tomcat — Serveur Java

Apache Tomcat est un conteneur de servlets Java (implémentation de référence des spécifications Jakarta Servlet/JSP), utilisé pour déployer des applications web Java packagées en WAR. C'est l'un des deux standards historiques du domaine avec Jetty, plus lourd mais très répandu en entreprise.

📄️Jetty — Serveur Java

Jetty (Eclipse Foundation) est un serveur web et conteneur de servlets Java, alternative à Tomcat réputée plus légère et plus simple à embarquer directement dans une application (usage courant : embarqué dans des outils comme SonarQube ou Solr plutôt que déployé comme serveur autonome).

📄️PostgreSQL — base de données relationnelle

PostgreSQL est un SGBD relationnel open source avancé (conformité SQL étendue, extensions comme PostGIS/pgvector, MVCC natif). Le service tourne via le démon postgres (paquet postgresql), géré par systemd. Cette fiche couvre l'angle service — pour la syntaxe SQL elle-même, voir les cours SQL de ce site.

📄️MySQL — base de données relationnelle

MySQL est un SGBD relationnel open source (racheté par Oracle), historiquement l'un des plus utilisés pour les applications web (stack LAMP). Le démon mysqld est géré par systemd sous le nom de service mysql. Cette fiche couvre l'angle service — pour la syntaxe SQL, voir les cours SQL de ce site. Sur la plupart des distributions récentes, mysql a été remplacé par le fork MariaDB (voir 065-mariadb.md), qui garde la compatibilité protocolaire.

📄️MariaDB — base de données relationnelle

MariaDB est le fork communautaire de MySQL (créé après le rachat de MySQL par Oracle), compatible protocole et largement adopté par défaut sur Debian/RHEL. Un cours dédié existe déjà sur ce site pour l'usage SQL/administration approfondie : MariaDB — cours complet. Cette fiche reste volontairement courte et couvre uniquement l'angle service/démon.

📄️MongoDB — base de données NoSQL orientée documents

MongoDB est un SGBD NoSQL orienté documents (stockage BSON/JSON), sans schéma rigide, conçu pour la scalabilité horizontale (sharding) et les charges applicatives modernes. Le démon mongod est géré par systemd.

📄️Cassandra — base NoSQL distribuée

Cassandra est un SGBD NoSQL distribué en pair-à-pair (pas de nœud maître), conçu pour la haute disponibilité et la scalabilité horizontale massive, avec un modèle de cohérence ajustable (tunable consistency). Utilisé pour des volumes très importants nécessitant une tolérance aux pannes multi-datacenter.

📄️InfluxDB — base de données orientée métriques

InfluxDB est une base de données time-series (séries temporelles), optimisée pour l'ingestion à haut débit et l'interrogation de métriques horodatées (monitoring, IoT, capteurs). Souvent associée à Telegraf (collecte) et Grafana (visualisation) dans la stack TICK.

📄️etcd — base clé-valeur distribuée

etcd est un magasin clé-valeur distribué et fortement cohérent, basé sur l'algorithme de consensus Raft. Il sert de source de vérité pour la configuration et l'état de systèmes distribués — c'est notamment le datastore central de Kubernetes (tous les objets du cluster y sont stockés).

📄️Redis — cache / base clé-valeur

Redis est un moteur de stockage clé-valeur en mémoire, utilisé comme cache, broker de messages léger (pub/sub) ou base de données rapide pour des structures simples (strings, listes, sets, hashes, sorted sets). Binaire principal : redis-server, package redis (ou redis-server sur Debian/Ubuntu).

📄️Memcached — cache mémoire

Memcached est un cache clé-valeur en mémoire, volontairement minimaliste : pas de persistance, pas de structures de données riches (juste des chaînes d'octets), mais très rapide et multi-thread nativement. Utilisé classiquement pour cacher des résultats de requêtes SQL ou des fragments de page web.

📄️RabbitMQ — message broker

RabbitMQ est un message broker implémentant principalement le protocole AMQP rabbitmq-server.

📄️Kafka — streaming / messaging

Kafka est une plateforme de streaming distribué : les producteurs publient des messages dans des topics partitionnés, les consommateurs les lisent (à leur rythme, avec relecture possible), le tout avec une forte capacité de débit et de rétention. Utilisé pour l'ingestion de logs, les pipelines d'événements, l'intégration de systèmes découplés.

📄️ZooKeeper — coordination distribuée

ZooKeeper est un service de coordination distribuée : configuration partagée, élection de leader, verrous distribués, découverte de service. Longtemps utilisé comme dépendance obligatoire de Kafka (avant le mode KRaft) et d'autres systèmes distribués (HBase, Solr).

📄️Elasticsearch — recherche / indexation

Elasticsearch est un moteur de recherche et d'indexation distribué, basé sur Lucene, piloté via une API REST/JSON. Utilisé pour la recherche full-text, l'analyse de logs (souvent dans une stack ELK avec Logstash/Filebeat et Kibana), et l'analytics en quasi temps réel.

📄️OpenSearch — recherche / analyse

OpenSearch est un fork open source d'Elasticsearch, créé par AWS en 2021 après le passage d'Elasticsearch à une licence non-OSI (SSPL/Elastic License). API et fonctionnement très proches d'Elasticsearch (compatibilité largement conservée sur les versions initiales), sous licence Apache 2.0.

📄️bind9 / named — Serveur DNS BIND

BIND (Berkeley Internet Name Domain, paquet bind9) est le serveur DNS open source de référence, utilisable en autoritaire (héberger des zones) ou en résolveur/cache. Le démon s'appelle named — c'est le même logiciel, bind9 étant le nom du paquet (Debian/Ubuntu) et named le nom du service/binaire (partout, y compris RHEL-like où le paquet s'appelle bind).

📄️dnsmasq — DNS / DHCP léger

dnsmasq combine un serveur DNS cache/forwarder, un serveur DHCP et un serveur TFTP en un seul démon léger. Très utilisé sur les petits réseaux (LAN domestique, labo, routeurs embarqués/OpenWRT) là où BIND/ISC-DHCP seraient surdimensionnés.

📄️unbound — Résolveur DNS

unbound est un résolveur DNS récursif et validant (contrairement à BIND, il ne fait pas d'autoritaire) derrière un Pi-hole, ou pour éviter de dépendre d'un résolveur tiers).

📄️kea-dhcp4-server — Serveur DHCP moderne (ISC Kea)

Kea est le successeur officiel d'ISC-DHCP (voir isc-dhcp-server/dhcpd, désormais en fin de vie). Architecture modulaire (démons séparés IPv4/IPv6/DDNS), configuration en JSON, API REST de contrôle (kea-ctrl-agent), et hooks extensibles — pensé pour l'intégration avec des outils modernes (bases de données pour les baux, automatisation).

📄️isc-dhcp-server / dhcpd — Serveur DHCP historique ISC

isc-dhcp-server est le nom du paquet (Debian/Ubuntu) qui fournit le démon dhcpd, longtemps LE serveur DHCP de référence sous Linux. ISC a officiellement mis fin de vie ce projet fin 2022 au profit de Kea, son successeur — encore largement déployé en production existante, mais à éviter pour un nouveau déploiement.

📄️Postfix — serveur SMTP

Postfix est un agent de transfert de courrier (MTA) open source, conçu comme une alternative plus simple et plus sûre à Sendmail. C'est le MTA le plus utilisé sur les serveurs Linux modernes, pour l'envoi/réception de mails (relais SMTP applicatif, ou serveur mail complet couplé à Dovecot).

📄️Exim4 — serveur SMTP

Exim (paquet exim4 sur Debian/Ubuntu) est un agent de transfert de courrier (MTA), historiquement le MTA par défaut de Debian. Il se distingue de Postfix par un fichier de configuration unique très flexible (règles de routage/ACL explicites) plutôt que de multiples fichiers dédiés — plus puissant mais réputé plus complexe à lire.

📄️Dovecot — serveur IMAP/POP3

Dovecot est un agent de livraison de courrier (MDA) qui expose les boîtes mail aux clients via IMAP et POP3. Il complète un MTA comme Postfix ou Exim4 : le MTA reçoit/route le mail, Dovecot le stocke et le sert au client (Thunderbird, Outlook, webmail...).

📄️OpenDKIM — signature DKIM

OpenDKIM signe (et vérifie) les emails sortants avec DKIM (DomainKeys Identified Mail) : une signature cryptographique ajoutée à l'en-tête du mail, vérifiable via une clé publique publiée en DNS. Avec SPF et DMARC, c'est un des trois piliers de l'authentification email moderne — indispensable pour ne pas finir en spam.

📄️ClamAV (clamav-daemon) — antivirus

ClamAV est un moteur antivirus open source, largement utilisé pour scanner les pièces jointes des mails (intégré à Postfix/Dovecot via milter/Sieve), les fichiers uploadés sur un serveur web, ou en scan à la demande. clamav-daemon (clamd) est le démon qui garde la base de signatures en mémoire pour scanner rapidement sans recharger à chaque exécution.

📄️vsftpd — Serveur FTP

vsftpd (Very Secure FTP Daemon) est un serveur FTP léger et orienté sécurité, très répandu comme alternative simple à Samba/NFS quand le client ne parle que FTP. Le protocole FTP transmet les identifiants en clair par défaut — vsftpd supporte FTPS (FTP sur TLS) pour corriger ça.

📄️proftpd — Serveur FTP

ProFTPD est un serveur FTP alternatif à vsftpd, plus modulaire : configuration proche de la syntaxe Apache (blocs `, ), support de modules (modtls, modsql pour authentifier contre une base de données, mod_vroot...), et possibilité de fichiers de config par répertoire (comme .htaccess`).

📄️smbd — Partage SMB/Samba

smbd est le démon principal de Samba, qui implémente le protocole SMB/CIFS : il permet à une machine Linux de partager des fichiers/imprimantes avec des clients Windows (et Linux/macOS, qui parlent aussi SMB). C'est le pendant Linux d'un partage réseau Windows. smbd gère l'accès aux fichiers/impression ; la résolution de noms NetBIOS est gérée par nmbd, et l'intégration à un domaine Active Directory par winbind.

📄️nmbd — NetBIOS Samba

nmbd est le second démon de la suite Samba : il gère la résolution de noms NetBIOS et l'annonce du serveur dans le voisinage réseau (Network Neighborhood/Explorateur réseau côté Windows), en implémentant le protocole NBNS (NetBIOS Name Service, équivalent WINS). Sur les réseaux modernes où la résolution de noms passe par DNS et où NetBIOS est désactivé côté clients Windows récents, nmbd devient optionnel — mais reste nécessaire pour la compatibilité avec du matériel/logiciel ancien.

📄️winbind — Intégration Windows/AD

winbind (démon winbindd, suite Samba) permet à une machine Linux de s'intégrer à un domaine Active Directory : il traduit les utilisateurs/groupes Windows en identités Unix (UID/GID), permettant l'authentification AD sur des services Linux (login système, Samba, sudo...) via PAM/NSS.

📄️nfs-server — Partage NFS

NFS (Network File System) est le protocole de partage de fichiers natif du monde Unix/Linux — plus simple et performant qu'SMB pour des clients Linux, mais avec un modèle de sécurité historiquement plus faible (authentification par IP/UID côté client, pas par mot de passe, sauf ajout de Kerberos). NFSv3 dépend de rpcbind pour la découverte de services ; NFSv4 en a beaucoup moins besoin (port unique 2049).

📄️rpcbind — RPC / NFS

rpcbind est un service d'annuaire pour les programmes ONC RPC (Open Network Computing Remote Procedure Call) NFS, NIS) en port TCP/UDP effectivement utilisé, ces derniers étant attribués dynamiquement. C'est un prérequis historique de NFSv3. NFSv4 s'en passe largement (port fixe 2049), ce qui simplifie beaucoup le filtrage réseau.

📄️tftpd-hpa — Serveur TFTP

TFTP (Trivial File Transfer Protocol) est un protocole de transfert de fichiers minimaliste, sans authentification, utilisé pour le boot réseau (PXE), le chargement de firmwares sur des équipements réseau (switches, routeurs), ou la sauvegarde de configurations Cisco/autres. tftpd-hpa est l'implémentation serveur la plus courante sous Debian/Ubuntu.

📄️libvirtd — virtualisation KVM/libvirt

libvirtd est le démon central de la stack libvirt, qui fournit une API unifiée pour piloter des hyperviseurs (principalement KVM/QEMU sous Linux, mais aussi Xen, LXC...). C'est la brique sur laquelle s'appuient virsh, virt-manager, et des outils d'infra comme Terraform (provider libvirt) ou OpenStack.

📄️virtlogd — logs des machines virtuelles

virtlogd est un démon auxiliaire de la stack libvirt dédié exclusivement à la gestion des logs de sortie console des machines virtuelles QEMU. Il a été séparé de libvirtd pour que les logs de VM survivent à un redémarrage du démon principal (libvirtd --reload, mise à jour...) sans interrompre la capture.

📄️virtlockd — verrouillage des disques de VM

virtlockd est le démon de verrouillage de la stack libvirt : il empêche qu'un même disque de machine virtuelle soit démarré simultanément par deux instances de libvirtd (par exemple sur deux hôtes différents partageant un stockage réseau), ce qui corromprait le disque. Comme virtlogd, il est séparé de libvirtd pour survivre à ses redémarrages et garder les verrous actifs.

📄️qemu-guest-agent — communication VM ↔ hyperviseur

Contrairement aux autres fiches de ce lot, qemu-guest-agent tourne à l'intérieur de la VM invitée (pas sur l'hôte). Il fournit un canal de communication (via un port série virtio) entre l'hyperviseur et l'invité, permettant à l'hôte de demander des actions coordonnées : gel du système de fichiers avant un snapshot, arrêt propre, récupération de l'IP réelle de la VM, etc.

📄️OpenVPN — VPN

OpenVPN est une solution de VPN mature basée sur TLS (via OpenSSL), fonctionnant en mode routé (TUN, couche 3) ou pont (TAP, couche 2). Historiquement le standard de facto avant l'arrivée de WireGuard, encore très répandu pour sa flexibilité (authentification par certificats, intégration LDAP/RADIUS, traversée de proxy HTTP).

📄️wg-quick — WireGuard

WireGuard est un VPN moderne intégré au noyau Linux depuis 5.6, reposant sur une cryptographie fixe et moderne (Curve25519, ChaCha20-Poly1305) plutôt que sur la négociation TLS d'OpenVPN. Résultat : configuration minimaliste, performances nettement supérieures, code source très réduit (donc plus auditable). wg-quick est le script/service qui monte une interface WireGuard à partir d'un fichier de config.

📄️strongSwan — VPN IPsec

strongSwan est une implémentation complète d'IPsec/IKEv2 pour Linux, très utilisée pour les VPN site-à-site en entreprise et l'accès distant (compatible clients natifs iOS/Android/Windows IKEv2, sans logiciel tiers). C'est la brique déjà utilisée dans le cours VPN via nmcli de ce site — cette fiche couvre l'angle service systemd natif (sans passer par NetworkManager), utile pour un serveur ou un tunnel site-à-site permanent.

📄️ipsec — service historique de gestion IPsec

ipsec désigne à la fois la commande et, historiquement, le service (ipsec.service, via le script starter) utilisé pour piloter une pile IPsec sous Linux — fourni aussi bien par strongSwan que par son cousin Libreswan. C'est l'interface historique, progressivement remplacée par swanctl côté strongSwan (voir strongSwan) mais encore très répandue en production, notamment sur les configurations existantes et sur Libreswan.

📄️keepalived — haute disponibilité / VRRP

keepalived implémente le protocole VRRP (Virtual Router Redundancy Protocol) sous Linux basculement automatique d'un reverse proxy, d'un routeur ou d'un load balancer sans intervention manuelle.

📄️corosync — couche de communication cluster

corosync fournit la couche de communication et de membership d'un cluster Linux il informe pacemaker de l'état du cluster.

📄️pacemaker — gestion de cluster HA

pacemaker est le gestionnaire de ressources d'un cluster haute disponibilité Linux : il décide où et quand démarrer/arrêter/déplacer des ressources (IP virtuelle, service, montage disque...) en fonction de l'état du cluster. Il s'appuie sur corosync pour connaître le membership et la communication inter-nœuds — les deux fonctionnent toujours ensemble.

📄️Consul — service discovery / configuration

Consul (HashiCorp) est un outil de service discovery, de health checking et de stockage clé-valeur distribué, utilisé pour permettre à des services répartis de se trouver dynamiquement les uns les autres (au lieu d'IP en dur) et de vérifier leur santé en continu. Souvent utilisé comme brique d'infrastructure pour du microservices/mesh réseau.

📄️Vault — gestion de secrets

Vault (HashiCorp) est un serveur de gestion centralisée de secrets : mots de passe, tokens API, certificats, clés de chiffrement. Il gère leur stockage chiffré, leur accès contrôlé par politique, leur rotation et leur expiration automatique (leases).

📄️Prometheus — monitoring / métriques

Système de monitoring et de base de données de séries temporelles (TSDB) open source, devenu le standard de facto de l'observabilité cloud-native. Fonctionne en pull : il va lui-même récupérer (scrape) les métriques exposées en HTTP par les cibles, plutôt que d'attendre qu'elles les lui envoient. Binaire prometheus, paquet prometheus.

📄️Grafana — visualisation des métriques

Plateforme de visualisation et de dashboards pour des sources de données de métriques et de logs (Prometheus, InfluxDB, Elasticsearch, MySQL...). Ne collecte rien elle-même : elle interroge les sources configurées et affiche des tableaux de bord. Paquet/service grafana-server.

📄️node_exporter — export métriques Linux

Agent officiel de l'écosystème Prometheus qui expose les métriques matérielles et système d'une machine Linux (CPU, mémoire, disque, réseau) sur un endpoint HTTP /metrics, au format texte Prometheus. Ne fait rien d'autre que collecter et exposer — c'est Prometheus qui vient le scraper. Binaire node_exporter.

📄️zabbix-agent — agent Zabbix

Agent installé sur chaque machine surveillée par une plateforme Zabbix : il collecte des métriques locales (CPU, mémoire, disque, process, logs) et les transmet au zabbix-server, soit en passif (le serveur interroge l'agent), soit en actif (l'agent envoie lui-même ses données, plus adapté aux gros parcs). Paquet zabbix-agent (ou zabbix-agent2, version moderne réécrite en Go avec support de plugins).

📄️zabbix-server — serveur Zabbix

Serveur central de la plateforme de supervision Zabbix : reçoit les métriques des zabbix-agent déployés sur le parc, les stocke en base (MySQL/PostgreSQL), évalue les déclencheurs (triggers) et génère les alertes. S'accompagne généralement d'un frontend web (zabbix-frontend-php) pour la configuration et les dashboards.

📄️Nagios — monitoring

Système de supervision historique (fin des années 90), toujours largement déployé. Fonctionne par plugins : chaque vérification (état d'un service, seuil CPU, ping...) est un exécutable indépendant qui retourne un code de sortie standardisé (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN) et un texte. Nagios orchestre ces checks selon une configuration déclarative d'hôtes et de services.

📄️Telegraf — collecte de métriques

Agent de collecte de métriques de l'écosystème InfluxDB (le "T" de la stack TICK), à l'architecture pilotée par plugins : plugins d'input (système, Docker, MySQL, MQTT...), de processing, et d'output (InfluxDB, Prometheus, Kafka...). Contrairement à node_exporter (passif, attend le scrape), Telegraf pousse activement les métriques vers ses destinations.

📄️ntopng — surveillance réseau

Outil d'analyse de trafic réseau en temps réel (successeur de ntop) : capture le trafic sur une ou plusieurs interfaces et présente une interface web avec le détail des flux, hosts, protocoles et volumes. S'appuie sur libpcap/PF_RING pour la capture.

📄️snmpd — agent SNMP

Agent SNMP (Simple Network Management Protocol, Net-SNMP) qui expose l'état d'une machine (CPU, mémoire, interfaces réseau, process) à des outils de supervision tiers (Zabbix, PRTG, LibreNMS...) via des requêtes SNMP GET/WALK sur des OID standardisés (MIB). Très répandu pour la supervision d'équipements réseau (switches, routeurs) et de serveurs.

📄️snmptrapd — réception de traps SNMP

Démon Net-SNMP qui reçoit les traps SNMP — des notifications poussées spontanément par un équipement (routeur, switch, onduleur...) lors d'un événement (lien down, seuil dépassé) — à la différence de snmpd qui répond à des requêtes de polling. Complète une supervision par polling avec de l'événementiel quasi temps réel.

📄️Filebeat — collecte de logs

Filebeat (Elastic) est un agent léger de collecte de logs : il surveille des fichiers de log (ou d'autres sources) sur une machine et transmet leur contenu vers Logstash, Elasticsearch ou Kafka. C'est le "Beat" le plus utilisé de la suite Elastic Beats — conçu pour être minimal en ressources et fiable (il retient sa position de lecture, pas de perte en cas de redémarrage).

📄️Logstash — traitement de logs

Logstash (Elastic) est un pipeline de traitement de logs : il reçoit des événements (souvent depuis Filebeat ou Kafka), les parse/transforme/enrichit (grok, filtres), puis les envoie vers une destination (typiquement Elasticsearch). Plus lourd que Filebeat, c'est la brique de transformation de la stack "ELK" (Elasticsearch, Logstash, Kibana).

📄️Fluentd — collecte de logs

Fluentd est un collecteur/routeur de logs unifié, alternative à la stack Filebeat/Logstash : il agrège des logs depuis de multiples sources, les structure en JSON, et les route vers une ou plusieurs destinations (Elasticsearch, S3, Kafka...). Très utilisé dans l'écosystème Kubernetes (projet CNCF) comme agent de collecte par nœud.

📄️rsync — synchronisation de fichiers

rsync synchronise des fichiers/dossiers en ne transférant que les différences. Il s'utilise dans deux modes : en commande ponctuelle via SSH (le plus courant, déjà détaillé dans le cours réseau Linux et les bases Linux), ou en démon rsyncd exposant un service réseau dédié (port TCP 873) — c'est cet angle service que couvre cette fiche.

📄️borgmatic — orchestrateur de sauvegardes Borg

borgmatic est une surcouche de configuration et d'orchestration autour de BorgBackup, l'outil de sauvegarde à déduplication et chiffrement. Il gère la planification, la rétention et les hooks (avant/après sauvegarde) via un simple fichier YAML, là où Borg seul s'utilise en ligne de commande.

📄️restic — sauvegardes chiffrées et dédupliquées

restic est un outil de sauvegarde moderne, écrit en Go, qui chiffre et déduplique les données et supporte de nombreux backends de stockage (local, SFTP, S3/MinIO, Backblaze B2, Azure...). Contrairement à Borg/borgmatic, il s'utilise généralement en une seule commande sans démon dédié, planifiée via cron ou un timer systemd.

📄️Bacula — sauvegarde centralisée

Bacula est une solution de sauvegarde réseau centralisée de niveau entreprise, organisée en plusieurs démons : le Director (orchestration, planification), le Storage Daemon (écriture sur le support de stockage) et le File Daemon (agent installé sur chaque machine à sauvegarder). Adapté à la sauvegarde de parcs de machines hétérogènes depuis un point de contrôle unique.

📄️Bareos — sauvegarde réseau (fork de Bacula)

Bareos (Backup Archiving Recovery Open Sourced) est un fork communautaire de Bacula, créé en 2010 quand une partie des développeurs de Bacula a souhaité continuer sous licence pleinement libre (AGPL) avec un développement ouvert, face à une version Bacula de plus en plus orientée vers l'offre commerciale de son éditeur. L'architecture reprend le même modèle à trois démons (Director, Storage Daemon, File Daemon) et une bonne partie de la syntaxe de configuration est compatible.

📄️MinIO — stockage objet compatible S3

MinIO est un serveur de stockage objet auto-hébergé, compatible avec l'API S3 d'Amazon. Il permet d'exposer un backend S3 sur sa propre infrastructure — utile comme cible de sauvegarde (restic, borgmatic...), stockage d'artefacts CI/CD, ou backend objet pour des applications qui parlent S3 nativement.

📄️Nextcloud — cloud privé auto-hébergé

Nextcloud est une plateforme de cloud privé auto-hébergée (fichiers, partage, calendrier, contacts, et de nombreuses applications additionnelles). Techniquement, ce n'est pas un service systemd unique mais une application PHP qui tourne derrière un serveur web (nginx ou apache2) via php-fpm, avec une base de données (postgresql, mariadb ou MySQL) et éventuellement Redis pour le cache/verrouillage.

📄️Syncthing — synchronisation de fichiers pair-à-pair

Syncthing synchronise des dossiers en continu entre plusieurs machines sans serveur central : chaque nœud communique directement avec les autres (P2P, chiffré), à la manière d'un Dropbox auto-hébergé et décentralisé. Contrairement à Nextcloud, il n'y a pas de "serveur" au sens strict — chaque instance est un pair égal aux autres.

📄️Jenkins — serveur CI/CD

Jenkins est un serveur d'intégration et de déploiement continu (CI/CD) open source, historiquement l'un des plus utilisés. Il orchestre des jobs (pipelines) déclenchés par des événements (push Git, planification, webhook) et délègue l'exécution à des agents (voir jenkins-agent).

📄️Jenkins Agent — nœud d'exécution

Un agent Jenkins (autrefois « slave ») est un nœud distinct du serveur Jenkins qui exécute réellement les étapes des jobs (build, tests, déploiement). Le serveur reste le contrôleur (planification, UI, stockage des résultats), l'agent apporte la puissance de calcul et l'isolation par machine/environnement.

📄️GitLab Runner — agent CI/CD

GitLab Runner est l'agent qui exécute les jobs définis dans .gitlab-ci.yml pour GitLab CI/CD. Contrairement à Jenkins (serveur + agents séparés), GitLab Runner est autonome : il s'enregistre auprès d'une instance GitLab (SaaS ou self-hosted) et exécute les jobs qu'elle lui assigne, généralement dans des conteneurs éphémères (executor Docker/Kubernetes).

📄️SonarQube — analyse de code

SonarQube est une plateforme d'analyse statique de code : qualité, bugs, vulnérabilités, dette technique et couverture de tests, avec un tableau de bord centralisé. Il s'intègre typiquement dans un pipeline CI (Jenkins, GitLab CI) via le sonar-scanner, qui envoie les résultats d'analyse au serveur.

📄️Rundeck — automatisation d'administration

Rundeck est une plateforme d'automatisation opérationnelle : elle expose des scripts/commandes d'administration (redémarrage de service, déploiement, tâche de maintenance) sous forme de jobs exécutables via une interface web, une API, ou une planification (cron intégré), avec contrôle d'accès et traçabilité (qui a lancé quoi, quand).

📄️ansible-pull — Ansible en mode agent

ansible-pull inverse le modèle habituel d'Ansible : au lieu qu'un contrôleur pousse (push, SSH) une configuration vers des machines cibles, chaque machine récupère elle-même (pull) un playbook depuis un dépôt Git et l'applique en local. Utile pour du bootstrap (cloud-init), des flottes très larges, ou des environnements où le contrôleur ne peut pas joindre les machines en SSH entrant. Pour la syntaxe des playbooks eux-mêmes, voir le cours Ansible — cette fiche se concentre sur la mise en service périodique via systemd.