Motivation initiale: ZFS

FreeBSD est un système d’exploitation « Unix-like ». Alors que j’utilise Linux depuis 2001, j’ai découvert FreeBSD récemment, soit il y a environ 2 ans. Ce qui m’a attiré initialement c’est la compatibilité avec le système de fichiers évolué ZFS, que j’ai appris à connaître à mon travail via Oracle Solaris et dont la maturité ne semble à point que sur FreeBSD et les « forks » d’OpenSolaris, si on exclue le système propriétaire d’Oracle. Ayant des données précieuses que je ne veux pas perdre et ayant déjà subit de la corruption silencieuse dans celles-ci, je voulais le système de fichiers le plus robuste possible. ZFS, en plus de cela, comporte plusieurs caractéristiques intéressantes comme la gestion de RAID logiciel avec « self healing », un mécanisme de clichés instantanés, la possibilité de compresser les données, des outils de gestion très intuitifs, etc. Son seul compétiteur sérieux se trouve sur Linux sous le nom de BTRFS mais ce système de fichiers n’a définitivement pas atteint la maturité dont fait preuve ZFS depuis plusieurs années et, pour l’avoir essayé, est plutôt questionnable sur certains  points dont sa gestion en ligne de commande.

Logiciels tiers et comparaison avec Linux

J’ai donc décidé par une soirée fin 2012 de lancer une installation de FreeBSD 9 et voir où cela allait me mener. Ce que je découvris, après une installation un peu broche à foin, me plut rapidement, à commencer par la configuration de base du système comme les paramètres réseau et le démarrage automatique de services qui se trouvent dans un seul et même fichier. La différence avec Linux allait m’apparaître encore plus clairement lorsque je compris que, contrairement à ce dernier qui n’est qu’un noyau entouré de logiciels tiers, FreeBSD est un système d’exploitation plus conventionnel comportant une base dont le noyau et plusieurs logiciels, tous assemblés et/ou développés par la même équipe, ainsi qu’un mécanisme avec lequel il est possible d’accéder à une multitude de logiciels tiers qu’on surnomme « ports ». La séparation qui existe entre la base et les ports est on ne peut plus nette, notamment parce que la base se gère via l’arborescence Unix/Linux classique (/bin, /etc, /usr, etc.) alors que les ports sont cantonnés dans /usr/local et parce que les deux se développent de façon indépendante (ex: La version majeure d’un port peut changer alors qu’on se trouve avec la même base). Contrairement à Linux où les versions de paquetages sont « gelées » à l’intérieur d’une même version du système d’exploitation et où les correctifs appliqués dans les nouvelles versions des logiciels sont « backportés » vers ces versions gelées, avec les ports, les versions ne sont pas gelées, ce qui veut dire qu’on a accès la plupart du temps à la dernière version disponible d’un paquetage, comportant évidemment ses nouvelles fonctionnalités mais aussi ses instabilités… Je tire profit des dernières versions, notamment avec le logiciel Netatalk 3.x, disponible seulement en version 2.x sur la plupart des distributions Linux actuelles, qui me permet de transformer mon serveur FreeBSD en « Time capsule » pour les sauvegardes Time Machine de mes postes de travail Mac OS X.

Un vrai gestionnaire de paquetages

