systemd 259 : Principaux changements et exigences système

Informatec Digital » Ressources » systemd 259 : Principaux changements et exigences système

La sortie de systemd 259 en tant que version stable marque un nouveau tournant pour l'un des composants les plus controversés et essentiels de l'écosystème Linux. Il s'agit du framework permettant d'initier et de gérer des services, déjà omniprésent dans la plupart des distributions, et cette version renforce encore ses exigences techniques, sa sécurité et l'abandon des technologies obsolètes.

Cette mise à jour fait suite à plusieurs mois de travail intensif et se concentre sur trois axes principaux : la compatibilité avec les nouvelles bibliothèques C, le renforcement de la sécurité et le nettoyage du code hérité (scripts SysV, TPM 1.2, iptables, etc.). Elle introduit également des modifications importantes concernant la gestion des privilèges avec run0, la gestion de la mémoire avec systemd-oomd, le stockage des journaux et le modèle de dépendances internes de libsystemd.

systemd 259 et support expérimental pour musl

L'une des caractéristiques les plus commentées de cette version est l' intégration, pour la première fois dans systemd 259, d'une prise en charge partielle de la bibliothèque standard C musl . Cette bibliothèque est largement utilisée dans les systèmes légers, les conteneurs minimalistes et les environnements embarqués, où la simplicité et une consommation de ressources réduite par rapport à glibc sont recherchées.

La prise en charge de musl est activée en définissant l'option « libc » du système de compilation Meson sur « musl » . Cependant, cette intégration est loin d'être complète : musl n'implémente pas le mécanisme NSS (Name Service Switch), ce qui entraîne la désactivation de plusieurs composants de systemd lors de la compilation avec cette bibliothèque.

Plus précisément, la compilation de systemd 259 avec musl exclut des composants essentiels tels que nss-systemd, nss-resolve, systemd-homed, systemd-userdbd et systemd-nsresourced . L'option DynamicUser et la possibilité d'exécuter systemd-nspawn sans privilèges sont également indisponibles, ce qui est particulièrement problématique dans les environnements de conteneurs qui dépendent fortement de ces fonctionnalités.

Les développeurs eux-mêmes reconnaissent ne pas pouvoir garantir un support à long terme . Sa continuité dépendra de l'intérêt réel de la communauté, de la maturité des couches supplémentaires qui fournissent les fonctionnalités manquantes à musl, et des signalements de bogues spécifiques à cette bibliothèque. Si la demande est faible ou si la maintenance s'avère trop complexe, il ne serait pas surprenant que ce support soit réévalué dans les versions futures.

Toutefois, cette ouverture à musl est importante sur le plan symbolique : systemd a été critiqué pendant des années pour sa dépendance quasi exclusive à glibc , ce qui le rendait incompatible avec les distributions alternatives et les configurations minimalistes. Cette mesure ne résout pas tout, mais elle rompt avec l’image d’un système totalement fermé aux autres bibliothèques C.

run0 et le nouveau modèle de privilèges : une alternative à sudo

Une autre caractéristique majeure de systemd 259 est l'utilitaire run0, proposé comme un remplacement moderne et plus sûr pour sudoCet outil était déjà basé sur systemd-run, mais il bénéficie désormais d'une fonctionnalité clé : l'option --empower.

Le nouvel argument `--empower` permet de démarrer une session avec des privilèges élevés sans passer par l'utilisateur root . Au lieu d'un changement d'utilisateur classique, `run0` exploite les capacités du noyau (comme `CAP_SYS_ADMIN`) pour accorder précisément les permissions nécessaires à l'exécution d'actions privilégiées, réduisant ainsi considérablement le risque d'obtenir les privilèges root.

De plus, les processus lancés selon cette approche sont regroupés dans un groupe logique « autonomisé » disposant d'un accès à un large éventail d'actions gérées par Polkit . L'objectif est que l'augmentation des privilèges soit progressive et contrôlée, maintenant une séparation plus stricte que celle généralement offerte par sudo, où l'accès est souvent trop étendu.

