NixOS, collection printemps‐été 17

La distribution NixOS sort en version printemps‐été 17. Cette distribution GNU/Linux, fondée sur le gestionnaire de paquets Nix propose une gestion « purement fonctionnelle » des paquets et services GNU/Linux. Une dépêche un peu ancienne, mais toujours d’actualité, en décrit les principes de fonctionnement ; certains points ont été développés par la suite.

Cette version comprend son lot de nouveautés :

• il est désormais possible d’utiliser un système de surcouches (ou overlays) pour ajouter ses propres paquets (ou versions de paquets) à la distribution ;
• de nouvelles versions pour de nombreux paquets, comme par un noyau Linux 4.9, Firefox 52 ou encore KDE / Plasma 5.8.6 ;
• plein de nouveaux services et d’améliorations, notamment en termes de sécurité.

Sommaire

• • Présentation de l’écosystème Nix et NixOS
  • Mode « compatibilité »
  • Les surcouches
  • Mises à jour d’importance
    • Chaîne de compilation
    • KDE
    • Quelques nouveaux services
  • Sécurité
    • Suivi des vulnérabilités
    • Fin de MD5
  • Réduction de l’empreinte

Présentation de l’écosystème Nix et NixOS

Nix, le gestionnaire de paquets, permet d’utiliser des paquets binaires, ainsi que des paquets sources, comme sous Gentoo ou Arch. Comme presque tous les systèmes de gestion de paquets, il permet la gestion des dépendances entre paquets. Ses principes de fonctionnement originaux lui permettent d’implémenter de façon sûre des fonctionnalités souvent peu stables ou absentes des autres gestionnaires de paquets. Il s’agit de la poursuite par la communauté du travail commencé par Eelco Dolstra dans sa thèse à la Technische Universiteit de Delft.

NixOS est une distribution GNU/Linux utilisant Nix comme système de gestion de paquets. Elle permet des mises à jour réversibles du système : si une nouvelle version d’un paquet, du système ou de sa configuration pose problème, on peut revenir à une version précédente en une commande. Elle utilise également le langage Nix pour la configuration du système, ce qui permet d’intégrer la configuration entre les différents services, mais aussi d’automatiser le redémarrage des services en fonction des changements de configuration.

L’écosystème Nix va au‐delà d’une simple distribution :

• NixOps permet d’orchestrer des réseaux de machines (physiques ou virtuelles), de façon plus simple et plus fiable que les systèmes classiques tel que Salt ou Puppet ;
• Hydra est un système de construction continue : il s’agit d’un programme qui construit en permanence un ensemble de paquets auxquels on soumet de nouvelles versions. Les paquets à construire sont spécifiées dans le langage Nix.

Parmi les avantages de cette approche, on distingue :

• la possibilité de revenir sur une mise à jour ou une installation : toutes ces opérations sont réversibles ;
• l’état du système est complètement défini à partir d’un fichier, de manière plus fiable qu’avec les systèmes comme Salt, Ansible ou Puppet ;
• sur une machine partagée, la possibilité d’installer des paquets pour son usage privé sans avoir à les recompiler et sans avoir besoin des droits d’administration ;
• la possibilité de mélanger paquets binaires et paquets recompilés et personnalisés ;
• des environnements de développement (avec nix-shell) qui permettent d’avoir des versions différentes des paquets suivant la tâche qu’on accomplit, afin de s’affranchir des incompatibilités.

Mode « compatibilité »

Le modèle Nix implique que tout ce qu’on installe se retrouve dans le store, avec le chemin /nix/store, ce qui n’est pas standard. La plupart du temps, cela ne pose pas de problème, mais cela peut compromettre l’utilisation de binaires conçus pour les systèmes plus classiques. Les commandes steam-run, ainsi que buildFhsEnv permettent de créer des environnements dans lesquels les paquets installés apparaissent à l’endroit prévu par la FHS. C’est ainsi notamment — comme les plus perspicaces l’auront saisi — que l’on peut utiliser les jeux Steam sous NixOS.

