Tous les articles

AlmaLinux vous donne la plateforme RHEL (même ABI, même cycle de vie de dix ans, même écosystème) gratuitement. Red Hat facture un montant à quatre chiffres par an et par serveur pour l'original. La question intéressante n'est pas laquelle est la moins chère ; c'est ce que l'abonnement achète précisément, et qui en a vraiment besoin. Ce guide détaille la réponse : SLA de support, certifications ISV, patching à chaud et options de cycle de vie d'un côté ; les vrais avantages d'indépendance d'Alma (y compris des pilotes que Red Hat a abandonnés) de l'autre, plus l'option gratuite à 16 systèmes de Red Hat dont la plupart des gens oublient l'existence.

CentOS Linux n'existe plus (CentOS 8 a atteint sa fin de vie fin 2021 et CentOS 7 a suivi à la mi-2024), et CentOS Stream n'est pas un remplaçant à l'identique. Les deux vrais successeurs sont AlmaLinux et Rocky Linux, et depuis 2023 ils ne fonctionnent plus de la même façon sous le capot : AlmaLinux vise la compatibilité ABI avec RHEL, Rocky conserve la parité binaire 1:1. Ce guide explique ce qui les distingue aujourd'hui, donne un verdict selon vos conditions plutôt qu'un « ça dépend », et détaille les vrais chemins de migration (migrate2rocky, almalinux-deploy, et ELevate pour le saut de version majeure depuis CentOS 7), avec la checklist préalable, le mur d'inhibiteurs et le plan de retour arrière.

Un serveur Linux fraîchement installé ne possède aucune règle de pare-feu. Chaque listener que vous démarrez devient instantanément accessible depuis l'ensemble d'Internet. La solution est une base courte et bien comprise : default-deny en entrée, autoriser le trafic established, et une allow-list explicite pour les services que vous faites réellement tourner. Ce guide construit cette base dans nftables règle par règle, explique les points que tout le monde rate (ICMP et IPv6), montre la même politique dans ufw et firewalld, et explique comment éviter de vous verrouiller vous-même dehors, ainsi que le piège de la publication de ports Docker.

Si votre serveur exécute une distro Debian, Ubuntu ou de la famille RHEL à jour, vos règles « iptables » s’exécutent presque certainement déjà à l’intérieur de nftables. La commande iptables est un shim de compatibilité depuis 2019. La vraie question n’est pas de savoir lequel l’emporte ; c’est de savoir si vous devez continuer à écrire des règles dans une syntaxe legacy par-dessus le nouveau moteur. Ce guide couvre ce qui a réellement changé au niveau architectural, une comparaison de syntaxe côte à côte, ce que disent honnêtement les données de performance, et un chemin de migration qui ne casse pas Docker et ne vous enferme pas dehors.

Un serveur dédié Linux vous offre une machine physique entière sans hyperviseur en travers du chemin, mais quelle distribution y faire tourner ? Ubuntu, Debian, les successeurs de CentOS et RHEL font chacun des compromis différents sur la cadence de publication, le support et le coût. Ce guide explique ce qu’est réellement un serveur Linux bare metal, quand il l’emporte sur un VPS ou une instance cloud, et comment choisir une distribution selon la charge de travail et les besoins de support, avec une comparaison côte à côte et des liens vers le serveur adapté à chacune.

Un serveur fraîchement provisionné commence à recevoir des sondes SSH quelques minutes après la mise en ligne de son IP ; les études par honeypot montrent que la plupart des machines exposées sont attaquées en moins d'un jour. La bonne nouvelle : les défenses qui comptent tiennent dans une checklist courte et sans éclat d'une heure, pas dans un projet de recherche en sécurité. Ce guide parcourt les huit étapes dans l'ordre (utilisateurs et clés SSH, base de pare-feu, mises à jour automatiques, fail2ban, synchronisation horaire, audit des services à l'écoute et journalisation) avec les commandes exactes pour Debian/Ubuntu et la famille RHEL, plus une liste honnête de ce à quoi ne pas gaspiller votre première heure.

Trois versions LTS d'Ubuntu sont actuellement en service : la 22.04 approche de la fin de son support standard, la 24.04 traverse ses confortables années intermédiaires, et la nouvelle 26.04 « Resolute Raccoon » arrive avec Linux 7.0. Celle qui convient à votre serveur dépend d'où vous en êtes dans le cycle, et la réponse diffère entre nouveaux déploiements et parcs existants. Ce guide donne le tableau des fenêtres de support, ce qui a réellement changé dans la 26.04 pour les opérateurs de serveurs, les raisons honnêtes de rester sur la 24.04 pour l'instant, et la mécanique de la mise à niveau, y compris le moment où s'ouvre le chemin de LTS à LTS après la 26.04.1.

Ubuntu est construit à partir de Debian, il s'agit donc d'une comparaison entre proches parents : même format de paquet, même système d'init, administration largement identique. Les vraies différences résident dans le rythme des versions, les fenêtres de support, la fraîcheur du noyau et qui se tient derrière les mises à jour : un rythme LTS fixe de deux ans avec une couverture payante optionnelle jusqu'en 2036, contre une version communautaire prête quand elle est prête, et gratuite pour toujours. Ce guide détaille ce que les deux partagent réellement, où ils diffèrent vraiment, et quelles charges de travail serveur favorisent lequel, avec les versions actuelles et les dates de support, pas du folklore.

Debian 12 « bookworm » a discrètement franchi une limite en juin 2026 : le support de sécurité standard a pris fin, et la distribution ne tourne désormais plus que sous le régime LTS. Debian 13 « trixie » a quant à elle mûri au fil de sept révisions mineures, ce qui fait de ce moment le bon pour la mise à niveau sur place. Ce guide couvre la procédure complète pour un serveur de production distant : la liste de vérification préalable (dont le piège du renommage d’interface qui peut couper un serveur distant du réseau en pleine mise à niveau), la mise à niveau elle-même en trois commandes, et les changements propres à trixie à vérifier ensuite : /tmp sur tmpfs, le déplacement de sysctl, et OpenSSH 10.