Donnez moi un NixOS à ronger

Petit aperçu de Nix : il y a plusieurs articles sympas ici, la récente revue de Seb95, à cause de laquelle je suis passé sur cette distribution il y a quelques jours (et sachant que visiblement lui n’y est pas resté!, peut-être qu’il me lit haha), ou cette revue plus ancienne, donc j’essaierai de mettre en avant d’autres aspects.

Sommaire

• Mini histoire à zapper
• Une distribution rétro-futuriste
  • Déclaratif
  • Immuable
  • Retour arrière
  • Multi-utilisateurs
  • En somme
• Je nixifie tu nixifies
• Interdit !
• Channel
• 2 wikis et 2000 manuels
• Et les autres bombes atomiques?

Mini histoire à zapper

Dejà reprécisons - il faut remonter à 2003 pour que Eelco Dolstra développe le gestionnaire de paquets Nix, mais la distribution, elle, NixOS date de 2006. Il y a deux versions par an, nommée YY.MM, par ex. 13.05 pour version de mai 2013 - brillant.

Pour la suite j’écrirai simplement Nix pour désigner la distribution.

En 2010 un wiki démarre. En 2013, la distribution 13.05 passe de upstart à systemd et systemd-boot au démarrage (alors appelé gummiboot). La version 13.10 est la première version stable de NixOS.
On peut noter chez la concurrence, en 2014 le lancement du projet Atomic de Red Hat.
En 2016, le wiki Nix officiel est clos et un wiki non officiel démarre…
Fedora Silverblue apparait 2018 comme projet de distinct de « Atomic ». En 2019 Open Suse démarre le projet Micro OS.
Côté Nix, en 2020 ont été intégrés les Flakes (22.05). Un installateur graphique apparait en 2022, sur la 22.05.
En 2024, le wiki Nix officiel redémarre (mais le nom officiel demeure…)

Une distribution rétro-futuriste

Dans Nix, il n’y a pas de répertoire /bin, de /sbin, de /lib ou de /usr. Tout est gardé dans un /nix/store.

Enfin moi j’ai quand même un /usr/bin/env mais j’avoue ça fait peu, ou un /bin mais qui ne contient qu’un symlink pour bash. Mais bref

Dans le /nix/store on va retrouver nos hiérarchies habituelles, rangées dans des « dérivations ». Prenons firefox : je ne l’aurai pas directement dans /usr/bin mais dans le store voici comment ça se présente

$ ls -R /nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0
/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0:
bin  lib  share

/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0/bin:
firefox

/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0/lib:
firefox  mozilla

/nix/store/lxgnpycfaac8w893wmka5hw3dad8w228-firefox-121.0/lib/firefox:
application.ini    defaults            firefox-bin   libgkcodecs.so        libmozavutil.so   libmozwayland.so   omni.ja        Throbber-small.gif
browser            dependentlibs.list  fonts         libipcclientcerts.so  libmozgtk.so      libxul.so          pingsender     vaapitest
crashreporter      distribution        glxtest       liblgpllibs.so        libmozsandbox.so  minidump-analyzer  platform.ini
crashreporter.ini  firefox             gmp-clearkey  libmozavcodec.so      libmozsqlite3.so  mozilla.cfg        removed-files

etc.
Pour le reste c’est plus standard.

$ ls /
bin  boot  dev  etc  home  lib  lib64  lost+found  nix  proc  root  run  srv  sys  tmp  usr  var

Déclaratif

La configuration, utilisateurs réseaux paquets services saucisson fromage, tout est déclaré dans un fichier /etc/nixos/configuration.nix.
Comme définir un point de montage pour un disque ou les règles du pare-feu, qui correspondraient à du /etc sur d’autres distributions, mais aussi par exemple créer un utilisateur - ce qui correspondrait plutôt à des commandes sur d’autres distributions, comme useradd.

