Show HN : Interactive Systemd – une meilleure façon de travailler avec les unités Systemd

 (isd-project.github.io)
2 points par GN⁺ 2025-01-19 | 1 commentaires | Partager sur WhatsApp
  • isd est un outil qui offre une meilleure façon de gérer les unités systemd, avec une interface utilisateur en terminal (TUI) permettant de rechercher des unités, d’actualiser automatiquement les aperçus, ainsi qu’une gestion intelligente de sudo et une interface personnalisable

Courte motivation

  • isd simplifie les processus complexes nécessaires pour interagir avec les unités systemd et fournit à l’utilisateur des informations utiles
  • Il réduit la corvée consistant à saisir répétitivement des commandes systemctl et actualise automatiquement les résultats affichés

Installation

  • isd peut être installé via AppImage, nix et uv
  • AppImage est un fichier exécutable unique pouvant fonctionner sur toutes les distributions Linux, y compris sur des serveurs distants aux permissions limitées
  • Pour installer isd dans un environnement nix, il est possible d’utiliser le paquet nix
  • uv est un gestionnaire de paquets Python, qui permet d’installer et de gérer isd

Utilisation de isd

  • isd permet de rechercher des unités systemd, de vérifier leur état et d’afficher un aperçu détaillé de plusieurs unités
  • Il envoie des commandes systemctl à l’unité sélectionnée et actualise automatiquement la sortie d’état
  • Il est possible d’ouvrir un pager dans isd pour consulter l’intégralité de la sortie d’état
  • Un pager séparé peut être ouvert pour la sortie du Journal, et il est possible de configurer des thèmes et des raccourcis clavier personnalisés

Mode utilisateur / système

  • isd s’exécute en mode user ou system, et les types d’unités affichés diffèrent selon le mode

Recherche floue

  • La barre de recherche floue charge toutes les unités et tous les fichiers d’unité correspondant au texte saisi, et les met en évidence selon leur état actuel

Sélection de plusieurs unités

  • Plusieurs unités peuvent être sélectionnées dans le widget des résultats de recherche, avec un aperçu des unités sélectionnées

Palette de commandes

  • La palette de commandes permet de voir toutes les commandes disponibles ainsi que leurs raccourcis clavier

Commandes

  • Par exemple, en appuyant sur Ctrl+O, il est possible d’arrêter l’unité sélectionnée

Prise en charge du pager

  • Pendant l’exécution de isd, il est possible d’ouvrir un pager pour consulter la sortie complète de l’aperçu

Personnalisation

  • isd offre des possibilités de personnalisation et de configuration, avec divers thèmes et raccourcis clavier afin d’optimiser la productivité de l’utilisateur

Résumé

  • Il est recommandé d’essayer isd soi-même pour juger de son utilité

Étapes suivantes

  • Consulter les sections sur la personnalisation et la sécurité

À lire aussi