Il est désormais possible grâce à dockerTools d’utiliser Nix pour préparer des images Docker de façon déclarative. Plutôt que d’écrire une suite de commandes qui permettent de préparer l’image, on décrit directement son contenu dans un fichier Nix. De même, dockerTools.pullImage permet de récupérer une image Docker et de la manipuler avec le langage Nix.

Les surcouches

Les surcouches, ou overlays en anglais et dans la documentation, permettent d’ajouter ses propres paquets à nixpkgs, la collection de paquets sur laquelle est basée NixOS. Cela permet, comme avec d’autres gestionnaires de paquets, de bénéficier de logiciels qui n’ont pas encore été empaquetés. Il est également possible de remplacer des paquets existants par ses propres versions. Si l’on choisit de le faire, les paquets qui dépendent du paquet remplacé seront recompilés pour utiliser le paquet de la surcouche.

Mises à jour d’importance

Chaîne de compilation

Le compilateur de référence de cette version est GCC 5.4.0, avec la Glibc 2.25. Les services sont orchestrés par systemd 232.

KDE

KDE 5, plus précisément Plasma 5.8.6 devient le bureau par défaut. KDE 4 n’est plus inclus.

Quelques nouveaux services

NixOS se distingue d’autres distributions par ses services, des programmes système dont l’installation et la configuration sont gérés globalement depuis le fichier configuration.nix.

De nouveaux services ont été ajoutés, voici une sélection tout à fait subjective :

• vim permet de faire de cet éditeur l’éditeur par défaut du système ;
• le démon de musique ympd peut désormais ambiancer les systèmes NixOS ;
• moins futile — encore que —, on peut également sauver le monde avec boinc, en ouvrant sa machine à des projets scientifiques en mal de temps de calcul distribué ;
• pour voir l’effet de tout cela sur le fonctionnement du système, l’outil de supervision Prometheus fait son apparition.

Sécurité

Suivi des vulnérabilités

Lorsqu’une vulnérabilité est découverte, elle est rapportée dans la collection de paquets nixpkgs. Il devient alors impossible d’installer le paquet incriminé jusqu’à ce qu’un correctif ait été appliqué. On peut toutefois utiliser une option ad hoc pour passer outre cette vérification, soit pour un paquet, soit globalement.

Fin de MD5

On peut avoir besoin d’installer des paquets depuis les sources, aussi bien avec le système de construction continue Hydra qui serait installé sur une machine centrale, que sur chaque machine suite à une demande d’utiliser des options particulières ou suite à l’utilisation d’une surcouche Nix.

Dans tous ces cas, la compilation du paquet commence par le téléchargement des sources, dont il faut vérifier l’intégrité. La description de chaque paquet contient à cet effet une empreinte cryptographique des sources (généralement SHA-256). L’empreinte MD5, obsolète, n’est plus utilisable à partir de la version 17.03 — son utilisation était de toute façon assez rare.

Réduction de l’empreinte

La dernière amélioration date de la version 16.09, qui n’avait pas été annoncée sur LinuxFr.org, et elle est assez appréciable : l’espace disque nécessaire pour les plus petites installations a été bien réduit, grâce à une chasse aux dépendances infondées. En particulier, il est désormais possible pour un paquet source de définir plusieurs sorties (outputs), qui seront installables comme paquet ou utilisables comme dépendance par d’autres paquets. Cela permet de diminuer les dépendances dans le cas où A dépend de B, B dépend de C, mais seulement pour sa documentation. Il est alors possible, quand on installe A, d’utiliser B sans sa documentation, donc sans la dépendance à C.

Aller plus loin

• La page de référence de NixOS (315 clics)
• Les nouveautés de la version 17.03 (64 clics)
• Une ancienne dépêche qui présente NixOS et l’écosystème Nix (150 clics)