URL: https://linuxfr.org/news/systemd-version-216 Title: systemd version 216 Authors: manawy esdeem, Davy Defaud, ZeroHeure, ElChinese, Nils Ratusznik, Benoît Sibaud, Melkor73, palm123, BAud, Xavier Teyssier et patrick_g Date: 2014年08月21日T04:11:42+02:00 License: CC By-SA Tags: systemd, gentoo et lennart_poettering Score: 55 Le programme d’init _systemd_ est sorti dans une nouvelle version. Par tradition, cette version ne se contente pas des habituelles corrections de bogues et modifications mineures, mais inclut de nouvelles options qui peuvent affecter tout le monde (sauf les irréductibles de _*BSD_, bien sûr). Cette dépêche présente un aperçu rapide des changements, ainsi qu’une traduction complète du journal des modifications. La dernière section décrit brièvement mon expérience de _systemd_ sous Gentoo. ---- [L’annonce officielle](http://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html) [La page officielle de systemd ](http://www.freedesktop.org/wiki/Software/systemd/) [La page Wikipedia de systemd](https://fr.wikipedia.org/wiki/Systemd) [DLFP : Systemd versions 212 à 215](http://linuxfr.org/news/systemd-versions-212-a-215) ---- Les changements importants ========================== Cette version confirme la vision de _systemd_ comme le chef d’orchestre du système d’exploitation, englobant tous les domaines, pour le meilleur ou pour le pire. Le réseau --------- De nombreuses nouveautés concernant le réseau ont été ajoutées dans cette version. Un nouvel outil, `networkctl`, permet d’obtenir les informations de configurations du réseau. Il est actuellement purement passif, mais devrait dans le futur permettre la configuration du réseau. En particulier, un effort a été apporté aux protocoles NTP, DNS et DHCP. Les deux premiers peuvent désormais utiliser plus d’informations provenant des requêtes DHCP. Les règles de nommage des interfaces ont aussi été changées. Si le noyau indique qu’il fournit un nom prédictible pour une interface, alors _udev_ utilisera ce nom. Il s’agit ici de fournir à l’utilisateur une interface unique pour paramétrer et surveiller le réseau. journald -------- _journald_ peut désormais utiliser l’algorithme LZ4 pour la compression, afin d’améliorer ses performances. Par défaut, il ne transmet désormais plus ses données au démon _syslog_. Ce changement a été décidé puisque _rsyslog_ n’attend plus cette transmission, mais pioche directement dans le journal. Enfin, la transmission du journal vers des machines distantes est facilitée grâce au nouvel outil `systemd-journal-upload`. L’installation d’un nouveau système ----------------------------------- Il est intéressant de noter l’apparition de l’utilitaire `systemd-firstboot` qui permet de configurer les informations de base d’un nouveau système. Voit‐on ici l’émergence d’un outil commun pour l’installation de nos distributions ? Dans le même état d’esprit, `systemd_sysusers` et `/etc/machine-info` disposent de nouvelles options permettant une plus grande flexibilité dans la configuration. La traduction du journal des modifications ========================================== * Désormais `timedated` ne lit plus les noms des implémentations de NTP autres que celle de _systemd_ depuis les fichiers `/usr/lib/systemd/ntp-units.d/*.list`. Les autres implémentations de NTP doivent ajouter la ligne `Conflicts=systemd-timesyncd.service` à leur fichier unité pour prendre la priorité et remplacer l’implémentation de NTP de _systemd_ qui est utilisée par défaut. * `systemd-sysusers` gagne un nouveau type de ligne, appelé `r`, pour configurer les gammes d’identifiants à allouer pour les utilisateurs et groupes système (UID et GID) . Les lignes de type `u` acceptent désormais une nouvelle colonne pour spécifier le répertoire _HOME_ de l’utilisateur qui sera créé. En outre, `systemd-sysusers` peut lire les informations depuis l’entrée standard plutôt que depuis un fichier. C’est utile lorsque l’utilitaire est invoqué par les scripts de pré‐installation d’un paquet RPM (les scripts `preinst`) qui doivent créer l’utilisateur avant de pouvoir créer un fichier, puisque ces fichiers peuvent appartenir à ce nouvel utilisateur. Une nouvelle macro RPM appelée `%sysusers_create_inline` a été introduite pour réaliser cette opération. Enfin, `systemd-sysusers` met à jour le fichier `/etc/shadow`, ainsi que les bases de données des utilisateurs et des groupes. Ceci devrait améliorer la compatibilité avec certains outils tels que `grpck`. * Un certain nombre d’interfaces logicielles (API) du processus 1 (PID 1) peuvent désormais, sous certaines conditions, consulter PolicyKit pour donner l’accès à des clients ne disposant pas des privilèges nécessaires. L’authentification interactive n’est pour l’instant pas encore prise en charge. Cependant, cette fonctionnalité devrait être ajoutée dans le futur. * `/etc/machine-info` dispose désormais de nouveaux champs pour configurer l’environnement de déploiement de la machine ainsi que son emplacement. L’utilitaire `hostnamectl` a été mis à jour avec de nouvelles commandes pour modifier ces champs. * `systemd-timesyncd` a été mis à jour pour obtenir les informations à propos des serveurs NTP depuis `systemd-networkd`, qui peut lui‐même les obtenir à partir des requêtes DHCP. * `systemd-resolved` inclut désormais un cache DNS client qui possède une implémentation complète de la résolution de nom [LLMNR] (https://fr.wikipedia.org/wiki/Link-local_Multicast_Name_Resolution). Un nouveau module [NSS] (https://fr.wikipedia.org/wiki/Name_Service_Switch) `nss-resolve` a été ajouté. Il utilise l’implémentation `nss-dns` de _glibc_ pour résoudre les noms d’hôtes via `systemd-resolved`. Les noms d’hôtes, les adresses ou un [enregistrement de ressource DNS] (https://fr.wikipedia.org/wiki/Liste_des_enregistrements_DNS) peuvent être résolus via les API D-BUS de `systemd-resolved`. Contrairement au solveur interne de _glibc_, `systemd-resolved` est compatible avec des systèmes disposant de plusieurs interfaces : un serveur DNS et un cache sont maintenus pour chaque interface. Les requêtes sont envoyées simultanément sur chaque interface où un serveur DNS est configuré afin de correctement prendre en compte les réseaux privés virtuels (VPN) et les réseaux locaux (LAN) qui pourraient produire différents noms de domaines. `systemd-resolved` peut obtenir les informations des serveurs DNS depuis `systemd-networkd` automatiquement, qui peut les avoir obtenues à partir des informations DHCP. Un utilitaire `systemd-resolve-host` a été ajouté pour obtenir la méthode de résolution DNS du démon `resolved`. `systemd-resolved` implémente [IDNA](https://tools.ietf.org/html/rfc5890 "Internationalized Domain Names in Applications [RFC 5890]") et choisit automatiquement l’encodage IDNA ou UTF-8 en fonction du protocole de transport, le DNS classique ou LLMNR. Dans la prochaine version, il est prévu d’inclure une implémentation [DNSSEC] (https://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) et [mDNS / DNS-SD] (https://fr.wikipedia.org/wiki/Zeroconf) à _systemd-resolved_. * Un nouveau module NSS `nss-mymachines` a été ajouté. Il résout automatiquement les noms de tous les conteneurs locaux enregistrés vers leurs adresses IP respectives. * Un nouvel outil client pour `systemd-networkd`, `networkctl`, a été ajouté. Il est actuellement purement passif et permet d’obtenir les configurations du réseau de `udev`, `rtnetlink` et `networkd`, et de les formater pour les présenter à l’utilisateur. Dans le futur, nous espérons l’étendre pour qu’il soit l’outil de contrôle de `networkd`. * Les unités `.socket` obtiennent un nouveau paramètre : `DeferAcceptSec=` qui contrôle l’option `TCP_DEFER_ACCEPT` pour les _sockets_ TCP [_N. D. T. : cette option est appelée un [sockopt](http://linux.die.net/man/2/setsockopt)_]. De la même façon, la prise en charge du contrôle des paramètres `keep-alive` de TCP a été ajoutée (`KeepAliveTimeSec=`, `KeepAliveIntervalSec=`, `KeepAliveProbes=`). Enfin, la désactivation optionnelle de l’[algorithme de Nagle] (https://fr.wikipedia.org/wiki/Algorithme_de_Nagle) pour TCP a été implémentée (`NoDelay=`). * `logind` a gagné une nouvelle session de type `web`, pour des projets comme [_Cockpit_](https://launchpad.net/cockpit) qui enregistrent des clients Web comme session PAM. * Les unités minuteries avec au moins un paramètre `OnCalendar=` sont désormais démarrées seulement après que la cible `timer-sync.target` a été atteinte. De cette façon, la limite de temps ne peut être atteinte avant que l’horloge système n’ait été corrigée, par exemple par un client NTP local. Ceci est particulièrement utile pour des machines embarquées sans [RTC](https://fr.wikipedia.org/wiki/Horloge_temps_r%C3%A9el), qui ne disposent que d’une horloge système imprécise. * L’option `--network-veth` de `systemd-nspawn` devrait désormais fournir une adresse MAC stable pour les deux côtés de l’interface. * Une nouvelle option `--volatile=` a été ajoutée à `systemd-nspawn` pour exécuter des instances de conteneur avec les dossiers `/etc` ou `/var` vides. * Le code du client `kdbus` a été mis à jour pour utiliser le nouveau sous‐système [_memfd_](http://www.phoronix.com/scan.php?page=news_item&px=MTc2NzQ) du noyau Linux 3.17 à la place de l’ancienne interface spécifique à _kdbus_. * Le client et le serveur DHCP de `systemd-networkd` connaissent désormais l’option `FORCERENEW`. De nouvelles options ont aussi été incluses pour configurer l’identifiant vendeur du client et le mode diffusion (_broadcast_) pour DHCP. * `systemd` n’informera plus le noyau de la zone horaire, puisque cette information est nécessairement incorrecte et hasardeuse, car le noyau n’a, par exemple, aucune connaissance de l’heure d’été. Cela signifie que les horodatages (_timestamps_) FAT seront toujours considérés comme en temps universel ([[UTC]]), ce qu’Android fait déjà. Enfin, lorsque l’horloge matérielle indique l’heure locale (plutôt qu’UTC), _systemd_ ne la resynchronisera pas, puisque cela peut induire Windows en erreur lors du prochain démarrage. * Une nouvelle option `verify` a été incluse dans `systemd-analyze` pour valider hors ligne les fichiers unités. * Plusieurs paramètres ont été inclus dans `systemd-network` pour configurer l’amalgame d’interfaces réseau. * Le client DHCP de `systemd-network` ne demande plus la diffusion (_broadcast_) par défaut, puisque cela impactait négativement certains réseaux. Pour les matériels où la diffusion est requise, elle peut être réactivée en utilisant l’option `RequestBroadcast=yes`. * `systemd-networkd` va désormais configurer les adresses [IPv4LL](https://fr.wikipedia.org/wiki/Automatic_Private_Internet_Protocol_Addressing) (si elles sont activées), même si DHCP a été configuré avec succès. * `udev` va désormais respecter les noms donnés par le noyau aux interfaces réseau, lorsque celui‐ci indique qu’ils sont prédictibles. Ce comportement peut être modifié en changeant l’option `NamePolicy=` dans le fichier `.link` correspondant. * Une nouvelle bibliothèque `systemd-terminal` a été ajoutée. Elle implémente un moteur complet d’analyse et de rendu des flux de type « terminal texte » (TTY). Cette bibliothèque a été pensée pour pouvoir implémenter un sous‐système de terminaux virtuels (VT) complet s’exécutant en espace utilisateur, pour remplacer l’implémentation actuelle du noyau. * Un nouvel outil, `systemd-journal-upload` permet d’envoyer les données du journal à une machine distante exécutant `systemd-journal-remote`. * `journald` ne transmettra plus toutes les données locales à un autre démon _syslog_. Ce changement a été décidé, car `rsyslog` (qui semble être l’implémentation la plus répandue de _syslog_ de nos jours) n’utilise plus cette possibilité. À la place, il extrait directement les données depuis le journal. Puisque transmettre ces données à un serveur _syslog_ non existant demande plus de ressources que nous le supposions, cette option a été désactivée. Si vous exécutez un serveur _syslog_ qui n’est pas une version récente de `rsyslog`, vous devez activer cette option (`ForwardToSyslog=` dans le fichier `journald.conf`). * `journald` prend désormais en charge l’algorithme de compression [LZ4](https://fr.wikipedia.org/wiki/LZ4) pour les gros champs du journal. Cette compression devrait être plus performante que [XZ](https://fr.wikipedia.org/wiki/XZ_%28format_de_fichier%29), la précédente option par défaut. * `machinectl` montre désormais l’adresse IP des conteneurs locaux s’il les connaît, ainsi que le nom de l’interface du conteneur. * Un nouvel outil `systemd-escape` a été ajouté. Il permet de facilement protéger les chaînes de caractères qui seront utilisées pour construire les noms d’unités. * Les messages `sd_notify()` peuvent désormais inclure un nouveau champ, `ERRNO=`, qui est lu et enregistré par _systemd_. Il sera affiché dans la sortie fournie par la commande `systemctl status` pour le service concerné. * Un nouveau composant `systemd-firstboot` permet de demander à l’utilisateur les informations de base de _systemd_ (zone horaire, nom de la machine, mot de passe _root_) lors d’un premier démarrage. Il peut aussi être utilisé pour fournir ces informations à des images Linux installées dans des répertoires [_N. D. T. : par exemple un `chroot` ou un conteneur_]. * Les exemples préinstallés de `sysctl.d` auront désormais l’option `net.ipv4.conf.default.promote_secondaries=1`, ceci afin de ne pas supprimer les adresses IP secondaires lorsque les adresses primaires l’ont été. Les personnes suivantes ont contribué à cette version : Ansgar Burchardt, Bastien Nocera, Colin Walters, Dan Dedrick, Daniel Buch, Daniel Korostil, Daniel Mack, Dan Williams, Dave Reisner, David Herrmann, Denis Kenzior, Eelco Dolstra, Eric Cook, Hannes Reinecke, Harald Hoyer, Hong Shick Pak, Hui Wang, Jean‐André Santoni, Jóhann B. Guðmundsson, Jon Severinsson, Karel Zak, Kay Sievers, Kevin Wells, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Marc‐Antoine Perennou, Martin Pitt, Michael Biebl, Michael Marineau, Michael Olbrich, Michal Schmidt, Michal Sekletar, Miguel Angel Ajo, Mike Gilbert, Olivier Brunel, Robert Schiele, Ronny Chevalier, Simon McVittie, Sjoerd Simons, Stef Walter, Steven Noonan, Susant Sahani, Tanu Kaskinen, Thomas Blume, Thomas Hindoe Paaboel Andersen, Timofey Titovets, Tobias Geerinckx‐Rice, Tomasz Torcz, Tom Gundersen, Umut Tezduyar Lindskog et Zbigniew Jędrzejewski‐Szmek. systemd et Gentoo ================= La distribution [Gentoo Linux](https://fr.wikipedia.org/wiki/Gentoo_Linux) fournit par défaut son propre système d’init : [OpenRC](https://en.wikipedia.org/wiki/OpenRC). Une des forces d’OpenRC est son intégration avec le principe fondamental de Gentoo : la personnalisation. Jusqu’à cet été, j’ai vécu très heureux avec ce système. Néanmoins, Gentoo pousse la personnalisation du système jusqu’à proposer l’utilisation de _systemd_ comme système d’init pour les utilisateurs qui le veulent (ou qui veulent utiliser toutes les possibilités de GNOME 3). Pour le plaisir de tester, j’ai basculé mon ordinateur portable sous _systemd_. L’installation se fait facilement en suivant les étapes ci‐dessous : 1. recompiler le noyau pour activer l’option `OpenRC` ou `systemd` fournie par l’équipe Gentoo, et reconstruire l’_initramfs_ pour appeler l’exécutable _systemd_ ; 2. activer le profil _systemd_ (ou activer manuellement les bons _useflags_ — principalement `USE=systemd -consolekit`) ; 3. recompiler son système (la partie la plus longue du processus) ; 4. configurer (à la main ou en utilisant les utilitaires de _systemd_) ; 5. profiter ! Une description détaillée de la procédure est disponible sur le [wiki](http://wiki.gentoo.org/wiki/Systemd) du projet Gentoo. Vous pourrez aussi trouver une rapide description des [différents systèmes d’init](http://wiki.gentoo.org/wiki/Comparison_of_init_systems). Je n’ai malheureusement pas grand chose à dire de plus, car tout a fonctionné directement sans problème. Ce qui témoigne à la fois de la qualité de _systemd_, mais aussi et surtout de la qualité de l’intégration faite par l’équipe de développement de Gentoo. Il faut toutefois noter que _systemd_ et OpenRC sont très différents dans leur configuration. Cependant, puisque _systemd_ est très répandu, la documentation est abondante. L’apparition d’utilitaires comme `systemd-firstboot` devrait faciliter cette étape de configuration. Ce nouveau système est plus rapide, comme attendu. Cependant, je l’ai installé sur un nouveau SSD, la comparaison est donc _légèrement_ biaisée.