Journal NixOS ou comment j'ai rendu mes machines interchangeables et ennuyeuses

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
58
10
nov.
2022

Salut,

Je voudrais te parler de NixOS, la distribution Linux déclarative. C'est solène% qui me l'a fait découvrir. Elle en a pas mal parlé sur son blog. Elle a même fait des trucs plutôt créatifs avec.

Je l'avais installé sur mon laptop secondaire il y a quelques mois à la place d'OpenBSD (déso / pas déso). C'est une machine que j'utilise assez rarement, et quasi exclusivement pour de la navigation web (youtube/rss dans la chambre). J'ai cherché à faire le truc le plus simple possible. LVM over LUKS, ext4, plasma5, firefox. L'installation est facile. Les utilisateurs de Arch ou BSD ne seront pas dépaysés, il suffit de booter sur un live usb et lire la fine documentation. L'administration est pour ainsi dire inexistante. Ça casse pas les gonades, ça marche, ça a totalement le killou seal of approval pour une machine d'usage léger ou ponctuel.

Le concept est simple. /etc/nixos/configuration.nix contient l'état désiré du système et la commande nixos-rebuild s'occupe de tout. Par exemple, si je prends cette configuration

# Edit this configuration file to define what should be installed on
# your system.  Help is available in the configuration.nix(5) man page
# and in the NixOS manual (accessible by running ‘nixos-help’).

{ config, pkgs, ... }:

{
  imports =
    [ # Include the results of the hardware scan.
      ./hardware-configuration.nix
    ];

  # Bootloader.
  boot = {
    initrd.luks.devices.crypted = {
        device = "/dev/disk/by-uuid/5819e617-8899-4e6e-a4f1-4986a6e3bc8e";
        allowDiscards = true;
        bypassWorkqueues = true;
    };
    loader = {
        systemd-boot.enable = true;
        efi = {
            canTouchEfiVariables = true;
            efiSysMountPoint = "/boot/efi";
        };
    };
  }

  networking = {
    hostName = "music";
    domain = "slaanesh.org";

    # Enable networking
    networkmanager.enable = true;
  }

  # Set your time zone.
  time.timeZone = "Europe/Paris";

  # Select internationalisation properties.
  i18n.defaultLocale = "en_US.utf8";

  # Enable the X11 windowing system.
  services.xserver.enable = true;

  # Enable the KDE Plasma Desktop Environment.
  services.xserver.displayManager.sddm.enable = true;
  services.xserver.desktopManager.plasma5.enable = true;

  # Configure keymap in X11
  services.xserver = {
    layout = "fr";
    xkbVariant = "bepo";
  };

  # Configure console keymap
  console.useXkbConfig = true;

  # Enable CUPS to print documents.
  services.printing.enable = true;

  # Enable sound with pipewire.
  sound.enable = true;
  hardware.pulseaudio.enable = false;
  security.rtkit.enable = true;
  services.pipewire = {
    enable = true;
    alsa.enable = true;
    alsa.support32Bit = true;
    pulse.enable = true;
  };

  users.users.killruana = {
    isNormalUser = true;
    description = "killruana";
    extraGroups = [ "networkmanager" "wheel" ];
    packages =  with pkgs; [
      firefox
      thunderbird
      vlc
      deltachat-desktop
      keepassxc
      libreoffice-qt
      libsForQt5.kpat
      lutris
      nextcloud-client
    ];
  };

  # Enable automatic login for the user.
  services.xserver.displayManager.autoLogin.enable = true;
  services.xserver.displayManager.autoLogin.user = "killruana";

  # Allow unfree packages
  nixpkgs.config.allowUnfree = true;

  # List packages installed in system profile. To search, run:
  # $ nix search wget
  environment.systemPackages = with pkgs; [
  ];

  # This value determines the NixOS release from which the default
  # settings for stateful data, like file locations and database versions
  # on your system were taken. It‘s perfectly fine and recommended to leave
  # this value at the release version of the first install of this system.
  # Before changing this value read the documentation for this option
  # (e.g. man configuration.nix or on https://nixos.org/nixos/options.html).
  system.stateVersion = "22.05"; # Did you read the comment?

}

