La systemd.conf 2016 a eu lieu récemment, les conférences ont été (bien) filmées, et les vidéos sont disponibles sur YouTube.
Vous pouvez commencer au début, par la présentation de Lennart Poettering: State of the Union/Portable Services. On voit qu'on se rapproche de plus en plus des systèmes stateless, le support du « factory reset », etc (voir cet article de 2014 à ce sujet). It's happening it's happening it's happening!
Il y a beaucoup d'autres présentations, par exemple :
- les concepts de bus1 dans le kernel (pour une meilleure implémentation de D-Bus, après la tentative kdbus) ;
- la gestion du DNS et DNSSEC ;
- les conteneurs ;
- NixOS ;
- l'utilisation de systemd dans les systèmes embarqués ;
- Config management ;
- Déployer systemd dans des gros data-centers ;
- systemd pour une session graphique (le desktop) ;
- et bien d'autres.
Arrêtez-vous bien à la fin ;)
# Vivement la fin du userland
Posté par OhMyGod . Évalué à -8.
Ce ne sera plus qu'un mauvais souvenir …
# Nixos...
Posté par Katyucha (site web personnel) . Évalué à 7.
J'utilisais Debian depuis 2000. 16 ans de Debian , je n'ai jamais réussi à adopter une autre distrib… jusqu'à NixOS. J'ai tout plaqué et vendu mon ame à ce linux.
La gestion des paquets, la gestion par fichier nix, le /etc en lecture seule…etc Bref, NixOS m'a adopté
[^] # Re: Nixos...
Posté par bubar🦥 (Mastodon) . Évalué à 5.
Il y a aussi « Clear Linux » qui se situe un peu dans la même veine, mais c'est du 100% Intel (et en bureau graphique c'est Xfce ou .. rien)
[^] # Re: Nixos...
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 10 octobre 2016 à 14:43.
J'ai testé et je trouve ça bien complexe… Genre le fichier de conf ou tu mets tout en vrac:
services = {
journald.rateLimitBurst = 0;
journald.rateLimitInterval = "0";
xserver.enable = true;
xserver.displayManager.gdm.enable = true;
xserver.desktopManager.gnome3.enable = true;
};
Je n'aime pas du tout… Pourquoi je ne peux pas faire systemctl enable gdm?
[^] # Re: Nixos...
Posté par Sébastien Wilmet . Évalué à 3.
Ton fichier de config tu peux le mettre dans Git. Pour un re-déployement c'est plus facile.
[^] # Re: Nixos...
Posté par newïc . Évalué à -2.
Moi avec Git je fais une sauvegarde de mon service USB et avec l'app git je le re-déploye.
[^] # Re: Nixos...
Posté par Katyucha (site web personnel) . Évalué à 3. Dernière modification le 10 octobre 2016 à 20:16.
Il faut aussi le structurer un minimum. Ton fichier de configuration, c'est du code source déclaratif
=> Je reprends ton exemple
Voila, plus propre, plus lisible.
EDIT : pourquoi tu fais un systemctl… => Bah parce que c'est ta configuration qui le fait : Computer as a code :)
[^] # Re: Nixos...
Posté par gnumdk (site web personnel) . Évalué à 4.
Parce que le systemctl, il est générique, je connais la syntaxe, ça fonctionne pour tous les services…
Là j'ai à me souvenir de xserver, enable = true, displayManager.gdm.enable = true…
Bref, en plus, c'est ce que fait SUSE depuis des années, je n'y vois rien de nouveau…
Après le gestionnaire de paquet semble intéressant mais loin d'être user friendly quand on compare avec un pacman…
[^] # Re: Nixos...
Posté par Katyucha (site web personnel) . Évalué à 2.
C'est bien le problème sous Linux. Y a trop de distribution, c'est difficile de s'y retrouver !
Si ta Suse te satisfait et que t'accroche pas à NixOS et ben, j'ai envie de dire tant pis : t'auras essayé au minimum. La meilleure distrib, c'est celle qu'on aime :)
[^] # Re: Nixos...
Posté par Kerro . Évalué à 4.
Parce que ce n'est pas (du tout) l'objectif de cette distribution.
Schématiquement cette distribution n'a pas de ligne de commande. Uniquement des fichiers de configurations (je force le trait, je précise pour les pénibles) un peu comme avec Chef ou Puppet. On a donc effectivement un système plus ou moins « sans état », il est le reflet de ses fichiers de configuration.
Tu installes une nouvelle machine ? Il suffit de copier la configuration.
En réalité tout n'est pas si rose. Une simple ligne de configuration ne permet pas encore de passer de mdadm+ext4 à zfs par exemple.
[^] # Re: Nixos...
Posté par benja . Évalué à 4.
Un autre point sensible, amha, c'est justement le langage Nix. Il me semble que, tôt ou tard, le besoin se fait sentir d'ajouter de la modularité et de l'abstraction. Du coup, le risque de se retrouver avec une "surcouche" au dessus de Nix me semble important. De ce point de vue, Guix me semble bien mieux placé. Guix est Nix avec la partie déclarative remplacée par un moteur scheme (guile). Notez que je n'ai jamais utilisé Nix (guix bien) donc mon analyse est forcément erronée ;-)
[^] # Re: Nixos...
Posté par Kerro . Évalué à 3.
Ça me semble tout à fait circonstancié comme remarque, car tant qu'à automatiser, il faut pouvoir utiliser à peu près ce qu'on veut comme language, ou au moins pouvoir faire appel à des programmes externes pour récupérer des paramètres.
# Vivement 'dredi
Posté par benja . Évalué à 5.
J'ai écouté attentivement un des talks de Lennart, simplement pour me tenir au fait des prochaines révolutions qui attendent le gentil utilisateur que je suis[1]. J'ai appris que son objectif actuel était d'implémenter des uid/gid dynamiques. Si j'ai bien compris, l'idée serait d'ajouter une couche de traduction (utilisant la technologie des namespaces) entre l'application et le filesystem. Celle-ci serait aussi responsable de maintenir une base de donnée contenant ces associations dynamiques. J'avoue avoir du mal à évaluer l'intérêt d'une telle fonctionnalité[2], il y a-t-il quelqu'un pour m'éclairer ?
1: Globalement je suis satisfait, j'ai le sentiment d'avoir un peu de répit avant de devoir me réadapter au sens Darwinien.
2: Je peux bien m'imaginer la complexité que ça va engendrer au niveau administration… enfin… quel est le prix de la survie ?
[^] # Re: Vivement 'dredi
Posté par Sébastien Wilmet . Évalué à 5.
Les user/group IDs dynamique, ça permet d'installer/lancer un service, et s'assurer que quand ce service est stoppé/désinstallé, le système soit redevenu comme avant, à part éventuellement les data et les logs.
Si pour lancer un service, ce service a besoin de créer un utilisateur ou un groupe, quand le service est stoppé il faut que l'utilisateur/groupe soit retiré. Pour avoir un système sans état (stateless). Les UID/GID fixes font partie de l'état.
Donc en gros l'idée c'est d'installer son OS, que l'image de cet OS soit read-only, qu'il y ait toujours moyen de revenir à cet état (factory reset), et que pour lancer des services, ces services créent (temporairement) l'état qu'ils ont besoin. Quand un "service portable" est stoppé/désinstallé, systemd s'assurera de faire un revert de tout l'état qu'a modifié ce service (en gardant les données à ne pas supprimer, bien entendu).
Et un "service portable" sera portable du fait que ça fonctionnera sur n'importe quelle distribution Linux (avec une version suffisamment récente du noyau et de systemd). C'est un container, mais mieux intégré au système (moins isolé). C'est une solution plus sécurisée, pour remplacer les super privileged containers.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.