Cette approche s'inscrit dans la tendance à éviter autant que possible l'utilisation directe de l'utilisateur root , un principe de sécurité fondamental. Toutefois, l'efficacité réelle de run0 reste à démontrer en production : il faudra observer son intégration aux politiques de chaque distribution, la configuration concrète de ses fonctionnalités et l'adaptation des administrateurs système à ce nouveau flux de travail.

Fin du support pour l'initialisation SysV et le nettoyage des processus hérités

systemd 259 marque également le début de la fin définitive des scripts de service de type System V. La compatibilité avec ces mécanismes classiques était considérée comme vouée à disparaître depuis des années, et un calendrier précis de leur suppression a désormais été établi.

Cette version annonce qu'en prévision de la prochaine version majeure, Les composants historiques tels que systemd-sysv-generator, systemd-rc-local-generator et systemd-sysv-install seront supprimés.C'est-à-dire, les scripts dans /etc/init.d/ Elles ne seront plus prises en compte par systemd, ce qui clôt une transition qui a duré près d'une décennie.

Pour les administrateurs qui gèrent encore des services personnalisés basés sur des scripts SysV , il est temps de se mettre au travail : tous ces scripts doivent être inventoriés et migrés vers des unités systemd natives (.service, .socket, etc.). Les grandes distributions ont déjà quasiment achevé cette transition, mais dans les environnements personnalisés ou les installations plus anciennes, certains « vestiges » peuvent encore s’exécuter en arrière-plan.

Ce processus de nettoyage des dépendances héritées ne se limite pas à SysV. Les versions récentes de systemd ont déjà supprimé la prise en charge des méthodes classiques telles que `/forcefsck` et `/fastboot` , les remplaçant par des paramètres du noyau et des mécanismes d'authentification plus modernes. Avec la version 259, la tendance est la même : une compatibilité ascendante réduite au profit d'un code source plus maintenable et cohérent.

Configuration minimale requise pour systemd : noyau, bibliothèques et environnement (259)

L'un des changements qui peut avoir le plus grand impact sur les systèmes plus anciens est l' augmentation des exigences logicielles minimales pour exécuter systemd 259. Cette version ne tient plus compte du matériel ou des piles logicielles très anciens et s'oriente clairement vers les plateformes modernes.

Parmi les exigences clés consolidées dans systemd 259 figurent : un engagement envers les plateformes modernes

• Noyau Linux 5.10 minimum (avec la recommandation d'aller au moins jusqu'à 5.14).
• glibc 2.34 comme une version minimale de la bibliothèque standard GNU.
• OpenSSL 3.0.0 comme base obligatoire pour les fonctions de chiffrement prises en charge.
• util-linux 2.37 comme condition préalable au fonctionnement de base du système.
• libxcrypt 4.4.0 pour la gestion des fonctions cryptographiques liées aux mots de passe.
• cryptsetup 2.4.0 et libseccomp 2.4.0 pour le chiffrement des volumes et le filtrage des appels système.
• Python 3.9.0 comme dépendance minimale pour les outils auxiliaires.
• Certaines notes mentionnent également elfutils 0.177 dans le cadre de la mise à jour de l'ensemble des dépendances.

Ce durcissement des conditions d'utilisation implique que les systèmes ou distributions très anciens utilisant des branches du noyau antérieures à la version 5.10 sont automatiquement exclus de la prise en charge de cette version, à moins de mettre à jour leur technologie sous-jacente. En contrepartie, on obtient un écosystème plus homogène, avec moins de cas particuliers et de solutions de compromis.

Pour la plupart des distributions système d'exploitation de bureau et serveur, ces exigences ne devraient pas poser de problème : les noyaux LTS modernes dépassent largement la limite de la version 5.10 , et les bibliothèques mentionnées sont largement disponibles. Les difficultés les plus importantes peuvent survenir dans les systèmes embarqués, les appareils ou les installations très anciennes qui ne sont pas mises à jour fréquemment.

Sécurité renforcée : TPM 2.0, chiffrement et restrictions de l’appareil