(on aime ou on aime pas la syntaxe. Pour ma part, je ne la trouve pas pire que celle de terraform) et que je fais un petit sudo nixos-rebuild switch; poof ! Je me retrouve avec la machine décrite plus haut. Mon utilisateur est créer automatiquement. Les paquets demandés sont installés. Y'a plus qu'à lancer firefox et venir mouler par ici. Vous remarquerez que les paquets sont déclarés au niveau de la config de mon utilisateur (users.users.killruana) au lieu de le faire au niveau du système (environment.systemPackages). NixOS possède les deux niveaux de granularité. Je peux installer des paquets au niveau global et les rendre à tous (typiquement les trucs tel que sudo, htop, fish) et je peux installer des paquets qui ne seront visible qu'au niveau de mon utilisateur (mon borderl quoi). Si je créai un second utilisateur et que je lui donne une autre liste de paquets, ben il n'aura pas les mêmes programmes d'installé. Et si y'a des paquets communs, les données sont mutualisés pour économiser de la place. Bref, chacun peut se créer son concon sans empieter sur celui des autres. C'est carré, c'est propre. J'aime. Ça a le killou seal of approval des trucs simples et qui juste marchent®.

Mon laptop principal est sous Arch. Arch à le killou seal of approval des trucs cool depuis 2007 (privilège partagé avec gentoo, LFS et OpenBSD). J'ai beaucoup aimé découvrir Arch. Rien ne m'était caché, tout m'était accessible. C'était un lieu idéal pour l'apprentissage et la manipulation des systèmes GNU/Linux/X/… tout en étant plus facile d'accès que Gentoo. Avec les années et l'expérince (15 ans quand même >_<), ça a perdu de sa coolitude, de son charme. Je l'utilise par défaut parce que je n'ai pas trouvé mieux depuis. Ça correspondait exactement à mes besoins. Simple, léger, ça juste marche. À tel point que ça en est ennuyeux. Y'a plus de surprise. Plus de magie. Une ou deux fois par an, un mail sur la mailing list prévenant d'une opération manuelle à effectuer lors d'une mise à jour. Et c'est à peu près tout. J'ai tout qui marche comme je veux, pourquoi est-ce que je chercherai à bidouiller/casser des trucs ? Bref, c'est devenu ennuyeux.

L'envie de nouveauté m'a poussé à remplacer Arch par NixOS. Je sais que cela va rapidement devenir ennuyeux parce que ça marche trop bien. Mais avant d'en arriver là, j'ai encore plein de trucs à maitriser, donc ça devrait aller quelque temps. Pis comme de toute façom je n'ai pas trouvé mieux, faudra faire avec.

Alors pourquoi NixOS c'est mieux que tout ? Déjà, comme mentionné plus haut, c'est très simple. La maintenance du système se résume à l'édition du fichier config. Y'a rien d'autre à faire, la magie (problament très noire et malfaisante mais diablement efficace) s'occupe de tout. À partir de là, je peux versionner la config avec git et facilement revenir en arrière si je ne suis pas satisfait de mes changements. La magie s'occupe de désinstaller et installer ce qu'il faut, générer les fichiers de configs qu'il faut, et recharger tout ce qu'il faut. La magie est tellement puissante qu'elle arrive à demander à i3 de relire sa config quand je modifie cette dernière dans configuration.nix. Yup, une bonne partie de mes dotfiles est directement géré par NixOS. Là, vous pourrez trouvez ma config pour i3. Bref, le système est toujours dans un état propre et à jour. J'aime même vu des exemples de configuration où les gens n'avaient des partitions que pour /boot, /home et /var (et la partition maudit /nix permettant l'accomplissement de la magie); / étant généré dynamiquement au démarage et monté en lecture seule. Car après tout, avec un tel systèm déclaratif et dynamique, pourquoi s'embeter à stocker / ? Avoir sa config avec git, c'est bien. Mais quid en cas de fuckage suffisant au point que le système ne boot plus ? Ben figurez-vous que le système aussi est versionné. à Chaque fois que nixos-rebuild s'exécute avec succès, il créait une nouvelle entrée dans le boot loader pour charger votre système nouvellement créer. Imaginez ici une capture d'écran de mon bootloader me permettant de choisir entre différentes générations du système (différentes options sont disponibles tel que "NixOS generation 85 - 2022-11-08", "NixOS generation 86 - 2022-11-08" ou "NixOS generation 87 - 2022-11-10"). Vous pouvez donc facilement rebooter à un état antérieur du système qui n'était pas encore cassé et retourner à vos occupations. C'est magique. Ça marche. J'aime. Ça a le killou seal of approval des trucs cools et simples qui juste marchent. Y'a la gestion des paquets aussi qui est bien. C'est très simple, y'en a pas. Je demande au système de me rendre tel logiciel disponible, et il s'occupe de tout. Je veux virer un truc, je supprime la ligne idoine dans configuration.nix et tadam, la magie fait le reste. Mon système est propre. Et il le reste. Tous les fichiers gérés par NixOS sont en lecture seule. Impossible d'éditer un fichier de config pour ajouter une option afin de tester un truc à la rache sur redis. Tu modifies la variable packages.services.redis.bla idoine et ton système reste propre et carré. Mais quid si je veux juste installer un truc à la rache ? Y'a une commande pour ça. Elle va automatiquement créer un nouvel environnement temporaire où le programme est disponible. Je quitte le shell, l'environnemnt est détruit. Pensez containers, mais sans les containers. Conceptuellement, un shell avec une variable $PATH augmenté d'une entrée vers un dossier temporaire contenant le programme désiré. Ce n'est pas du containeur ou du chroot. Vous êtes toujours pleinement dans votre système.

jtremesay@edemaruh ~> ruby
The program 'ruby' is not in your PATH. It is provided by several packages.
You can make it available in an ephemeral shell by typing one of the following:
  nix-shell -p jruby
  nix-shell -p logstash6-oss
  nix-shell -p logstash7-oss
  nix-shell -p ruby
  nix-shell -p ruby_3_0
  nix-shell -p ruby_3_1
jtremesay@edemaruh ~ [127]> nix-shell -p ruby

[nix-shell:~]$ ruby 
^CTraceback (most recent call last):
ruby: Interrupt


[nix-shell:~]$ 
exit
jtremesay@edemaruh ~ [SIGINT]> which ruby
which: no ruby in (/run/wrappers/bin:/home/jtremesay/.nix-profile/bin:/etc/profiles/per-user/jtremesay/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin:/home/jtremesay/.local/bin)

Y'a même plus de sens à la notion de paquets installés. Y'a les trucs que je veux qu'ils soient tous le temps disponibles et indiqués dans configuration.nix et y'a les trucs dont j'ai besoin que très ponctuellement et dont ça ne me dérange pas de taper quelques caractères de plus pour les avoir. Au moins je n'aurai pas à payer le coup de sa mise à jour lors de la mise à jour du système, seulement lors d'un très éventuel usage futur. De plus, ça permet de créer des environnement de développement très propre. Vous faites votre shell.nix qui contient les trucs nécessaire à votre projet, et nix-shell. Genre pip install -r requirements.txt sauf que ça s'occupe d'installer python et tous le reste. De cette manière, vous vous assurez que tous le monde utilise les mêmes libs et versions, diminuant fortement l'occurence des chezmoiçamarche®. C'est le genre de truc que j'aurai aimé avoir que je faisais du C++. J'ai pas encore fini de tout explorer, mais il semblerait qu'il soit aussi possible de gérer des groupes de containers remplaçant ainsi les outils tel que docker compose pour avoir un truc simple et pas relou à la maison. Toutes les options de configurationt disponibles sont disponible . La liste des paquets est disponible .

Bref, voici quelque unes des raisons pour lesquels NixOS est le meilleur système du monde.

