Publication du gestionnaire système systemd 249.

Après trois mois de développement, la version du gestionnaire système systemd 249 est désormais disponible. Cette nouvelle version permet de définir des utilisateurs/groupes au format JSON, stabilise le protocole Journal, simplifie l'organisation du chargement des partitions de disque se remplaçant mutuellement, ajoute la possibilité de lier des programmes BPF aux services, réalise un mappage des identifiants utilisateurs dans les partitions montées, et propose une large gamme de nouveaux paramètres de réseau et d'options pour le démarrage de conteneurs.

Principales modifications :

  • Le protocole Journal a été documenté et peut être utilisé dans les clients à la place du protocole syslog pour la livraison locale des journaux. Le protocole Journal est mis en œuvre depuis un certain temps et est déjà utilisé dans certaines bibliothèques clientes, cependant son soutien officiel n'a été annoncé que maintenant.
  • Dans userdb et nss-systemd, la lecture de définitions supplémentaires d'utilisateurs, placées dans les répertoires /etc/userdb/, /run/userdb/, /run/host/userdb/ et /usr/lib/userdb/, spécifiées au format JSON, a été assurée. Il est noté que cette possibilité fournira un mécanisme supplémentaire pour créer des utilisateurs dans le système, garantissant une intégration complète avec NSS et /etc/shadow. Le support du format JSON pour les enregistrements d'utilisateurs/groupes permettra également d'attacher divers paramètres de gestion des ressources et d'autres configurations reconnues par pam_systemd et systemd-logind.
  • Dans nss-systemd, la synthèse des enregistrements d'utilisateur/groupe dans /etc/shadow utilisant des mots de passe hachés provenant de systemd-homed a été assurée.
  • Un mécanisme a été implémenté pour simplifier l'organisation des mises à jour en utilisant des partitions de disque qui se remplacent mutuellement (une partition active, et une autre en réserve - la mise à jour est copiée sur la partition de réserve, puis elle devient active). Si l'image disque contient deux partitions racines ou /usr, et que udev n'a pas détecté la présence du paramètre 'root=' ou qu'une gestion d'images disque est en cours, indiquée par l'option « --image » dans les utilitaires systemd-nspawn et systemd-dissect, la partition à charger peut être déterminée par la comparaison des étiquettes GPT (sous-entendu, l'étiquette GPT mentionne le numéro de version du contenu de la partition et systemd choisira la partition avec des modifications plus récentes).
  • Des fichiers de services ont ajouté la configuration BPFProgram, qui permet de charger des programmes BPF dans le noyau et de les gérer liés à des services systemd spécifiques.
  • Dans le systemd-fstab-generator et le systemd-repart, il est désormais possible de démarrer à partir de disques qui n'ont qu'une partition /usr sans partition racine (la partition racine sera générée par l'outil systemd-repart lors du premier démarrage).
  • Dans systemd-nspawn, l'option «—private-user-chown» a été remplacée par une variante plus universelle «—private-user-ownership», qui peut prendre les valeurs «chown» comme équivalent de «—private-user-chown», «off» pour désactiver l'ancienne configuration, «map» pour le mappage des identifiants d'utilisateurs dans les systèmes de fichiers montés, et «auto» pour choisir «map» si la fonctionnalité nécessaire est présente dans le noyau (5.12+) ou revenir à l'appel récursif «chown» sinon. Le mappage permet d'associer des fichiers d'un utilisateur sur une partition montée d'un autre utilisateur au système actuel, simplifiant ainsi le partage de fichiers entre différents utilisateurs. Dans le mécanisme des répertoires personnels portables systemd-homed, le mappage permettra aux utilisateurs de déplacer leurs répertoires personnels sur des supports externes et de les utiliser sur différents ordinateurs, dont la répartition des identifiants d'utilisateurs ne correspond pas.
  • Dans systemd-nspawn, l'option «—private-user» peut désormais utiliser la valeur «identity» pour refléter directement les identifiants d'utilisateurs lors de la configuration de l'espace de noms (user namespace), c'est-à-dire que l'UID 0 et l'UID 1 dans le conteneur seront reflétés par l'UID 0 et l'UID 1 du côté hôte, réduisant ainsi les vecteurs d'attaques (le conteneur obtiendra les capacités d'un processus uniquement dans son propre espace de noms).
  • Dans systemd-nspawn, une option «—bind-user» a été ajoutée pour passer un compte utilisateur du voisinage hôte dans le conteneur (le répertoire personnel est monté dans le conteneur, une entrée utilisateur/groupe est ajoutée, et un mappage UID est effectué entre le conteneur et l'environnement hôte).
  • Dans systemd-ask-password et systemd-sysusers, la prise en charge de la demande de mots de passe définis (passwd.hashed-password. et passwd.plaintext-password.) a été ajoutée grâce à un mécanisme introduit dans la version 247 de systemd pour le transfert sécurisé de données sensibles à l'aide de fichiers temporaires dans un répertoire séparé. Par défaut, les informations d'identification sont prises du processus avec PID1, qui les reçoit, par exemple, du gestionnaire de conteneurs, permettant ainsi de configurer le mot de passe de l'utilisateur lors du premier démarrage.
  • Dans systemd-firstboot, la prise en charge de l'utilisation du mécanisme de transfert sécurisé de données sensibles pour demander divers paramètres système a été ajoutée, ce qui peut être appliqué pour initialiser les paramètres système lors du premier démarrage d'une image de conteneur ne contenant pas les configurations nécessaires dans le répertoire /etc.
  • Au cours du processus PID 1 pendant le démarrage, l'affichage simultané du nom et de la description de l'unité est assuré. La sortie peut être modifiée via le paramètre « StatusUnitFormat=combined » dans system.conf ou l'option de ligne de commande du noyau « systemd.status-unit-format=combined ».
  • Dans les utilitaires systemd-machine-id-setup et systemd-repart, l'option « —image » a été ajoutée pour transférer un fichier avec l'identifiant de la machine dans des images disque ou pour augmenter la taille de l'image disque.
  • Dans le fichier de configuration des partitions utilisé par l'utilitaire systemd-repart, un paramètre MakeDirectories a été ajouté, qui peut être utilisé pour créer des répertoires arbitraires dans le système de fichiers créé, avant qu'ils ne soient reflétés dans la table des partitions (par exemple, pour créer des répertoires pour des points de montage dans la partition racine, afin de pouvoir immédiatement monter la partition en mode lecture seule). Pour gérer les indicateurs GPT dans les partitions créées, des paramètres Flags, ReadOnly et NoAuto ont été ajoutés. Dans le paramètre CopyBlocks, une valeur « auto » a été implémentée pour sélectionner automatiquement la partition de démarrage actuelle comme source lors de la copie des blocs (par exemple, lorsque vous devez transférer votre propre partition racine vers un nouveau support).
  • Dans GPT, un indicateur «grow-file-system» a été implémenté, similaire à l'option de montage x-systemd.growfs, permettant l'extension automatique de la taille du système de fichiers jusqu'aux limites du disque, si la taille du système de fichiers est inférieure à celle de la partition. Cet indicateur s'applique aux systèmes de fichiers Ext3, XFS et Btrfs, et peut être utilisé avec des partitions détectées automatiquement. Par défaut, l'indicateur est activé pour les partitions en écriture, créées automatiquement via systemd-repart. L'option GrowFileSystem a été ajoutée pour configurer l'indicateur dans systemd-repart.
  • Dans le fichier /etc/os-release, le support des nouvelles variables IMAGE_VERSION et IMAGE_ID a été intégré pour définir la version et l'identifiant des images mises à jour de manière atomique. Les spécificateurs %M et %A ont été proposés pour substituer les valeurs indiquées dans diverses commandes.
  • Le paramètre «—extension» a été ajouté à l'utilitaire portablectl pour activer les images portables de l'extension système (par exemple, elles peuvent être utilisées pour distribuer des images avec des services supplémentaires intégrés dans la partition racine).
  • Dans l'utilitaire systemd-coredump, l'extraction des informations ELF build-id lors de la création d'un core dump de processus a été assurée, ce qui peut s'avérer utile pour identifier à quel paquet le processus défaillant appartient, si les informations sur le nom et la version des paquets deb ou rpm ont été intégrées dans les fichiers ELF.
  • Dans udev, une nouvelle base matérielle pour les appareils FireWire (IEEE 1394) a été ajoutée.
  • Dans udev, trois modifications ont été ajoutées au schéma de sélection des noms des interfaces réseau «net_id», rompant ainsi la compatibilité : des caractères incorrects dans les noms des interfaces sont maintenant remplacés par «_» ; les noms des slots PCI hotplug pour les systèmes s390 sont maintenant traités sous forme de nombres hexadécimaux ; l'utilisation de jusqu'à 65535 appareils PCI intégrés est désormais autorisée (auparavant, les numéros supérieurs à 16383 étaient bloqués).
  • Dans systemd-resolved, le domaine «home.arpa» a été ajouté à la liste des NTA (Negative Trust Anchors), recommandé pour les réseaux domestiques locaux, mais non utilisé dans DNSSEC.
  • Dans le paramètre CPUAffinity, le déchiffrement des spécificateurs «%» a été assuré.
  • Dans les fichiers «.network», le paramètre ManageForeignRoutingPolicyRules a été ajouté, qui peut être utilisé pour exclure le traitement des politiques de routage tierces dans systemd-networkd.
  • Dans les fichiers «.network», le paramètre RequiredFamilyForOnline a été ajouté pour déterminer la présence d'une adresse IPv4 ou IPv6 comme signe que l'interface réseau est en état «online». Dans networkctl, l'état «online» est affiché pour chaque lien.
  • Le paramètre OutgoingInterface a été ajouté aux fichiers «.network» pour définir les interfaces sortantes lors de la configuration des ponts réseau.
  • Le paramètre Group a été ajouté aux fichiers «.network», permettant de configurer un groupe Multipath pour les enregistrements dans la section «[NextHop]».
  • Des options «-4» et «-6» ont été ajoutées à systemd-network-wait-online pour limiter l'attente de connexion uniquement à IPv4 ou IPv6.
  • Le paramètre RelayTarget a été ajouté aux réglages du serveur DHCP, plaçant le serveur en mode DHCP Relay. Des options RelayAgentCircuitId et RelayAgentRemoteId ont été proposées pour un réglage complémentaire du relais DHCP.
  • Le paramètre ServerAddress a été ajouté au serveur DHCP, permettant de spécifier explicitement l'adresse IP du serveur (sinon, l'adresse est choisie automatiquement).
  • Une section [DHCPServerStaticLease] a été mise en œuvre dans le serveur DHCP, permettant de configurer des liaisons statiques d'adresses (baux DHCP) en spécifiant les liaisons d'adresses IP fixes aux adresses MAC et vice versa.
  • Le paramètre RestrictAddressFamilies a été mis en œuvre pour prendre en charge la valeur «none», ce qui signifie que le service n'aura pas accès aux sockets de n'importe quelle famille d'adresses.
  • Dans les fichiers «.network», les sections [Address], [DHCPv6PrefixDelegation] et [IPv6Prefix] ont vu leur prise en charge de la configuration RouteMetric, permettant de spécifier une métrique pour le préfixe de route créé pour l'adresse spécifiée.
  • Dans nss-myhostname et systemd-resolved, la synthèse des enregistrements DNS avec des adresses pour les hôtes ayant le nom spécial «_outbound» a été assurée, pour lesquels une adresse IP locale est toujours fournie, choisie en fonction des routes par défaut utilisées pour les connexions sortantes.
  • Une configuration activée par défaut RoutesToNTP a été ajoutée dans la section «[DHCPv4]» des fichiers .network, prescrivant l'ajout d'une route distincte via l'interface réseau actuelle pour accéder à l'adresse du serveur NTP, obtenue pour cette interface via DHCP (de manière similaire à la configuration DNS, cela garantit que le trafic vers le serveur NTP sera dirigé via l'interface par laquelle cette adresse a été obtenue).
  • Des réglages SocketBindAllow et SocketBindDeny ont été ajoutés pour gérer l'accès aux sockets liés au service actuel.
  • Une configuration conditionnelle ConditionFirmware a été mise en œuvre pour les fichiers unit, permettant de créer des vérifications évaluant les fonctionnalités du firmware, telles que le fonctionnement sur des systèmes UEFI et device.tree, ainsi que la vérification de la compatibilité avec certaines fonctionnalités du device-tree.
  • L'option ConditionOSRelease a été implémentée pour vérifier les champs dans le fichier /etc/os-release. Lors de la détermination des conditions de vérification des valeurs des champs, les opérateurs '=' , '!=' , '<' , '=' , '>' sont autorisés.
  • Dans l'outil hostnamectl, les commandes de type 'get-xyz' et 'set-xyz' ont été débarrassées des préfixes 'get' et 'set', par exemple, au lieu de 'hostnamectl get-hostname' et 'hostnamectl set-hostname', on peut utiliser la commande 'hostnamectl hostname', dont l'attribution d'une valeur est déterminée en spécifiant un argument supplémentaire ('hostnamectl hostname value'). Le support des anciennes commandes est maintenu pour assurer la compatibilité.
  • Dans l'outil systemd-detect-virt et la configuration ConditionVirtualization, une identification correcte des environnements Amazon EC2 est garantie.
  • La configuration LogLevelMax dans les fichiers unit est désormais appliquée non seulement aux messages log générés par le service, mais aussi aux messages du processus PID 1 qui mentionnent le service.
  • Il est désormais possible d'inclure les données SBAT (UEFI Secure Boot Advanced Targeting) dans les fichiers systemd-boot EFI PE.
  • De nouvelles options 'headless' et 'password-echo' ont été mises en œuvre dans /etc/crypttab - la première permet de sauter toutes les opérations liées à la demande interactive de mots de passe et de PIN à l'utilisateur, tandis que la seconde permet de configurer la méthode d'affichage de la saisie du mot de passe (ne rien afficher, afficher caractère par caractère ou afficher des astérisques). Dans systemd-ask-password, l'option '--echo' a été ajoutée pour des objectifs similaires.
  • Dans systemd-cryptenroll, systemd-cryptsetup et systemd-homed, le support pour le déverrouillage des partitions chiffrées LUKS2 à l'aide de tokens FIDO2 a été étendu. De nouvelles options '--fido2-with-user-presence', '--fido2-with-user-verification' et '--fido2-with-client-pin' ont été ajoutées pour gérer la vérification de la présence physique de l'utilisateur, la vérification et la nécessité d'entrer un code PIN.
  • Dans systemd-journal-gatewayd, les options '--user', '--system', '--merge' et '--file' ont été ajoutées, similaires aux options équivalentes de journalctl.
  • En plus des dépendances directes entre les unités, définies par les paramètres OnFailure et Slice, le support pour des dépendances inversées implicites OnFailureOf et SliceOf a été ajouté, ce qui peut être utile, par exemple, pour identifier toutes les unités faisant partie d'un slice.
  • De nouveaux types de dépendances entre les unités ont été ajoutés : OnSuccess et OnSuccessOf (l'inverse de OnFailure, appelé lors d'une terminaison réussie); PropagatesStopTo et StopPropagatedFrom (permettent de propager l'événement d'arrêt d'une unité à une autre unité); Upholds et UpheldBy (alternative à Restart).
  • Dans l'utilitaire systemd-ask-password, une option « —emoji » a été ajoutée pour contrôler l'apparition du symbole de cadenas (🔐) dans la ligne de saisie du mot de passe.
  • Documentation sur la structure de l'arborescence des textes sources systemd ajoutée.
  • Pour les unités, une propriété MemoryAvailable a été ajoutée, indiquant combien de mémoire reste disponible pour l'unité avant d'atteindre la limite fixée par les paramètres MemoryMax, MemoryHigh ou MemoryAvailable.

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster