Show HN: Interaktives Systemd – Ein verbesserter Ansatz für die Arbeit mit Systemd-Units

 (isd-project.github.io)
2 Punkte von GN⁺ 2025-01-19 | 1 Kommentare | Auf WhatsApp teilen
  • isd ist ein Tool, das einen besseren Weg zur Verwaltung von systemd-Units bietet, mit einer Terminal User Interface (TUI), über die sich Units durchsuchen lassen, Vorschaen automatisch aktualisiert werden, intelligentes sudo-Handling erfolgt und eine anpassbare Benutzeroberfläche bereitsteht

Kurze Motivation

  • isd vereinfacht die komplexen Abläufe, die für die Interaktion mit systemd-Units nötig sind, und stellt dem Nutzer nützliche Informationen bereit
  • Es reduziert die Mühe, systemctl-Befehle wiederholt eingeben zu müssen, und aktualisiert die Ausgabe automatisch

Installation

  • isd kann über AppImage, nix und uv installiert werden
  • AppImage ist eine einzelne ausführbare Datei, die auf allen Linux-Distributionen ausgeführt werden kann und sich auch auf Remote-Servern mit eingeschränkten Berechtigungen nutzen lässt
  • Um isd in einer nix-Umgebung zu installieren, kann das nix-Paket verwendet werden
  • uv ist ein Python-Paketmanager, über den sich isd installieren und verwalten lässt

Verwendung von isd

  • isd durchsucht systemd-Units, prüft ihren Status und bietet eine Vorschau mit Detailinformationen zu mehreren Units
  • Es sendet systemctl-Befehle an ausgewählte Units und aktualisiert die Statusausgabe automatisch
  • Innerhalb von isd kann ein pager geöffnet werden, um die vollständige Statusausgabe anzuzeigen
  • Für die Journal-Ausgabe lässt sich ein separater pager öffnen, außerdem können anpassbare Themes und Keybindings festgelegt werden

Benutzer-/Systemmodus

  • isd wird im user- oder system-Modus ausgeführt; je nach Modus unterscheiden sich die angezeigten Unit-Typen

Fuzzy-Suche

  • Über die Fuzzy-Suchleiste werden alle Units und Unit-Dateien geladen, die zur Eingabe passen, und abhängig vom aktuellen Status hervorgehoben

Mehrere Units auswählen

  • Im Suchergebnis-Widget können mehrere Units ausgewählt werden; für die ausgewählten Units wird eine Vorschau angezeigt

Befehlspalette

  • Über die Befehlspalette lassen sich alle verfügbaren Befehle und Keybindings anzeigen

Befehle

  • Zum Beispiel kann mit Ctrl+O die ausgewählte Unit gestoppt werden

Pager-Unterstützung

  • Während isd läuft, kann ein pager geöffnet werden, um die vollständige Vorschauausgabe anzuzeigen

Anpassung

  • isd bietet Anpassbarkeit und Konfigurierbarkeit sowie verschiedene Themes und Keybindings, damit Nutzer optimal produktiv arbeiten können

Zusammenfassung

  • Es wird empfohlen, isd selbst auszuprobieren, um zu beurteilen, ob es nützlich ist

Nächste Schritte

  • Den Abschnitt zu Anpassung und Sicherheit ansehen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-19
