Quand j’ai commencé dans le monde de l’administration systèmes il y a plus de deux décennies, mon chemin s’est rapidement orienté vers Linux/GNU et plus précisément Debian. C’était mon approche la plus simple de la philosophie et des concepts derrière les systèmes Unix. Au fil du temps j’ai découvert des systèmes comme OpenBSD pour sa sécurité, NetBSD et FreeBSD (et quelques-uns de ses dérivés notables comme PfSense). Ils m’ont toujours attirés par leur approche plus « pure » du concept KISS intrinsèquement lié à UNIX. Mais l’inertie de l’acquis et l’excellent fonctionnement sous tous ses aspects de Debian ne laissaient pas de place pour m’aventurer dans un usage plus général, au-delà de tâches spécifiques, avec les systèmes BSD. Et puis l’intrusion de systemd est arrivée.
Je ne veux pas entrer dans un débat déjà très discuté et rebattu entre défenseurs et détracteurs de systemd. Chacun a ses arguments pour et contre. J’ai les miens et systemd ne me convient pas. Je l’utilise quotidiennement dans mon travail car il a été introduit de force dans presque tout l’écosystème Linux, mais je lui suis reconnaissant d’avoir été la motivation pour m’aventurer plus sérieusement dans l’utilisation de FreeBSD.
Après de nombreuses années avec Debian et quelques-unes avec FreeBSD, je veux essayer de partager les différences d’un point de vue pratique pour l’administrateur systèmes qui ne vit pas dans un monde utopique et qui a besoin d’avoir le travail fait rapidement et efficacement. Je veux préciser que ce qui est détaillé est toujours du point de vue de l’administration serveur et non d’un environnement de bureau.
Ma première utilisation en production avec FreeBSD (en excluant pfsense) fut l’installation d’un serveur pour héberger divers sites web dans un environnement typiquement PHP et la gestion du courrier pour plusieurs domaines avec protection anti-spam et autres subtilités nécessaires actuellement sur tout serveur SMTP moderne. Le résultat a été très positif et m’a permis d’affronter de front les multiples particularités requises pour maintenir FreeBSD au quotidien. J’ai également un serveur FreeBSD fonctionnel pour les sauvegardes en production profitant des avantages de ZFS. Le résultat également imbattable.
Avec cette introduction, je veux essayer de montrer quelles différences, avantages et inconvénients offre chaque système. Je n’entrerai pas dans les détails sur l’installation, tout administrateur système compétent saura gérer n’importe quel installateur des deux sans aucun problème pour avoir un système de base correctement opérationnel.
Système de base
C’est la première chose que vous trouvez en arrivant à FreeBSD. Il existe une parfaite séparation entre ce que doit être un système complet et fonctionnel de base et les fonctionnalités supplémentaires que vous souhaitez y ajouter. Tout est exquisément bien pensé, on apprécie le bon travail de décennies, c’est un système prévisible, cohérent, sans changements drastiques entre versions et parfaitement documenté avec son propre système de mise à jour indépendant qui fonctionne parfaitement entre les changements de versions mineures et majeures. C’est le rêve de tout administrateur systèmes.
Debian en revanche, comme toute distribution Linux, est un conglomérat d’applications et de bibliothèques avec ses propres utilitaires de gestion + un noyau qui prétendent créer un système cohérent. Et généralement Debian le fait très bien, mais n’atteint pas le niveau de FreeBSD, ni en documentation officielle ni en perfection, avec des changements de fonctionnalités de base entre versions (lisez systemd) rendant compliqué la mise à jour d’un serveur d’une version Debian à une version supérieure. Un autre exemple clair à cet égard sont les outils réseau et les pare-feux avec plusieurs changements drastiques dans les différentes versions de Linux et donc Debian.
Support matériel
L’avantage général de Debian est ici clair, son noyau Linux dispose d’un support beaucoup plus important de la part des fabricants et d’une communauté plus large, ce qui lui donne une plus grande capacité à disposer de pilotes pour différents périphériques. Mais cela sera plus important à prendre en compte pour un usage bureau. Dans le cas des serveurs il n’y aura pratiquement pas de problèmes et la majorité des fournisseurs de serveurs dédiés et cloud/VPS seront compatibles avec FreeBSD. Et si c’est vous qui choisissez le matériel, vérifiez au préalable qu’il est compatible si vous souhaitez l’utiliser avec FreeBSD.
ZFS
Si vous ne connaissez pas ce système de fichiers, vous devriez. Ce n’est pas le système de fichiers universel pour tous les cas, loin de là. Il a ses avantages et inconvénients et cet article n’est pas celui pour parler de ZFS. Mais si vous voulez utiliser ce système de fichiers, actuellement il y a peu de systèmes d’exploitation qui l’intègrent dans leur base aussi magistralement que FreeBSD. ZFS peut également être inclus comme module dans le noyau Linux, même certaines distributions l’intègrent par défaut bien que Debian ait décidé de ne pas le faire en interprétant sa licence comme incompatible.
Mais la question n’est pas si vous pouvez l’utiliser ou non, la question est « comment » et dans ce sens l’avantage de FreeBSD est absolu. Il est parfaitement intégré dans sa base, la mise à jour du système et la documentation.
Virtualisation / Conteneurs / VPS / Cloud
En simplifiant, il existe essentiellement deux options pour avoir un système indépendant de l’hôte/hyperviseur : virtualisation avec noyau indépendant ou conteneurs avec noyau partagé. Les deux cas peuvent être utilisés aussi bien dans Debian que dans FreeBSD.
En ce qui concerne la virtualisation, dans Debian le plus courant est d’utiliser KVM, FreeBSD dispose de Bhyve. Dans ce domaine on peut dire que KVM a actuellement l’avantage d’avoir un plus grand support de la part de la communauté et des grandes entreprises, Bhyve est plus jeune mais avance à bon rythme avec une technologie plus actuelle et peut-être à l’avenir avec de meilleurs résultats que KVM. Personnellement j’ai quelques machines virtualisées dans Bhyve avec Debian installée et je n’ai pas trouvé de problèmes de performance majeurs, ce ne sont pas non plus des machines critiques. L’une d’elles exécute la suite Collabora Online pour Nextcloud qui n’offre pas de moyen simple de l’installer sur FreeBSD.
Mais si nous parlons de conteneurs, la situation s’inverse. Sous Linux il y a eu et il existe de multiples options : Linux-Vservers, OpenVz, lxc, systemd-nspawn, lxd, docker… et bien d’autres encore. J’ai utilisé Linux-Vservers pendant assez d’années, dommage qu’il n’ait pas eu l’attraction nécessaire de la communauté. Sous FreeBSD nous avons les fameux Jails, un vrai joyau parfaitement intégré dans le système (comme c’est habituel dans FreeBSD).
En comparant FreeBSD avec Debian/Linux dans ce cas je vois un avantage pour sa simplicité, facilité et intégration dans le système de base du premier. LXC (avec cgroups, apparmor…) est la technologie sous-jacente pour la plupart des conteneurs et c’est un système complexe qui dépend de l’implémentation de la distribution et vous êtes lié à utiliser systemd que vous le vouliez ou non et les différentes couches de gestion du manager. Je donne ici un avantage clair à FreeBSD, philosophie UNIX et principe KISS. Oui, ensuite il y a Docker qui est très facile sous Linux et peut faciliter la vie de l’administrateur et automatiser les processus… mais ce n’est pas le même objectif qu’un système complet et a ses problèmes de conception.
Applications et système de paquets
C’est une section importante à prendre en compte. Un système de base cohérent est fondamental mais ensuite nous devons ajouter ce qui est nécessaire pour notre objectif. C’est ici qu’il faut mieux peser les avantages et inconvénients de chaque OS.
Debian d’un côté, offre l’un des dépôts les plus larges en termes d’applications. Parmi ses caractéristiques :
- grand nombre d’applications à installer
- les paquets diffèrent de l’original dans leur configuration à la « façon Debian »
- support de sécurité rapide des vulnérabilités
- la version de l’application ne change pas vers de nouvelles versions supérieures et vous restez ancré à la version installée pendant toute la durée de vie de votre version Debian, si vous avez besoin de nouvelles versions vous devez recourir aux « backports » ou à des sources externes à Debian qui ont compilé le paquet pour vous (avec les risques de sécurité que cela peut impliquer) ou vous débrouiller pour compiler vous-même
- pour chaque application il existe différentes versions selon différentes options de compilation (postfix-sqlite, postfix-mysql, postfix-ldap…).
D’un autre côté, FreeBSD s’est historiquement basé sur le système « ports » dans lequel chaque utilisateur « compile » l’application pour son système, les ports sont des Makefile (et un peu plus) qui aident et automatisent cette tâche. Actuellement le système pkg (paquets dérivés des ports avec des options spécifiques) a beaucoup avancé et il est possible d’avoir presque tout installé en binaire. À noter :
- Le nombre de différents ports/packages pour FreeBSD est comparable à celui de Debian et utilise le concept « rolling release » dans lequel ils ne maintiennent pas la même version initiale du paquet en appliquant des correctifs de sécurité mais vont de pair avec la version originale de l’application.
- Il n’existe pratiquement pas et il n’est pas nécessaire le concept de sources tierces externes car vous compilez ce dont vous avez besoin et pouvez facilement créer vos propres dépôts si nécessaire.
- Contrairement à Debian, il n’existe pas de différentes versions du même paquet pour différentes options de compilation, un basique est inclus et si vous avez besoin d’autre chose… vous compilez.
- Pour vous aider à gérer les ports et packages il existe plusieurs outils comme poudriere et synth qui allègent cette tâche mais cela peut encore être fastidieux.
- Si vous utilisez les pkgs précompilés vous pouvez mettre plus de temps à recevoir les mises à jour de sécurité car les ressources de FreeBSD sont moindres et compiler tout pour toutes les plateformes supportées prend du temps.
- Si vous utilisez des paquets binaires vous avez deux dépôts différents : « latest » et « quarterly ». Le premier intègre toujours la dernière mise à jour effectuée dans les ports, surtout de nouvelles versions. « Quarterly » en revanche reste « stable » pendant trois mois sans modifier la version sauf s’il y a un problème de sécurité ou autre problème sérieux, dans ce cas une mise à jour est bien appliquée.
Il est difficile de décider quel système est meilleur dans cet aspect. Voici trois exemples illustratifs gérés avec FreeBSD et Debian : postfix, php, percona.
1. Postfix/Dovecot/Rspamd
Quand j’ai installé mon serveur SMTP pour mes domaines j’ai décidé d’utiliser FreeBSD. Pour ma configuration particulière j’avais besoin de postfix avec support sqlite, de même pour dovecot et aussi des options spécifiques pour rspamd. Sous Debian, par défaut, j’ai le paquet postfix-sqlite de même que pour dovecot. L’installation aurait été directe. Sous FreeBSD en revanche, le pkg compilé par défaut est très basique et pour avoir le support sqlite j’avais besoin de compiler. Pour cela j’ai créé mon propre dépôt avec synth où je maintiens et compile les paquets dont j’ai besoin pour les différents serveurs FreeBSD, de sorte que de façon transparente pour ceux-ci j’utilise toujours des pkgs. L’inconvénient est que cela m’oblige à compiler chaque fois qu’il y a une mise à jour de sécurité, c’est généralement rapide, mais il faut surveiller car on peut finir par compiler jusqu’au dernier paquet du serveur (ils sont tous liés, j’entrerai dans les détails à ce sujet dans un futur post). L’avantage, que pour rspamd l’option dont j’avais besoin n’existait pas dans Debian et il aurait été beaucoup plus fastidieux de compiler et maintenir manuellement sans l’aide d’un système comme les ports/synths/poudriere de FreeBSD.
2. PHP
Avec PHP nous verrons des différences conceptuelles claires entre les deux systèmes de paquets. Généralement, dans un environnement d’hébergement plusieurs versions de PHP cohabitent, même certaines très anciennes et sans support depuis quelques années. Disons que vous voulez avoir disponible de la version 5.6 à la 7.4. Sous Debian, depuis la base, c’est très compliqué, il n’y a qu’une seule version PHP supportée dans la version Debian que vous avez installée, sous Buster par exemple vous devriez vous contenter de php7.3 uniquement, que faites-vous alors ? vous avez besoin d’utiliser une source externe (sury.org), un dépôt externe dans lequel vous faites confiance pour installer des binaires sur votre serveur et qui altruistement se consacre à préparer et compiler différentes versions PHP pour une version Debian spécifique. Sans ce dépôt « altruiste » vous devriez voir pour compiler PHP depuis zéro sans l’aide d’un système comme les ports avec toutes les complications et le temps de maintenance supplémentaire que cela peut impliquer.
FreeBSD en revanche vous offre dans sa liste de paquets toutes les versions PHP actuellement supportées, à la date actuelle les 7.2, 7.3 et 7.4 mais pose d’autres problèmes. Il n’est pas possible de faire cohabiter plusieurs versions PHP (j’ai signalé un bug dans FreeBSD demandant aux responsables du paquet PHP de remédier à ce problème) de sorte que pour utiliser les différentes versions il est nécessaire soit de compiler en modifiant les options dans les ports, soit d’utiliser un « jail » pour chaque version de php-fpm. Pour les versions PHP plus anciennes vous pouvez télécharger le dernier port depuis le dépôt subversion et le compiler facilement, comme il n’y a plus de mises à jour car ce sont des versions non supportées par PHP vous ne devrez compiler qu’une seule fois.
3. Percona MySQL
Il y a quelque temps un client m’a demandé un nouveau serveur avec la dernière version 8 de Percona MySQL. Mon intention initiale était d’installer FreeBSD mais j’ai d’abord vérifié si Percona était disponible. Malheureusement ce n’était pas le cas en version 8, oui les 5.5, 5.6 et 5.7. En théorie je pourrais voir pour télécharger les sources et compiler manuellement sans aide des ports et ainsi de suite… mais à long terme cela aurait posé des inconvénients de maintenance en plus du temps de mise en route initial qui n’auraient pas été couverts par le budget. Pour Debian, Percona n’est pas non plus disponible (dans aucune version) dans sa base mais Percona lui-même fournit un dépôt externe auquel vous devez faire confiance et vous pouvez installer Percona sans problèmes (bien, il y en a eu quelques-uns). Le choix dans ce cas a été clair et montre que le plus grand support des entreprises pour Debian/Linux joue en sa faveur.
Pour terminer cette section avec un concept important dans la configuration de base et l’interaction du système de paquets dans les mises à jour. La configuration par défaut de FreeBSD tend à être proche de la configuration par défaut de l’application laissant une grande partie de la responsabilité de configurer l’app/service à l’administrateur, même dans les mises à jour de services ceux-ci ne sont généralement pas redémarrés par pkg et la plupart du temps une intervention manuelle est nécessaire. Sous Debian cet aspect est beaucoup plus automatisé et les scripts postinstall et preinstall, etc. essaient de minimiser autant que possible et de rendre automatiques les mises à niveau. Le problème est que souvent cela, dans des services et systèmes complexes interconnectés, peut entraîner des erreurs. Vous pouvez contrôler un service automatiquement mais difficilement son interrelation avec de multiples autres facteurs de sorte qu’au final il faut généralement prêter attention aux possibles tâches automatisées que le système de paquets réalisera pour qu’il ne laisse pas votre système KO si vous avez l’intention d’automatiser la mise à niveau sur plusieurs serveurs simultanément. C’est une affaire personnelle, mais j’aime davantage la façon de FreeBSD d’intervenir le moins possible dans le système puisqu’au final vous avez toujours la responsabilité de vérifier que tout se passe correctement.
Sécurité et support à long terme
Pour la maintenance d’un système pendant probablement des années, il est nécessaire qu’il fournisse un support de sécurité et des mises à jour, tant à son système de base qu’à ses applications (même si vous pouvez toujours compiler les applications vous-même). Aussi bien Debian que FreeBSD offrent un temps de support étendu pour une version majeure.
FreeBSD. Selon sa propre page de support/sécurité : « Under the current support model, each major version stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release. » Nous avons donc 5 ans de support garanti pour notre système même s’il faut faire des mises à niveau mineures de la même version majeure.
Debian. Offre un support étendu similaire de 5 ans bien qu’une fois qu’une nouvelle version de Debian a été publiée (généralement avant 5 ans) ce n’est pas Debian directement qui s’occupe du support de sécurité mais un projet parallèle de bénévoles LTS. Il existe également un projet commercial « ELTS » qui fournit un support pour quelques années supplémentaires à une ancienne version Debian mais seulement au système et aux paquets utilisés par les clients de cette entreprise (Freexian) bien que les mises à jour soient ensuite librement disponibles pour toute la communauté Debian.
La différence principale dans les deux supports sont les versions des applications, pour le meilleur et pour le pire. Sous FreeBSD pendant les 5 ans vous utiliserez la dernière version de l’application. Sous Debian les versions ne varient pas et seuls des correctifs de sécurité sont appliqués aux existantes. En 5 ans vous pouvez vous être retrouvé très en retard dans les fonctionnalités ce qui d’autre part peut être intéressant si vous avez une stack stable qui ne nécessite pas de possibles nouvelles incompatibilités introduites par de nouvelles versions. Ce dernier point dans FreeBSD n’est pas non plus critique, par exemple vous pouvez installer python2 ou python3 et ne serez pas forcé de passer à python3.
Maintenance et mises à niveau
Traité en partie dans la section du système de paquets, les mises à niveau du système de base méritent une mention séparée. Ce que j’aime le plus dans FreeBSD c’est la facilité de changer entre versions majeures sans grands problèmes. Comme le système de base est indépendant et que les applications ont une politique « rolling release », le changement entre versions est généralement simple. De plus grâce à l’intégration parfaite avec ZFS, des outils comme beadm vous permettent de faire un snapshot avant la mise à niveau et si quelque chose se passe mal de revenir à la version originale en quelques secondes. Sous Debian en revanche il faut y réfléchir à deux fois avant de passer d’une version majeure à une autre… maintenant init.d ou systemd ? ifconfig ou ip ? systemd-networkd ou etc/network/interfaces ? iptables ou nftables ?…
Performances
Sujet épineux, si vous cherchez sur internet vous trouverez de multiples benchmarks comparant Linux et FreeBSD et encore plus de fanatiques défendant l’un ou l’autre système et franchement peu importe. Les deux systèmes fonctionnent extrêmement bien et avec des performances optimales s’ils sont bien configurés et si les technologies appropriées sont correctement choisies. Si vous faites bien votre travail les performances strictes de l’un ou l’autre seront difficilement le facteur décisif.
Conclusions
La solution parfaite n’existe pas. Avec les arguments présentés de mon expérience et vos propres recherches, choisissez le système qui rend votre vie plus facile et qui s’adapte le mieux à votre objectif.