En matière de sécurité, systemd 259 accélère ses progrès grâce à plusieurs décisions importantes. La plus visible est l' abandon définitif de la prise en charge de TPM 1.2 par systemd-boot et systemd-stub , faisant de TPM 2.0 la norme de référence.

Ce changement implique que les systèmes utilisant TPM 1.2 pour gérer les politiques de démarrage sécurisé ou les clés de chiffrement devront être mis à niveau matériellement (par exemple, en changeant la carte mère) pour continuer à utiliser ces fonctionnalités avec les nouvelles versions de systemd-boot. De nombreux utilisateurs de postes de travail Linux ont désactivé TPM et le démarrage sécurisé ; ils pourraient donc ne pas remarquer ce changement, mais celui-ci pourrait avoir un impact dans les environnements d'entreprise ou à haute sécurité.

Dans les versions précédentes, comme systemd 258, des ajustements importants avaient déjà été apportés dans ce domaine : OpenSSL est devenue la seule bibliothèque de chiffrement prise en charge par systemd-resolved et systemd-importd , excluant ainsi des alternatives telles que GnuTLS et libgcrypt. Tout cela témoigne d'une consolidation autour d'un ensemble plus restreint et mieux contrôlé d'outils cryptographiques.

Dans la branche 258, des restrictions d'accès par défaut plus strictes ont été introduites pour tty/pts : les nœuds sont créés avec les permissions 0600 au lieu de 0620, empêchant ainsi les autres utilisateurs d'écrire sur nos terminaux. Ceci illustre une fois de plus comment systemd peaufine depuis un certain temps les détails de bas niveau, ce qui, combiné, renforce la sécurité globale du système.

libsystemd est plus modulaire et se charge dynamiquement.

Afin d'améliorer l'efficacité et de réduire les dépendances, systemd 259 introduit des changements importants dans la façon dont libsystemd interagit avec les autres bibliothèques système . L'objectif est d'éviter que toutes les dépendances ne soient chargées dès le départ, mais uniquement en cas de besoin.

Plus précisément, libsystemd utilise désormais dlopen() pour charger dynamiquement des bibliothèques telles que libacl, libblkid, libseccomp, libselinux et libmount . Cela signifie que ces dépendances ne sont pas liées de manière rigide à la compilation et ne sont pas toujours chargées en mémoire : elles ne sont activées que lorsqu’une fonction spécifique les requiert.

Ce même mécanisme, avec `dlopen()`, s'applique également à l'intégration avec le sous-système d'audit Linux et PAM . Ainsi, le démarrage et le fonctionnement normal de systemd peuvent être allégés dans les environnements qui n'exigent pas l'utilisation simultanée de tous ces composants.

En revanche, les fonctionnalités auparavant assurées par la bibliothèque libcap ont été directement intégrées à libsystemd . Cela élimine une dépendance externe supplémentaire, simplifie la chaîne de compilation et réduit les risques de défaillance ou d'incompatibilité.

De manière générale, cette approche offre une meilleure modularité et une empreinte mémoire et disque réduite , notamment dans les systèmes où l'on souhaite des temps de démarrage rapides et un ensemble de services compacts.

Changements concernant le réseau et les conteneurs : adieu iptables, bonjour nftables

Le domaine de la mise en réseau et de la virtualisation subit également des changements importants. À partir de systemd 259, systemd-networkd et systemd-nspawn ne prennent plus en charge la création de règles NAT à l'aide d'iptables/libiptc . Seul nftables est désormais pris en charge comme pare-feu.

Cela affecte directement les conteneurs gérés par systemd-nspawn qui s'appuient sur la NAT via iptables , ainsi que les réseaux définis dans systemd-networkd qui utilisent des règles de traduction d'adresses avec le backend classique. Lors de tests avec des versions candidates, des défaillances silencieuses de la fonctionnalité NAT ont été observées jusqu'à la migration complète de la configuration vers nftables.