Jusqu’à tout récemment, le système des ports obligeait ses utilisateurs à tout compiler (de façon automatique mais quand même..), la seule alternative étant d’utiliser de vieux paquetages binaires gérés par un outil de gestion primitif. Donc, en plus de devoir attendre lors de l’installation et de la mise à jour des paquetages, la gestion de ceux-ci comportait un élément de risque non négligeable puisque la source des paquetages était multiple, soit les différents sites des fournisseurs, plutôt qu’un dépôt centralisé. Advenant le cas, donc, où un des sites devenait indisponible, c’est tout le processus qui pouvait s’écrouler. Pour palier à cela, l’équipe de développement de FreeBSD conçu un mécanisme de paquetages binaires récents muni d’un outil de gestion très comparable à apt ou yum qu’on retrouve dans des distributions de Linux. Ce mécanisme, appelé « pkgng », repose en fait sur la compilation hebdomadaire de l’ensemble des ports disponibles et leur entreposage dans un dépôt centralisé, ce qui veut dire qu’il peut y avoir un délai entre l’apparition d’un nouveau port et sa disponibilité dans pkgng, mais ce qui accélère de beaucoup la gestion de paquetages en plus de la rendre grandement plus fiable. Le système traditionnel de ports demeurant tout de même pertinent lorsque des « flags » de compilation spécifiques doivent être utilisés pour un paquetage quelconque, son utilisation conjointe avec pkgng rend désormais la gestion de paquetages sous FreeBSD efficace tout en demeurant flexible, égalant ou surpassant même celle qu’on retrouve dans des distributions Linux. N’eût été de pkgng, mon vagabondage avec FreeBSD serait peut-être terminé. Je peux donc dire que le timing que j’ai eu dans ma découverte du système d’exploitation fût excellent.

Virtualisation matérielle

Autre élément nouveau qui favorise une certaine fidélité de ma part envers le petit démon rouge (la mascotte du système) est l’apparition récente d’un outil de virtualisation propre à FreeBSD nommé Bhyve. Étant étiqueté comme léger et moderne, son apparition tardive rend maintenant la virtualisation matérielle moins gênante que du temps où on devait se rabattre sur VirtualBox d’Oracle. Il me permet présentement de rouler quelques machines virtuelles Linux dont la dernière version de Ubuntu et de CentOS.

Un autre type de virtualisation

Ci-dessus, je précise « virtualisation matérielle » car FreeBSD n’est pas en reste d’un autre type de virtualisation, qui commence seulement à sortir de la marginalité avec Linux (LXC et Docker), soit la virtualisation au niveau du système d’exploitation (« OS-level virtualization ») implémentée sous le nom de « jails » dans FreeBSD. Les jails sont utilisées depuis belle lurette et contrastent fortement avec les solutions de virtualisation matérielle en ce sens qu’elles partagent le même noyau que l’hôte physique. L’isolation est surtout au niveau des processus et du système de fichiers. On les surnomme parfois « chroot on steroids ». Ce genre de virtualisation est avantageux notamment par rapport à l’intégration qu’il permet avec l’hôte physique. Par exemple, les commandes jtop et jps, respectivement inspirées de top et ps, indiquent à quelle(s) jail(s) appartiennent les processus lorsque lancées à partir de l’hôte physique. Également, il est possible de gérer les fichiers d’une jail à partir de l’hôte physique directement, sans passer par une commande de connexion ou autre, puisque la racine de la jail est en fait un sous-dossier de ce dernier. Fait intéressant, alors que ce type de virtualisation ne permet, à l’habitude, que d’opérer des « containers » (terme générique pour « jails ») ayant le même système d’exploitation que l’hôte physique, sur FreeBSD, à cause de 2 éléments distincts, il est possible de rouler des jails Linux CentOS et Debian. Pour Linux CentOS, cela est possible car FreeBSD comporte une couche d’émulation Linux normalement utilisée pour faire fonctionner une application spécifique Linux (le plugin Flash d’Adobe pour navigateurs web par exemple) alors que pour Debian, ou plutôt Debian GNU/kFreeBSD (et non Debian GNU/Linux), cela est possible car la distribution Debian a été portée pour fonctionner sous un noyau FreeBSD. L’exotisme et l’utilité de ces deux possibilités me plaisent beaucoup et sont également des facteurs de ma fidélité au système d’exploitation présentement discuté.

Conclusion

Voilà, ça fait le tour de la préoccupation qui m’a menée vers FreeBSD ainsi que des raisons pourquoi je continue à l’utiliser aujourd’hui. Également, et probablement d’une importance plus grande, ce texte est mon premier exercice de blogage à vie! La glace est maintenant cassée!!