Quand vous « compilez » le fichier /etc/nixos/configuration.nix, Nix va s’occuper tout seul des /etc/fstab, iptables (*), /etc/group, et ainsi de suite ; en général on précise que l’on « switche » vers ce nouvel OS et Nix redémarre les services avec la nouvelle config (à vous de savoir si redémarrer des services est suffisant, ou si pour prendre en compte les changements vous préférez redémarrer la session voire reboot).

(*nftables dispo)

Exemple fstab, au lieu d’éditer fstab je mets ça dans /etc/nixos/configuration.nix

 # FSTAB
  fileSystems."/home" = {
    device = "/dev/disk/by-uuid/220260f3-a7b2-4387-9a0b-9d17c604aa18";
    fsType = "ext4";
   options = [ # If you don't have this options attribute, it'll default to "defaults" 
     # boot options for fstab. Search up fstab mount options you can use
     "users" # Allows any user to mount and unmount
     "nofail" # Prevent system from failing if this drive doesn't mount     
   ];
  };

Ou encore ma fichue imprimante Samsung
Sous Debian, j’aurai peut-être ajouté un dépôt dans /etc/apt, j’aurai rafraichi puis installé un paquet. Sous Nix j’édite le fichier.

  # Enable CUPS to print documents.
  services.printing.enable = true;
  services.printing.drivers = [ pkgs.samsung-unified-linux-driver ];

On peut même se retrouver à configuration de manière abstraite… En effet, imaginons que je configure le pare-feu : quel pare-feu suis-je en train de configurer?

networking.firewall.allowedTCPPorts = [ 80 443 ];

La documentation vous apprendra que par défaut, Nix passe par iptables pour implémenter les règles que vous précisez. Avec la directive ci-dessous, les mêmes règles seraient implémentées en se basant sur nftables.

networking.nftables.enable

Immuable

Est-ce que NixOS est immuable? On pourrait dire, comme Distro Watch, non, car on peut en réalité écrire sur la totalité du système de fichier. L’immuabilité est plutôt fonctionnelle - au sens où on ne lance pas de commande, on édite un fichier /etc/nixos/configuration.nix (que l’on peut scinder, au besoin), qui donnera toujours le même résultat. (spoil cf quand même plus bas : channel).

Retour arrière

Après construction du système, au démarrage, vous aurez le choix d’amorcer (booter) sur chaque version de l'OS que vous avez construite. On peut démarrer sur une ancienne version. Un peu comme démarrer sur une ancienne version du noyau mais appliqué à tout.

Multi-utilisateurs

Vous pouvez avoir plusieurs versions d’un paquet installées en même temps, en fonction des utilisateurs. Certainement très utile… et pas testé chez moi.

En somme

Cette page décrit bien les logiques différentes entre Nix et un système basé sur Debian pour quelques opérations courantes.

Bon clairement si le besoin c’est installer firefox et qu’on doit éditer un fichier /etc puis rebuild le système, on ne ressent pas particulièrement d’avantage à utiliser Nix vs un autre système (mais en cas de souci, vous serez bien content d’avoir le rollback…)

• À noter cela dit que l’installation de paquets n’est pas vraiment plus longue. Rebâtir le système n’est pas vraiment plus long qu’un apt-get ou équivalent. Ce qui m’étonne le plus c’est que par défaut il n’y a pas de commande pour chercher des paquets (… ??!!! …bon il y a le site officiel et on peut par exemple installer nix-search-cli) .
• On peut bien sûr utiliser des Flatpak si on active cette option. Par défaut si on installe GNOME, cela vient d’ailleurs avec gnome-software qui n’inclut que les Flatpak. Au moins c’est un Gnome Software léger, ça change ahem ahem…
• Pour les AppImage j’en parle plus bas

Donc l’usage pour installer une application graphique ne changera pas vraiment la vie. À noter tout de même que le dépôt est particulièrement large.

Mais quid de paquets un peu plus complexes? Quand j’ai voulu installer nginx avec le TLS, j’ai eu une bonne surprise. J’imaginais une tannée du fait de devoir « passer par Nix » pour gérer tout ce qui est configuration et certificats. En effet plus question de lancer des commandes pour acquérir ou renouveler des certificats. Comment faire? Pour le coup la doc me l’a indiqué rapidement.

      security.acme.acceptTerms = true;
      security.acme.defaults.email = "mon@email.example.com";

          services.nginx = {
            enable = true;
              virtualHosts = {
                 "mon.domaine" = {
                     forceSSL = true;
                     enableACME = true;
                     root = "/var/www/mon.domaine";
              };

Et voilà! Nginx est installé, mon domaine pointe vers le bon dossier, le http redirige vers https, Nix acquiert les certificats (par défaut Let'sEncrypt mais se personnalise si on veut), et surtout Nix définit un systemd pour renouveler les certificats.

Et là on voit que Nix c’est un peu l’opposé d’une ditribution minimaliste comme Arch… Les points forts de Arch sont les points faibles de Nix et réciproquement…

À noter que /etc/nginx n’existe pas. Dans mon exemple ce sera nix/store/brxfza7n2hjy6n15ffdrb7wlr2fqygy8-nginx. conf…

$ systemctl status nginx
● nginx.service - Nginx Web Server
     Loaded: loaded (/etc/systemd/system/nginx.service; enabled; preset: ignored)
     Active: active (running) since Sat 2025-03-29 09:45:55 CET; 1 day 10h ago
 Invocation: 84e49760dcee4e5ea0a6baa79dd6ceb2
    Process: 35568 ExecReload=/nix/store/alqjcv381xp2wawjc919h1qr6p4q8gvj-nginx-1.26.3/bin/nginx -c /nix/store/brxfza7n2hjy6n15ffdrb7wlr2fqygy8-nginx.conf -t>
    Process: 35569 ExecReload=/nix/store/9m68vvhnsq5cpkskphgw84ikl9m6wjwp-coreutils-9.5/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)

Oui tout est dans le nix store, bah oui logique.

On voit aussi que cette distribution est aussi agréable qu’elle est

• bien empaquetée
• bien documentée (j’y reviens plus bas…)

Je nixifie tu nixifies

Définir des choses dans /etc/nixos en déclaratif plutôt que de taper des commandes ou éditer d’autres fichiers comme /etc/nginx, c’est ce qu’on appelle nixifier, qui vient du verbe galérer-de-ouf. Non je plaisante.

Cela veut dire que pour tout ce que vous pouvez faire avec les services, le paquet Nix doit proposer des options pour le faire dans /etc/nixos… Un peu effrayant au premier abord? Par ex. si je veux utiliser une fonction plus exotique de Nginx, alors la config Nix doit inclure un moyen de le spécifier, et doit inclure chaque option Nginx ??

En fait de nombreux services vont proposer d’ajouter des options « extra ». Par ex. si je veux utiliser la fonction Nginx « rate-limit » et que le paquet Nix n’a pas d’option pour ça… Eh bien je vais utiliser une directive « appendHttpConfig » qui va me permettre de directement écrire dans le nginx.conf. Comme cela je continue d’utiliser les avantages Nix, mais je peux profiter d’options non nixifiées.

     services.nginx = {
        enable = true;
    appendHttpConfig = " limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/m; " ;
          virtualHosts = {
             "mon.domaine" = {
                 forceSSL = true;
                 enableACME = true;
                 root = "/var/www/mon.domaine";
         extraConfig = "limit_req zone=mylimit;";
          };

On peut même avoir le besoin de générer un fichier /etc. Pas de souci, exemple avec fail2ban, on peut générer un fichier /etc/fail2ban/filter.d

    # Defines a filter 
    "fail2ban/filter.d/nginx-py.local".text = pkgs.lib.mkDefault (pkgs.lib.mkAfter ''
      [Definition]
failregex = ^.* \[error\] \d+#\d+: \*\d+ (\S+ )?\"\S+\" (failed|is not found) \(2\: No such file or directory\), client\: <HOST>, server\: \S*\, request: \"(GET|POST|HEAD) .*$
    '');
  };

Interdit !

Je ne vais pas rentrer dans le détail, car je suis encore débutant, mais on ne peut pas exécuter ce que l’on veut sous Nix.

$ touch holalal.sh
$ echo -e '#!/bin/sh \necho "toto"' >> holalal.sh
$ chmod +x holalal.sh
$ ./holalal.sh
bash: ./holalal.sh: Permission denied
$ bash holalal.sh 
toto

Appliqué aux AppImage, eh bien j’ai un peu galéré. Apparemment on lance $appimage-run . Pas de bol pour moi, ça ne passe pas. J’ai testé deux trois un million de trucs à l’aveuge pour le fun (extraire puis ajouter chmod+x, passer par exec, voire par du sudo oh la la pardonnez moi…) Comme Google n’était clairement pas mon ami, j’ai voulu tester d’empaqueter l’AppImage moi-même. C’était la bonne piste! Si j’étais familier avec Nix cela m’aurait pris 2s. Un petit fichier .nix de quelques lignes plus tard, je peux construire cette AppImage et cette fois la lancer.
Dans de nombreux cas vous trouverez l’ppImage déjà empaquetée.

Channel

Vous souvenez vous, Nix propose une version tous les 6 mois. Mais dites-moi… Comment met-on à jour si on lance pas de commande dans Nix et qu’on n’utilise que vi /etc/nixos/configuration.nix ?
Et là, voilà la vérité révélée : oui on utilise des commandes, et non Nix n’est pas que déclarative.
(cf par exemple https://nlewo.github.io/nixos-manual-sphinx/installation/upgrading.xml.html )

# nix-channel --add https://nixos.org/channels/*channel-name* nixos
# nixos-rebuild switch --upgrade

On peut également spécifier dans la config que l’on veut automatiquement passer sur les nouvelles versions. En attendant cela veut dire que deux fichiers /etc/nixos/configuration.nix ne correspondent pas forcément au même OS!

Note sur les channels : similairement à Debian, il y a un channel unstable si on veut passer en mode rolling.

Pour résoudre cette question des channels il y a les Flake. En gros l’idée est de préciser non seulement qu’un paquet est installé mais aussi quelle version.
https://nixos-and-flakes.thiscute.world/nixos-with-flakes/introduction-to-flakes#nix-flakes-and-classic-nix
Mais rien n’oblige à utiliser Flake.

2 wikis et 2000 manuels

• Deux wikis : un wiki officiel, qui a été suspendu, car il n’était pas super à jour, du coup un wiki non officiel est apparu, puis ils ont remis le wiki officiel :O !!! du coup on a plein de manuels (utilisateur, dev, celui du gestionnaire de paquets Nix…) et deux wikis et on se retrouve à jongler.
• On a l’impression d’avoir atteint le point où toute tentative d’améliorer ne fait qu’empirer. Je propose « Tools that need a manual to find the manual » ! …
• Mes premières recherches sur Internet sont simplement désastreuses, je tombe sur plein de versions différentes. Et souvenez-vous que Nix est à la fois un langage, un gestionnaire, un builder, une distribution…
• Peut-être que des sites pour répertorier , comme https://nixos.org/learn/ peuvent un peu aider…

Mais à l’heure qu’il est, si Nix a un défaut c’est bien la documentation chaotique.

Et les autres bombes atomiques?

Fedora Silverblue propose aussi le retour arrière. Toutes les applications graphiques sont des Flatpak, et les applis dév utilisent le module Toolbox. Cf la présentation par Renault, plutôt historique puis pratique.
Silverblue semble avoir de larges défis à relever mais pourrait représenter l’avenir de Fedora.

Côté Open Suse atomic, il y a eu Micro OS (2019), puis Aeon d’abord basé dessus puis devenu projet indépendant pour offir GNOME. (En parallèle le projet Kalpa se développe pour le bureau KDE.) Vous pouvez lire cette revue par LWN. Sur Aeon la méthode préférée d’installation de paquets est encore Flatpak, mais il y a aussi Distrobox.

Voilà pour ce que je connais, cela mériterait bien plus!