1 commentaires

 
GN⁺ 2025-01-19
Commentaires sur Hacker News

  • Ça a l’air bien
    La façon dont ExecStop est géré dans les scripts de service systemd m’a toujours vraiment embrouillé
    ExecStart est la commande exécutée au démarrage du système ou quand l’utilisateur lance le service, mais ExecStop s’exécute après la fin de la commande de démarrage
    Si l’on veut que la commande stop soit exécutée à l’arrêt du système ou quand l’utilisateur arrête le service, il faut définir RemainAfterExit=yes
    ExecStop est en pratique moins un événement de « fin du service » qu’un événement de « phase de nettoyage »

    • Il faut raisonner en termes de « au démarrage » et « à l’arrêt »
      Il faut se souvenir que systemd est conçu pour les démons
      Si vous n’exécutez qu’une seule commande qui se termine un jour, il faut indiquer à systemd de la traiter différemment d’un démon
      Comme d’autres l’ont dit, oneshot + RemainAfterExit est probablement la combinaison que vous cherchez
    • Avec type=forking, ExecStop fonctionne comme on l’attend

  • J’aime vraiment beaucoup
    Après avoir utilisé uniquement la ligne de commande pure jusqu’à m’en rendre malade, j’ai commencé récemment à utiliser des outils comme lazygit/lazydocker pour examiner des états système/arborescence opaques, et ma productivité a nettement augmenté
    Je gère plusieurs services au niveau utilisateur et système, mais le débogage est ennuyeux
    Le passage dès la première phrase qui énumère les commandes courantes et leurs inconvénients m’a vraiment parlé
    Comme je suis sous NixOS, je ne peux pas directement modifier des fichiers unit immuables, mais pour l’exploration des services, la visibilité et l’administration, ça a l’air très utile

    • Moi aussi j’utilise NixOS, et c’est justement pour ça que j’ai créé ce projet
      Je prévois d’ajouter un « guide » dans la documentation, mais en résumé, pour déboguer des units sous NixOS, ça vaut le coup de regarder systemctl edit --runtime
      Ça simplifie beaucoup le débogage

  • Ça a l’air très bien
    Je maintiens un projet similaire et travailler avec l’API systemd/dbus a été assez pénible
    J’aimerais essayer ça pour voir si je peux en tirer quelque chose
    https://github.com/rgwood/systemctl-tui

    • Génial
      Je pense que je vais m’en servir souvent
      Il ne manque plus qu’un paquet deb

  • Enfin un client systemd, ravi de voir ça
    L’étape suivante, ce serait un TUI pour les systèmes non Linux comme macOS, FreeBSD ou Windows
    Sur macOS, j’utilise LaunchControl.app, mais ce n’est pas un TUI
    Petite remarque : avec uv 0.5.21, j’ai dû faire comme ci-dessous, et uvx ne fonctionnait pas du tout
    $ uv tool install git+https://github.com/isd-project/isd
    En revanche, la commande de la documentation $ uv tool install https://github.com/isd-project/isd/isd@latest ne marchait pas
    Cela dit, uv est bien plus rapide que pip(x), donc j’ai adopté le changement

    • C’était une erreur et c’est corrigé maintenant
      Merci de l’avoir signalé

  • C’est génial que uv rende l’installation de ce genre d’outils aussi simple
    Ce qui manque dans la procédure d’installation, c’est que uv installe cet outil en ignorant les dépendances Python
    Ma machine était en 3.10, donc isd ne fonctionnait pas, et j’ai résolu ça avec l’option -p 3.13
    Ça vaudrait le coup de le mentionner dans la documentation

    • Merci de l’avoir signalé
      J’ai ajouté ce flag dans la documentation

  • « si vous en avez marre de taper », c’est exactement mon cas
    Et pourtant j’aime systemd
    Je ne l’ai pas encore installé, mais je me demande s’il peut se connecter à des hôtes distants
    J’utilise souvent systemctl --host status foo.service, et je consulte à distance le status, les timers, les logs, etc.

    • Je découvre systemctl --host
      Malheureusement, ce n’est pas pris en charge
      C’est en gros plutôt un wrapper sophistiqué autour du systemctl local
      Cela dit, il y a une AppImage, donc l’exécuter sur un serveur distant pourrait, hopefully, être simple
      Quoi qu’il en soit, ouvrez une issue et j’y jetterai un œil

  • On ne peut pas installer ce genre de chose sur des serveurs distants ou dans des images Docker
    Il faudrait plusieurs backends pour exécuter les commandes et collecter les informations : local, SSH, Docker
    Il faudrait pouvoir l’installer en local, puis exécuter les commandes sur une machine distante via SSH, et aussi via docker exec

  • Je doute que l’affirmation « cette AppImage ne fonctionne pas si Nix est installé » soit vraiment correcte.
    Je comprends pourquoi cela ne marche pas sur NixOS. Il semblait qu’elle ne pouvait pas exécuter le systemctl de l’hôte.
    Mais il ne semble pas y avoir de raison pour que cela ne fonctionne pas simplement parce que Nix est installé sur un autre OS.
    Fait intéressant, avec Nix v2.24.11, la commande Nix fournie ne fonctionnait pas non plus.
    $ nix run https://github.com/isd-project/isd échouait avec Failed to open archive (Unrecognized archive format).
    Cela pourrait fonctionner en le reformulant sous forme d’URL Git, mais comme Nix dispose d’un fetcher GitHub natif plus efficace, la vraie commande semble plutôt être nix run github:isd-project/isd.
    Le projet lui-même est chouette.
    À l’origine, je voulais créer quelque chose de similaire avec l’API DBus de systemd et Qt, et j’avais même déjà écrit un peu de code.
    L’API DBus fournit très probablement presque toutes les fonctionnalités nécessaires. Bien sûr, appeler systemd -H est bien plus simple que d’implémenter soi-même le tunneling SSH.
    Il est frustrant de voir que systemd et le Linux moderne regorgent de données et d’interfaces qui pourraient faciliter l’administration du système, notamment la gestion du bureau, traditionnellement assez opaque, mais que tout cela reste peu exposé.
    Autrefois, il était difficile de savoir ce qui s’était passé quand une appli de démarrage automatique xdg échouait, mais maintenant que systemd lance ces applis xdg auto-start sur certains bureaux, il devient facile de créer une GUI qui montre les éléments de démarrage en échec et un visualiseur de logs.
    Pourtant, il ne semble pas exister d’outil maintenu et relativement abouti pour cela, ce qui est assez frustrant.

    • Oui, c’est vrai. C’est devenu compliqué, donc je ne voulais pas le recommander en détaillant les subtilités.
      En résumé, l’AppImage est générée avec nix, et l’AppImage « monte » le répertoire /nix/ présent à l’intérieur de l’AppImage. Ce n’est pas un overlay.
      Donc, dans le TUI, les appels qui accèdent à /nix/ n’aboutissent pas au répertoire /nix du système, ce qui provoque toutes sortes de comportements bizarres.
      Par exemple, sur Ubuntu, on peut installer EDITOR avec home-manager.
      Comme systemctl est « accessible », isd démarre normalement, mais si on ouvre EDITOR sous /nix, il est introuvable, ce qui est très déroutant pour l’utilisateur.
      Du coup, si vous utilisez déjà Nix, c’est plus simple de vous dire d’utiliser la méthode d’installation Nix.
      J’ai maintenant corrigé la documentation erronée.
      Je partage aussi cette frustration.
      Personnellement, je trouverais très amusant de construire ce genre d’outil, mais ce n’est pas une tâche facile, et se pose aussi la question de savoir qui financerait ce travail.
      Même ce TUI, malgré un périmètre raisonnable, a demandé pas mal de travail.
      Donc je ne pense pas investir beaucoup dans des « interfaces de plus haut niveau ».
      Et au passage, je ne sais pas pourquoi le commentaire d’origine est aussi mal reçu.
    • Je ne comprends absolument pas pourquoi ce commentaire est si mal reçu.
      Quelqu’un peut l’expliquer ?

  • Ça a l’air excellent et bien réalisé.
    Cela dit, le simple fait qu’un tel outil soit nécessaire est regrettable.
    La plupart des interactions avec systemd sont triviales : redémarrer un service, consulter les logs pour voir ce qui ne va pas, vérifier si un service démarre au boot.
    Je ne comprends pas qu’l’utilisabilité de systemd soit à ce point insuffisante pour ces tâches pourtant si courantes.
    Cela dit, ce TUI semble utile, donc merci.
    Bien sûr, systemd est plus déterministe qu’initd et embarque toutes sortes de fonctionnalités.
    Heureusement, aujourd’hui, la plupart de ces interactions peuvent être automatisées et donc disparaître, si bien qu’on n’en est plus à la haine brûlante d’autrefois.
    Maintenant, c’est plutôt un feu couvant.

    • Je comprends qu’on ne veuille pas « alourdir » systemd en y ajoutant un TUI complexe et subjectif.
      Malgré tout, j’aurais vraiment aimé qu’il y ait une interface plus proche du projet amont.
      Cela dit, rendre systemd convivial pour les débutants et accessible ne semble pas être une priorité majeure dans leur financement.

  • Comment la sécurité est-elle gérée ?
    Je ne parle pas des permissions système que Linux gère bien, mais de la garantie que l’outil ne puisse pas être compromis par un attaquant externe pour permettre une prise de contrôle à distance.

    • C’est l’auteur.
      Je pense que c’est une question importante à se poser quand on exécute une application ou un script qui fait des choses avec sudo.
      C’est pourquoi j’ai rédigé une section Security assez détaillée dans la documentation d’isd.
      https://isd-project.github.io/isd/security/
      N’hésitez pas à me signaler s’il manque quelque chose.