Retournons à mon laptop principal. Insertion de la clé USB. Allumage du laptop. Mashage de toutes les touches parce que je ne me souviens jamais de quel touche permet de choisir le périphérique de boot (déso / pas déso, je n'ai pas à réinstaller souvent). Boot sur la clé USB. passage du clavier en bépo. Formatage. On va rester sur un truc simple. Parce j'aime les trucs simples qui juste marchent. 2 "disques" NVMe de 1 To, chacun contenant un swap chiffré par LUKS (cryptsetup luksFormat /dev/sda2 && cryptsetup open /dev/sda2 swap0 && mkswap /dev/mapper/swap0 + pareil sur sdb avec swap1) (le swap n'est utilisé que pour l'hibernation, cela fait sens de les chiffrer) et une partition chiffrée utilisées dans un btrfs en raid 1 (cryptsetup … && mkfs.btrfs -d raid1 -m raid1 /dev/mapper/root{0,1}). Y'a aussi une petite partion fa32 pour l'ESP (UEFI system partition )(mkfs.vfat -f32 /dev/sda1). On monte les partitions (swapon /dev/mapper/swap{0,1} && mount /dev/mapper/root0 /mnt && mkdir /mnt/boot && mount /dev/sda1 /mnt/boot). On génère la config initiale (nixos-generate-config --root /mnt). On fait des ajustements (vim /mnt/etc/nixos/configuration.nix) (ATTENTION: si vous utilisez des partitions chiffrées nécéssaires au boot, il faut l'indiquer ici. Un exemple est disponible . Tout le reste est detecté automatiquement sauf ça -_-). On fait le bootstrap (nixos-install). On reboot (reboot). Le bootloader a bien été configuré, notre système démarre. Il nous demande bien la phrase de déchiffrement des différentes partitions (une seule phrase pour les 4 partitions parce que c'est déjà suffisament bien relou à taper comme ça). Toute la séquence de boot se passe bien. On arrive sur le prompt. On se connecte en root, on récupére la configuration du laptop secondaire via une clé usb, nixos-rebuild && reboot. Une phrase de déchiffrement plus tard, on arrive sur notre bureau plasma et tous nos programmes sont installés. As expected. Simple et cool. Ça juste marche. Il est temps de faire la configuration fine du système. Après quelques heures passés dans la doc et la config, j'ai accouché d'une monstruosité. Dans ce dépot, j'ai la config pour récréer mon système pour qu'il soit tel que je l'aime (i3, xterm, fish, XRessources au petits oignons, nvim avec quelques plugins) tout en tenant compte des différences hardware (une machine intel avec carte graphique intégré et l'autre avec amd et nvidia + drivers proprio; Aussi des différences dans le formatage : btrfs raid 1 vs ext4 over lvm). Bref, (re-)installer une nouvelle machine se résume à formater; git clone; nixos-install; récréer les comptes partout (firefox sync, thunderbird, deltachat, nextcloud-desktop, keepass, steam) et la machine et prête pour le service. Pas de surprise. Simple et efficace. Ça juste marche.

Grace à sa nature déclarative et un dépot git, je peux facilement avoir le même système partout. nvim . && git add . && git commit && git push d'un côté, git pull && nixos-rebuild switch de l'autre. Tadam. La magie noire fait le reste.

Après quelques jours à l'avoir utilisé activement, je suis très satisfait. J'ai pu jouer à mes jeux steam. J'ai pu mettre en place un environement pour faire du dev web "moderne" avec vue.js (:cry: mais plus la partie purement nodejs parce que j'y comprends rien. Pas la mise en place de l'environnement dans NixOS crée à coup de nix-shell -p nodejs :P).

La magie noire est assuré par le gestionnaire de paquet Nix et le langage de programmation (configuration ?) Nix qui méritent un journal dédié.

À court terme, j'envisage de passer mon serveur @home de OpenBSD vers NixOS. Il n'héberge que quelques apps php et mon site perso. La migration devrait être facile. Juste le temps de faire des expérimentations avec les stacks webs sur n'importe laquelle de mes maintenant totalement interchangeables machines. Pas de peur de crader le système, git revert && nixos-rebuild switch si on est pas satisfait. git add . && git commit si on est satisfait. Pas peur de rater une ligne dans un fichier de config lors de l'installation du serveur. Tout est versionné et a déjà était testé. C'est simple, c'est propre, ça juste marche. Ça m'ennui déjà… Où est la plaisir ? Où est la découverte ?

