GNOME 3.34 est maintenant géré avec systemd, le système d'initialisation controversé

GNOME 3.34 est maintenant géré avec systemd, le système d'initialisation controversé,
et apporte ainsi quelques changements

Systemd est le gestionnaire de système et de service par défaut pour la plupart des distributions Linux. Les critiques relatives à systemd portent principalement sur le fluage des fonctionnalités, car le projet ne serait pas conforme à la philosophie « faire une chose et bien la faire » des systèmes Unix en général. D'autres aspects, tels que l'utilisation de journaux binaires (par opposition aux journaux de texte lisibles par l'homme) ont également suscité des critiques.

Bien entendu, les critiques ont été aussi alimentées lorsque des failles de sécurité ont été découvertes. Nous pouvons par exemple citer trois vulnérabilités découvertes par Qualys dans systemd-journald au début de l’année, notamment :

• CVE-2018-16864 et CVE-2018-16865, deux corruptions de mémoire ;
• CVE-2018-16866, une fuite d'informations (lecture en dehors des limites).

Pièce jointe 507069

Qualys a expliqué que : « À notre connaissance, toutes les distributions Linux basées sur systemd sont vulnérables, mais SUSE Linux Enterprise 15, openSUSE Leap 15.0 et Fedora 28 et 29 ne sont pas exploitables, car leur espace utilisateur est compilé avec GCC's -fstack-clash-protection ».

Si certains projets comme Knoppix dans sa version 8.6 (une distribution Linux basée sur Debian) ont décidé de lui tourner le dos, d'autres comme GNOME ont décidé de l'embrasser davantage.

Dans un billet de blog, Benjamin Berg de GNOME a expliqué que :

« Si vous utilisez déjà GNOME 3.34, votre session est probablement gérée avec systemd actuellement. Pendant longtemps, nous utilisions déjà une instance systemd pour chaque utilisateur pour lancer DBus et pour les applications activées par DBus. Ainsi, avec GNOME 3.34, nous avons finalement franchi l’étape suivante et transféré le reste de la session à l'exécution avec systemd.

« Du point de vue de l’utilisateur, rien ne devrait avoir changé à ce stade, je pense que la plupart des régressions ont été traitées. Cette modification n’affectera pas non plus les développeurs d’applications, car les fichiers XDG autostart continuent d’être pris en charge et sont préférés au moins pour le moment.

« Le grand avantage est que cela permet d’autres améliorations. Beaucoup de travail a été fait pour permettre à Xwayland d'être démarré à la demande et systemd joue un petit rôle dans cette fonctionnalité. De même, nous pourrons également fermer les services nécessaires uniquement si un matériel spécifique est présent (par exemple, des cartes à puce). De plus, en utilisant systemd, il est maintenant facile de mettre en sandbox tous les composants, ce qui vous donnera un peu plus de sécurité ».

Il en a également profité pour mentionner quelques informations supplémentaires sur les modifications, les concepts, etc.

Slices, scopes et session utilisateur

Sur un système géré par systemd, chaque utilisateur se voit attribuer un user-X.slice et la session de l’utilisateur sera exécutée dans une session-Y.scope. Vous pouvez également voir quelques autres unités spécifiques à l'utilisateur sur l'hôte, y compris user@X.service, qui est l'instance systemd de l'utilisateur. Il s’agit d’un processus systemd distinct pour l’utilisateur, qui s’arrêtera à nouveau si l’utilisateur n’est plus connecté.

« Avec le passage à systemd, non seulement les applications et les services activés par DBus, mais votre session entière est maintenant lancée à l’aide de l’instance systemd de votre utilisateur. Cela a quelques effets secondaires qui peuvent sembler étranges au début. Par exemple, la session-Y.scope mentionnée précédemment, qui contenait plus de 200 processus, est maintenant réduite à 4 processus. Un autre effet secondaire est qu’il est devenu plus difficile de comprendre à quelle session appartient un processus (cela concerne un certain nombre de services) ou que ps ne montrera plus un tty.

« Mais nous avons abordé ces effets secondaires et espérons qu’il n’y ait aucune régression à ce stade. Votre session GNOME est toujours toujours liée à la session-Y.scope (par exemple, l’utilisation de loginctl kill-session continue de fonctionner de manière fiable). Et les services ont été mis à jour pour comprendre le nouveau régime et choisir la bonne session dans tous les cas. Pour gérer tout cela, une nouvelle API a également été ajoutée à l'interface systemd DBus et d'autres améliorations pourraient être apportées dans ce domaine ».

Cas d'utilisation

Si vous avez GNOME 3.34, vous pouvez maintenant appliquer tous les outils dont systemd dispose pour gérer la session de votre utilisateur. Rappelez-vous simplement d'ajouter l'option --user, et tout devrait fonctionner comme prévu. Un bon candidat pour essayer tout cela est gsd-media-keys.

Si nous regardons systemctl --user, nous trouverons deux entrées:

• gsd-media-keys.target
• gsd-media-keys.service

Notez que les unités défaillantes n'apparaîtront pas dans la liste. Il est donc conseillé de toujours consulter le journal si vous suspectez une défaillance du service. Malheureusement, cela est nécessaire pour pouvoir vous reconnecter de manière fiable après un échec de session.

Nous pouvons contrôler gsd-media-keys.target (et non gsd-media-keys.service) afin que vous puissiez essayer de l'arrêter et de le démarrer et vous remarquerez que la plupart des associations de touches globales ont cessé de fonctionner.

• systemctl --user stop gsd-media-keys.target
• systemctl --user start gsd-media-keys.target

Nous pouvons également extraire les messages de journal pour le service à partir de journalctl.

• journalctl --user -u gsd-media-keys.service

Mais, malheureusement, il n'enregistrera pas beaucoup d'informations par défaut. Mais connaissant les variables d’environnement systemd et GLib, nous pouvons exécuter:

• systemctl --user --runtime edit gsd-media-keys.service

et écrire :

• [Service]Environment=G_MESSAGES_DEBUG=all

Cela active les messages de débogage lors du prochain redémarrage du service. La configuration ne persistera pas, car nous avons passé --runtime. Si vous redémarrez gsd-media-keys.target et inspectez à nouveau son journal, vous remarquerez qu'il contient beaucoup plus d'informations.

Benjamin Berg indique que « Si vous avez une version de développement de GNOME installée quelque part en dehors de votre chemin normal (par exemple, jhbuild) et que vous l'utilisez pour vous connecter, vous devrez peut-être mettre à jour votre configuration. Dans jhbuild, il existe un exemple de script jhbuild-session qui garantit que les fichiers d'unité appropriés seront utilisés. Les lignes correspondantes les copient dans le dossier $XDG_RUNTIME_DIRECTORY de l’utilisateur et rechargent le daemon systemd ».

Source : GNOME

Et vous ?

:fleche: Que pensez-vous de systemd dans l'absolu ?
:fleche: Utilisez-vous GNOME ? Quelle version ?
:fleche: Que pensez-vous de cette plus grande intégration de systemd dans GNOME ?

Voir aussi :

:fleche: La version 8.6 de Knoppix devient la première de la distribution Linux basée sur Debian à abandonner systemd, son créateur en explique les raisons
:fleche: systemd a désormais plus de 1,2 million de lignes de code qui sont réparties sur 3260 fichiers, et proviennent de près de 1400 auteurs différents
:fleche: Des vulnérabilités de corruption de mémoire dans systemd affectent la plupart des distributions Linux, aucun correctif n'est disponible pour le moment
:fleche: La version stable de Devuan ASCII 2.0 est disponible, la deuxième version du fork de Debian continue de promouvoir des alternatives à systemd