NixOS, collection printemps‐été 17

Posté par . Édité par Davy Defaud, ZeroHeure, Nÿco, palm123 et Nils Ratusznik. Modéré par Nÿco. Licence CC by-sa
Tags : aucun
30
6
avr.
2017
Distribution

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.

NisOS

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

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.

  • # Génial. Voir aussi GNU Guix, autres liens

    Posté par . Évalué à 5.

    Génial, très bien expliqué !

    Voir aussi Guix: https://www.gnu.org/software/guix/ qui donc permet la même chose, mais tout avec le language Guile (un scheme, lisp quoi), quand Nix utilise plusieurs langages et son propre DSL pour la configuration. (Guix est évidemment inspiré de Nix, son mainteneur actuel en était un contributeur (ancien mainteneur ?). Guix est toujours développé à l'INRIA Bordeaux.)
    Je crois pas que Guix ait packagé KDE, ils ont Gnome en tout cas.

    Article qui montre l'intérêt de ces gestionnaires de paquets dans un environnement multi-utilisateurs de supercalculateurs: https://matutine.gitlab.io/2016/09/26/gnu-guix-dans-un-environnement-de-supercalculateurs.html

  • # Merci

    Posté par (page perso) . Évalué à 1.

    Merci pour la news ! Je suis déjà un adepte depuis quelques années. Vraiment bien cette distrib et sa philosophie

  • # Article Nix/NixOS dans le GNU/Linux Magazine du mois

    Posté par . Évalué à 1.

    Le GNU/Linux Magazine du mois (numéro 203) a un article présentant Nix et NixOS. Je vous le recommanderais chaudement si je ne l'avais pas écrit :

    http://www.gnulinuxmag.com/mettez-en-place-un-systeme-de-reconnaissance-faciale/

    Bonne lecture

  • # Python

    Posté par . Évalué à 1.

    Et pour les langages type python ou perl, chaque paquet a t'il droit a son propre hash ou alors tous sont-ils regroupés par environment virtuel?

    • [^] # Re: Python

      Posté par . Évalué à 1.

      Je ne suis pas sûr de comprendre exactement la question, mais les paquets python et perl sont des paquets comme les autres. Si tu indiques ce que tu cherches à faire, je pourrais certainement répondre plus précisément.

    • [^] # Re: Python

      Posté par (page perso) . Évalué à 2. Dernière modification le 10/04/17 à 08:55.

      Tu as les packages python qui sont disponibles avec chacun leur hash

      $ nox numpy
      ...
      29 python3.5-numexpr-2.6.1 (nixpkgs.python35Packages.numexpr)
          Fast numerical array expression evaluator for NumPy
      30 python3.5-numpy-1.11.3 (nixpkgs.python35Packages.numpy)
          Scientific tools for Python
      31 python3.5-numpy-1.10.4 (nixpkgs.python35Packages.numpy_1_10)
          Scientific tools for Python
      32 python3.5-numpydoc-0.6.0 (nixpkgs.python35Packages.numpydoc)
          Sphinx extension to support docstrings in Numpy format
      ...
      

      Mais rien ne t’empêche d'utiliser un environnement virtuel au sein de nix. Je fais cela par exemple en Haskell car stack (l'outil d'env virtuel que j'utilise) apporte aussi d'autres choses intéressantes. Comme cela nix gère tes librairies externes, et ton env virtuel gère les lib du langage et le fait "peut-être" mieux.

    • [^] # Re: Python

      Posté par . Évalué à 2.

      Pour python, chaque paquet/librairie est installé dans un préfix qui lui est propre. Cependant, nous avons tous les mécanismes en place pour pouvoir composer ces différents paquets.

      Une appli packagée (installée sous un préfix qui lui est propre) charge ses dépendances là où elles sont. Pour ça les applis sont patchées à l’installation. Par exemple, voici ce que ça donne pour poezio (seules les premières lignes sont propres à nix, les suivantes viennent de poezio) :

      #!/nix/store/g8h4lr486n2d9vh13rcjp1w9grakr71m-python3-3.5.3/bin/python3.5m
      
      # -*- coding: utf-8 -*-
      import sys;import site;import functools;sys.argv[0] = '/nix/store/qriiq4lirjl35m6a144hq2jxdfc6ycq7-poezio-0.11/bin/poezio';functools.reduce(lambda k, p: site.addsitedir(p, k), ['/nix/store/qriiq4lirjl35m6a144hq2jxdfc6ycq7-poezio-0.11/lib/python3.5/site-packages','/nix/store/bmx90yrwl5rm5cppbcwmf47rajxpv9mi-python3.5-aiodns-1.0.1/lib/python3.5/site-packages','/nix/store/va6xcs7y0fzh969wlg3j8vpcllqdjw85-python3.5-pycares-1.0.0/lib/python3.5/site-packages','/nix/store/hl46j7wr3vwv6034c0van3jbvg1mvsr9-python3.5-setuptools-30.2.0/lib/python3.5/site-packages','/nix/store/y0zyn3h5ajwxr23g86ypvamxzywl70fb-python3.5-slixmpp-1.2.4.post1/lib/python3.5/site-packages','/nix/store/iw85cx9w4hqph47xbm03x314prv7c3z6-python3.5-pyasn1-0.1.9/lib/python3.5/site-packages','/nix/store/ys52c5mx8wiwjdmlc49v24g9pjc9ii1z-python3.5-pyasn1-modules-0.0.8/lib/python3.5/site-packages','/nix/store/47bnim72z1ifs5vk5w9y8m40bq5yzak3-python3.5-pyinotify-0.9.6/lib/python3.5/site-packages','/nix/store/730x7qn846p4mpvk1vqzyi3mcczg38c0-python3.5-potr-1.0.1/lib/python3.5/site-packages','/nix/store/ckfgkn52adgvhij8r5ncabf4b2ib927m-python3.5-pycrypto-3.4.3/lib/python3.5/site-packages','/nix/store/myl35b3zwar2l31r60ypv13kfyfr7dvm-pycryptodome-3.4.3/lib/python3.5/site-packages','/nix/store/6gk6sb6girpjqamrz3b7fwd5sl0cfmhs-python3.5-mpd2-0.5.5/lib/python3.5/site-packages'], site._init_pathinfo());
      import re
      import sys
      
      from poezio.__main__ import run
      
      if __name__ == '__main__':
          sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
          sys.exit(run())

      Ça a l’air un peu barbare, mais si on regarde tranquillement, ça nous donne (entre autre*) :

      • l’interpréteur (exact) à utiliser en première ligne
      • l’ensemble des chemins où les différentes dépendances se trouvent

      Dans les gros avantages à cela, on trouve une réelle facilité à faire co-éxister différents interpréteurs et différentes librairies sans que l’ajout de l’un ou l’autre (ni sa mise à jours d’ailleurs) ne vienne perturber une appli que est installée et qui tourne telle qu’elle est.

      Par rapport à un venv « classique » à la python où tu installes toutes tes dépendances dans un même prefix (ce qui peut être fais si vraiment on le souhaite), l’approche nix a l’avantage que les composants sons ré-utilsables d’un contexte à un autre. Qui a déjà du monter, et remonter des venvs avec numpy / scipy comprendra très vite l’intérêt de ne pas avoir à refaire une install (et donc une compilation des modules natifs) des différents composants…

      Le second très grand avantage de nix par rapport à un venv se fait sentir quand on ne fais pas que du pure python, mais qu’on va avoir des environnements utilisant des composants non gérés par pip.

      * Le script python réel nommé .poezio-wrapped est en fait appelé par un wrapper poezio utilisé pour mettre en place différentes variables d’environnement (dont PATH afin de pouvoir gérer les dépendances éventuelles vers des applis / outils devant être accessible à poezio)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.