trucs ayant le killou seal of approval c'est simple et ça juste marche® :

  • NixOS
  • Arch Linux
  • OpenBSD (pas en desktop; mais en petit serveur @home, c'est fabuleux <%)
  • i3
  • xterm
  • fish
  • la bouilloire en fonte
  • la gourde en alu à fermeture comme la bouteille de limonade en verre façon traditionelle, si tu sais comment ça s'appelle n'hésite pas à le dire dans les commentaires
  • le rasoir de sureté (todo: essayer le rasoir sabre)/blaireau/savon
  • l'Opinel (mon cœur dit Laguiole, la praticité dit Opinel)
  • le vélo
  • # à fond la forme

    Posté par  . Évalué à 6. Dernière modification le 10 novembre 2022 à 22:13.

    Sur la forme évite les gros pâtés de texte, ça donne pas envie de lire, mais vraiment pas… Alors que le sujet est intéressant.

    Sur le fond, NixOS est dans mon bookmark todo depuis 15 jours et j'ai testé hier. Ce que je trouve génial :

    • l'idée de reproductibilité d'installation, permet des déploiement au poil près
    • le cassage en règle de la FHS
    • la distinction entre les paquets system et user
    • le test de build suite à une mise à jour
    • le fichier de configuration centrale avec les anciennes version dans le bootloader
    • la simplicité et l'efficacité

    Ce qui tu as résumé plus simplement par le côté ennuyant dans un sens qu'on aime bien dans l'informatique : sans surprise, sans effet de bord.

    • [^] # Re: à fond la forme

      Posté par  (site web personnel) . Évalué à 10.

      Sur la forme évite les gros pâtés de texte, ça donne pas envie de lire, mais vraiment pas… Alors que le sujet est intéressant.

      C'est justement parce que ça m'interesse que je m'emporte >_< Je crois que je ne sais pas faire simple et concis.

      Ce que je trouve génial :

      • l'idée de reproductibilité d'installation, permet des déploiement au poil près
      • le cassage en règle de la FHS
      • la distinction entre les paquets system et user
      • le test de build suite à une mise à jour
      • le fichier de configuration centrale avec les anciennes version dans le bootloader
      • la simplicité et l'efficacité

      et le fait que ça passe facilement à l'échelle

      Ce qui tu as résumé plus simplement par le côté ennuyant dans un sens qu'on aime bien dans l'informatique : sans surprise, sans effet de bord.

      C'est parfait pour la prod, ça manque d'un petit peps pour le desktop. C'est la première fois qu'un OS est aussi effacé. Une fois investi le temps dans la configuration initale, je n'interagi plus avec lui. Ce n'est pas un jouet avec lequel s'amuser, c'est un outil froid et impitoyable qui s'occupe de tout pour toi. Le cœur me pousse à retourner vers archlinux et openbsd, mais la raison me pousse à rester sur nix pour le gain de temps.

      • [^] # Re: à fond la forme

        Posté par  . Évalué à 5. Dernière modification le 10 novembre 2022 à 23:22.

        Non, non, la forme est très bien, change pas j'ai beaucoup rigolé.

        la bouilloire en fonte

        en fonte, t'es sûr là ?

        • [^] # Re: à fond la forme / Le Creusot

          Posté par  . Évalué à 2.

          Un bon vieux caquelon Le Creusot pourrait gagner un nouveau badge bouilloire, juste en lui mettant de l'eau à bouillir dedans :-)

          L'approche a 4 maillons faibles : le prix du nécessaire gaz, la passoire thermique qu'est la cuisine vu les aérations non obturables obligatoires, le faible rendement pour chauffer un mug d'eau, et les émissions de CO2 de la méthode. Tout compris, cette bouilloire certes juste marche super bien mais seulement si on oublie ce qu'elle cause ;-)

    • [^] # Re: à fond la forme

      Posté par  . Évalué à 5.

      Sur la forme évite les gros pâtés de texte, ça donne pas envie de lire, mais vraiment pas… Alors que le sujet est intéressant.

      Ça dépend pour qui. Pour ma part, je n'ai même pas remarqué qu'on pouvait y voir du pâté (de tête ?), chaque paragraphe traite d'un point, c'est bien articulé, non, je ne trouve pas que c'est rébarbatif, bien au contraire, on commence à lire et on veut la suite… ;-) (oui, au fait, il y aura un épisode 2 ? ;-p)

      Pour ma part, c'est la ioutioubmanie qui m'insupporte, alors que la majorité aime bien (mais pas sur DLFP, ouf !) et en place partout. Moralité : ne définis pas comme généralité ce qui tient à ton goût personnel.

      • [^] # Re: à fond la forme

        Posté par  . Évalué à 6.

        Et ben moi j'ai lâché à la moitié. Le sujet m'intéresse et c'est pour ça que je me suis accroché tant qu'il s'agissait de généralités, après quoi les paragraphes ont commencé à prendre la totalité de mon écran. J'y reviendrait peut-être plus tard même si c'est peu probable.

        Je ne dis pas ce que l'auteur doit faire ou pas, mais s'il y a besoins de feedback sur la question, moi aussi ça m'a gêné.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Gourde

    Posté par  . Évalué à 5.

    Le système de fermeture de bouteille que tu décrit se nomme 'fermeture mécanique', aussi appelé 'fermeture à cannette'.
    Sinon, très bonjour, nal, très intéressant malgrès les gros pavés.
    Il faut que je zyeute si ils font un truc pour les tartes à la framboise.

    Il y a 10 sortes de gens dans le monde – ceux qui comprennent le ternaire, ceux qui ne le comprennent pas et ceux qui le confondent avec le binaire.

    • [^] # Re: Gourde

      Posté par  (site web personnel) . Évalué à 3.

      Le système de fermeture de bouteille que tu décrit se nomme 'fermeture mécanique', aussi appelé 'fermeture à cannette'.

      Merci !

  • # Songe

    Posté par  . Évalué à 4.

    J'y songe moi aussi mais j'utilise des logiciels propriétaires qui ont l'air d'être un enfer à packager pour nix.

    Du coup ma debian reste très tranquille

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Songe

      Posté par  (site web personnel) . Évalué à 3.

      Bof, cela dépend.

      Maintenant t'as https://nixos.wiki/wiki/Packaging/Binaries#Using_AutoPatchelfHook et associés. En gros pour faire un package nix sur un truc proprio, tu dois:

      • Fetch le binaire
      • Ajouter les dependences
      • utiliser les auto patchs pour patcher les library path et autre shebang
      • recommencer à ajouter des dependences tant qu'il y a des warnings.

      C'est sensiblement le même processus qu'un package debian. Je ne dis pas, des fois c'est vraiment l'horreur, mais c'est pas pire que pour un autre système. La seule difference c'est que des fois les trucs proprio sont déjà packagés pour les distributions classiques.

  • # buildroot

    Posté par  (site web personnel) . Évalué à 4.

    C’est amusant, j’ai en tête un journal un peu similaire sur buildroot. La version 2022-11 est en RC-1, je comptais me laisser un peu le temps avant la sortie pour préparer ce que j’avais à y mettre :)

  • # Pays de l'ennui

    Posté par  . Évalué à 7.

    Bienvenue au pays de l'ennui !

    Pour ce qui est de la magie noire, c'est juste des modules écrits dans le langage Nix, ça revient au même que d'utiliser des playbooks ansible au final, sauf que c'est écrit spécifiquement pour NixOS et que ça s'intègre bien 👍

    Il y a un framework de test de malade aussi dans Nixpkgs (la collection de packages par défaut utilisée par Nix), genre recommence d'image pour vérifier qu'une fenêtre graphique apparait bien ou démarrer plusieurs VMs en réseau pour tester un serveur quake 3 côté client et serveur 🤪 et le pire, c'est qu'il suffit juste de lancer nix-build nixos/tests/{le_test} depuis le répertoire du répo pour les exécuter, pas de setup compliqué 🙀 C'est d'un ennui.

    • [^] # Re: Pays de l'ennui

      Posté par  (site web personnel) . Évalué à 1.

      "ça revient au même que d'utiliser des playbooks ansible au final"

      Justement, pour quelqu'un (un ami) qui est déjà habitué à l'écriture de playbooks pour décrire ses configs, quel serait son intérêt ?

      • [^] # Re: Pays de l'ennui

        Posté par  (site web personnel) . Évalué à 3.

        Ansible ne sert pas qu'à installer par exemple. Ça peut servir pour faire des opérations (sauvegarde, mise à jour séquentielle dans une grappe de serveurs de base de données, audit de conformité, etc.).

  • # how nixos do it

    Posté par  . Évalué à 7. Dernière modification le 13 novembre 2022 à 19:48.

    J'ai toujours des interrogations après avoir testé nixos et lu pas mal de doc. À chaud :

    La doc est éclatée, au sens propre comme au figuré

    Il y a le manual officiel qui explique bien comment installer et le fait que tout est piloté via le configuration.nix et nixos-rebuild switch. On setup assez facilement les quelques paquets systèmes. Après plus rien. Il faut chercher, un peu de le wiki non officiel et beaucoup sur google et quelques blogs.

    Dès qu'on veut rentrer dans le détail de choses simples, tout est mélangé entre les syntaxes officielles, nouvelles expérimentales, des définitions à la "inception" sans fin. J'ai été rassuré quand d'autres ont ressenti la même chose.

    configuration.nix

    Au bout de quelques heures, j'ai capté que l'ensemble des options du configuration.nix se trouvent ici. ça m'éviterait une meilleure visibilité.

    NixOS xor Nix

    La doc Nixos renvoie parfois sur Nix pour certaines commandes et là, je fini par être perdu. Nixos et sa config globale par root mais dont certains utilisateurs non root peuvent utiliser nix comme gestionnaire de paquets. Parfois ça parle de fichier .nix utilisateur sans expliquer ou les stocker et comment les appeler ? Pareil pour des bouts de code de config, difficile de savoir ou les mettre.

    How nixos do it

    Finalement, ce qui serait intéressant c'est une tableau comparatif "other distros" vs "Nixos" sur les tâches ou actions habituelles sous linux.

    Questions
    • nixos sait faire tourner des images dockers ? c'est la bonne façon de faire ?
    • nixos sait faire tourner des images avec podman, un exemple de config simple ?

    J'ai encore des heures de docs et tests à me taper…

    • [^] # Re: how nixos do it

      Posté par  . Évalué à 4. Dernière modification le 14 novembre 2022 à 10:47.

      Exemple de container appsmith tournant via podman :

          { config, pkgs, ... }:
          let
            host = "appsmith.mondomaine.fr";
          in
          {
            virtualisation = {
              podman = {
                enable = true;
                dockerCompat = true;
              };
              oci-containers = {
                backend = "podman";
                containers.appsmith-ce = {
                  image = "appsmith/appsmith-ce";
                  autoStart = true;
                  ports = [ "5002:80" ]; #server locahost : docker localhost
                };
              };
            };
          }
      

      J'ai un dossier docker dans lequel j'ai les fichiers .nix spécifiques à chaque application (j'en utilise 3). Ce dossier est dans le dépot git et accessible à l'ensemble des mes environnements (une petite dizaine de machines physiques et virtuels, du laptop à la workstation au serveur physique, à la maison ou chez un hébergeur sur le net)

      Ce que tu as fais une fois, tu peux le partager avec les autres systèmes. Tu arrêtes de perdre ton temps.

      Nixos, passé la phase d'intro, c'est top.

      • [^] # Re: how nixos do it

        Posté par  . Évalué à 2.

        J'ai un dossier docker dans lequel j'ai les fichiers .nix spécifiques à chaque application (j'en utilise 3)

        Ces scripts nix sont importés par le configuration.nix et mise à jour en root avec nixos-rebuild switch ou exécutés avec un simple utilisateur ? si oui quelle commande ?

        C'est sur cette partie : distinction entre config par root du système et config environnement utilisateur par un utilisateur sur laquelle je butte.

        Merci pour cet éclairage

        • [^] # Re: how nixos do it

          Posté par  . Évalué à 2.

          Tout est possible :D

          Dans le configuration.nix :

          imports = [
          ./hardware-configuration.nix
          ../docker/appsmith.nix
          Installation via la commande classique : sudo nixos-rebuild switch

          Mais perso, j'ai un dossier nixos-config avec toutes les config (host/module/docker)
          host = le dossier nixos de chaques machine
          modules = des fichiers nix spécifiques à certaines appli, comme grafana ou nextcloud
          docker = dossier contenant la configuration d'une application devant tourner sous docker/podman

          sur chaque machine, j'ai remplacé le dossier /etc/nixos par un lien qui pointe sur $HOME/git/nixos-config/hosts/lamachine

          ainsi, j'édite la configuration avec un user standard, je rebuild+switch via sudo et tous les modules fichiers de confs sont réutilisable sur chaque machine vu que tout est dans 1 seul dépot git

          Pour les machines desktop, j'utilise home-manager pour les configurations user.

          • [^] # Re: how nixos do it

            Posté par  . Évalué à 3.

            Pour compléter ma réponse. Si l'application est utilisée que par mon user, home-manager

            Si c'est un service (X ou web) : configuration.nix et les imports de fichiers

            X est installé en tant que service vi configuration.nix

            La configuration de i3status est faite via home-manager

            Y a pas de regle absolue, pour moi c'est du feeling. Le tout c'est de rester cohérent et pas avoir besoins de faire sudo dès que j'ai besoins d'un truc (nix-shell pour une exécution immédiate d'une commande et pour des projets particuliers, en plus de direnv )

            • [^] # Re: how nixos do it

              Posté par  . Évalué à 4.

              Y a pas de regle absolue, pour moi c'est du feeling.

              Plusieurs façons de faire, effectivement.

              J'aimerai migrer de docker à podman afin de gagner en sécurité/gestion sur notre serveur de build/préprod entre plusieurs développeurs :

              • actuellement avec docker : un accès compte unique admin sur portainer que tout le monde utilise. Ou des comptes qui ont tous un accès à docker via sudo et potientiellement un dév peut poutrer le container d'un autre.
              • migration vers podman : chaque dév avec son compte, sans privilège particulier ni sudo. Il lance son container, sur une plage de ports qui lui sera dédié, et sous sa session non accessible aux autres.

              Pour la prod, même idée, ce sont des comptes spécifiques pour chaque applications (containers) qui seront lancés via une config globales (import dans le configuration.nix). Mais dans ce cas, chaque container sera lancé par un user dédié. Possible ?

              • [^] # Re: how nixos do it

                Posté par  . Évalué à 2. Dernière modification le 14 novembre 2022 à 14:12.

                je me réponds :

                En root, mettre la config podman dans le configuration.nix avec nixos-rebuild pour l'avoir au niveau système.

                virtualisation = {
                ## setup podman
                podman = {
                enable = true;
                dockerCompat = true;
                defaultNetwork.dnsname.enable = true;
                };
                };

                En simple user, lancer un socket podman

                systemctl --user start podman.socket
                Puis la commande classique podman en console…

                podman run ...

          • [^] # Re: how nixos do it

            Posté par  . Évalué à 2. Dernière modification le 15 novembre 2022 à 11:50.

            Tu ne t'exposes pas à un risque d'escalade de privilèges en éditant le fichier de conf avec un user standard (et en t'accordant les droits nécessaires en tant qu'user) ?

            Ça, ce sont les sources. Le mouton que tu veux est dedans.

            • [^] # Re: how nixos do it

              Posté par  . Évalué à 2.

              à mon sens, tu as autant de risques qu'en exécutant une commande avec sudo sur n'importe quel distribution à la différence près que git te montrera que ton fichier à été modifié, donc tu sauras qu'il y a eu un usage inaproprié.

              Par contre le retour arrière sera quand même vachement plus simple

  • # Je m'emmerde encore plus que toi

    Posté par  (site web personnel) . Évalué à 3.

    Perso, j'ai longtemps pensé à migrer de Arch/Fedora vers Nix et puis finalement, j'ai jeté mon dévolu sur Silverblue.

    Bon, résultat, j'ai presque pas configuré un truc sur ma machine depuis l'installation en fait (hormis Flathub en mode user et le mode staged de rpm-ostree).

    Ca fonctionne tout seul, vraiment tout seul.

  • # D’accord ! mais…

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 05 décembre 2022 à 16:16.

    Je partage complètement l’avis exprimé par killruana.

    Mais un conseil : n’utilisez pas Gnome avec NixOS. Ou alors expliquez-moi comment.

    Sur un NixOS très basique, je rencontre des problèmes (exemple1, exemple2) et au fil des commentaires, on découvre que sous un magnifique emballage, la réalité n’est pas toujours très propre…

    Cela dit, j’ai conscience que le problème est lié à tel ou tel logiciel ou techno (Wayland vs X11), et non à Nix et son cœur technologique.

  • # Guix ?

    Posté par  . Évalué à 2. Dernière modification le 21 décembre 2022 à 10:20.

    Je suis étonné que personne ne mentionne Guix en alternative à ce sujet sur Nix, qui me semble plus "libre" :

    https://linuxfr.org/news/nix-1-7-nixpkgs-et-nixos-14-04-guix-0-6#guix-le-nix-de-gnu

    Désormais en version 1.4 : https://guix.gnu.org/

Suivre le flux des commentaires

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