Meinungen auf Hacker News

  • Sieht gut aus
    Die Art, wie ExecStop in systemd-Service-Skripten behandelt wird, fand ich wirklich verwirrend.
    ExecStart ist der Befehl, der beim Systemstart oder wenn der Nutzer den Service startet, ausgeführt wird, aber ExecStop wird ausgeführt, nachdem der Startbefehl beendet ist.
    Wenn der Stop-Befehl beim Herunterfahren des Systems oder wenn der Nutzer den Service stoppt, ausgeführt werden soll, muss RemainAfterExit=yes gesetzt werden.
    ExecStop ist eigentlich weniger ein Event „zum Beenden des Services“, sondern eher ein Event „zum Aufräumzeitpunkt“.

    • Man kann es als „beim Starten“ und „beim Stoppen“ betrachten.
      Man sollte im Kopf behalten, dass systemd auf Daemons ausgerichtet ist.
      Wenn ein Service nur einen einzelnen Befehl ausführt, der irgendwann endet, muss man systemd ausdrücklich sagen, dass es ihn anders als einen Daemon behandeln soll.
      Wie andere schon gesagt haben, ist vermutlich oneshot + RemainAfterExit die gewünschte Kombination.
    • Bei type=forking verhält sich ExecStop so, wie man es erwartet.

  • Gefällt mir wirklich gut.
    Ich habe bis zum Umfallen nur die reine Kommandozeile benutzt, aber seit Kurzem nutze ich Tools wie lazygit/lazydocker, um undurchsichtige System-/Baumzustände sichtbar zu machen, und meine Produktivität ist stark gestiegen.
    Ich verwalte mehrere Services auf Benutzer- und Systemebene, aber Debugging ist mühsam.
    Der Teil im ersten Satz, der die üblichen Befehle und ihre Umständlichkeit aufzählt, hat mich wirklich angesprochen.
    Da ich NixOS nutze, wird das direkte Bearbeiten unveränderlicher Unit-Dateien wohl nicht funktionieren, aber das Durchsuchen, die Sichtbarkeit und die Verwaltung von Services dürften sehr hilfreich sein.

    • Ich bin ebenfalls NixOS-Nutzer, und genau deshalb habe ich dieses Projekt gebaut.
      Ich plane, der Dokumentation einen „Guide“ hinzuzufügen; kurz gesagt lohnt es sich, beim Debuggen von Units unter NixOS systemctl edit --runtime auszuprobieren.
      Das macht Debugging deutlich einfacher.

  • Sieht sehr gut aus.
    Ich betreue ein ähnliches Projekt, und der Umgang mit der systemd/dbus API war ziemlich schmerzhaft.
    Ich möchte es ausprobieren und sehen, ob ich daraus etwas lernen kann.
    https://github.com/rgwood/systemctl-tui

    • Großartig.
      Werde ich wohl viel nutzen.
      Das Einzige, was fehlt, ist ein deb-Paket.

  • Endlich gibt es einen systemd-Client, schön zu sehen.
    Als nächsten Schritt würde ich mir eine TUI für Nicht-Linux-Systeme wie macOS, FreeBSD und Windows wünschen.
    Unter macOS nutze ich LaunchControl.app, aber das ist keine TUI.
    Eine Sache: Mit uv 0.5.21 musste ich es wie unten machen, und uvx funktionierte überhaupt nicht.
    $ uv tool install git+https://github.com/isd-project/isd
    Dagegen funktionierte $ uv tool install https://github.com/isd-project/isd/isd@latest aus der Dokumentation nicht.
    Trotzdem bin ich umgestiegen, weil uv deutlich schneller ist als pip(x).

    • Das war ein Fehler und ist jetzt behoben.
      Danke für den Hinweis.

  • Es ist toll, dass uv die Installation solcher Tools so einfach macht.
    Was in der Installationsanleitung fehlt: uv ignoriert die Python-Abhängigkeit und installiert dieses Tool trotzdem.
    Auf meiner Maschine läuft 3.10, daher funktionierte isd nicht; mit der Option -p 3.13 ließ sich das beheben.
    Das wäre eine Erwähnung in der Dokumentation wert.

    • Danke für den Hinweis.
      Ich habe das Flag in die Dokumentation aufgenommen.

  • „Wenn dich das Tippen schon einmal genervt hat“ – das bin genau ich.
    Und das, obwohl ich systemd mag.
    Ich habe es noch nicht installiert, frage mich aber, ob man sich mit Remote-Hosts verbinden kann.
    Ich nutze häufig systemctl --host status foo.service und prüfe status, timers, logs usw. remote.

    • Von systemctl --host höre ich zum ersten Mal.
      Leider wird das nicht unterstützt.
      Grob gesagt ist es eher ein schicker Wrapper um das lokale systemctl.
      Aber da es ein AppImage gibt, könnte es hopefully einfach sein, es auf einem Remote-Server auszuführen.
      Öffne jedenfalls gern ein Issue, dann schaue ich es mir an.

  • Auf Remote-Servern oder in Docker-Images kann man so etwas nicht installieren.
    Man braucht mehrere Backends zum Ausführen von Befehlen und Sammeln von Informationen: lokal, SSH, Docker.
    Man sollte es lokal installieren können und dann per SSH Befehle auf einer Remote-Maschine ausführen sowie es auch per docker exec ausführen können.

  • Ich frage mich, ob „Wenn Nix installiert ist, funktioniert dieses AppImage nicht“ wirklich stimmt.
    Dass es unter NixOS nicht geht, verstehe ich. Es sah so aus, als könne es das systemctl des Hosts nicht ausführen.
    Aber ich sehe keinen Grund, warum es auch auf einem anderen OS nicht gehen sollte, nur weil dort Nix installiert ist.
    Interessanterweise funktionierte unter Nix v2.24.11 auch der angegebene Nix-Befehl nicht.
    $ nix run https://github.com/isd-project/isd schlägt mit Failed to open archive (Unrecognized archive format) fehl.
    Wenn man es in eine Git-URL-Form bringt, könnte es funktionieren, aber Nix hat einen effizienteren eingebauten GitHub-Fetcher, daher scheint der eigentliche Befehl nix run github:isd-project/isd zu sein.
    Das Projekt selbst ist cool.
    Ich wollte ursprünglich mit der DBus API von systemd und Qt etwas Ähnliches bauen und hatte auch schon ein wenig Code geschrieben.
    Die DBus API bietet wahrscheinlich fast alles, was man dafür braucht. Natürlich ist es deutlich einfacher, systemd -H aufzurufen, als eigenes SSH-Tunneling zu implementieren.
    Es ist frustrierend, dass systemd und modernes Linux voller Daten und Interfaces sind, die Systemadministration – besonders die traditionell wenig transparente Desktop-Verwaltung – erleichtern könnten, diese aber kaum sichtbar gemacht werden.
    Früher war es schwer herauszufinden, was passiert war, wenn eine xdg-Autostart-App fehlschlug. Jetzt starten manche Desktops xdg-Autostart-Apps über systemd, sodass es leicht wäre, eine GUI zu bauen, die fehlgeschlagene Autostart-Einträge und einen Log-Viewer anzeigt.
    Aber es scheint kein gepflegtes und einigermaßen vollständiges Tool dafür zu geben, was ziemlich frustrierend ist.

    • Stimmt, es wurde kompliziert, und ich wollte es nicht empfehlen und dann die Details erklären müssen.
      Kurz gesagt: Das AppImage wird mit Nix erzeugt, und das AppImage „mountet“ das /nix/-Verzeichnis innerhalb des AppImages. Es ist kein Overlay.
      Daher gehen Aufrufe aus der TUI, die auf /nix/ zugreifen, nicht ins /nix-Verzeichnis des Systems, und alle möglichen seltsamen Probleme entstehen.
      Zum Beispiel kann man unter Ubuntu per home-manager EDITOR installieren.
      systemctl ist „zugänglich“, also startet isd normal, aber wenn es den EDITOR unter /nix öffnen will, findet es ihn nicht, was aus Nutzersicht sehr verwirrend ist.
      Deshalb ist es einfacher zu sagen: Wenn du bereits Nix nutzt, verwende die Nix-Installationsmethode.
      Die falsche Dokumentation habe ich inzwischen korrigiert.
      Die Frustration kann ich nachvollziehen.
      Persönlich fände ich es wirklich spannend, so ein Tool zu bauen, aber es ist keine leichte Aufgabe, und die Frage ist auch, wer diese Arbeit finanzieren würde.
      Diese TUI hatte einen beherrschbaren Umfang und war trotzdem ziemlich viel Arbeit.
      Deshalb glaube ich nicht, dass ich zu viel in ein „höherstufiges Interface“ investieren werde.
      Nebenbei: Ich weiß nicht, warum die Reaktion auf den ursprünglichen Kommentar so negativ ist.
    • Ich verstehe überhaupt nicht, warum dieser Kommentar so schlecht ankommt.
      Kann das jemand erklären?

  • Sieht großartig aus und ist gut gemacht.
    Allerdings ist es schade, dass ein solches Tool überhaupt nötig ist.
    Die meisten Interaktionen mit systemd sind trivial: einen Dienst neu starten, Logdateien ansehen, um herauszufinden, was schiefgelaufen ist, prüfen, ob ein Dienst beim Booten gestartet wird.
    Ich verstehe nicht, warum die Benutzbarkeit von systemd bei solchen häufigen Aufgaben so schwach ist.
    Trotzdem scheint diese TUI hilfreich zu sein, also danke dafür.
    Natürlich ist systemd im Gegensatz zu initd deterministischer und enthält alle möglichen Funktionen.
    Zum Glück lässt sich heutzutage der Großteil dieser Interaktionen wegautomatisieren, sodass der brennende Hass von früher nicht mehr da ist.
    Jetzt ist es eher noch Glut.

    • Ich verstehe, warum man systemd nicht mit einer komplexen, meinungsstarken TUI „aufblähen“ will.
      Trotzdem wäre ein Interface näher am Upstream-Projekt wirklich schön gewesen.
      Allerdings scheint es für ihre Finanzierung nicht besonders wichtig zu sein, systemd anfängerfreundlich und zugänglich zu machen.

  • Wie wird Sicherheit gehandhabt?
    Ich meine nicht Systemberechtigungen, die Linux gut behandelt, sondern ob garantiert ist, dass es nicht von externen Angreifern übernommen und ferngesteuert wird.

    • Ich bin der Autor.
      Ich halte das für eine wichtige Frage, die man sich stellen sollte, wenn man eine Anwendung oder ein Skript ausführt, das etwas mit sudo macht.
      Deshalb habe ich auf der isd-Dokumentationsseite einen ziemlich ausführlichen Abschnitt Security geschrieben.
      https://isd-project.github.io/isd/security/
      Wenn etwas fehlt, sag mir bitte Bescheid.