L’heure du test — épisode 1 — NixOS

Posté par . Édité par Davy Defaud, palm123, galbolle, ZeroHeure, patrick_g, Nils Ratusznik, BAud, Benoît Sibaud, rpnpif, Parleur et Syvolc. Modéré par ZeroHeure. Licence CC by-sa
Tags :
49
28
avr.
2017
Distribution

Logo
L’heure du test est un rendez‐vous qui vous propose de nombreux tests et guides d’installation de distributions, étape par étape et en exposant leurs avantages et leurs inconvénients.

Aujourd’hui, on s’attaque à une distribution qui est un peu particulière, j’ai nommé NixOS !
Logo NixOS

Sommaire

NixOS ?

NixOs dont le slogan est « La distribution purement fonctionnelle » est une distribution GNU/Linux avec une approche unique pour la gestion des paquets et la configuration.

NixOS est construit au‐dessus du gestionnaire de paquets Nix, qui est déclaratif, ce qui rend les mises à niveau de paquets fiables et présente de nombreux autres avantages.

Vous pouvez configurer votre système dans le langage de NixOS via un ensemble de fichiers de configuration.

NixOS possède un mécanisme de mise à jour et de retour en arrière. Imaginons que vous changiez une configuration ou que vous fassiez une mise à jour d’un logiciel de votre système qui le fait planter, vous pouvez revenir en arrière en annulant les modifications effectuées.

De même, il est possible de mélanger des paquets sources et binaires.

Télécharger NixOS

Pour télécharger NixOS, cela se passe ici : télécharger NixOS.
Vous avez le choix entre différentes installations :

  • en téléchargeant l’ISO pour ensuite la graver sur un CD/DVD ou sur une clef USB (disponible en 32 bits et 64 bits) vous avez deux possibilités : soit prendre un CD autonome (live CD) pour pouvoir tester NixOS sans l’installer, soit télécharger l’installation minimale pour uniquement l’installer ;
  • via une machine tout prête pour être importée dans VirtualBox, mais uniquement pour l’architecture 64 bits ;
  • pour l’installer sur l’hébergement Amazon EC2 ;
  • ou pour la plate‐forme Microsoft Azure.

Pour VirtualBox, comme dit précédemment, vous pouvez utiliser une image tout prête de la machine, mais c’est plus ludique de faire tout le processus d’installation.

Installer NixOS

Configuration du BIOS

Commencez par démarrer sur votre CD/DVD ou via votre clef USB. En changeant l’ordre d’amorçage dans votre BIOS, si ce n’est pas déjà fait, ou en accédant au menu d’amorçage rapide.

Ensuite, vous vous retrouvez devant la console root.

Configurer votre clavier

Commencez par mettre le terminal en clavier Francais (AZERTY) avec : loadkeys fr. Si vous êtes en bépo : loadkeys fr-bepo.

Connexion à Internet

Tout d’abord :

  • si vous êtes en Wi‐Fi, vous devez configurer votre accès à Internet ;
  • si vous êtes en Ethernet, la connexion se fait automatiquement.

Ensuite, on va tester pour voir si on est bien connecté à Internet, car c’est nécessaire pour installer le système en faisant un : ping www.google.fr. Si vous recevez une réponse, c’est que c’est bon !

Partitionnement

Ensuite, on va partitionner notre disque dur en utilisant l’utilitaire fdisk et mkfs.etx4.
Commencez par lister vos partitions sur vos disques en faisant : fdisk -l.
Formatez ensuite la première partition pour installer le système :
mkfs.ext4 -L nixos /dev/sda1

On configure NixOS

Pour configurer NixOs il faut éditer le fichier : /mnt/etc/nixos/configuration.nix. Grâce à ce fichier de configuration vous pouvez paramétrer tout de votre système Nix.
Que ce soit :

  • la configuration du système horaire ;
  • le chargeur de boot par exemple Grub ;
  • la configuration des utilisateurs de la machine ;
  • les paquet de base disponibles pour tous les utilisateur de la machine ;
  • la configuration de votre serveur graphique type Xorg ou encore Wayland ;
  • la configuration du réseau ;
  • la configuration de votre gestionnaire de bureau KDE, Gnome, E17, XFCE et autres et votre gestionnaire de fenêtre awesome, twm, i3, openbox, compiz.

