Systemd est une suite logicielle primordiale du monde GNU/Linux. Elle peut être présente du début à la fin de l'allumage du système, permettant de gérer de manière fine la vie des autres services.
Systemd est sorti en 2010, en a énervé certains notamment en raison de l'approche audacieuse et intégrée, et a séduit une grande majorité de systèmes GNU/Linux à partir de 2015. Aujourd'hui il est possible de voir Systemd dans la plupart des grandes distributions, gérant les arcanes du système en s'appuyant sur les mécanismes noyau de cgroup, dbus et namespace notamment.
La version 256 succède à la v255 sortie en décembre 2023, où vous trouverez encore d'énormes évolutions et encore plus d'intégration afin de proposer un écosystème cohérent, le plus automatique possible, compatible avec chacun des autres systèmes, et cherchant à offrir de la sécurité par défaut associé à une granularité de configuration et d'isolation.
Il peut être intéressant de remarquer qu'au moins, à ma connaissance, deux développeurs fortement actifs, sont des salariés de Microsoft, travaillant autant sur systemd qu'à la normalisation d'un certain standard Linux par le truchement du groupe UAPI. Ce sont Lennart Poettering et Luca Boccassi, mais peut être en connaissez vous d'autres ?
Je vous invite également à vous pencher sur casync et mkosi (maintenu par Daan De Meyer, de chez Meta), deux nouvelles marottes de ces développeurs fous mais qui semblent avoir réussi le pari, qu'en pensez-vous ?
NdM : La dépêche qui suit est une traduction en français des nouveautés de la version 256.
Sommaire
-
Une nouvelle version de systemd v256 est sortie
- Modifications depuis la version précédente v255
-
Modifications générales et nouvelles fonctionnalités v256
- Sur la gestion des services
- Journalisation et autres gestions d'erreurs
- À propos de la gestion des périphériques
systemd-hostnamed
offre divers manières de modifier le nom et la description du système- La gestion du réseau avec systemd
- À propos de
systemd-nspawn
, l'alternative sécurisée et fine dechroot
- À propos du multi résolveur
systemd-resolved
, qui peut remplacerdnsmasq
,Avahi
&libnss-mdns
- Une intégration fine de SSH
systemd-boot
etsystemd-stub
et outils associés, une alternative minimale & ukify àgrub
systemd-run/run0
, une alternative sécurisée àsudo
- Outillages en ligne de commande
systemd-vmspawn
, permet de générer un système d'exploitation dans une machine virtuellesystemd-repart
, pour retailler un disque à la volée- Bibliothèques autours du monde systemd
systemd-cryptsetup
systemd-cryptenroll
, où l'aide au chiffrement de disquesystemd-homed
systemd-logind
,systemd-userdbd
systemd-creds
, mécanisme de gestion des authentifications, pour arrêter de balancer du mot de passe en clair partout- De quoi mettre en veille et mettre en veille prolongée
- Espaces de noms utilisateurs non privilégiés et gestion des montages de disques
- Divers changements
- Documentations
- Contributeurs
Une nouvelle version de systemd v256 est sortie
Modifications depuis la version précédente v255
Annonces de futures suppressions de fonctionnalités et de modifications incompatibles
La prise en charge du vidage automatique des caches de la base de données des utilisateurs/groupes
nscd
sera abandonnée dans une prochaine version.La prise en charge du groupe de contrôle cgroupv1 (hiérarchies « héritées » et « hybrides ») est désormais considérée comme obsolète, et systemd refusera par défaut de démarrer sous celui-ci. Pour réactiver de force la prise en charge de cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 doit être défini sur la ligne de commande du noyau. L'option Meson 'default-hierarchy=' est également obsolète, c'est-à-dire que seul le groupe cgroup v2 (hiérarchie
unifiée
) peut être sélectionné comme valeur par défaut au moment de la compilation.La prise en charge des scripts de service System V est à présent obsolète et sera supprimé dans une prochaine version. Veuillez vous assurer de mettre à jour votre logiciel maintenant pour inclure un fichier d'unité systemd natif au lieu d'un héritage de scripts System V, afin conserver la compatibilité avec les futures versions de systemd.
La prise en charge de la variable EFI
SystemdOptions
est à présent obsolète.bootctl systemd-efi-options
émettra un avertissement lorsqu'il sera utilisé. Il semble que cette fonctionnalité soit peu utilisée et qu'il soit préférable d'utiliser des approches alternatives comme les informations d'identification et les contextes. Le plan est d'abandonner complètement le support ultérieurement, mais cela pourrait être réexaminé en fonction des commentaires des utilisateurs.Le commutateur
--expand-environment=
desystemd-run
, qui est actuellement désactivé par défaut lorsqu'il est combiné avec --scope, sera modifié dans une prochaine version pour être activé par défaut.Auparavant,
systemd-networkd
ne supprimait explicitement aucun ID de VLAN de pont attribué sur le maître de pont et les ports. Depuis la version 256, si un fichier.network
pour une interface possède au moins un paramètre valide dans la section[BridgeVLAN]
, alors tous les ID de VLAN attribués sur l'interface qui ne sont pas configurés dans le fichier.network
sont supprimés.Le paramètre
IPForward=
dans le fichier.network
est obsolète et remplacé par les paramètresIPv4Forwarding=
etIPv6Forwarding=
. Ces nouveaux paramètres sont pris en charge à la fois dans le fichier.network
et dansnetworkd.conf
. S'ils sont spécifiés dans un fichier .network, ils contrôlent les paramètres correspondants par lien. S'ils sont spécifiés dansnetworkd.conf
, ils contrôlent les paramètres globaux correspondants. Notez qu'auparavantIPv6SendRA=
etIPMasquerade=
impliquaientIPForward=
, mais maintenant ils impliquent les nouveaux paramètres par lien. L'un des moyens les plus simples de migrer les configurations, qui fonctionnait comme un routeur avec la version précédente, consiste à activer à la foisIPv4Forwarding=
etIPv6Forwarding=
dans networkd.conf. Voir systemd.network(5) et networkd.conf(5) pour plus de détails.systemd-gpt-auto-generator
arrêtera de générer des unités pour les partitions ESP ou XBOOTLDR s'il trouve des entrées de montage pour ou en dessous des hiérarchies/boot/
ou/efi/
dans/etc/fstab
. Cela permet d'éviter que le générateur n'interfère avec les systèmes dans lesquels l'ESP est explicitement configuré pour être monté sur un chemin, par exemple/boot/efi/
(ce type de configuration est obsolète, mais reste courant).Le comportement de
systemd-sleep
etsystemd-homed
a été mis à jour pour geler les sessions utilisateur lors de l'entrée dans les différents modes de veille ou lors du verrouillage d'une zone d'accueil gérée par homed. Ceci est connu pour causer des problèmes avec les pilotes propriétaires NVIDIA. Les conditionneurs des pilotes propriétaires NVIDIA peuvent souhaiter ajouter des fichiers de configuration déroulants qui définissentSYSTEMD_SLEEP_FREEZE_USER_SESSION=false
poursystemd-suspend.service
et les services associés, etSYSTEMD_HOME_LOCK_FREEZE_SESSION=false
poursystemd-homed.service
.systemd-tmpfiles
etsystemd-sysusers
, lorsqu'ils reçoivent un chemin de fichier de configuration relatif (avec au moins un séparateur de répertoire/
), ouvriront le fichier directement, au lieu de rechercher le chemin partiel donné dans les emplacements standard. L'ancien mode n'était pas utile car la configurationtmpfiles.d/
etsysusers.d/
a une structure plate sans sous-répertoires sous les emplacements standard et ce changement facilite le travail avec des fichiers locaux avec ces outils.systemd-tmpfiles
applique désormais correctement la configuration imbriquée aux strophes (stanzas) « R » et « D ». Par exemple, avec la combinaison de « R /foo » et « x /foo/bar », /foo/bar sera désormais exclu de la suppression.systemd.crash_reboot
et les paramètres associés sont obsolètes au profit desystemd.crash_action=
.
Modifications générales et nouvelles fonctionnalités v256
-
Divers programmes tenteront désormais de charger le fichier de configuration principal à partir d'emplacements situés sous
/usr/lib/
,/usr/local/lib/
et/run/
, et pas seulement sous/etc/
. Par exemple,systemd-logind
recherchera/etc/systemd/logind.conf
,/run/systemd/logind.conf
,/usr/local/lib/systemd/logind.conf
et/usr/lib/systemd/logind.conf
et utilise le premier fichier trouvé. Cela signifie que la logique de recherche pour le fichier de configuration principal et pour les drop-ins est désormais la même.- De même, l'installation du noyau recherchera les fichiers de configuration dans
/usr/lib/kernel/
et dans les autres emplacements de recherche, et prend désormais également en charge les drop-ins. - systemd-udevd prend désormais en charge les drop-ins pour
udev.conf
.
- De même, l'installation du noyau recherchera les fichiers de configuration dans
-
Un nouveau binaire
systemd-vpick
a été ajouté. Il implémente le nouveau protocolevpick
, dans lequel un répertoire*.v/
peut contenir plusieurs fichiers dont les versions (suivant la spécification du format de version UAPI) sont intégrées dans le nom du fichier. Les fichiers sont classés par version et la plus récente est sélectionnée.-
systemd-nspawn --image=/--directory=
,systemd-dissect
,systemd-portabled
et les paramètresRootDirectory=
,RootImage=
,ExtensionImages=
etExtensionDirectories=
pour les unités prennent désormais en charge le protocolevpick
et permettent d'utiliser la dernière version sélectionnée automatiquement si un répertoire*.v/
est spécifié comme source.
-
Les informations d'identification du service chiffrées peuvent désormais être rendues accessibles aux utilisateurs non privilégiés.
systemd-creds
a obtenu de nouvelles options--user/
--uid=
pour chiffrer/déchiffrer les informations d'identification d'un utilisateur spécifique.Le nouvel outil de ligne de commande
importctl
pour télécharger, importer et exporter des images disque viasystemd-importd
est ajouté avec les verbes suivants :pull-tar
,pull-raw
,import-tar
,import-raw
,import-fs
,export-tar
,export-raw
,list-transfers
etcancel-transfer
. Cette fonctionnalité était auparavant disponible dansmachinectl
, où elle était utilisée exclusivement pour les images machine. Le nouveauimportctl
généralise cela pour les images de service sysext, confext et portables.Les sources systemd peuvent désormais être compilées proprement avec toutes les dépréciations d'OpenSSL 3.0 supprimées, y compris la logique du moteur OpenSSL désactivée.
Sur la gestion des services
-
Un nouveau paramètre de gestionnaire système
ProtectSystem=
a été ajouté. C'est analogue au réglage de l'unité, mais s'applique à l'ensemble du système. Il est activé par défaut dans le fichier initrd.- Notez que cela signifie que le code exécuté dans initrd ne peut pas être naïvement attendu à ce qu'il puisse écrire dans /usr/ pendant le démarrage. Cela affecte dracut <= 101, lequel écrit un crochet ("hooks") dans /lib/dracut/hooks/. src.
Un nouveau paramètre d'unité
WantsMountsFor=
a été ajouté. Il est analogue àRequiresMountsFor=
, mais crée une dépendanceWants=
au lieu deRequires=
. Cette nouvelle logique est désormais utilisée à divers endroits où des montages ont été ajoutés en tant que dépendances pour d'autres paramètres (WorkingDirectory=-…, PrivateTmp=yes, lignes cryptsetup avecnofail
).Le nouveau paramètre d'unité
MemoryZSwapWriteback=
peut être utilisé pour contrôler le nouveau bouton de groupe de contrôlememory.zswap.writeback
ajouté dans le noyau 6.8.-
Le gestionnaire a acquis une méthode
D-Bus org.freedesktop.systemd1.StartAuxiliaryScope()
pour déléguer certains processus d'un service vers une nouvelle portée.- Cette nouvelle étendue restera en cours d'exécution, même lorsque l'unité de service d'origine est redémarrée ou arrêtée. Cela permet à une unité de service de diviser certains processus de travail qui doivent continuer à s'exécuter. Les propriétés du groupe de contrôle de la nouvelle étendue sont copiées à partir de l'unité d'origine, de sorte que diverses limites sont conservées.
-
Les unités exposent désormais les propriétés
EffectiveMemoryMax=
,EffectiveMemoryHigh=
etEffectiveTasksMax=
,- qui signalent la limite la plus stricte dont systemd a connaissance pour l'unité donnée.
-
Un nouveau spécificateur de fichier d'unité
%D
- correspondra à
$XDG_DATA_HOME
pour les services utilisateur - ou correspondra à
/usr/share/
pour les services système
- correspondra à
AllowedCPUs=
prend désormais en charge l'extension du spécificateur.Le paramètre
What=
dans les unités.mount
et.swap
accepte désormais les identifiants de style fstab, par exempleUUID=…
ouLABEL=…
.RestrictNetworkInterfaces=
prend désormais en charge les noms d'interface réseau alternatifs.PAMName=
implique désormaisSetLoginEnvironment=yes
.-
systemd.firstboot=no
peut être utilisé sur la ligne de commande du noyau pour désactiver les requêtes interactives,- mais autoriser d'autres configurations de premier démarrage en fonction des informations d'identification.
Le nom d'hôte du système peut être configuré via les informations d'identification système
systemd.hostname
.-
Le binaire systemd ne chargera plus en chaîne le binaire
telinit
de sysvinit lorsqu'il est appelé sous le nominit/telinit
sur un système qui n'est pas démarré avec systemd.- Cela a déjà été pris en charge pour garantir qu'une distribution sur laquelle les deux systèmes d'initialisation sont installés peut raisonnablement passer de l'un à l'autre via un simple redémarrage. Les distributions ont apparemment perdu tout intérêt pour cela, et la fonctionnalité n'a pas été prise en charge sur la distribution principale à laquelle elle était encore destinée depuis longtemps, et a donc été supprimée maintenant.
-
Un nouveau concept appelé
capsules
a été introduit.- Les
capsules
enveloppent des gestionnaires de services supplémentaires par utilisateur, dont les utilisateurs sont transitoires et ne sont définis que tant que le gestionnaire de services est en cours d'exécution. - (Ceci est implémenté via
DynamicUser=1
), permettant à un gestionnaire d'utilisateurs d'être utilisé pour gérer un groupe de processus sans avoir besoin de créer un compte utilisateur réel. - Ces gestionnaires de services fonctionnent avec les répertoires personnels de
/var/lib/capsules/<capsule-name>
- et peuvent contenir des services réguliers et d'autres unités.
- Une capsule est démarrée via un simple
systemctl start capsule@<name>.service
. - Consultez la page de manuel
capsule@.service(5)
pour plus de détails. - Divers outils systemd (y compris, et surtout,
systemctl
etsystemd-run
) ont été mis à jour pour interagir avec les capsules via le nouveau commutateur--capsule=
/-C
.
- Les
-
Les unités
.socket
ont obtenu un nouveau paramètrePassFileDescriptorsToExec=
, prenant une valeur booléenne.- S'ils sont définis sur true, les descripteurs de fichiers que l'unité de socket encapsule sont transmis à
ExecStartPost=
,ExecStopPre=
,ExecStopPost=
en utilisant l'interface$LISTEN_FDS
habituelle. - Cela peut être utilisé pour effectuer des initialisations supplémentaires sur les sockets une fois qu'elles sont allouées. (Par exemple, pour y installer un programme eBPF supplémentaire).
- S'ils sont définis sur true, les descripteurs de fichiers que l'unité de socket encapsule sont transmis à
-
Le paramètre
.socket
MaxConnectionsPerSource=
(qui imposait jusqu'à présent une limite aux connexions simultanées par IP dans les unités de socket Accept=yes),- a désormais également un effet sur les sockets
AF_UNIX
- il limitera le nombre de connexions simultanées à partir du même UID source (tel que déterminé via SO_PEERCRED).
- Ceci est utile pour implémenter les services IPC dans un simple mode Accept=yes.
- a désormais également un effet sur les sockets
-
Le gestionnaire de services maintiendra désormais un compteur des cycles de redémarrage logiciel effectués par le système.
- Il peut être interrogé via les API D-Bus.
-
La logique d'exécution de systemd prend désormais en charge la nouvelle API
pidfd_spawn()
introduite par la glibc 2.39,- qui nous permet d'invoquer un sous-processus dans un groupe de contrôle cible et de récupérer un pidfd en une seule opération.
-
systemd/PID 1 enverra désormais un message
sd_notify()
supplémentaire à son VMM ou gestionnaire de conteneur superviseur signalant le nom d'hôte sélectionné (X_SYSTEMD_HOSTNAME=
) et l'ID de la machine (X_SYSTEMD_MACHINE_ID=
) au démarrage.- De plus, le gestionnaire de services enverra des messages
sd_notify()
supplémentaires (X_SYSTEMD_UNIT_ACTIVE=
) chaque fois qu'une unité cible est atteinte. - Cela peut être utilisé par les VMM/gestionnaires de conteneurs pour planifier précisément l’accès au système.
- Par exemple, dès qu'un système signale que
ssh-access.target
est atteint, un gestionnaire VMM/conteneur sait qu'il peut désormais se connecter au système via SSH. - Enfin, un nouveau message
sd_notify()
(X_SYSTEMD_SIGNALS_LEVEL=2
) est envoyé au moment où le PID 1 a terminé avec succès l'installation de ses différents gestionnaires de signaux de processus UNIX (c'est-à-dire le moment où SIGRTMIN+4 envoyé au PID 1 commencera à avoir pour effet d'arrêter proprement le système). -
X_SYSTEMD_SHUTDOWN=
est envoyé peu de temps avant l'arrêt du système et contient une chaîne identifiant le type d'arrêt, c'est-à-direpoweroff
,halt
,reboot
. -
X_SYSTEMD_REBOOT_PARAMETER=
est envoyé en même temps et porte la chaîne passée àsystemctl --reboot-argument=
s'il y en avait une.
- De plus, le gestionnaire de services enverra des messages
-
Les nouvelles propriétés D-Bus
ExecMainHandoffTimestamp
etExecMainHandoffTimestampMonotonic
sont désormais publiées par unités de services.- Cet horodatage est considéré comme la toute dernière opération avant de transférer le contrôle aux binaires invoqués. Ces informations sont disponibles pour d'autres types d'unités qui exécutent des processus (c'est-à-dire les unités de montage, d'échange, de socket), mais actuellement uniquement via
systemd-analyze dump
.
- Cet horodatage est considéré comme la toute dernière opération avant de transférer le contrôle aux binaires invoqués. Ces informations sont disponibles pour d'autres types d'unités qui exécutent des processus (c'est-à-dire les unités de montage, d'échange, de socket), mais actuellement uniquement via
Un horodatage supplémentaire est désormais pris par le gestionnaire de service lorsqu'une opération d'arrêt du système est lancée. Il peut être interrogé via D-Bus pendant la phase d'arrêt. Il est transmis lors des redémarrages logiciels à l'invocation suivante du gestionnaire de services, qui l'utilisera pour enregistrer le temps de « grisage » global de l'opération de redémarrage logiciel, c'est-à-dire l'heure à laquelle l'arrêt a commencé jusqu'à ce que le système soit à nouveau complètement opérationnel.
-
systemctl status
affichera désormais l'ID d'invocation dans sa sortie habituelle, c'est-à-dire l'ID de 128 bits attribué de manière unique au cycle d'exécution actuel de l'unité.- L'ID est pris en charge depuis longtemps, mais il est désormais affiché de manière plus visible, car il s'agit d'un identifiant très utile pour un appel spécifique d'un service.
-
systemd génère désormais une nouvelle chaîne
taint
unmerged-bin
pour les systèmes qui ont/usr/bin/
et/usr/sbin/
séparés.- De nos jours, il est généralement recommandé de faire de ce dernier un lien symbolique vers le premier.
-
Une nouvelle option de ligne de commande kernel
systemd.crash_action=
a été ajoutée qui configure ce qu'il faut faire après le crash du gestionnaire système (PID 1).- Cela peut également être configuré via
CrashAction=
dans systemd.conf.
- Cela peut également être configuré via
systemctl kill
prend désormais en charge--wait
qui fera attendre la commande jusqu'à ce que les services signalés se terminent.
Journalisation et autres gestions d'erreurs
-
systemd-journald
peut désormais transférer les entrées de journal vers un socket (AF_INET
,AF_INET6
,AF_UNIX
ouAF_VSOCK
).- Le socket peut être spécifié dans
journald.conf
via une nouvelle optionForwardAddress=
ou via les informations d'identificationjournald.forward_address
. - Les enregistrements de journaux sont envoyés au format d'exportation du journal.
- Un paramètre associé
MaxLevelSocket=
a été ajouté pour contrôler les niveaux de journalisation maximum pour les messages envoyés à ce socket.
- Le socket peut être spécifié dans
systemd-journald lit désormais également les informations d'identification de
journal.storage
lorsque cherche où stocker les fichiers journaux.-
systemd-vmspawn
a obtenu une nouvelle option--forward-journal=
pour transmettre les entrées de journal de la machine virtuelle à l'hôte.- Cela se fait via un socket
AF_VSOCK
, c'est-à-dire qu'il ne nécessite pas de mise en réseau dans l'invité.
- Cela se fait via un socket
journalctl
a obtenu l'option-i
comme raccourci pour--file=
.journalctl
a gagné une nouvelle option-T
/--exclude-identifier=
pour filtrer certains identifiants syslog.journalctl
a gagné une nouvelle option--list-namespaces
.systemd-journal-remote
accepte désormais également les socketsAF_VSOCK
etAF_UNIX
: il peut donc être utilisé pour recevoir les entrées transmises parsystemd-journald
.systemd-journal-gatewayd
permet de restreindre la plage horaire des entrées récupérées avec un nouveau paramètre d'URLrealtime=[<since>]:[<until>]
.systemd-cat
a gagné une nouvelle option--namespace=
pour spécifier l'espace de noms du journal cible auquel la sortie doit être connectée.systemd-bsod
a gagné une nouvelle option--tty=
pour spécifier le TTY de sortie
À propos de la gestion des périphériques
-
/dev/
contient désormais des liens symboliques qui combinent des informationsby-path
&by-{label,uuid}
:/dev/disk/by-path/<chemin>/by-<label|uuid|…>/<label|uuid|…>
- Cela permet de distinguer les partitions avec un contenu identique sur plusieurs périphériques de stockage.
- Ceci est utile, par exemple, lors de la copie du contenu brut du disque entre périphériques.
-
systemd-udevd
crée désormais des liens symboliques/dev/media/by-path/
persistants pour les contrôleurs multimédias.- Par exemple, le pilote
uvcvideo
peut créer/dev/media0
qui sera lié en tant que/dev/media/by-path/pci-0000:04:00.3-usb-0:1:1.0-media-controller
.
- Par exemple, le pilote
Une nouvelle unité
systemd-udev-load-credentials.service
a été ajoutée pour récupérer les drop-insudev.conf
et les règles udev à partir des informations d'identification.-
Une liste d'autorisation/liste de refus peut être spécifiée pour filtrer les attributs sysfs utilisés lors de la création des noms d'interface réseau.
- Ces listes sont stockées sous forme d'entrées hwdb
-
ID_NET_NAME_ALLOW_<sysfsattr>=0|1
- et
ID_NET_NAME_ALLOW=0|1
- L'objectif est d'éviter des modifications inattendues des noms d'interface lorsque le noyau est mis à jour et que de nouveaux attributs sysfs deviennent visibles.
-
- Ces listes sont stockées sous forme d'entrées hwdb
-
Une nouvelle unité
tpm2.target
a été ajoutée pour fournir un point de synchronisation pour les unités qui s'attendent à ce que le matériel TPM soit disponible.- Un nouveau générateur
systemd-tpm2-generator
a été ajouté qui insérera cette cible chaque fois qu'il détectera que le micrologiciel a initialisé un TPM, mais que Linux n'a pas encore chargé de pilote pour celui-ci.
- Un nouveau générateur
systemd-backlight
prend désormais correctement en charge les périphériques numérotés créés par le noyau pour éviter les collisions dans le sous-système LED.L'opération de mise à jour
systemd-hwdb
peut être désactivée avec une nouvelle variable d'environnementSYSTEMD_HWDB_UPDATE_BYPASS=1
.
systemd-hostnamed
offre divers manières de modifier le nom et la description du système
-
systemd-hostnamed
expose désormais l'ID de la machine et l'ID de démarrage via D-Bus.- Il expose également les hôtes
AF_VSOCK CID
, si disponible.
- Il expose également les hôtes
systemd-hostnamed
fournit désormais une interface Varlink de base.systemd-hostnamed
exporte les données complètes dansos-release(5)
etmachine-info(5)
via D-Bus et Varlink.hostnamectl
affiche désormais l'UUID du produit du système et le numéro de série du matériel s'il est connu.
La gestion du réseau avec systemd
systemd-networkd
fournit désormais une interface Varlink de base.La prise en charge du proxy ARP de
systemd-networkd
a gagné une nouvelle option pour configurer une variante de VLAN privé du proxy ARP pris en charge par le noyau sous le nomIPv4ProxyARPPrivateVLAN=
.-
systemd-networkd
exporte désormais les propriétésNamespaceId
etNamespaceNSID
via D-Bus et Varlink.- qui exposent l'inode et le NSID de l'espace de noms réseau géré par l'instance networkd)
systemd-networkd
prend désormais en charge les paramètresIPv6RetransmissionTimeSec=
etUseRetransmissionTime=
dans les fichiers.network
pour configurer le temps de retransmission pour les messages de sollicitation de voisin IPv6.networkctl
a acquis de nouveaux verbes « mask » et « unmask » pour masquer les fichiers de configuration réseau tels que les fichiers.network
.networkctl edit --runtime
permet de modifier la configuration volatile sous/run/systemd/network/
.La mise en œuvre derrière le paramètre réseau
TTLPropagate=
a été supprimée, et ce paramètre est désormais ignoré.systemd-network-generator
récupérera désormais la configuration situé dans.netdev/
.link/
.network/networkd.conf
à partir des informations d'identification du système.systemd-networkd
récupérera désormais les secrets dewireguard
depuis les informations d'identification (credentials).L'API Varlink de
systemd-networkd
prend désormais en charge l'énumération des homologues LLDP.Les fichiers .link prennent désormais en charge les nouveaux champs
Property=
,ImportProperty=
,UnsetProperty=
pour définir les propriétés udev sur un lien.Les différents fichiers
.link
fournis par systemd pour les interfaces censées être gérées uniquement parsystemd-networkd
portent désormais une propriété udev ID_NET_MANAGED_BY=io.systemd.Network garantissant que les autres solutions de gestion de réseau honorant cette propriété udev n'entrent pas en conflit avec networkd, en essayant de gérer ces interfaces.-
Les fichiers
.link
prennent désormais en charge un nouveau paramètreReceiverPacketSteeringCPUMask=
- pour configurer les processeurs vers lesquels diriger les paquets entrants.
-
La section
[Réseau]
des fichiers.network
a gagné un nouveau paramètreUseDomains=
,- qui est un bouton générique unique pour contrôler les paramètres du même nom dans
[DHCPv4]
,[DHCPv6]
et[IPv6AcceptRA]
.
- qui est un bouton générique unique pour contrôler les paramètres du même nom dans
-
Le fichier
99-default.link
que nous livrons par défaut- (qui définit la politique pour tous les périphériques réseau auxquels aucun autre fichier .link ne s'applique)
- répertorie désormais
mac
parmiAlternativeNamesPolicy=
. - Cela signifie que les interfaces réseau recevront désormais par défaut un nom de périphérique alternatif supplémentaire basé sur l'adresse MAC. (c'est-à-dire enx…)
À propos de systemd-nspawn
, l'alternative sécurisée et fine de chroot
systemd-nspawn
fournit désormais un répertoire/run/systemd/nspawn/unix-export/
dans lequel la charge utile du conteneur peut exposer les socketsAF_UNIX
pour leur permettre d'y accéder de l'extérieur.systemd-nspawn
teintera l'arrière-plan du terminal des conteneurs d'une couleur bleuâtre. Cela peut être un contrôleur avec le nouveau commutateur--background=
.systemd-nspawn
a obtenu la prise en charge de l'optionowneridmap
pour les montages--bind=
afin de mapper le propriétaire du répertoire cible depuis l'intérieur du conteneur vers le propriétaire du répertoire lié au système de fichiers hôte.systemd-nspawn
prend désormais en charge le déplacement des périphériques réseau Wi-Fi dans un conteneur, tout comme les autres interfaces réseau.
À propos du multi résolveur systemd-resolved
, qui peut remplacer dnsmasq
, Avahi
& libnss-mdns
systemd-resolved
lit désormais les codes d'erreur RFC 8914 EDE fournis par les services DNS en amont.systemd-resolved
et solvectl prennent désormais en charge les enregistrements RFC 9460 SVCB et HTTPS, ainsi que les enregistrements RFC 2915 NAPTR.solvectl
a acquis une nouvelle option --relax-single-label= pour permettre d'interroger des noms d'hôtes en une seule partie via DNS unicast pour chaque requête.L'interface Varlink IPC de
systemd-resolved
prend désormais en charge la résolution des services DNS-SD ainsi qu'une API pour résoudre les RR DNS bruts.Les fichiers de description de service .dnssd DNS_SD de
systemd-resolved
prennent désormais en charge lessous-types
DNS-SD via le nouveau paramètre SubType=.La configuration de
systemd-resolved
peut désormais être rechargée sans redémarrer le service, c'est-à-dire quesystemctl reload systemd-resolved
est désormais pris en charge.
Une intégration fine de SSH
Un drop-in de configuration sshd pour permettre aux clés ssh acquises via
userdbctl
(par exemple exposées par des comptes de typesystemd-homed
) d'être utilisées pour l'autorisation des connexions SSH entrantes.-
Un petit nouveau générateur d'unités
systemd-ssh-generator
a été ajouté. Il vérifie si le binairesshd
est installé. Si tel est le cas, il le lie via l'activation de socket par connexion à différentes sockets en fonction du contexte d'exécution :- Si le système est exécuté sur une VM prenant en charge
AF_VSOCK
, il lie automatiquement sshd auAF_VSOCK
port 22 . - Si le système est invoqué en tant que conteneur OS complet et que le gestionnaire de conteneur pré-monte un répertoire
/run/host/unix-export/
, il liera sshd à un socketAF_UNIX
/run/host/unix-export/ssh
. L'idée est que la liaison du gestionnaire de conteneur monte également le répertoire à un endroit approprié sur l'hôte, de sorte que le socketAF_UNIX
puisse être utilisé pour se connecter facilement de l'hôte au conteneur.
- Si le système est exécuté sur une VM prenant en charge
sshd est également lié à un socket AF_UNIX
/run/ssh-unix-local/socket
, qui consiste à utiliserssh/sftp
à la manière desudo
pour accéder aux ressources d'autres utilisateurs locaux.Via l'option de ligne de commande du noyau
systemd.ssh_listen=
et les informations d'identification systèmessh.listen
,sshd
peut être lié à des options supplémentaires explicitement configurées, notamment les portsAF_INET
/AF_INET6
.En particulier, les deux premiers mécanismes devraient faciliter grandement la gestion des machines virtuelles locales et des conteneurs de système d'exploitation complets, car les connexions SSH fonctionneront basiquement à partir de l'hôte – même si aucun réseau n'est disponible.
-
systemd-ssh-generator
génère optionnellement un fichier de service d'activation de socket par connexion en encapsulantsshd
. Ceci n'est fait que si la distribution n'en fournit pas elle-même sous le nom desshd@.service
. L'unité générée ne fonctionne correctement que si le répertoire de séparation des privilèges SSHprivsep
existe. Malheureusement, les distributions varient & placent ce répertoire de manière très variable. Voici une liste incomplète :-
/usr/share/empty.sshd/
(nouveau sous Fedora) -
/var/empty/
/var/empty/sshd/
-
/run/sshd/
(debian/ubuntu ?)
-
Si le répertoire SSH privsep
est placé sous /var/
ou /run/
, il faut veiller à ce que le répertoire soit créé automatiquement au démarrage si nécessaire, car ces répertoires peuvent être ou sont toujours vides. Cela peut être fait via un drop-in tmpfiles.d/
. Vous pouvez utiliser l'option meson sshdprivsepdir
fournie par systemd pour configurer le répertoire, au cas où vous souhaiteriez que systemd crée automatiquement le répertoire selon vos besoins, si votre distribution ne le couvre pas de manière native.
Recommandations aux distributions, afin que les choses fonctionnent correctement :
• Veuillez fournir un fichier de service SSH par connexion sous le nom sshd@.service
.
• Veuillez déplacer le répertoire SSH privsep
dans /usr/
* afin qu'il soit véritablement immuable sur les systèmes d'exploitation basés sur des images
* qu'il soit strictement sous le contrôle du gestionnaire de paquets
* et qu'il ne nécessite jamais de recréation si le système démarre avec un répertoire /run/
ou /var
vide.
• Dans le prolongement de ceci : veuillez envisager de suivre l'exemple de Fedora ici et d'utiliser /usr/share/empty.sshd/
pour minimiser les différences inutiles entre les distributions.
• Si votre distribution insiste pour placer le répertoire dans /var/
ou /run/
alors veuillez au moins fournir un drop-in tmpfiles.d/
pour le recréer automatiquement au démarrage, afin que le binaire sshd
fonctionne correctement, quel que soit le contexte dans lequel il se trouve appelé.
- Un petit outil
systemd-ssh-proxy
a été ajouté, censé faire office de pendant desystemd-ssh-generator
. C'est un petit plug-in pour le client SSH (viaProxyCommand
/ProxyUseFdpass
) pour lui permettre de se connecter aux socketsAF_VSOCK
ouAF_UNIX
. Exemple :ssh vsock/4711
se connecte à une VM locale avec le cid 4711, oussh unix/run/ssh-unix-local/socket
pour se connecter à l'hôte local via le socketAF_UNIX
/run/ssh-unix-local/socket
.
systemd-boot
et systemd-stub
et outils associés, une alternative minimale & ukify à grub
La prise en charge des mesures PCR TPM 1.2 a été supprimée de
systemd-stub
. Le TPM 1.2 est obsolète et – en raison de la faiblesse (selon les normes actuelles) des algorithmes cryptographiques qu'il ne prend en charge – n'offre pas réellement les avantages en matière de sécurité qu'il est censé offrir. Étant donné que le reste de la base de code de systemd n'a jamais pris en charge TPM 1.2, la prise en charge a également été supprimée desystemd-stub.
systemd-stub
mesurera désormais sa charge utile via les nouvelles APIEFI Confidential Computing
(CC), en plus des mesures préexistantes duTPM
.Les confextes (cf
[systemd-sysext](https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html)
) sont également chargés parsystemd-stub
depuis l'ESP.kernel-install
a obtenu le support de--root=
pour le verbelist
.bootctl
fournit désormais une interface Varlink de base et peut être exécuté en tant que service(démon) via une unité modèle.systemd-measure
a obtenu de nouvelles options--certificate=
,--private-key=
et--private-key-source=
pour permettre l'utilisation desmoteurs
oufournisseurs
d'OpenSSL comme mécanisme de signature à utiliser lors de la création de valeurs de mesure signées PCR TPM2ukify
a obtenu la prise en charge de la signature des signatures PCR via les moteurs et fournisseurs OpenSSL.ukify
prend désormais en charge les noyauxzboot
.systemd-boot
prend désormais en charge la transmission de commutateurs de ligne de commande de noyau supplémentaires aux noyaux invoqués via une chaîne SMBIOS Type #11io.systemd.boot.kernel-cmdline-extra
. Ceci est similaire à la prise en charge préexistante de cela danssystemd-stub
, mais s'applique également aux entrées de spécification du chargeur de démarrage de type n°1.La prise en charge automatique de l'inscription SecureBoot par
systemd-boot
prend également en charge l'inscriptiondbx
(auparavant, seule l'inscriptiondb/KEK/PK
était prise en charge). Il prend également désormais en charge le mode UEFI « Personnalisé ».La politique
pcrlock
est enregistrée dans un fichier d'informations d'identification non chiffrépcrlock.<entry-token>.cred
sous XBOOTLDR/ESP dans le répertoire/loader/credentials/
. Il sera récupéré au démarrage parsystemd-stub
et transmis à initrd, où il pourra être utilisé pour déverrouiller le système de fichiers racine.systemd-pcrlock
a obtenu une option--entry-token=
pour configurer le jeton d'entrée.systemd-pcrlock
fournit désormais une interface Varlink de base et peut être exécuté en tant que démon via une unité modèle.-
La politique d'accès au TPM nvindex de
systemd-pcrlock
a été modifiée- cela signifie que les politiques pcrlock précédentes stockées dans nvindexes sont invalidées.
- Ils doivent être supprimés (
systemd-pcrlock remove-policy
) et recréés (systemd-pcrlock make-policy
). - Pour le moment,
systemd-pcrlock
reste une fonctionnalité expérimentale, mais elle devrait devenir stable dans la prochaine version, c'est-à-dire la v257.
Le commutateur
--recovery-pin=
desystemd-pcrlock
prend désormais trois valeurs :hide
,show
,query
. Si « afficher » est sélectionné, le code PIN de récupération généré automatiquement est affiché à l'utilisateur. Si « requête » est sélectionné, le code PIN est demandé à l'utilisateur.sd-stub
prend désormais en charge la nouvelle section PE.ucode
dans les UKI, qui peut contenir des données de microcode CPU. Lorsque le contrôle est transféré au noyau Linux, ces données sont ajoutées au début de l'ensemble des initrds transmis.
systemd-run/run0
, une alternative sécurisée à sudo
-
systemd-run
est désormais un binaire multi-appels. Lorsqu'il est invoqué en tant querun0
, il fournit une interface similaire àsudo
, tous les arguments commençant au premier paramètre non-option étant traités comme la commande à invoquer en tant que root.- Contrairement à « sudo » et aux outils similaires, il n'utilise pas de binaires setuid ou d'autres méthodes d'élévation de privilèges
- mais exécute à la place la commande spécifiée comme une unité transitoire
- Elle est démarrée par le gestionnaire de services système, de sorte que les privilèges sont supprimés plutôt que gagnés.
- Cela met ainsi en œuvre un modèle de sécurité beaucoup plus robuste et sûr.
- Comme d'habitude, l'autorisation est gérée via Polkit.
-
systemd-run/run0
teintera désormais l'arrière-plan du terminal sur les terminaux pris en charge :- dans un ton rougeâtre lors de l'appel d'un service racine
- dans un ton jaunâtre sinon.
- Cela peut être contrôlé et désactivé via le nouveau commutateur
--background=
.
systemd-run
a gagné une nouvelle option--ignore-failure
pour supprimer les échecs de commandes.
Outillages en ligne de commande
-
systemctl edit --stdin
permet la création de fichiers d'unité et de drop-ins avec du contenu fourni via l'entrée standard.- Ceci est utile lors de la création d’une configuration par programme ; l'outil se charge de déterminer le nom du fichier, de créer les répertoires éventuels et de recharger ensuite le gestionnaire.
systemctl disable --now
etsystemctl mask --now
fonctionnent désormais correctement avec les modèles d'unités.systemd-analyze architectures
répertorie les architectures CPU connues.systemd-analyze --json=…
est pris en charge pour lesarchitectures
,capability
,exit-status
systemd-tmpfiles --purge
purgera (supprimera) tous les fichiers et répertoires créés via la configurationtmpfiles.d
.systemd-id128
a gagné de nouvelles options--no-pager
,--no-legend
et -j/--json=
.hostnamectl
a gagné-j
comme raccourci pour--json=pretty
ou--json=short
loginctl
prend désormais en charge-j/
--json=
.resolvectl
prend désormais en charge-j/
--json=
pour--type=
.systemd-tmpfiles
a gagné une nouvelle option--dry-run
pour simuler ce qui serait fait sans réellement agir.varlinkctl
a obtenu un nouveau commutateur--collect
pour collecter toutes les réponses d'un appel de méthode qui prend en charge plusieurs réponses et le transforme en un seul tableau JSON.systemd-dissect
a acquis une nouvelle option--make-archive
pour générer un fichier d'archive (tar.gz et similaire) à partir d'une image disque.
systemd-vmspawn
, permet de générer un système d'exploitation dans une machine virtuelle
-
systemd-vmspawn
a gagné- une nouvelle option
--firmware=
pour configurer ou lister les définitions de firmware pour Qemu - une nouvelle option
--tpm=
pour activer ou désactiver l'utilisation d'un TPM logiciel - une nouvelle option
--linux=
pour spécifier un noyau binaire pour le démarrage direct du noyau - une nouvelle option
--initrd=
pour spécifier un initrd pour le démarrage direct du noyau - une nouvelle option
-D
/--directory
pour utiliser un répertoire simple comme système de fichiers racine - une nouvelle option
--private-users
similaire à celle desystemd-nspawn
- de nouvelles options
--bind=
et--bind-ro=
pour lier une partie de la hiérarchie du système de fichiers de l'hôte à l'invité - une nouvelle option
--extra-drive=
pour attacher du stockage supplémentaire - et
-n
/--network-tap
/--network-user-mode
pour configurer le réseau.
- une nouvelle option
Un nouveau
systemd-vmspawn@.service
peut être utilisé pour lancersystemd-vmspawn
en tant que service.-
systemd-vmspawn
a obtenu les nouveaux commutateurs--console=
et--background=
qui contrôlent la manière d'interagir avec la VM.- Comme auparavant, une interface de terminal interactive est fournie par défaut, mais désormais avec un fond teinté d'une teinte verdâtre.
systemd-vmspawn
peut désormais enregistrer ses VM auprès desystemd-machined
, contrôlé via le commutateur--register=
.-
La commande start de
machinectl
(et associée) peut désormais appeler des images- soit en tant que conteneurs via
systemd-nspawn
(le commutateur est--runner=nspawn
, la valeur par défaut) - soit en tant que VM via
systemd-vmspawn
(le commutateur est--runner=vmspawn
, ou court-V
).
- soit en tant que conteneurs via
systemd-vmspawn
prend désormais en charge deux commutateurs--pass-ssh-key=
et--ssh-key-type=
pour configurer éventuellement des clés SSH transitoires à transmettre aux machines virtuelles invoquées afin de pouvoir y accéder en SSH une fois démarrées.-
systemd-vmspawn
activera désormais diverses options sur les VMs-
HyperV enlightenments
" - et le
VM Generation ID
-
Une nouvelle variable d'environnement
$SYSTEMD_VMSPAWN_QEMU_EXTRA
peut contenir des options de ligne de commande qemu supplémentaires à transmettre à qemu.-
systemd-machined
a acquis une nouvelle méthode D-BusGetMachineSSHInfo()
qui est utilisé parsystemd-vmspawn
pour récupérer les informations nécessaires pour se connecter au système.-
systemd-machined
a acquis une nouvelle interface Varlink qui est utilisée parsystemd-vmspawn
pour enregistrer les machines avec diverses informations & métadonnées supplémentaires.
-
systemd-repart
, pour retailler un disque à la volée
-
systemd-repart
a obtenu de nouvelles options--generate-fstab=
et--generate-crypttab=
- pour écrire les fichiers fstab et crypttab correspondant aux partitions générées.
-
systemd-repart
a obtenu une nouvelle option--private-key-source=
- pour permettre d'utiliser les
moteurs
oufournisseurs
d'OpenSSL comme mécanisme de signature à utiliser lors de la création de partitions de signature Verity.
- pour permettre d'utiliser les
-
systemd-repart
a obtenu un nouveau paramètreDefaultSubvolume=
dans les drop-insrepart.d/
- qui permettent de configurer le sous-volume btrfs par défaut pour les systèmes de fichiers btrfs nouvellement formatés.
Bibliothèques autours du monde systemd
-
libsystemd
a obtenu un nouvel appelsd_bus_creds_new_from_pidfd()
- pour obtenir un objet d'informations d'identification pour un pidfd
- et
sd_bus_creds_get_pidfd_dup()
pour récupérer le pidfd à partir d'un objet d'informations d'identification.
-
La logique d'identification de
sd-bus
acquerra désormais également les listes de groupes UNIX du homologue- et le pidfd du homologue si pris en charge et demandé.
La macro RPM
%_kernel_install_dir
a été ajoutée avec le chemin d'accès au répertoire des plugins d'installation du noyau.-
Les dépendances
liblz4
,libzstd
,liblzma
,libkmod
,libgcrypt
ont été modifiées- de dépendances de bibliothèque partagée habituelles en dépendances basées sur
dlopen()
. - Notez que cela signifie que ces bibliothèques pourraient ne pas être automatiquement récupéré lorsque les dépendances ELF sont résolues. En particulier le manque de libkmod peut causer des problèmes de démarrage. Cela affecte le dracut <= 101
- de dépendances de bibliothèque partagée habituelles en dépendances basées sur
Les binaires systemd ELF qui utilisent des bibliothèques via dlopen() sont maintenant construits avec une nouvelle section de note d'en-tête ELF, suite à une nouvelle spécification définie à
docs/ELF_DLOPEN_METADATA.md, qui fournit des informations sur lesquels lesonames
sont chargés et utilisés s'ils sont trouvés au moment de l'exécution. Cela permet aux outils et packagers pour découvrir par programme la liste des éléments facultatifs
dépendances utilisées par tous les binaires systemd ELF. Un analyseur avec packaging les outils d'intégration sont disponibles sur git-
L'API
sd-journal
a obtenu un nouvel appelsd_journal_stream_fd_with_namespace()
- qui ressemble à
sd_journal_stream_fd()
mais crée un flux de journaux ciblé sur un espace de noms de journal spécifique.
- qui ressemble à
-
L'API sd-id128 a obtenu un nouvel appel d'API
sd_id128_get_invocation_app_special()
- pour acquérir un ID spécifique à l'application dérivé de l'ID d'appel de service.
-
L'API sd-event a obtenu un nouvel appel d'API
sd_event_source_get_inotify_path()
- qui renvoie le chemin du système de fichiers pour lequel une source d'événement inotify a été créée.
systemd-cryptsetup
systemd-cryptenroll
, où l'aide au chiffrement de disque
-
L'argument du nœud de périphérique pour
systemd-cryptenroll
est désormais facultatif.- S'il est omis, il sera automatiquement déduit du périphérique de bloc de support de
/var/
- (qui est très probablement le même que le système de fichiers racine, ce qui signifie effectivement que si vous ne spécifiez rien, sinon l'outil enregistrera désormais par défaut une clé dans périphérique LUKS du système de fichiers racine).
- S'il est omis, il sera automatiquement déduit du périphérique de bloc de support de
systemd-cryptenroll
peut désormais s'inscrire directement avec une clé publiquePKCS11
(au lieu d'un certificat).-
systemd-cryptsetup
systemd-cryptenroll
peuvent désormais verrouiller un disque avec une clé EC fournie par PKCS#11- (auparavant, il ne prenait en charge que RSA).
-
systemd-cryptsetup
prend en charge l'option crypttablink-volume-key=
- pour lier la clé du volume au jeu de clés du noyau lorsque le volume est ouvert.
-
systemd-cryptenroll
n'activera plus la protection contre les attaques par dictionnaire (c'est-à-dire activer NO_DA) pour les inscriptions TPM qui n'impliquent pas de code PIN.-
DA
ne devrait pas être nécessaire dans ce cas (puisque l'entropie de la clé est suffisamment élevée pour rendre cela inutile), - mais un risque un verrouillage accidentel en cas de modifications inattendues du PCR.
-
-
systemd-cryptenroll
prend désormais en charge l'inscription d'un nouvel emplacement tout en déverrouillant l'ancien emplacement via TPM2- (auparavant, le déverrouillage ne fonctionnait que via un mot de passe ou FIDO2).
systemd-homed
systemd-logind
, systemd-userdbd
-
systemd-homed
prend désormais en charge le déverrouillage des répertoires personnels lors de la connexion via SSH.- Auparavant, les répertoires personnels devaient être déverrouillés avant toute tentative de connexion SSH.
-
Les enregistrements utilisateur au format JSON ont été étendus avec une zone de stockage publique distincte appelée « Répertoires binaires des enregistrements utilisateur » ("User Record Blob Directories").
- Ceci est destiné à stocker l'image d'arrière-plan de l'utilisateur, l'image de l'avatar et d'autres éléments similaires qui sont trop volumineux pour tenir dans l'enregistrement utilisateur lui-même.
-
systemd-homed
,userdbctl
ethomectl
prennent désormais en charge les répertoires binaires.
-
homectl
a gagné--avatar=
et--login-background=
- pour contrôler deux éléments spécifiques des répertoires binaires.
- Un nouveau champ
additionalLanguages
a été ajouté aux enregistrements utilisateur JSON (tel que pris en charge parsystemd-homed
etsystemd-userdbd
),- qui est étroitement lié au
preferredLanguage
préexistant, et permet de spécifier plusieurs langues supplémentaires pour le compte utilisateur. - Il est utilisé pour initialiser la variable d'environnement
$LANGUAGES
lorsqu'elle est utilisée.
- qui est étroitement lié au
-
Une nouvelle paire de champs
preferredSessionType
etpreferredSessionLauncher
a été ajoutée aux enregistrements utilisateur JSON,- qui peuvent être utilisées pour contrôler le type de session de bureau à activer de préférence lors des connexions de l'utilisateur.
-
homectl
a gagné un nouveau verbefirstboot
, et une nouvelle unitésystemd-homed-firstboot.service
- ce verbe est utilisé pour créer des utilisateurs dans un environnement de premier démarrage,
- soit à partir des informations d'identification du système
- soit en interrogeant de manière interactive.
- ce verbe est utilisé pour créer des utilisateurs dans un environnement de premier démarrage,
-
systemd-logind
prend désormais en charge une nouvelle classe de sessionbackground-light
qui n'envoie pas l'unitéuser@.service
.- Ceci est destiné aux sessions automatisées, type cron, sans nécessiré d'interactions utilisateurs
- Cela rend l'ouverture plus légère et rapide.
Le gestionnaire de services par utilisateur sera désormais suivi comme un type de session « gestionnaire » (manager) distinct parmi les sessions de connexion de chaque utilisateur.
-
homectl
prend désormais en charge un mode--offline
,- grâce auquel certaines propriétés du compte peuvent être modifiées sans déverrouiller le répertoire personnel.
-
systemd-logind
a acquis une nouvelle méthodeorg.freedesktop.login1.Manager.ListSessionsEx()
- qui fournit des métadonnées supplémentaires par rapport à
ListSessions()
. -
loginctl
l'utilise pour lister des champs supplémentaires dans les sessions de liste.
- qui fournit des métadonnées supplémentaires par rapport à
-
systemd-logind
a gagné une nouvelle méthodeorg.freedesktop.login1.Manager.Sleep()
- qui redirige automatiquement vers
SuspendThenHibernate()
,Suspend()
,HybridSleep()
ouHibernate()
,- selon ce qui est pris en charge et configuré,
- une nouvelle paramètre de configuration
SleepOperation=
, - ainsi qu'une méthode d'assistance associée
org.freedesktop.login1.Manager.CanSleep()
- et une propriété
org.freedesktop.login1.Manager.SleepOperation
. -
systemctl sleep
appelle la nouvelle méthode pour mettre automatiquement la machine en veille de la manière la plus appropriée.
- une nouvelle paramètre de configuration
- selon ce qui est pris en charge et configuré,
- qui redirige automatiquement vers
systemctl sleep
appelle une nouvelle méthode pour mettre automatiquement la
machine dans le mode sommeil de la manière la plus appropriée.
systemd-creds
, mécanisme de gestion des authentifications, pour arrêter de balancer du mot de passe en clair partout
systemd-creds
fournit désormais une API Varlink IPC pour chiffrer et déchiffrer les informations d'identification.-
La sélection de clé
tpm2-absent
desystemd-creds
a été renommée ennull
, puisque c'est ce qu'elle fait réellement :-
chiffrer
etsigner
avec une clé nulle fixe. -
--with-key=null
ne doit être utilisé que dans des cas très spécifiques, - car il n'offre aucune protection en matière d'intégrité ou de confidentialité.
- c'est-à-dire qu'il n'est sûr à utiliser comme solution de secours que dans des environnements dépourvus à la fois d'un TPM et d'un accès au système de fichiers racine pour utiliser la clé de chiffrement de l'hôte, ou lorsque l'intégrité est assurée d'une autre manière.
-
-
systemd-creds
a obtenu un nouveau commutateur--allow-null
.- S'il est spécifié, le verbe
decrypt
décodera les informations d'identification chiffrées qui utilisent la clénull
- Par défaut, cela est refusé, car l'utilisation de la clé
null
annule le cryptage authentifié normalement effectué.
- S'il est spécifié, le verbe
De quoi mettre en veille et mettre en veille prolongée
-
Le fichier de configuration
sleep.conf
a obtenu un nouveau paramètreMemorySleepMode=
- pour configurer le mode veille plus en détail.
-
Un nouveau petit service
systemd-hibernate-clear.service
a été ajouté- qui efface les informations d'hibernation de la variable EFI
HibernateLocation
,- au cas où le périphérique de reprise disparaîtrait.
- Normalement, cette variable est censée être nettoyée par le code qui lance l'image de reprise depuis l'hibernation.
- Mais lorsque le périphérique est manquant et que ce code ne s'exécute pas,
- ce service effectuera désormais le travail nécessaire, garantissant qu'aucune information d'image d'hibernation obsolète ne reste lors des démarrages suivants.
- qui efface les informations d'hibernation de la variable EFI
Espaces de noms utilisateurs non privilégiés et gestion des montages de disques
-
Un nouveau petit service
systemd-nsresourced.service
a été ajouté.- Il fournit une API Varlink IPC qui attribue une plage UID/GID de 64 Ko gratuite et allouée de manière transitoire à un espace de noms d'utilisateur non initialisé fourni par un client. Il peut être utilisé pour implémenter des gestionnaires de conteneurs sans privilèges et d'autres programmes nécessitant des plages d'ID utilisateur dynamiques. Il fournit également des interfaces pour déléguer ensuite des descripteurs de fichiers de montage, des groupes de contrôle et des interfaces réseau aux espaces de noms utilisateur configurés de cette manière.
-
Un nouveau petit service
systemd-mountfsd.service
a été ajouté.- Il fournit une API Varlink IPC pour monter des images DDI et renvoyer un ensemble de descripteurs de fichiers de montage pour celles-ci. Si un espace de noms utilisateur fd est fourni en entrée, alors les montages sont enregistrés avec l'espace de noms utilisateur. Pour garantir la confiance dans l'image, elle doit fournir des informations Verity (ou bien une authentification polkit interactive est requise).
L'outil
systemd-dissect
peut désormais accéder aux DDI sans aucun privilège en utilisantsystemd-nsresourced
/systemd-mountfsd.
-
Si le gestionnaire de services s'exécute sans privilèges (c'est-à-dire
systemd --user
),- il prend désormais en charge
RootImage=
pour accéder aux images DDI, également implémenté viasystemd-nsresourced
/systemd-mountfsd.
- il prend désormais en charge
-
systemd-nspawn
peut désormais fonctionner sans privilèges,- si un DDI approprié est fourni via
--image=
, encore une fois implémenté viasystemd-nsresourced
/systemd-mountfsd.
- si un DDI approprié est fourni via
Divers changements
-
timedatectl
etmachinectl
ont obtenu l'option-P
,- un alias pour
--value --property=…
.
- un alias pour
Divers outils permettant d'imprimer joliment les fichiers de configuration mettront désormais en évidence les directives de configuration.
-
varlinkctl
a obtenu le support du transportssh:
.- Cela nécessite OpenSSH 9.4 ou plus récent.
-
systemd-sysext
a obtenu la prise en charge de l'activation des extensions système de manière mutable,- où un répertoire supérieur inscriptible est stocké sous /
var/lib/extensions.mutable/
, - et une nouvelle option
--mutable=
pour configurer ce comportement. - Un mode « éphémère » n'est pas non plus pris en charge lorsque la couche mutable est configurée pour être un tmpfs qui est automatiquement libéré lorsque les extensions système sont rattachées.
- où un répertoire supérieur inscriptible est stocké sous /
Les coredumps sont désormais conservés pendant deux semaines par défaut (au lieu de trois jours comme auparavant).
-
Le paramètre
portablectl
--copy=
a obtenu un nouvel argumentmixte
,- qui entraînera la liaison des ressources appartenant au système d'exploitation
- (par exemple : les profils portables) mais aux ressources appartenant à l'image portable à copier (par exemple les fichiers unitaires et les images elles-mêmes).
-
systemd enregistrera désormais les types MIME de ses divers types de fichiers
- (par exemple, fichiers journaux, DDI, informations d'identification cryptées…) via l'infrastructure d'informations mime partagées XDG.
- (Les fichiers de ces types seront ainsi reconnus comme leur propre élément dans les gestionnaires de fichiers de bureau tels que les fichiers GNOME.)
systemd-dissect
affichera désormais la taille de secteur détectée d'un DDI donné dans sa sortie par défaut.systemd-portabled
génère désormais des messages de journal structurés reconnaissables chaque fois qu'un service portable est attaché ou détaché.-
La vérification de la signature
Verity
dans l'espace utilisateur (c'est-à-dire la vérification par rapport aux clés/etc/verity.d/
) lors de l'activation des DDI peut désormais être activée/désactivée- via une option de ligne de commande du noyau
systemd.allow_userspace_verity=
- et une variable d'environnement
SYSTEMD_ALLOW_USERSPACE_VERITY=
.
- via une option de ligne de commande du noyau
-
La gestion des quotas du système de fichiers ext4/xfs a été retravaillée,
- de sorte que quotacheck et quotaon soient désormais invoqués en tant que services basés sur un modèle par système de fichiers
- (par opposition à des singletons uniques à l'échelle du système), de style similaire à la logique fsck, growfs, pcrfs.
- Cela signifie que les systèmes de fichiers avec quota activé peuvent désormais être raisonnablement activés au moment de l'exécution du système, et pas seulement au démarrage.
systemd-analyze dot
affichera désormais également les dépendancesBindsTo=
.systemd-debug-generator
a acquis la possibilité d'ajouter des unités arbitraires en fonction de leur transmission via les informations d'identification du système.Une nouvelle option de ligne de commande du noyau
systemd.default_debug_tty=
peut être utilisée pour spécifier le TTY pour le shell de débogage, indépendamment de son activation ou de sa désactivation.portablectl
a obtenu un nouveau commutateur--clean
qui efface les données d'un service portable (cache, logs, state, runtime, fdstore) lors de son détachement.
Documentations
La documentation restante qui se trouvait sur https://freedesktop.org/wiki/Software/systemd/ a été déplacée vers https://systemd.io/.
Un nouveau laïus décrivant les interfaces virtuelles d'intégration de systemd a été ajouté :
La page de manuel
sd_notify()
contient des exemples de code C et Python qui montrent comment implémenter l'interface dans ces langages sans impliquer libsystemd.
Contributeurs
Contributions from: A S Alam, AKHIL KUMAR,
Abraham Samuel Adekunle, Adrian Vovk, Adrian Wannenmacher,
Alan Liang, Alberto Planas, Alexander Zavyalov, Anders Jonsson,
Andika Triwidada, Andres Beltran, Andrew Sayers,
Antonio Alvarez Feijoo, Arthur Zamarin, Artur Pak, AtariDreams,
Benjamin Franzke, Bernhard M. Wiedemann, Black-Hole1, Bryan Jacobs,
Burak Gerz, Carlos Garnacho, Chandra Pratap, Chris Simons,
Christian Wesselhoeft, Clayton Craft, Colin Geniet, Colin Walters,
Costa Tsaousis, Cristian Rodríguez, Daan De Meyer,
Damien Challet, Dan Streetman, David Tardon, David Venhoek,
Diego Viola, Dionna Amalie Glaze, Dmitry Konishchev,
Edson Juliano Drosdeck, Eisuke Kawashima, Eli Schwartz,
Emanuele Giuseppe Esposito, Eric Daigle, Evgeny Vereshchagin,
Felix Riemann, Fernando Fernandez Mancera, Florian Schmaus,
Franck Bui, Frantisek Sumsal, Friedrich Altheide,
Gabríel Arthúr Pétursson, Gaël Donval, Georges Basile Stavracas Neto,
Gerd Hoffmann, GNOME Foundation, Guido Leenders,
Guilhem Lettron, Göran Uddeborg, Hans de Goede, Harald Brinkmann,
Heinrich Schuchardt, Henry Li, Holger Assmann, Ivan Kruglov,
Ivan Shapovalov, Jakub Sitnicki, James Muir, Jan Engelhardt,
Jan Macku, Jeff King, JmbFountain, Joakim Nohlgård,
Jonathan Conder, Julius Alexandre, Jörg Behrmann, Keian, Kirk,
Kristian Klausen, Krzesimir Nowak, Lars Ellenberg,
Lennart Poettering, Luca Boccassi, Ludwig Nussel, Lukáš Nykrýn,
Luna Jernberg, Luxiter, Maanya Goenka, Mariano Giménez,
Markus Merklinger, Martin Ivicic, Martin Srebotnjak,
Martin Trigaux, Martin Wilck, Matt Layher, Matt Muggeridge,
Matteo Croce, Matthias Lisin, Max Gautier, Max Staudt, MaxHearnden,
Michael Biebl, Michal Koutný, Michal Sekletár, Mike Gilbert,
Mike Yuan, Mikko Ylinen, MkfsSion, MrSmör, Nandakumar Raghavan,
Nick Cao, Nick Rosbrook, Norbert Lange, Ole Peder Brandtzæg,
Ondrej Kozina, Oğuz Ersen, Pablo Méndez Hernández,
Pierre GRASSER, Piotr Drąg, QuonXF, Rafaël Kooi, Raito Bezarius,
Rasmus Villemoes, Reid Wahl, Renjaya Raga Zenta, Richard Maw,
Roland Hieber, Ronan Pigott, Rose, Ross Burton, Sam Leonard,
Samuel BF, Sarvajith Adyanthaya, Sergei Zhmylev, Sergey A, Shulhan,
SidhuRupinder, Simon Fowler, Sludge, Stuart Hayhurst, Susant Sahani,
Takashi Sakamoto, Temuri Doghonadze, Thilo Fromm, Thomas Blume,
TobiPeterG, Tobias Fleig, Tomáš Pecka, Topi Miettinen,
Tycho Andersen, Unique-Usman, Usman Akinyemi, Vasiliy Kovalev,
Vasiliy Stelmachenok, Vishal Chillara Srinivas, Vitaly Kuznetsov,
Vito Caputo, Vladimir Stoiakin, Werner Sembach, Will Springer,
Winterhuman, Xiaotian Wu, Yu Watanabe, Yuri Chornoivan,
Zbigniew Jędrzejewski-Szmek, Zmyeir, aslepykh, chenjiayi,
cpackham-atlnz, cunshunxia, djantti, hfavisado, hulkoba, ksaleem,
medusalix, mille-feuille, mkubiak, mooo, msizanoen, networkException,
nl6720, r-vdp, runiq, sam-leonard-ct, samuelvw01, sharad3001, sushmbha,
wangyuhang, zzywysm, İ. Ensar Gülşen, Łukasz Stelmach,
Štěpán Němec, 我超厉害, 김인수
— Edinburgh, 2024-06-11
Vous êtes invité à télécharger l'archive tar ici si vous souhaitez le compiler vous-même.
Aller plus loin
- System and Service Manager (28 clics)
- Github systemd (23 clics)
- liste d'échanges des dev systemd (11 clics)
- Blog perso de Lennart sur systemd v256 (32 clics)
- Conférence autour de l'écosystème systemd le 25-26 sept 2024 (6 clics)
- The Linux Userspace API (UAPI) Group, offre de décliner en normes les approches autour de systemd (15 clics)
- mkosi - une alternative intégrée à debootstrap ou supermin, utilisant les outils systemd (40 clics)
- casync - un rsync optimisé pour les VM et autres gros machins (encore un truc de Lennart...) (50 clics)
- Systemd v256 - La page des notes de version (9 clics)
- Systemd v255 - La page des notes de version (10 clics)
# Déjà vendredi ?
Posté par Lenbootil . Évalué à 4.
Ah ben non.
[^] # Re: Déjà vendredi ?
Posté par Tonton Th (Mastodon) . Évalué à 10.
Mais si, on est bien vendredi !
https://github.com/systemd/systemd/issues/33349
[^] # Re: Déjà vendredi ?
Posté par Stéphane Ascoët (site web personnel) . Évalué à -10.
Et bien, encore un truc qui confirme que j'ai raison de boycotter cette merde! Et j'apprends que Lennart Poettering serait passé de Red Hat à m$… que le support des anciens scripts d'initialisation est abandonné, comme ça, sans tambour ni trompette…
Maldhatter:
Miguel:
Dès le départ le but était bien de remplacer GNU, c'est la raison pour laquelle j'appelle les distributions qui l'ont adopté "Systemd/Linux". Je souscris à l'hypothèse défendue par certains comme quoi c'est dans l'intérêt de Red Hat de rendre Linux aussi complexe que window$ afin de vendre un maximum de support. Et maintenant, les masques tombent avec l'entrée en scène de m$, dont l'implication dans le libre rentre bien dans son habituelle stratégie d'"Embrace, extend and extinguish"
Vive les distributions GNU/Linux sans Systemd!
[^] # Re: Déjà vendredi ?
Posté par jmiven . Évalué à 10.
En même temps, si tu "boycottes" les distributions concernées, ce n'est pas étonnant que tu sois passé à côté de l'information.
Ah oui, parce qu'auparavant les distributions utilisaient GNU Shepherd. Et syslog-ng et vixie-cron sont des projets GNU. Non sérieusement, quels sont les projets GNU "remplacés" par systemd ?
Poettering ayant été embauché par MS il y a déjà deux ans, j'espère que quelqu'un a pensé à ramasser les masques.
Elles semblent rendre un grand service aux développeurs des autres distributions, oui.
[^] # Re: Déjà vendredi ?
Posté par Tonton Th (Mastodon) . Évalué à 3.
Et où peut-on en trouver une liste à jour ?
[^] # Re: Déjà vendredi ?
Posté par madhatter (site web personnel) . Évalué à 6.
Sur wikipédia il y a une page https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd
There is no spoon...
[^] # Re: Déjà vendredi ?
Posté par vincele . Évalué à 1.
Bonjour,
sinon il y a aussi la recherche sur distrowatch qui permet quelques critères d'intérêt.
[^] # Re: Déjà vendredi ?
Posté par Maderios . Évalué à 4.
Le problème, à part Slackware et OpenWrt (embarqué), c'est la pérennité et le suivi de ces distributions à audience confidentielle qui refusent d'intégrer Systemd. Tant de distributions ont disparu depuis le siècle dernier…
[^] # Re: Déjà vendredi ?
Posté par madhatter (site web personnel) . Évalué à 5.
Dans les distro pérennes, on peut ajouter quand même Gentoo qui n'est pas dans la liste Wikipedia mais laisse le choix entre systemd et OpenRC à l'installation.
On pourrait y mettre également Alpine Linux qui semble avoir une bonne cote de popularité et est pas mal vue du côté des conteneurs de part sa légèreté, ainsi que GuixSD qui reste certes assez confidentielle mais qui est la distribution officielle du projet GNU.
There is no spoon...
[^] # Re: Déjà vendredi ?
Posté par jmiven . Évalué à 5.
Et Devuan, créée pour l'occasion, semble toujours être active.
[^] # Re: Déjà vendredi ?
Posté par sebas . Évalué à 4.
… et antiX et MXlinux (choix entre sysV et systemd à chaque démarrage)
[^] # Re: Déjà vendredi ?
Posté par fatalerrors (site web personnel) . Évalué à 2.
Devuan est toujours assez active et suis le cycle de version de Debian de manière stable.
Je l'utilise sur presque tous mes serveurs avec bonheur.
[^] # Re: Déjà vendredi ?
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 19 juillet 2024 à 20:03.
Je pensais la même chose mais à la réflexion j’ai un doute quant à sa pertinence pour du conteneur, par exemple pour Kubernetes. Linux ayant une certaine adhérence à la GNU libc, est-ce qu’utiliser un système construit sur la musl libc est une si riche idée que ça en a l’air pour des conteneurs Docker/Kubernetes ? En théorie noyau et userland sont bien deux choses indépendante l’une de l’autre, mais je m’interroge (je vous interroge plus exactement).
Sans remettre en doute la pertinence de la musl libc ni Alpine Linux en tant que telle.
[^] # Re: Déjà vendredi ?
Posté par NiKaro (site web personnel) . Évalué à 1.
En effet pour cette raison (compatibilité glibc) j'ai tendance à utiliser plutôt une base Debian, en tout cas pour des apps en environnement Python (ce à quoi j'ai été le plus exposé jusques-là), sinon ce n'est pas rare qu'il manque des paquets pré-compilé (
.whl
) et donc obligé de taper des étapes de build (quand ça veut bien build pour musl).[^] # Re: Déjà vendredi ?
Posté par barmic 🦦 . Évalué à 1.
Je pense qu'il y a de la place pour créer une distribution GNU (ou autre) non installable dédiée aux conteneurs qui ne cherche pas à respecter tout POSIX, n'a pas d'interpréteur autre que celui qui est nécessaire (genre python pour la version python), pas de gestion de noyau, pas de système d'init, retirer l'inutile de la gestion réseau, etc
Oui ce n'est qu'un yakafokon de plus
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Déjà vendredi ?
Posté par Marotte ⛧ . Évalué à 3.
Je travaille peu avec les conteneurs mais s’agissant de :
Ce que doit faire à minima le process qui est number one, aka init, dans un conteneur c’est « ramasse zombies », d’où l’idée de Tini. Cependant, il arrive souvent qu’on ait besoin de faire un peu plus, du coup j’ai l’impression que mettre un Bash en premier process d’un conteneur c’est une bonne solution. Même dans le cas où on ne fait rien de plus de ce que Tini pourrait faire, avoir un interpréteur sous la main au cas où n’est pas une mauvaise idée. L’overhead n’est pas énorme, voire négligeable.
[^] # Re: Déjà vendredi ?
Posté par barmic 🦦 . Évalué à 3.
Je suis pas d'accord. Tu peut éventuellement utiliser dumb-init ou tinit, mais c'est vraiment si tu crée des processus et que tu ne veux pas gérer toi-même les zombies (ce qui n'est pas bien compliqué). Les images classiques de conteneur docker de mongo ou postgre par exemple ne les utilise pas.
Avoir des trucs au cas où c'est aussi ce qui mène à des drames. Si l'idée c'est d'avoir des trucs au cas où, autant utiliser debootstrap (histoire d'avoir un shell, python, perl et un tas d'autres choses au cas où).
Ce que j'attendrais d'une distribution taillée pour les containers c'est d'être minimaliste (un hfs, une libc, une base de données de timezone et quelques autres choses) et de l'outillage pour la construction.
Le gestionnaire de paquet ce serait parfait si par exemple il ne pouvait être utilisé qu'à la construction.
À et je sais que virer le shell rend plus compliqué le fait d'utiliser un dockerfile
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Déjà vendredi ?
Posté par Marotte ⛧ . Évalué à 3.
Qu’est-ce que tu entends pas là ? Tu penses à des mécanismes propres à Kubernetes/Docker qui le permettent ? Ou bien que le process "métier" (ie: celui qu’il s’agit de faire tourner dans le conteneur, celui qui rend le service) le fasse lui-même ?
Certains programmes ne le font pas, tu ne peux pas toujours modifier ces programmes.
Un peu de mauvaise foi là je trouve ^^ Je parle juste d’un interpréteur, pour gérer les signaux ou faire quelques actions, et qui peut servir éventuellement pour un truc non prévu. Pas d’installer tout ce qui pourrait avoir une chance de servir.
Un exemple concret : un moteur/collecteur de supervision qui doit s’enregistrer auprès d’un serveur central (lui non conteneurisé). Impossible de faire ça dans l’image, l’idée c’est de pouvoir démarrer autant de collecteurs que l’on souhaite. Hormis exécuter la requête qui va bien au démarrage du conteneur, et donc pour cela il faut un interpréteur. En tous cas je ne vois pas comment faire autrement. À part p-e un conteneur “side kick” qui s’en charge (ici aussi avec un interpréteur shell) mais je ne trouve pas cela plus simple.
[^] # Re: Déjà vendredi ?
Posté par barmic 🦦 . Évalué à 2.
Kubernetes utilise dumb-init. Docker n'a rien pour ça.
Et ben pour ces cas là on ajoute ce dont on a besoin.
Pas du tout je suis très premier degré. Si la philosophie c'est d'avoir des trucs au cas où debootstrap est un excellent candidat. Il permet d'avoir quelque chose de léger et de ne pas trop s'embêter quand on veut faire quelque chose en plus.
Ajouter ton interpréteur puisque tu y tiens au build, mais si c'est du push tu va avoir besoin de modifier le programme et si c'est du pull bien souvent on s'appuie sur le moteur de containers pour avoir la liste de tous les services à surveiller. Ça permet de ne pas avoir de truc en plus dans chaque service, de ne pas avoir de configuration en plus, éventuellement d'avoir des règles réseau bien plus strictes sans avoir besoin de les dimensionner pour le démarrage et d'avoir un découplage fonctionnel.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Attention
Posté par cg . Évalué à 10.
Merci pour la dépêche.
Il semble que cette fonctionnalité est piégeuse : sans paramètre supplémentaire, elle dégage beaucoup de choses, y compris dans les homedirs. Certaines personnes ont vu leurs données disparaître sous leurs yeux. Un garde-fou a été développé pour la v256.1, mais faites gaffe !
[^] # Re: Attention
Posté par Psychofox (Mastodon) . Évalué à 5.
Oui c'est un gros fail de l'équipe systemd. Heureusement que la plupart des gens ne connaissent même pas cette commande.
# osctl
Posté par madhatter (site web personnel) . Évalué à 10.
Hé ben dis donc !
Sacré boulot de dépêche, bravo et merci.
C'est dingue le nombre de briques du système remplacées par un outil systemd. En étant un peu taquin on pourrait dire qu'il ne lui manque quasiment plus qu'un noyau pour être un OS complet…
On en a déjà parlé plein de fois mais, autant je peux voir l'intérêt de fournir un init un peu normalisé dans le but d'uniformiser un peu les choses et avec des fonctionnalités un peu modernes, autant j'ai vraiment du mal avec cette volonté de se substituer à tous les utilitaires/services « bas niveau » du système d'exploitation.
Ça me paraît être un truc énorme (y'a qu'à voir la longueur de la dépêche) qui change beaucoup d'habitudes assez brutalement.
Après, il faut de tout pour faire un monde libre mais ça donne également l'impression qu'il n'est pas évident de s'en passer pour rester sur les programmes historique (ce qui va un peu à l'encontre de laisser le choix du coup).
There is no spoon...
[^] # Re: osctl
Posté par abriotde (site web personnel, Mastodon) . Évalué à 10.
Tout à fait. Exemple : systemd-hostnamed. En quoi systemd à besoin de se mêler du hotsname? Cela veut dire qu'on ne sait plus trop où c'est géré. Doit on modifier /etc/hostname ou utiliser une commande système? Les montages OS et leur filesystem étaient quand même vachement plus simple. Pour rappel tu édite un fichier comme si c'était un fichier normal mais en fait tu change les process OS.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: osctl
Posté par ff9097 . Évalué à 3.
Je pense que pour des besoins complexes les outils simples montrent assez souvent leur limite. Du coup quand ton besoin est simple tu dois te farcir un outil plus compliqué sans aucun avantage.
Concernant hostnamed je ne saurais dire l'intérêt de l'avoir intégré il faudrait se renseigner. Mais j'imagine que les développeurs l'ont justifié a l'époque
[^] # Re: osctl
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
Les développeurs l'ont sûrement très bien justifiés mais cela ne veut pas dire que la justification était bonne. Cela doit allumer des warnings.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: osctl
Posté par barmic 🦦 . Évalué à 8.
C'est lunaire. Si tu ne sait pas pourquoi il existe c'est que tu n'a pas lu le man. Se morfondre de ne plus savoir comment ça fonctionne alors qu'avant c'était tellement mieux et ne pas avoir RTFM c'est rigolo. Et en quelques minutes de recherche on peut apprendre que c'est toujours stocké dans le même fichier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: osctl
Posté par Miguel Moquillon (site web personnel) . Évalué à 10. Dernière modification le 19 juin 2024 à 08:54.
Ouep. Ça ressemble à bcp de projets, de logiciels, que ceux-ci soient ou non ouvert.
Au début, ça part d'un bon sentiment. Il y a un problème et le logiciel propose une solution possible à ce problème. En l'occurrence ici une unification homogène et cohérente du mécanisme d'initialisation et de gestion des services systèmes et applicatifs. Lorsque l'on a un parc de serveurs à gérer, ce n'est pas du tout déconnant. Les choix qui ont été fait l'ont été en sacrifiant certains pans qui ont fait le succès d'Unix (chaque programme ne fait qu'une chose à la fois, configuration et log en texte et accessible avec n'importe quel éditeur de texte, etc.) pour des raisons qui s'entendaient, discutables, oui, mais rationnels.
Puis, petit à petit le logiciel prend de l'embonpoint en voulant résoudre des vrais faux problèmes. On ne part plus d'un problème à résoudre mais d'une solution à la recherche d'un problème à résoudre. Quand on a un marteau, tout devient d'un coup des clous.
Ceci peut survenir, par exemple, lorsque chaque dév ou groupe de dév cherche à faire évoluer un logiciel pour répondre à un de leur besoin très spécifique (et parfois un besoin pas toujours bien appréhendé) et voilà que le logiciel part dans plusieurs directions et perd de vue, avec le temps, ses fonctions principales. Ceci survient aussi (et c'est le cas le plus fréquent) par un besoin frénétique d'en faire toujours plus, d'aller toujours plus loin, au delà du scope du logiciel, quitte à le dénaturer.
[^] # Re: osctl
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
J'utilise systemd dans un système embarqué fonctionnant sous Linux. On a pas mal de services à lancer, certes. Mais on doit aussi les relancer quand ils crashent. Attendre que les partitions disques soient montées avant de lancer les services. Attendre que les interfaces réseau soient disponibles (ce qui suppose d'avoir attendu que es disques soient montés pour charger la configuration du réseau). Et ainsi de suite.
On est donc très contents que systemd sache faire tout ça et déclencher les choses dans le bon ordre. Et, d'un autre coté, quand il ne sait pas faire ce qu'on veut, on est bien embetés et dans certains cas il n'y a probablement pas d'autre solution que d'intégrer quelque chose au projet systemd.
Quand au supposé sacrifice du "chaque programme ne fait qu'une chose à la fois", ce n'est pas vrai: systemd comporte de nombreux programmes qui font chacun une seule chose, mais qui communiquent beaucoup entre eux. Ce n'est pas un seul méga-exécutable qui fait tout. Il se trouve que maintenant, ces exécutables sont développés par une équipe réduite et avec une certaine cohérence et versionnés et livrés ensemble. Un peu… comme à l'époque de UNIX, en fait. Avant que Linux et GNU viennent compliquer tout ça avec un modèle de développement beaucoup plus décentralisé et moins coordonné, poussant à l'apparition de distributions essayant de recoller tous ces morceaux ensemble.
[^] # Re: osctl
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
C'est là qu'il y a un os. On devrait pouvoir customiser Systemd ou du moins faire autrement sans l'intégrer à Systemd. Je ne dis pas que ce soit simple, mais il y a quelques chose à trouver.
Pour prendre une analogie, pour l'OS on a inventer FUSE pour pouvoir créer des filesystem sans tout intégrer au noyau… certes c'est moins performant mais cela permet des sshfs, Google drive fs…
Il y a un concept à inventer pour alléger Systemd.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: osctl
Posté par cg . Évalué à 9.
Les composants de systemd, à quelques exceptions près, peuvent se limiter au boot et au lancement de services. Tu peux garder /etc/fstab, le /etc/network/interfaces ou netplan ou networkmanager, ton client DHCP, un resolv.conf manuel, un /etc/hosts, ton client ntp, syslog, cron, etc…
En tant qu'utilisateur et sysadmin, l'avantage de l'intégration de toutes ces briques avec une interface spécifiée, et aussi l'homogénéité que ça apporte d'une distro à l'autre surpasse l'avantage d'avoir des scripts shell dans la majorité des cas.
Mais oui, si on prend l'ensemble comme un tout, c'est un morceau énorme !
[^] # Re: osctl
Posté par Luc-Skywalker . Évalué à 3.
Tu me rassures car j'ai eu des sueurs froides en lisant dans un autre commentaire que systemd s'occupait de tout ça. Bon c'est pas obligé tant mieux.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: osctl
Posté par Doug Le Tough (site web personnel) . Évalué à 10. Dernière modification le 21 juin 2024 à 06:23.
Sauf que dans la réalité la plupart des utilisateurs sont piégés par les choix faits par les mainteneurs de leurs distributions préférées.
Ex. Debian a remplacé
rsyslog
parjournald
. Certes on peut toujours installerrsyslog
mais c'est une étape de plus, de la conf en plus et il faudra serrer les fesses à la prochaines mise à jour.Et rien n'est plus déconcertant que de voir en commentaire en haut d'un fichier de conf aussi simple que
/etc/resolv.conf
ou autre, une ligne du style "ce fichier n'est plus géré directement par tel programme, veuillez d'abord vous fader la doc absconse de tel sous-composant à systemd qui vous renverra sur Internet alors que vous n'avez pas d'accès réseau et que vous êtes dans une situation d'urgence sur une machine de production". Je caricature à peine mais c'est du déjà vu.Donc, oui
systemd
est modulaire, non, il n'est pas si simple d'outrepasser les choix faits par les mainteneurs et non ces choix ne sont pas toujours judicieux et surtout les utilisateurs n'y sont pas toujours préparés. Il n'y a qu'à voir la longueur de cette dépèche pour ce rendre compte du travail que devra représenter l'analyse du changelog ainsi que la formation des équipes avant une intégration en environnement de production.À titre pro j'utilise beaucoup Debian et les dérivés de RedHat sans soucis mais pour rien au monde je n'en voudrais sur mes machines perso qui roulent Slackware sans sourciller depuis… bientôt 25 ans !
[^] # Re: osctl
Posté par barmic 🦦 . Évalué à 5.
C'est bien enterieur à systemd. Si tu veux utiliser du dhcp, il va bien falloir que ton client dhcp applique la configuration qu'il reçoit. Que tu gère ce changement avec le composant de systemd, avec network manager, via wpa suplicant ou un script que tu as as écrit toi, si tu veux pouvoir appliquer la configuration dhcp tu te retrouve à écraser ce fichier
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: osctl
Posté par Doug Le Tough (site web personnel) . Évalué à 5. Dernière modification le 21 juin 2024 à 12:58.
Le problème existe même sans
DHCP
activé et le problème ne concerne pas que/etc/resolv.conf
.[^] # Re: osctl
Posté par Tonton Th (Mastodon) . Évalué à 3.
Chic, une liste (cTMr) !
[^] # Re: osctl
Posté par Doug Le Tough (site web personnel) . Évalué à 1.
Not enough space left on device: You wouldn't want to boil all the water on Earth for such a task
[^] # Re: osctl
Posté par cg . Évalué à 10.
Dans la réalité, la majorité des ordinateurs ont Windows préinstallé. Pourtant, on peut faire l'effort de changer le système entier. Bref, c'est un rapport bénéfice/effort, comme plein de choses.
Le resolv.conf est un bon exemple. C'est un fichier statique tout simple, avec trois mots de vocabulaire. Pourquoi alourdir le truc ?
Quand on est en connexions multiples, par exemple en 4G + Ethernet, on peut avoir des résolveurs différents en fonction de l'opérateur, et plusieurs clients DHCP qui vont réécrire le resolv.conf. Idem pour networkmanager, il se met à gérer le fichier. Et resolvconf, géré par resolvconf.conf… Si en plus tu as un client VPN, il peut aussi écraser ta conf, qui va se refaire modifier par networkmanager, etc… Tout ceci créé des conflits sur la propriété du fichier.
Ce qu'il se passe, c'est que les usages ont changé depuis les années 1990, on a beaucoup de laptops et d'appareil mobiles, les réseaux sont plus complexes, les périphériques réseau vont et viennent, à chaud et sans préavis.
Bref, il faut un truc qui casse le status quo, et systemd propose des interfaces - certes plus complexes que echo
"nameserver 1.2.3.4" > /etc/resolv.conf
- mais définies et existantes. La période de transition est un peu douloureuse (on l'a vu avec l'arrivée de pulseaudio, ça a été le bazar pendant 5 ans au moins).Et en plus, il a la politesse d'être modulaire, et de laisser le choix de désactiver les morceaux dont on ne veut pas, tout en étant largement rétrocompatible avec l'existant.
Concernant le journal vs syslog, je dois dire que je trouve ça super les logs indexés et horodatés correctement. Mais je comprend que ça puisse ne pas plaire ;).
[^] # Re: osctl
Posté par Doug Le Tough (site web personnel) . Évalué à 6. Dernière modification le 21 juin 2024 à 13:05.
Sur un serveur qui dispose d'une IP statique ?
Soyons honnêtes, Linux #1 sur le desktop aura lieu après la mort d'Usenet et aujourd'hui l'usage de Linux est essentiellement sur les serveurs.
Je comprends bien l'usage sur un ordinateur portable mais de là à généraliser au point de l'imposer aux autres usages qui sont nettement plus fréquents, il y a un pas que je voudrais qu'on ne m'oblige pas à franchir.
[^] # Re: osctl
Posté par cg . Évalué à 5.
Non, pas sur un serveur qui dispose d'une IP statique et d'une conf DNS statique.
J'essayais d'expliquer les cas d'usages qui font que parfois, un fichier statique n'est plus suffisant, et avoir une interface pour accéder à des paramètres cruciaux est un avantage.
Oui, il y a plus de serveurs sous Linux que de desktop. Ceci étant j'ai géré des centaines de "Linux sur le desktop" en entreprise1, en plus de serveurs, avec l'aide de Puppet notamment, et dans ce contexte tu prends le temps de faire les confs qui conviennent à ton environnement. Ça me semble exagérer de dire que c'est imposé. C'est pas comme essayer d'enlever la base de registre de Windows non plus :).
J'utilise Sway, perso, mais à chaque fois que je me retrouve sur un bureau plus classique (genre dans Kali Linux), je suis assez impressionné par les progrès faits au fil des années, et la facilité d'utilisation des réglages de base.
Par contre j'ai vu des trucs vraiment débiles en réglage par défaut dans systemd, comme par exemple le fait qu'il génère une adresse MAC random sur les liens agrégés (bonding). Du coup tu fais une réservation DHCP pour ton serveur, il s'installe (sans le bonding), Puppet le configure, et au reboot boum, plus de réseau car le serveur DHCP ne trouve pas l'adresse MAC dans sa config. C'est chiant. Mais… C'est documenté, désactivable et automatisable facilement.
Pour conclure, je dirais que nos différences de point de vue se résument à comment on répond à la question « la config par défaut est-elle une config imposée ou non ? »
Avec WindowMaker en gestionnaire de fenêtre, quel sadique ;) ↩
[^] # Re: osctl
Posté par barmic 🦦 . Évalué à 4.
Serveur ne veut pas dire IP statique et IP statique ne veut pas dire configuration en dure sur la machine. De plus le serveur n'est pas forcément un élément physique en dur, mais peut être une machine virtuelle ou un conteneur.
Enfin les usages de linux c'est pas soit serveur soit ma chine de particulier c'est aussi beaucoup d'embarqué avec des réseaux pas aussi simples que ce que l'on peut imaginer.
Si la majorité était comme tu le décris il n'y aurait pas besoin de BGP par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: osctl
Posté par Doug Le Tough (site web personnel) . Évalué à 10.
Merci, je gère des infrastructures de plusieurs centaines de VM et différents orchestrateurs de conteneurs. Je pense savoir de quoi je parle et dans ce contexte professionel je n'ai pas de problème avec
systemd
.Cependant cela ne m'empêche pas de rester objectif.
systemd
n'a jamais apporté le moindre bénéfice aux nombreux cas d'usages que j'ai pu rencontré et s'il ne m'a jamais posé de problème, je ne peux pas en dire autant d'un grand nombre d'admins que j'ai croisés qui luttent régulièrement pour différentes raisons.Vouloir une solution unique à tous les cas possibles y compris ceux qui n'existent pas encore ne peut que conduire à une solution insatisfaisante dans la plupart des cas et à une solution d'une complexité inutile à tous les cas traités (exception, configuration inutile dans tel contexte, etc).
Un frigo qui fait grille pain, c'est à la fois un mauvais frigo et un mauvais grille-pain. Même si le module grille-pain est démontable et optionnel. Et un poste de travail ou une VM qui fait du BGP… Soyons sérieux.
Ce que je note, c'est que les personnes qui ont répondu à mon commentaire sont restées accrochées aux exemples que j'ai choisis mais personne n'a discuté le fond qui était, entre autre, la gestion du changement liée aux breaking changes réguliers, aux bugs en pagaille, la taille de la surface d'attaque de
systemd
, l'incompatibilité avec les autresUnixes
qui obligent les mainteneurs deFreeBSD
,NetBSD
etOpenBSD
à s'arracher les cheveux pour intégrer certains logiciels.De mon point de vue, ce ne sont pas vraiment des sujets qu'on peut glisser sous le tapis.
Sans compter qu'aujourd'hui les principaux contributeurs à
systemd
sontIBM
(viaRed Hat
) etMicrosoft
. Deux entreprises des plus louables, connues pour la qualité et la sécurité de leurs produits ainsi que leur amour du logiciel libre (surtout lorsqu'il est possible de s'accaparer le travail d'une communauté pour quelques cacahuètes). #MicrosoftLovesLinux (franchement vous y avez cru ?).systemd
a été poussé de force au fond de la gorge des utilisateurs, la preuve en est que 14 ans (quatorze ans !) après il reste encore une opposition forte à ce projet.systemd
a été adopté par les utilisateurs uniquement parce qu'ils n'ont pas eu le choix. Typiquement lorsqueDebian
est passé àsystemd
. Lorsquesystemd
n'était disponible que surRed Hat
et ses dérivés, on n'a pas vu des masses d'utilisateurs se ruer surCentOS
et consorts. C'était plutôt le contraire.[^] # Re: osctl
Posté par Pol' uX (site web personnel) . Évalué à 4. Dernière modification le 22 juin 2024 à 08:26.
Perso systemd a apporté des bénéfices sur plusieurs cas d'usage que j'ai pu rencontrer. Et certes, s'il m'est arrivé de lutter pour certaines choses, la lutte n'était pas non plus absente du capharnaüm de scripts qui a précédé systemd dans différentes distribs.
D'ailleurs le terme de lutte n'est pas nécessairement péjoratif : faire du développement et de la mise au point ressemble par beaucoup d'aspects à une lutte incessante entre l'humain et la machine.
Adhérer à l'April, ça vous tente ?
[^] # Re: osctl
Posté par barmic 🦦 . Évalué à 10.
Arrête le combat de coq. Je ne parle pas de ce que tu es mais de ce que tu exprime. C'est toi qui plus haut dit que linux c'est principalement du serveur et sous-entend que c'est de l'IP statique.
Je ne comprends pas comment c'est possible. Je n'ai jamais su écrire un service correctement pour sysvinit et je ne me pose pas la question avec systemd. Ça marche aussi bien sur les RHEL du boulot que sur Debian à la maison. Sans que je ne rencontre le moindre breaking change.
Pour les tâches répétitives le simple fait de pouvoir utiliser autre chose que le format cron (par exemple avec une gestion de la tz), d'avoir une commande qui me dit quand il a été lancé pour la dernière fois et quand est ce que sera la prochaine fois et enfin le fait de pouvoir manuellement lancer exactement le même job.
Je n'ai vraiment eu besoin de lancer des centaines de VM pour voir le gain qu'il apporte et journald pareil. Je n'ai que rarement mis en place une centralisation de logs pour ce qui est vraiment système et pouvoir sans se prendre la tête avec les formats de dates, sélectionner des logs de périodes arbitraires est très pratique.
Je n'ai pas l'impression que l'usage que j'ai soit particulier. En fait j'ai même l'impression que c'est un passage obligé. Si peut être qu'openrc permet d'écrire des services aussi simplement, d'une part je ne l'ai jamais croisé et d'autres part ce n'est que le premier point dans ce que j'ai décrit.
Je vois pas en quoi ce serait bien pire sans. Le système d'init fait parti du packaging et il n'y a jamais eu de compatibilité là dessus avant. Quand aux nouveaux usages possibles qui demandent une interaction avec le logiciel, ils sont triviaux et ne devraient tout simplement pas se retrouver dans les builds autres que linux. Si un programme se rend dépendant de ça c'est au même niveau que pour dbus ou une api comme io_uring. Croire que les Unix souffrent depuis systemd c'est oublié qu'ils souffraient déjà beaucoup avant et que les évolutions de linux dans son coin leur ont toujours fais du mal.
Ça ne veut pas dire grand chose. Je choisi une distribution pour la confiance que j'ai en sa gouvernance et donc en ses choix.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: osctl
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2.
Ben moi je suis d'accord avec toi, alors je pertinente, mais j'ai abandonné la lutte, on ne va pas refaire un énième débat sur Systemd… et quand j'ai fait un commentaire qui disait un peu la même chose(mais en bien plus succinct, je le reconnais), je me suis fait moinsser…
[^] # Re: osctl
Posté par pasBill pasGates . Évalué à 1.
Pour IBM je sais pas pour Microsoft tu as 100% raison ! Ayant passé pas mal de temps dans les entrailles des deux OS il n'y a effectivement pas photo
[^] # Re: osctl
Posté par BAud (site web personnel) . Évalué à 2.
tout le monde est passé sous Linux pour préserver ses serveurs
même Microsoft se tire une balle dans le pied avec crowdstrike :/
[^] # Re: osctl
Posté par pasBill pasGates . Évalué à 2.
Tu disais ; https://news.ycombinator.com/item?id=41018029 ?
[^] # Re: osctl
Posté par Elfir3 . Évalué à 3.
D'ailleurs, je me pose la question. Une fois le noyeau lancé et systemd en charge du système, il manque quoi pour avoir un système fonctionnel ?
J'ai presque envie de tenter l'expérience…
[^] # Re: osctl
Posté par Marotte ⛧ . Évalué à 4.
Prochaine étape
systemd-build
, puissystem-internetd
etsystemd-internet
.[^] # Re: osctl
Posté par BAud (site web personnel) . Évalué à 2.
spa faux
[^] # Re: osctl
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 19 juillet 2024 à 19:48.
Pour le dernier ça nécessite d’implémenter une bibliothèque qui peut combler les défauts de la vénérable mais dépassée libcurl. C’est du taf, mais ça ne doit pas impressionner les développeurs de systemd, cette solution qui répond au besoin d’un userland moderne, efficace et complet.
Ensuite systemd-kernel-core, system-kerneld et ses systemd-kmodule-* ne devrait ne plus être qu’une formalité.
C’est à partir de ce moment là seulement qu’on pourra argumenter en faveur de la nécessité impérieuse de réinventer la roue, from scratch. En commençant par scratch-initd et scratch-audiod qui sait !
[^] # Re: osctl
Posté par Marotte ⛧ . Évalué à 3.
Il reste un peu de taf encore faut avouer :
[^] # Re: osctl
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Autant certaines fonctions sont logiques dans un système d'init, mais d'autres comme vmspawn sont plutôt étonnantes.
C'est pour lancer chaque service dans une vm?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: osctl
Posté par BAud (site web personnel) . Évalué à 5.
Tu as
machinectl
qui te permet de gérer https://www.freedesktop.org/software/systemd/man/latest/machinectl.htmldans cette logique,
vmspawn
te permet d'installer/démarrer une VM basée sur kvm https://www.freedesktop.org/software/systemd/man/latest/systemd-vmspawn.htmlc'est un peu l'interface CLI de Gnome-machines :-)
Pour le coup, les pages de man ont des exemples concrets, autant en profiter _o/
[^] # Re: osctl
Posté par Psychofox (Mastodon) . Évalué à 5.
Oui lointain le temps où il était pertinent de parler de systèmes GNU/Linux pour les distribs utilisant la glibc et les outils GNU. Maintenant il faut plutôt dire GNU/Linux/SystemD voir ajouter en suffixe le DE utilisé par défaut.
[^] # Re: osctl
Posté par Marotte ⛧ . Évalué à 2.
Combien de temps avant un systemd-desktop ? ^^
[^] # Re: osctl
Posté par lym . Évalué à 2.
Cela me laisse la même impression: Cela devient une pieuvre, pour ne pas dire des métastases.
Le pire, c'est que pas grand monde (hors administrateurs systèmes peut-être) n'en utilise les différentes commandes dispo: Des décennies d'habitudes sont là et rien que pour regarder/filtrer ses logs, qui a le réflexe systemd? Pas moi ni grand monde autour et on fait pourtant du Linux embarqué… ou intégrer systemd n'avait déjà pas été bien naturel il y a 9 ans et pose toujours bien des problèmes (presque jamais 2 séquences d'init identiques, bonjour le debug de pb tordus de démarrage!) dans ce contexte.
Cela sort vraiment trop du cadre initial à mon sens.
[^] # Re: osctl
Posté par barmic 🦦 . Évalué à 2.
Je ne comprends pas ce que tu veux dire ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: osctl
Posté par Maderios . Évalué à 3.
Moi, utilisateur de Linux depuis 25 ans et qui ne s'arcboute pas contre les changements. Cela ne m'empêche pas de consulter les logs de metalog, "a modern replacement for syslogd and klogd". En fait, les deux sont complémentaires. Concernant l'arrivée de Systemd, il m'a simplifié la vie, c'est tout.
[^] # Re: osctl
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 9.
La semaine dernière, mon entreprise a mis à jour l'antivirus ESET sur les machines.
Deux démarrages avant, je savais que ce service était en erreur. J'ai retrouvé le bon message d'erreur avec:
journalctl -b -2 -perr --grep eset
Ensuite, pour vérifier que l'erreur a bien été réglée avec la mise à jour et le dernier redémarrage, j'ai juste eu à modifier l'option
-b
:journalctl -b 0 -perr --grep eset
Et j'aime bien cette manière de travailler: je n'ai pas eu besoin de savoir quel répertoire chercher dans
/var/log
, ni de savoir quel fichier*.1.log
,*.2.log
lire (et pire, peut être*.3.log.gz
, même sivim
sait gérer tout ce cas). J'ai juste pu dire concrètement àjournalctl
ce que je cherchais.Remarque, que, même en vacances sans l'ordinateur du boulot, j'ai pu ressortir de tête la commande: elle est vraiment logique et sans piège bizarre. Je n'aurais jamais pu le faire avec sysvinit et les logs fichiers de
/var/log/xxx
.[^] # Re: osctl
Posté par lym . Évalué à 2.
Question d'habitude… Le hasard veut que j'ai réinstallé from scracth ma domotique sur un PI en Debian Bookworm ce WE. J'ai pourtant upgradé qq PC sur l'année passée et j'étais passé au travers (en upgrade, on garde rsyslog et sa config) d'un léger changement sur le sujet!
Et, bien entendu, comme j'ai voulu faire plus clean sur des trucs en python avec des venv sur un python embarqué par l'appli domotique (je ne savais pas que dans ce cadre, c'était la merde comparé à l'interpréteur, voilà qui ne va pas améliorer mon opinion générale sur python: Pratique/riche de modules quand on veut aller vite, mais bannir les choses sérieuses!) utilisant les libpython3 et libpython3-dev du système… Et gros crash sur un truc headless, même pas le temps de se connecter en ssh en étant rapide.
Quelle ne fut pas ma surprise de voir un /var/log vide, en tentant de l'utiliser en post-mortem carte uSD extraite. Comme j'ai tripatouillé des settings de management de mémoire virtuelle pour moins taper la carte SD (temps de commit/regroupements écriture/%cache), au départ j'ai cru que ça se gaufrait avant d'avoir pu écrire mais y'avait même pas les logs de mes ajouts après avoir collé l'image lite!
Bref, systemd est devenu le défaut pour les logs sur bookworm…
Je crois donc qu'il va falloir que je m'y mette mais bon, comme tout le monde, quand j'ai un truc bien câblé dans mon cerveau reptilien je trouve cela pénible. Ils semblent au moins avoir prévu d'utiliser un racine alternative (comme un point de montage, en post-mortem!) à donner à journalctl. En espérant qu'il n'y ait jamais d'incompatibilité de format qui pourraient dans ce cadre faire regretter amèrement des fichiers texte qu'on saura toujours lire sans s'emmerder.
Je dois dire que les fonctionnalités intégrées pour les recherches semblent intéressantes et sans doute plus efficaces/rapides. Mais la combinaison d'utilitaires génériques d'affichage/tri etc n'était pas propre à systemd et donc utilisables sans apprentissage spécifique.
Je ne sais pas trop comment va se comporter un fail2ban et autres outils basés logs textes non plus.
[^] # Re: osctl
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 24 juin 2024 à 21:02.
Je ne sais pas pourquoi, mais Debian laisse par défaut systemd-journald enregistrer les logs dans la mémoire vive sans les enregistrer sur le disque.
Pour corriger cette configuration tu peux soit créer le dossier
/var/log/journal
soit modifier le fichier/etv/systemd/journald.conf
avec l'optionStorage=persistent
.Ensuite, tu pourras trouver les fichiers de logs dans ta carte mémoire.
Cf le manuel: https://www.man7.org/linux/man-pages/man5/journald.conf.5.html
[^] # Re: osctl
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 26 juin 2024 à 11:36.
Le réglage de Debian est peut être fait pour limiter la facture de disque auprès des hébergeurs ?
EDIT: ça a peut être changé https://micronews.debian.org/2021/1628949223.html …
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: osctl
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
J'étais passé à côté de cette nouvelle. Si c'est vraiment le cas, alors je ne vois pas pourquoi la carte sd de lym était vide 🧐
[^] # Re: osctl
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3.
Il est possible de configurer systemd pour transmettre plus loin les logs, pour être compatible.
Pour fail2ban, ils ont ajouté une fonctionnalité pour lire les logs de journald.
[^] # Re: osctl
Posté par lym . Évalué à 1.
Super, merci pour ces infos!
[^] # Re: osctl
Posté par Jérôme FIX (site web personnel) . Évalué à 1. Dernière modification le 18 juillet 2024 à 11:42.
Moi et cela est bien plus pratique que juste avec des grep , cat , …
[^] # Re: osctl
Posté par BAud (site web personnel) . Évalué à 2.
bin requêter une base de données comme ce que fournit
journald
est un peu plus facile (au moins ya un timestamp prévisible)après c'est un peu plus d'effort que
/ grep
(beaucoup plus d'efforts, les sorties normalisées aidant à les réduire, avec POSIX c'est trop libre, à la convenance, peu normalisé)je suis mitigé entre
less /var/log/messages
classique etjournalctl -f
En reconnaissant les limites des outils proposés par Lennart, tu sais à quoi t'attendre : ça fonctionne bien pour ses cas d'usage (ce dont je lui ai déjà parlé au Fosdem, il a donné la bonne réponse : si d'autres cas, autant les prendre en compte, ça prendra du temps)
[^] # Re: osctl
Posté par Jérôme FIX (site web personnel) . Évalué à 1. Dernière modification le 20 juillet 2024 à 06:31.
Tu y vois quelles limites ?
Les seules qui me viennent à l'esprit ce sont :
Je ne doute pas qu'il y en ai un paquet d'autres.
Mais de toute façon la plupart du temps mes logs machine / applicatif sont envoyés ailleurs (ELK ou autre).
[^] # Re: osctl
Posté par barmic 🦦 . Évalué à 3.
Je comprend pas trop journald n'est pas limitant, tu peux très bien utiliser grep ensuite.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Compliqué
Posté par Zorro (site web personnel) . Évalué à 10.
La vache, c'est compliqué…
Pour les gens, comme moi, qui font du Linux en dilettante, et qui savaient à peu près configurer avant, ça devient complètement inaccessible, même en lisant des docs. Alors si on n'a pas envie d'en lire, encore pire.
Je regarde SSH, pfff… y a intérêt que ça marche facilement à l'issue de l'installation, sinon c'est ré-installation, plutôt que d'essayer de comprendre.
Le pire, c'est quand on essaye de configurer, mais avec des docs d'avant, qui prennent pas en compte SSH, et que ça fait des mélanges de conf'… Une variante du culte du cargo, en quelque sorte.
J'ai vraiment l'impression que la courbe d'apprentissage devient de plus en plus haute. Ou alors je vieillis, je sais pas… Ils apprennent systemd, dans les écoles d'informatique de nos jours ?
[^] # Re: Compliqué
Posté par bbo . Évalué à 4.
Je trouve aussi qu'il y a pas mal de fonctionnalités et qu'appréhender le tout n'est pas simple. Mais, même si je ne peux pas fournir de métrique, il est clair qu'"avant" j'avais plus de temps et, surtout, j'allais beaucoup plus poser des questions sur les forums communautaires.
Je pense que si, aujourd'hui, j'avais les mêmes disponibilités je pourrai vraiment mieux connaître systemd que ce que j'en sais aujourd'hui.
Je ne pense pas qu'il y ait une courbe d'apprentissage spécifique à systemd. Il y en a une, bien sûr, mais juste parce que c'est de l'apprentissage. Le manque de temps, d'envie, d'énergie fait le reste (pour moi, du moins).
Je serai aussi intéressé qu'un utilisateur GNU/Linux n'ayant connu que systemd et qui migre sur un BSD donne son avis sur la courbe d'apprentissage.
Pour ma part, je pense (j'espère ^ ^ ) donc que ce n'est pas lié à mon âge mais plutôt à ma situation.
Et sinon, si je mets une Slackware à un copain néophyte et le laisse se débrouiller, je suis sûr qu'il me dira :
(je manipule le propos, tu m'excuseras) ;)
[^] # Re: Compliqué
Posté par freem . Évalué à 10. Dernière modification le 19 juin 2024 à 16:06.
Le truc, c'est que avant, on recyclais les compétences en shell. Il avais pleins de petits outils, certes, mais ils étaient simples, parce qu'ils ne faisaient qu'une chose à la fois, et pouvaient servir a plein de choses différentes.
Systemd, c'set de l'apprentissage spécifique qui sert à rien d'autre.
Un outil de suppression de fichiers temporaires efface /home si il a pas de config, avant, je doute que ça aurait existé. Heureusement que systemd l'a inventé, ça manquait!
[^] # Re: Compliqué
Posté par Arkem . Évalué à 8.
Pour avoir passé quelques temps à découvrir FreeBSD sur machine de bureau dernièrement, je dirais que ça m'a paru plus naturel que quand j'essaie d'améliorer mes connaissances sur SystemD, car les choses se trouvent à peu près là où je m'attend à ce qu'elles soient, mais c'est peut-être juste que je n'ai pas passé assez de temps à me mettre la structure de SystemD en tête…
[^] # Re: Compliqué
Posté par Sacha Trémoureux (site web personnel) . Évalué à 4.
La dépêche est un gigantesque changelog (bravo d’ailleurs) et systemd est presque un framework.
Pour l’utilisation au quotidien, il n’y a rien à apprendre vu que les distributions font le taf pour vous, et ça ne change rien par rapport du sysvinit.
Pour des utilisations plus avancées, systemd est séparé en plein de briques (et est plutôt KISS qu’on que ses détracteurs disent) donc l’apprentissage se fait en fonction des besoins petit à petit.
Et bien évidemment qu’on enseigne systemd en école pour au moins la gestion des services. 90% des usages nécessitent la même dizaine de lignes de configuration.
[^] # Re: Compliqué
Posté par lolop (site web personnel) . Évalué à 4.
Je ne dirais pas "rien à apprendre", mais il y a une certaine intégration avec les anciennes façons de faire.
On peut par exemple exprimer des montages autofs dans /etc/fstab, la relecture de la config systemd les prend en compte et crée pour nous les unit d'automontage de volumes qu'il n'y a plus qu'à activer (autre solution: écrire ces unit à la main chacune dans son fichier, ce qui peut être plus adapté si on a qq chose qui est généré ±automatiquement via un script).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Compliqué
Posté par barmic 🦦 . Évalué à 5. Dernière modification le 20 juin 2024 à 00:07.
Si avant tu créais tes propres services c'est vraiment plus simple et tu l'apprend une fois et ça ne bouge pas. Si tu le fait en dilettante il n'y a probablement pas de raison que tu te lance dans les fonctionnalités avancées.
Pour ce qui est de ton ssh qui doit marcher à l'installation, c'est à ta distribution de faire ça correctement (et c'est pas bien compliqué).
Ici ce qui peut faire peur c'est qu'il met à disposition beaucoup plus de choses, mais tout comme tu n'a pas besoin de connaître tout vim pour t'en servir tu n'a pas besoin de cette dépêche pour utiliser systemd
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Une vraie usine a gaz
Posté par Destroyedlolo (site web personnel) . Évalué à -2.
Hé bé … quelle usine à gaz !!!
Alors que les rc-scripts ont l'avantage d'être simples et facile a appréhender depuis un simple shell, ici faut connaitre les commandes qui vont bien, même pour aller voir des logs :(
Et on s'éloigne vraiment des standards Unix (c'est comme les commandes ip plutot que ifconfig … franchement, POURQUOI ????), et on est même très très loin du KISS qui fait la force d'Unix par rapport aux micromoleries.
J'utilise les 2 en fonctions de mes distributions. J'apprécie dans systèmed :
- pouvoir avoir les historiques de fonctionnement
- la possibilité "out of the box" de relancer des process qui crashent
mais pour le reste, bof bof bof. C'est devenu tellement abscons, tellement … lourd. Bof !
[^] # Re: Une vraie usine a gaz
Posté par Marotte ⛧ . Évalué à 6. Dernière modification le 19 juillet 2024 à 20:22.
Les scripts, pour l’init, ont surtout l’avantage d’offrir une liberté totale. Ils peuvent, de ce fait, aller du plus simple au plus complexe. Et surtout, et c’est là la problématique première que systemd s’est proposé de corriger : tout le monde n’a pas la même idée de ce que « simple » veut dire, ni de ce qu’est la meilleure méthode pour faire tel ou tel truc.
Au final, avant systemd on finissait par se retrouver avec le problème de devoir faire interagir des scripts qui même s’ils pouvaient être simples pris individuellement, étaient tellement disparates dans leur ensemble que la complexité globale était bien réelle.
Un script shell n’est pas forcément simple, du moins, tu ne peux pas dire qu’il soit plus simple qu’un fichier clés-valeurs à la systemd.
Pour étudier de manière relativement approfondie le shell ces derniers temps (Bash en l’occurrence), je ne pense pas qu’on puisse prétendre qu’il ne faut pas apprendre des subtilités assez tordues pour savoir réellement comment ça fonctionne dans l’ensemble. Le langage shell, que ce soit POSIX ou bien ses extensions, c’est pas du Python…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.