Au-delà de la traduction d'adresses, systemd-resolved acquiert la capacité d'utiliser des hooks locaux en /run/systemd/resolve.hook/Ces commandes sont exécutées à chaque requête de résolution de nom local. Cela permet à l'administrateur de personnaliser le DNS de manière avancée et d'implémenter une logique spécifique.

Dans le domaine de l'importation et de la gestion d'images, systemd-importd intègre une logique native pour la gestion des fichiers TAR, en s'appuyant sur libarchive de l'utilitaire GNU tar. De plus, systemd-importd et systemd-machined peuvent désormais être exécutés en mode utilisateur, gérant les images système placées dans ~/.local/state/machines/.

Pour contrôler ces modes, l' utilitaire importctl ajoute les options « --user » et « --system » , permettant de choisir facilement entre le contexte utilisateur et le niveau système. Cette approche est utile dans les environnements de développement et de test où il est préférable de ne pas modifier la configuration globale de la machine.

Journalisation persistante par défaut et gestion de l'espace disque

Un autre changement ayant un impact pratique est la modification de mode de stockage du journal par défaut, le sous-système de journalisation de systemd. Jusqu'à présent, le comportement « automatique » dépendait de l'existence ou non du répertoire /var/log/journal.

Avec systemd 259, le mode par défaut devient « persistant », que le dossier existât ou non auparavant. Cela signifie que le journal sera enregistré définitivement sur le disque dur par défaut, au lieu d'être stocké dans la mémoire vive.

Cette décision présente des avantages et des inconvénients. D'une part, elle simplifie considérablement le dépannage , car les journaux sont conservés après un redémarrage sans intervention particulière de l'administrateur. D'autre part, sur les systèmes embarqués, les conteneurs légers ou les environnements disposant d'un espace de stockage très limité, elle peut entraîner une augmentation significative de l'utilisation du disque.

Dans ces scénarios, il sera plus important que jamais d'ajuster les politiques de rotation et de taille des journaux , voire de forcer un mode de stockage différent si vous souhaitez éviter une usure excessive (par exemple, dans les mémoires flash avec un nombre limité de cycles d'écriture).

systemd-oomd, suivi de la mémoire insuffisante et contrôle des ressources

La gestion de la mémoire et les scénarios de « mémoire insuffisante » bénéficient également d'améliorations significatives. Le composant systemd-oomd, chargé de répondre aux situations de mémoire insuffisante , intègre de nouvelles propriétés pour une meilleure visibilité.

Plus précisément, les propriétés OOMKills et ManagedOOMKills sont désormais disponibles pour les services . Elles enregistrent le nombre de processus arrêtés par le noyau ou par systemd-oomd lui-même en raison d'une mémoire insuffisante. Ces informations sont directement accessibles via les outils systemd, ce qui facilite l'analyse ultérieure des incidents.

Lorsqu'un processus devient incontrôlable et commence à « dévorer » la RAM au point de mettre le système en péril , ces indicateurs vous permettent de voir d'un coup d'œil quelles unités ont été affectées, combien de fois le mécanisme OOM a été déclenché et quels composants exercent la plus forte pression sur la mémoire.

Pour les administrateurs d'environnements à forte charge ou de systèmes aux ressources très limitées, cette capacité accrue d'observer les erreurs de mémoire insuffisante (OOM) est particulièrement utile, car elle permet d'identifier les services mal dimensionnés ou les fuites de mémoire qui auraient pu passer inaperçues auparavant.

Autres améliorations notables de systemd 259

Outre les changements majeurs mentionnés ci-dessus, systemd 259 intègre de nombreuses améliorations et optimisations mineures disséminées dans tout l'écosystème . Nombre d'entre elles sont assez techniques, mais il est important de les examiner car, ensemble, elles représentent un changement significatif.

Parmi les nouvelles fonctionnalités de l'API, L'interface basée sur le protocole Varlink est en cours d'extension. pour permettre l'accès à la configuration du service et l'exécution d'appels IPC tels que Reload() y Reexecute()Des appels spécifiques sont également ajoutés pour gérer les fonctionnalités systemd-repart, systemd-resolved et systemd-networkd.