On monte la partition /dev/sda1 qui a comme libellé « nixos » dans /mnt :
mount LABEL=nixos /mnt

Ensuite, on va générer un fichier de configuration initial :
nixos-generate-config --root /mnt

Ensuite, on peut commencer à configurer NixOS à notre sauce :
nano /mnt/etc/nixos/configuration.nix

Configurer Grub

Ajoutez tout d’abord le démarrage sur le premier disque /dev/sda :
boot.loader.grub.device = "/dev/sda";

Configurer NixOS pour VirtualBox

Si vous êtes sous VirtualBox, dans le fichier, ajoutez la ligne permettant à NixOS de savoir qu’il se situe dans une machine virtuelle :
virtualisation.virtualbox.guest.enable = true;

Ajoutez la ligne pour désactiver la vérification des journaux du système de fichiers :
boot.initrd.checkJournalingFS = false;

Configurer l’interface graphique

Installer X.org

Vous pouvez activer l’affichage de l’écran de connexion (par exemple sddm) dès le démarrage : services.xserver.displayManager.sddm.enable = true; et activer l’utilisateur par défaut avec :

services.xserver.displayManager.sddm.autoLogin = {
  user = "votre_login";
  enable = true;
};
Installer un gestionnaire de bureau

Si vous voulez installer, par exemple :

  • KDE 5 : services.xserver.desktopManager.kde5.enable = true; ;
  • GNOME 3 : services.xserver.desktopManager.gnome3.enable = true; ;
  • Xfce : services.xserver.desktopManager.xfce.enable = true; ;
  • E17 : services.xserver.desktopManager.e17.enable = true;.
Installer un gestionnaire de fenêtres

C’est le même principe pour les gestionnaires de fenêtres. Par exemple, pour installer twm :
services.xserver.windowManager.twm.enable = true;
Pour Awesome :
services.xserver.windowManager.awesome.enable = true;

Installer des applications pour tous les utilisateurs

On peut installer une application pour tous les utilisateurs. Par exemple, pour Emacs, vous devez écrire :
environment.systemPackages = [ pkgs.emacs ];

Finalisation de l’installation

Une fois votre système configuré, vous pouvez lancer l’installation de NixOS :
nixos-install

Découverte de NixOS

Le gestionnaire de paquetages Nix

L’une des particularités de NixOS est que vous pouvez installer des applications sans droit root. Dans ce cas, l’application est uniquement visible sur le compte d’utilisateur pour lequel vous l’avez installée.

Installer et désinstaller une application pour un compte utilisateur

L’installation d’une application se fait via la commande :
nix-env --install firefox
On peut voir que Firefox est installé.
Maintenant essayons de désinstaller Firefox :
nix-env --uninstall firefox

Revenir en arrière

Bien sûr, là, Firefox est désinstallé ; mais pas vraiment, car si vous faites un :
nix-env --rollback
Alors, Firefox est de retour ; cette commande annule l’action précédente, c’est‐à‐dire la désinstallation de Firefox.

Nettoyer le cache

Vu que le paquet n’est pas totalement désinstallé, cela occasionne des pertes d’espace disque ; une des solutions est de lancer la commande :
nix-env --delete-generations old
suivie par :
nix-collect-garbage
pour supprimer complètement les programmes désinstallés.

Attention, si vous n’avez plus d’espace disque, certains programmes qui ont besoin d’écrire des choses sur le disque peuvent refuser de fonctionner et cela peut provoquer une instabilité du système.

Pour lister l’ensemble des paquets présents sur Nix : nix-env -qa.

Le système de channel

NixOS possède un système de canal qui permet de choisir les versions sur lesquelles on veut faire des mises à jour.

Lister les channels

Pour savoir le canal qu'on suit taper simplement :
nix-channel --list

Pour connaître la liste des canaux que vous pouvez utiliser, vous pouvez aller sur le dépôt de NixOS, les canaux que vous pouvez suivre commencent par le préfixe nixos-.

Changer de channel

