L’heure du test — épisode 1 — NixOS

• # Euh…

  Posté par barmic le 28 avril 2017 à 15:54. Évalué à 0.

  

  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 Goffi (site web personnel, Mastodon) le 28 avril 2017 à 20:53. Évalué à 7.

  

  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 Katyucha (site web personnel) le 29 avril 2017 à 13:18. Évalué à 3.

    

    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 Arthur Accroc le 30 avril 2017 à 07:56. Évalué à 6.

      

      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 ?

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: Plus difficile

        Posté par barmic le 02 mai 2017 à 16:48. Évalué à 3.

        

        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 Arthur Accroc le 03 mai 2017 à 06:39. Évalué à 2.

          

          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…).

          « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

          • [^] # Re: Plus difficile

            Posté par barmic le 03 mai 2017 à 11:52. Évalué à 4.

            

            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 Arthur Accroc le 07 mai 2017 à 16:03. Évalué à 2.

              

              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.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

      • [^] # Re: Plus difficile

        Posté par galbolle le 10 mai 2017 à 17:50. Évalué à 3.

        

        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 lancelotsix le 02 mai 2017 à 16:48. Évalué à 3.

      

      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 41px le 21 mai 2017 à 18:10. Évalué à 1.

      

      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 lancelotsix le 02 mai 2017 à 17:12. Évalué à 4.

    

    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 nokomprendo (site web personnel) le 28 avril 2017 à 21:27. Évalué à 10.

  

  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.

  • [^] # Re: mouais...

    Posté par MTux le 28 avril 2017 à 22:10. Évalué à -1.

    

    Y'a écrit "épisode 1"…

    • [^] # Re: mouais...

      Posté par nokomprendo (site web personnel) le 28 avril 2017 à 22:17. Évalué à 9.

      

      oui, y'a même écrit "épisode 1 - NixOS"
      donc pour moi, ça veut dire que l'épisode 2 sera sur une autre distrib; et je ne vois rien qui laisse penser le contraire

      • [^] # Re: mouais...

        Posté par ZeroHeure le 28 avril 2017 à 23:17. Évalué à 9.

        

        Il est d'ailleurs en cours de rédaction… http://linuxfr.org/redaction/news/l-heure-du-test-episode-2-linux-mint Il ne tient qu'à vous, lecteurs, de rendre ce genre d'articles plus intéressant, en y participant.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • [^] # Re: mouais...

    Posté par Katyucha (site web personnel) le 29 avril 2017 à 13:20. Évalué à 1.

    

    T'inquiete pas, on est sous Linux, rien n'est imposé. J'adore cette distro épicétout !

• # Logo

  Posté par Ant le 29 avril 2017 à 10:14. Évalué à -4.

  

  É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 xcomcmdr le 29 avril 2017 à 10:33. Évalué à 7.

    

    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 Benoît Sibaud (site web personnel) le 29 avril 2017 à 14:43. Évalué à 4.

    

    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 gusterhack le 30 avril 2017 à 09:59. Évalué à 6.

  

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

• # Une configuration non à jours

  Posté par lancelotsix le 02 mai 2017 à 16:41. Évalué à 3.

  

  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 ;)

  • [^] # Re: Une configuration non à jours

    Posté par gusterhack le 03 mai 2017 à 18:58. Évalué à 2. Dernière modification le 03 mai 2017 à 19:00.

    

    Merci de la précision j'avais pas vue ce changement. :)

Suivre le flux des commentaires

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