Dans le domaine de la configuration et des unités, l'option ExecReloadPost a été introduite . Elle permet de lancer des commandes immédiatement après le rechargement de la configuration d'un service. De plus, les fichiers de configuration se terminant par « .ignore » sont désormais automatiquement ignorés , ce qui simplifie la désactivation des fichiers sans avoir à les supprimer ou à les renommer.

Les unités temporaires acquièrent la propriété Descripteur de fichier du répertoire racine, qui définit le descripteur de fichier correspondant au répertoire racine, et une nouvelle option est ajoutée Chemin de l'espace de noms utilisateur, qui vous permet de lier un lecteur à un espace de noms utilisateur en spécifiant un chemin dans /procDans systemd-nspawn, la directive apparaît NamespacePath dans la section à partir des fichiers .nspawn pour indiquer l'espace de noms réseau à utiliser.

D'autres composants tels que systemd-sysext et systemd-confext intègrent des fichiers de configuration dédiés en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confVariables environnementales SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Ils vous permettent de régler les options de montage des superpositions.

Dans l'univers d'udev, cette option est ajoutée. OPTIONS="dump-json" vers systemd-udevd Pour afficher l'état actuel d'un événement au format JSON, la fonction net_id Il génère des noms prévisibles pour les interfaces sans fil sur les systèmes dotés de DeviceTree et crée des liens symboliques. /dev/gpio/by-id/... pour les périphériques GPIO.

La section relative aux utilisateurs et aux comptes est également renforcée : La base de données utilisateur comprend un champ UUIDL'utilitaire userdbctl prend en charge l'option « -uuid » pour effectuer une recherche par cet identifiant, et homectl update Il prend désormais en charge l'option « --recovery-key » pour ajouter des clés de récupération aux comptes existants.

Dans systemd-homed, les options « --prompt-shell » et « --prompt-groups » sont intégrées lors du premier démarrage via systemd-homed-firstboot.service, et dans systemd-firstboot, l'option « --prompt-keymap-auto » semble demander la configuration du clavier lors de l'utilisation de la console locale au premier démarrage.

El Le gestionnaire de démarrage systemd-boot ajoute la possibilité de définir le niveau de détail du journal. avec paramètre log-level en loader.conf ou avec le champ SMBIOS io.systemd.boot.loglevelDe plus, des exigences plus strictes sont mises en place pour les partitions telles que XBOOTLDR, qui doivent désormais être au format VFAT, conformément aux exigences déjà imposées à l'ESP dans les systèmes UEFI modernes.

Au niveau réseau avancé, systemd-networkd ajoute les options EmitDomain et Domain pour le serveur DHCP et implémente un contrôleur qui détermine les noms d'hôtes attribués par DHCP à l'aide de la résolution DNS. Parallèlement, systemd-modules-load charge les modules du noyau en parallèle , réduisant ainsi le temps de démarrage sur les systèmes comportant de nombreux pilotes.

Enfin, dans la section intégrité, systemd-integrity-setup ajoute la prise en charge des algorithmes HMAC-SHA256, PHMAC-SHA256 et PHMAC-SHA512 , élargissant ainsi la gamme d'options cryptographiques disponibles pour protéger l'intégrité du système.

Avec tous ces changements, systemd 259 conforte sa position de version hautement technique, exigeante et résolument tournée vers l'avenir . Elle incite les utilisateurs à abandonner les technologies obsolètes telles que SysV init, iptables et TPM 1.2, renforce la sécurité et la gestion des ressources, améliore la modularité interne et ouvre la voie à de nouvelles configurations avec musl, bien que partiellement et sous certaines conditions. Pour les utilisateurs finaux de distributions à mises à jour mineures, nombre de ces nouveautés passeront presque inaperçues ; en revanche, pour les administrateurs et les projets utilisant systématiquement la dernière version, il est temps d'examiner attentivement les scripts, les unités et la configuration matérielle requise avant d'effectuer la migration.