Supposons que vous souhaitiez suivre le canal de mise à jour de la version 14.12 de NixOS. Vous pouvez simplement le suivre en tapant :
nix-channel --add https://nixos.org/channels/nixos-14.12 nixos (root)
Et ensuite taper :
nixos-rebuild switch --upgrade (root)
Pour mettre à jour vers cette version. Si, par exemple, vous étiez à la 16.09, vous rétrogradez vers la 14.12.

Conclusion

NixOS est vraiment une super distribution, peu importe l’erreur que vous faites, vous pouvez revenir en arrière. La configuration du système est très simple, vous n’avez pas à jongler avec les fichiers de configuration, tout se fait dans un seul. Et, ça, c’est cool !
Note finale : 9/10

  • # Euh…

    Posté par . Évalué à 0 (+0/-3).

    L’heure du test est un rendez‐vous qui vous propose de nombreux tests et guides d’installation de distributions, étape par étape et en exposant leurs avantages et leurs inconvénients.

    J'aurais plutôt dis écris :

    L’heure du test est un rendez‐vous qui vous propose de nombreux tests et guides d’installation de distributions reconnus dans le monde du logiciel libre. Étape par étape et en exposant leurs avantages et leurs inconvénients, ceux-ci vous aident à faire vos premiers pas dans les méandres d'une distribution depuis 1946 !

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # configuration

    Posté par (page perso) . Évalué à 7 (+5/-0).

    Ce n'est pas la première fois que j'en entends parler, et c'est vraiment intéressant, merci pour la dépêche.

    Comment ça marche pour le fichier de configuration unique ? Le coup des paquets, des locales, etc pas de soucis. Mais pour les fichiers de confs dans les différents formats, il faut bien que ça passe par /etc/ non ? Si la conf est générée depuis le fichier unique, comment est faite la correspondance (mapping) ? Est-ce qu'il n'y a pas un risque qu'une option ne soit pas disponible ? Et la doc du coup est totalement différente non ?

    exemple concret : comment je change mon port ssh ? Comment je décide de quels services démarrent avec un fichier unique ?

    • [^] # Re: configuration

      Posté par . Évalué à 3 (+2/-0).

      Par exemple =>

      Ma conf de ssh

      openssh = {
      enable = true;
      passwordAuthentication=false;
      permitRootLogin="no";
      } ;

      Tu me parles du port => Je regarde le fichier descriptif :
      https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/ssh/sshd.nix
      Donc j'aurais juste à rajouter, par exemple :

      ports = [44] ;

      Et pour ta deuxième question => Bah regarde la description de mon openssh => enable = true ;

      vala :)

      • [^] # Plus difficile

        Posté par . Évalué à 6 (+4/-0).

        Bon, les fichiers de configuration, il gère.
        J’ai regardé aussi pour X.org, il semble que NixOS permette assez librement les configurations habituelles (utile par exemple pour une configuration fine du pavé tactile).

        Par contre, supposons que je veuille modifier un fichier qui n’est pas un fichier de configuration.
        Par exemple, modifier la disposition de clavier Bépo pour échanger les guillemets français et les chevrons.
        Sur une distribution classique, je peux soit modifier la disposition Bépo existante dans le fichier /usr/share/X11/xkb/symbols/fr façon sagouin, soit ajouter une nouvelle disposition dans ce fichier ou dans un fichier indépendant, mais dans ce cas il faut que je la déclare dans /usr/share/X11/xkb/rules/evdev.xml (voire dans d’autres fichiers du répertoire rules) pour qu’elle soit correctement prise en compte. En tout cas, il faut modifier au moins un fichier existant.

        De ce que j’ai compris de NixOS, on n’est pas sensé écrire directement dans les fichiers du système et comme ça n’est pas considéré comme un fichier de configuration, il n’y a certainement pas de fichier xkb.nix (en tout cas, je n’en ai pas vu) permettant de le gérer. Donc comment peut-on procéder pour faire ce genre de modification ?

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: Plus difficile

          Posté par . Évalué à 3 (+0/-0).

          Créer un paquet nix pour ça ? Ça n'a pas l'air bien compliqué.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Plus difficile

            Posté par . Évalué à 2 (+0/-0).

            Reste la question de savoir si tu es obligé de refaire le paquet de xkb, ce qui implique de le refaire à chaque nouvelle version.

            Avec les .deb (bien compliqués pour le coup), il me semble qu’un mécanisme (dont le nom ne me revient malheureusement pas…) rend possible de faire un paquet qui puisse modifier automatiquement un fichier d’un autre paquet quand celui-ci est mis à jour (une complication plus utile que de conserver un tas de trucs historiques qui ne servent plus depuis des années…).

            Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

            • [^] # Re: Plus difficile

              Posté par . Évalué à 4 (+1/-0).

              Avec les .deb (bien compliqués pour le coup), il me semble qu’un mécanisme (dont le nom ne me revient malheureusement pas…) rend possible de faire un paquet qui puisse modifier automatiquement un fichier d’un autre paquet quand celui-ci est mis à jour (une complication plus utile que de conserver un tas de trucs historiques qui ne servent plus depuis des années…).

              dpkg-divert tu peux t'en servir sans avoir besoin de créer un paquet.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # dpkg-divert !

                Posté par . Évalué à 2 (+0/-0).

                Merci, c’est ce que je cherchais.

                Autant il y a plein de complications dans Debian et ses dérivées que je considère superflues (dans le système de paquets, mais aussi des fichiers de configuration qui font doublons avec ceux d’origine des logiciels concernés), autant cette fonctionnalité manque cruellement aux autres distributions.

                Non pas qu’on en ait besoin souvent, mais quand on en a besoin et qu’on ne l’a pas, on doit surveiller chaque mise à jour pour vérifier que la modification qu’on a faite ne saute pas. C’est lourd.

                Refaire un paquet, c’est la solution propre avec une autre distribution, mais devoir le refaire à chaque mise à jour du paquet d’origine, c’est encore plus lourd que de restaurer la modification à la main.

                Quand j’administrais des Fedora, je scriptais mes modifications. Le script commençait par faire la mise à jour des paquets, puis rejouait les modifications si elles n’étaient plus en place. C’est ce que j’avais trouvé de plus pratique.

                Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: Plus difficile

          Posté par . Évalué à 3 (+2/-0).

          La solution ici serait de faire un «override» local du paquet, comme expliqué ici. L'exemple qui est donné dans le manuel change la source du paquet (en l'occurence pour construire emacs à partir des sources locales). Pour patcher un fichier au moment de la construction du paquet, il faudrait utiliser un truc comme suit:

             environment.systemPackages = [
                (pkgs.xorgserver.overrideAttrs (oldAttrs: {
                  patches = oldAttrs.patches ++ [ /path/to/mes/modifications/de_symbols_fr.patch ];
                }))
              ];

          Malheureusement, ça va imposer des reconstructions de plein de chose (a minima, xorg lui-même), car nix ne sait pas à l'avance quelle seront les conséquences de ce changement dans un fichier des sources (seront-elles bénignes ou radicales), donc il considère qu'il doit reconstruire tout ce qui dépend de xorg.

      • [^] # Re: configuration

        Posté par . Évalué à 3 (+2/-0).

        Il est également possible de regarder http://nixos.org/nixos/options.html pour trouver les options disponibles. C’est en général plus rapide de regarder là que dans la source du service.

        Par exemple pour openssh, http://nixos.org/nixos/options.html#services.openssh donnera toutes les options utiles.

      • [^] # Re: configuration

        Posté par . Évalué à 1 (+1/-0).

        Lister les options :

        nixos-option services.openssh
        

        Exemple pour le port ssh :

        nixos-option services.openssh.ports
        
        Value:
        [ 22 ]
        
        Default:
        [ 22 ]
        
        Description:
        
        Specifies on which ports the SSH daemon listens.
        
        Declared by:
          "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/services/networking/ssh/sshd.nix"
        
        Defined by:
          "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/services/networking/ssh/sshd.nix"
        
    • [^] # Re: configuration

      Posté par . Évalué à 4 (+3/-0).

      Très bonne question ;)

      En général, ce qui est favorisé est que le service NixOS expose des options qui sont exprimables dans le langage de Nix pour avoir une configuration déclarative.

      Ce qui se passe derrière, c’est que le fichier de configuration « réel » est généré en fonction de ce qui a été déclaré dans le DSL nix. Il est tout à fait possible que des options ne soient pas accessibles via le DSL nix. En général, les mainteneurs exposent les principales configurations via des attributs nix, et pour le reste il y a souvent un attribut « fourre tout » qui va contenir un blob de texte qui va être inséré direct dans le fichier de conf généré.

      Pour openssh, ce paramètre magique est services.openssh.extraConfig.

      On peut donc facilement avoir une déclaration comme ça :

        services.openssh = {
          enable = true;
          ports = [ 44 ];
          extraConfig = ''
            Match User linuxfr
              ChrootDirectory /home/linuxfr
              AllowTCPForwarding no
              ForceCommand internal-sftp
          '';
        };
      

      Pour ce qui est de la localisation des fichiers de config, autant que faire ce peut, elles ne sont pas dans /etc. Les configurations sont un résultat d’après la config de l’utilisateur, et sont donc rangées avec tous les résultats, dans /nix/store. Dans la majorité des cas, les scripts de lancement des services (ici l’unit systemd) va lancer openssh en lui spécifiant où trouver le fichier de configuration :

      $ grep sshd_config /etc/systemd/system/sshd.service
      ExecStart=/nix/store/wk90g951ybhh67qmbzq6g2y867356rcq-openssh-7.4p1/bin/sshd -f /nix/store/k3sdz12hsak7amps64zxi6a29bkd556q-sshd_config

      Bien sur, sshd.service est également généré via nix, il est donc lui-même dans /nix/store :

      $ readlink -f /etc/systemd/system             
      /nix/store/66daxxs9f2gjfnmak193lb5i3lip8r1b-system-units

      C’est ce mécanisme qui fait qu’il est simple de passer d’une config / version à l’autre « juste » en mettant à jours un lien symbolique.

  • # mouais...

    Posté par . Évalué à 10 (+12/-2).

    Salut

    D'avance désolé de râler mais je ne vois pas trop l'intérêt d'un nième test de distrib du style "je décris l'install du système et quelques logiciels/configs/commandes de base". Tout le monde peut faire ça soi-même en passant 1/2h sur la doc et une machine virtuelle. Ce qui serait vraiment intéressant, ce serait plutôt un retour d'expérience de quelqu'un qui utilise la distrib tous les jours depuis au moins un an.

    Concernant NixOS, l'intérêt tient surtout dans son système de paquetage (qui est d'ailleurs utilisable sur n'importe quelle distrib classique) et sur les "nix expressions" qui permettent à un développeur ou à un admin sys de créer des environnements virtuels légers et reproductibles; or l'article n'en parle pas vraiment (et encore moins de la façon de les mettre en oeuvre).

    Cela dit, NixOS est une distrib vraiment intéressante et cet article a le mérite d'en parler donc merci pour ça.

  • # Logo

    Posté par . Évalué à -4 (+3/-8).

    Était-ce vraiment nécessaire, cet énorme logo ?
    Rien que cela ça m'énerve, je n'ai pas envie de lire la dépêche.

    • [^] # Re: Logo

      Posté par . Évalué à 7 (+8/-3).

      Ne lis pas la dépêche alors.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Logo

      Posté par (page perso) . Évalué à 4 (+2/-1).

      Le logo était trop grand, ça arrive quand le site d'origine utilise une grande image mais en le redimensionnant et que celui qui l'ajoute à un grand écran (ie la taille de l'image ne le choque pas).

  • # Merci

    Posté par . Évalué à 6 (+6/-1).

    Merci, pour vos commentaires, critique ( positive et négatifs).

  • # Une configuration non à jours

    Posté par . Évalué à 3 (+2/-0).

    Bonjour,

    Je me permet de signaler un changement récent qui est intervenu dans la dernière release (17.03).

    Pour activer KDE5, il ne faut plus utiliser

    services.xserver.desktopManager.kde5.enable = true
    

    comme indiqué dans la dépêche, mais

    services.xserver.desktopManager.plasma5.enable = true;
    

    Au « pire », le lecteur curieux essayant avec la configuration de la dépêche aura un message l’invitant à renommer kde5 en plasma5, donc rien de bien méchant ;)

Envoyer un commentaire

Suivre le flux des commentaires

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