Das abgebildete schwarze Tier hat gut 70 cm Risthöhe und 34 kg Gewicht. Es nennt sich Bommel und wird von den meisten Menschen als Hund wahrgenommen. In der Tat interessiert er sich für Individuen dieser Spezies, insbesondere für weibliche, jedoch mit tendenziell bisexueller Ausrichtung auch für kastrierte männliche. Trotz weiterer hündischer Merkmale des Prinzips „Immer der Nase nach“ bin ich mir nach drei Jahren mit diesem Tier so gut wie sicher, dass es sich um KEINEN Hund handelt:
Hunde rennen Stöckchen und Frisbees hinterher, Bommel nur Weibern. Hunde denken nur ans Fressen, Bommel will eine Einladung zum Napf plus Bestätigung am Napf, dass die Einladung wirklich gilt. Hunde wälzen sich in schlammigen Pfützen, Bommel macht einen Bogen. Hunde danken dir für ein Leckerli, indem sie noch den halben Finger als Zugabe nehmen. Bommel holt es sich mit zartester Rücksicht. Hunde hören auf „Stop“ und „Down“, Bommel schaut, ob das im Moment sinnvoll ist. Sieht er keinen Anlass („Hier ist kein Auto!“), schaut er mich tadelnd an – und lässt es.
Bommel ist wahrscheinlich kein Hund, sondern ein Pudel. Nach Goethe und Schopenhauer ist ein Pudel ein Wesen mit durchaus ungewissem Kern. Ich werde die gemeinsamen Jahre nutzen, Genaueres herauszufinden.
Ein Bild aus besten Tagen (Sommer 2016)…
Some people like cats exclusively. I for one care less for them. I say there is not, nor ought there be nothing so exalted on the face of God’s great earth as that prince of pets: The king size poodle in the incarnation of Bommel… (Frank Zappa in memoriam et variationem)
Was sieht man hier? Objektiv nur Teile von Herr und Hund mit Natur. Wer das „Herr-und-Hund-Sein“ kennt, sieht VIEL mehr: Interessenskongruenz und tiefe Harmonie …
Bommel in memoriam
geboren 13.04.2013, viel zu früh verstorben am 10.09.2025
Bommel war unfassbar sozial und freute sich über alle Begegnungen (eine Handvoll intimer Rüden-Feinde ausgenommen) – über Menschen fast noch mehr als über Hunde. Das blieb nicht einseitig: Hundert Mal hörte ich bei noch weiter entfernten Personen (mit oder ohne Hund), die vielleicht erst besorgt einen großen Hund hatte kommen sehen, den erleichteren, nun erfreuten Ruf „Das ist doch der Bommel!“.
Bommel war witzig: Mit Gras unter den Beinen und ausreichend Platz blieb er stocksteif stehen, spreizte die Vorderbeine und blitzte mit den Augen. Das hieß – steig ab vom Rad, wir MÜSSEN raufen! Und das gönnte ich ihm oft und gerne, denn der Spaß seiner spielerischen Angriffe und meiner Abwehr war beidseitig. Jeder schlaue Hundelehrer wird unsere „harten“ Raufereien als pädagogische Todsünde verurteilen, aber wir liebten sie – und sie blieben EXKLUSIV (wie auch ähnliche Verfolgungsjagden auf dem Fahrrad und Beiß-Simulationsspiele mit meiner Tochter): Es ist dem Hund niemals eingefallen, Ähnliches mit anderen Personen zu beginnen.
Bommel war hingebungsvoll aufmerksam. Er wollte jedes an ihn gerichtete Wort verstehen. Bei Worten, die er nicht kannte, legte er fragend den Kopf um 45 Grad schief. Das hieß: Ich verstehe es nicht, aber ich will es verstehen!
Bommel kannte Reue und Entschuldigung – ein Beispiel: Als er mir im Laufspiel die Wegkurve so gekreuzt hatte, dass ich stürzte, setzte er sich sofort vor mich und hob mehrfach entschuldigend eine Vorderpfote.
Bommel war eigensinnig auf eine liebenswürdige Weise, die ihn ein Stück über das „Hund-Sein“ erhob. Tatsächlich habe ich in all den Jahren keinen Hundehalter in basisdemokratischer Diskussion mit seinem Hund erlebt. Bei uns war das vor allem bei Wegentscheidungen überaus häufig: Bog ich „falsch“ ab, blieb er stehen: Er würde die andere Richtung bevorzugen… Oft gab ich nach, wenn nicht, akzeptierte er – früher oder später, bei deutlicher Mahnung früher. Man kann das Verhalten des Hundes kritisieren, das des Halters, der solche Autoritätszweifel erzogen hat – ich vermisse diese „Gespräche“ schmerzlich.
Bommel war kein Schmusehund, aber er war dankbar. In seinen Kraftjahren nahm er Huldigungen mit Genuss, ohne sie jemals infantil oder unterwürfig einzufordern. Mit zunehmendem Alter zeigte er seine unverbrüchliche Bindung immer deutlicher. Unvergesslich emotional war seine Heimkehr nach mehrtägigem und traumatischem Klinikaufenthalt. Er leckte Hände und Arme (NIE zuvor in zehn Jahren!) und zeigte bei aller Schwäche überdeutlich, dass eine Tonnenlast an Verlustangst von ihm gefallen war – zurück bei uns und am vertrauten Ort. Er genas und blieb uns für weitere zwei Jahre.
Gibt es irgendwas, was ich an Bommel kritisieren könnte? Vielleicht, dass er (der Pudel!) wasserscheuer war als jede Katze. Er ist in seinem Leben genau drei Meter geschwommen – dies nach einem instinktiven Sprung (Fisch?) in einen Weiher sofort zurück ans Ufer. Über seine Tat selbst erschrocken, schüttelt er sich und beschließt, solches Abenteuer nie mehr zu unternehmen…
In den meisten aktuellen Linux-Distributionen arbeitet Systemd als primärer Prozess mit der PID „1“ als Boss aller nachfolgenden Systemdienste. Dieser Heftschwerpunkt erläutert Werkzeuge und Techniken dieses Init-Prozesses mit umfassendem Anspruch.
Der Init-Daemon Systemd
Die Reichweite des Systemd-Konzepts und die damit einhergehenden Chancen einer Standardisierung von Linux-Systemen sind unbestritten. Systemd hat aber Vorgänger wie Sysvinit und Upstart als Init-Daemon insbesondere deshalb abgelöst, weil er durch Parallelisierung der frühen Startprozesse für schnellere Bootzeiten sorgt. Die Aufgabe des Init-Prozesses ist schnell erklärt: Beim Start der Hardware lädt der Bootloader den Linux-Kernel. Der Kernel startet dann den Init-Prozess aus dem Pfad /sbin/init, der die Prozess-ID „1“ erhält. Welches Init-System bei einer Linux-Distribution aktiv ist, erfahren Sie daher am einfachsten durch eine Frage nach Prozess „1“:
cat /proc/1/comm
Die Ausgabe wird in der Regel „systemd“ lauten. Dieser Init-Prozess lädt dann alle erforderlichen Systemdienste, Dateisysteme, Timer. Nachdem Systemd die volle Kontrolle und Übersicht hat, ist es die logische Konsequenz, dass es deren Verwaltung übernehmen muss. Und das macht Systemd umfassend und gründlich. Als wichtigste Benutzerschnittstelle dient das Tool Systemctl, um das es in diesem ersten Artikel ausschließlich gehen soll. Es öffnet nämlich den Zugang zum kompletten Systemd-Kosmos mit seinen diversen Unit-Klassen.
Systemctl und die Systemd-Units
Systemctl wird oft als „Dienste-Manager“ bezeichnet. Das ist zwar wahrscheinlich der häufigste Einsatzzweck, unterschlägt aber, dass Systemctl sämtliche Systemd-Units verwaltet. Dienste, also die Klasse „Service“, ist nur eine dieser Klassen (siehe Tabelle “ Systemd: Die Unit-Klassen“). Das Kommando
systemctl
ohne weitere Filter ist eine Abkürzung für
systemctl list-units
und zeigt alle aktuell aktiven Systemd-Units. In der Regel wird man die Liste zwecks besserer Übersicht auf eine bestimmte Unit-Klasse wie „service“ filtern. Ob hilfreich oder am Ende doch eher verwirrend, liefern alle folgenden Syntaxvarianten exakt dasselbe Resultat:
systemctl list-units --type=service
systemctl --type=service
systemctl -t service
Das Ergebnis ist die Prozessliste aller aktuell geladenen Systemdienste.
Eine anders geartete Abfrage richtet sich an die Systemd-Konfigurationsdateien. Der Befehl
systemctl list-unit-files -t service
liefert sämtliche Dienstekonfigurationen aus, die auf dem System vorliegen. Das ist vor allem relevant, um eine schnelle Übersicht über Änderungen aller Art zu ermitteln. Abgeschaltete oder ganz deaktivierte Units erscheinen hier nämlich mit roter Signalfarbe als „disabled“ oder „masked“. Wenn man will, kann man nach solchen Units mit
systemctl list-unit-files -t service –-state=disabled
oder „—state=masked“ noch zielgenauer fahnden.
Geänderte oder abgeschaltete Units (hier Dienste) sind mit „list-unit-files“ schnell zu finden.
Unit-„Properties“ anzeigen und steuern
Systemctl kann Units nicht nur anzeigen, starten und stoppen (siehe unten), sondern auch im Detail verändern und umkonfigurieren. Der Unterbefehl „show“ von systemctl (Beispiel)
systemctl show ssh.service
zeigt alle Eigenschaften der angesprochenen Unit – zumeist ziemlich viele, sodass sich oft eine Sortierung (sort) oder ein Grep-Filter empfiehlt:
systemctl show ssh.service | grep -i "cpu"
Der aktive Befehl (Beispiel)
systemctl set-property ssh.service CPUWeight=20
kann dann die Eigenschaften interaktiv und für die laufende Sitzung ändern. Ein weiteres Beispiel für Ressourcensteuerung ist unten im Abschnitt „Die Slice-Units“ skizziert. Neben der dort gezeigten CPU-Begrenzung mit „CPUQuota=20%“ gibt es weitere interessante Eigenschaften wie „MemoryMax=500M“ (Limitierung von Services oder Slices) oder „IOWeight=500“ (Standard ist „100“, Maximum ist „1000“ – relevant etwa für die Webserver-Optimierung).
„Property“-Änderungen dauerhaft speichern: Eingriffe mit systemctl set-property gelten sofort, allerdings nur bis zum nächsten Neustart des Dienstes oder des Systems (transient). Dauerhafte Einstellungen benötigen ein korrigierendes „Drop-In-File“. Diese Dateien haben den Vorteil, dass die Originale unter /usr/lib/systemd/system/ stets unverändert bleiben (wichtig bei Systemupdates). Erfreulicherweise muss man sich um den korrekten Namen und Speicherort solcher Dateien nicht kümmern, weil systemctl das nach (Beispiel)
sudo systemctl edit user.slice
selbst am besten weiß. Vorbereitend ist es aber immer zu empfehlen, vorher die gewünschte Änderung mit systemctl set-property interaktiv zu testen. Dabei werden nämlich falsch geschriebene Properties oder ungültige Werteangaben automatisch abgelehnt. Korrekte, interaktiv angeforderte Änderungen erscheinen hingegen am Ende der Datei, die man danach mit systemctl edit öffnet. Die Property-Angabe am Dateiende kann man aber nicht einfach (und naheliegend) durch Entfernen des Kommentarzeichens (#) aktiv schalten. Sie muss vielmehr nach oben in Zeile 3 oder 4 kopiert werden – vor die Zeile „Edits below […] will be discarded“.
Nach dem Speichern der Datei, die dann /etc/systemd/system/[name].d/override.conf lauten wird, kann die Aktion mit
permanent gesetzt werden – dies zumindest für Service- oder Timer-Units. Für andere Units ist ein Neustart erforderlich.
Systemctl ändert Prozesseigenschaften: Das Erstellen der Änderungsdatei ist etwas fummelig, aber um Dateipfade und Abgleich mit der Originaldatei kümmert sich Systemd.
Die Unit-Klasse „Service“
An der Verwaltung mit Systemdiensten kommt kein Linux-Nutzer vorbei, der zumindest den einen oder anderen Netzwerkdienst wie SSH oder Apache laufen hat. Die wichtigsten Befehle lauten wie folgt (am Beispiel SSH):
Diese Kommandos funktionieren auch ohne explizite Unit-Bezeichnung:
systemctl stop ssh
„stop“ und „start,“ oder einfacher „restart“ sind alltägliche Aktionen, wenn ein Dienst wie Apache, SSH oder Samba eine manuelle Konfigurationsänderung neu einlesen soll. Zum dauerhaften Abschalten eines Dienstes gibt es die folgenden Kommandos:
systemctl disable ssh
systemctl mask ssh
„disable“ deaktiviert einen Dienst an sich dauerhaft, verhindert aber nicht, dass diesen ein anderer Systemdienst unter der Haube neu aktiviert. Erst der „mask“-Befehl macht auch dieses unmöglich und deaktiviert einen Dienst nachhaltig. Dies kann bei Bedarf nur der Systemadministrator (also Sie) mit
systemctl unmask ssh
systemctl start ssh
wieder rückgängig machen.
Ein Eingriff in Systemdienste, vor allem aber das Abschalten von Diensten ist stets heikel, aber systemctl kann das nicht nur erledigen, sondern bietet auch gute Kontrolle darüber, was auf dem System verändert wurde. Eine gut lesbare Übersicht mit farbigen Markierungen („disabled“ rot, „enabled“ grün) liefert der folgende Befehl, der nicht die Dienste, sondern die darunterliegenden Konfigurationsdateien abfragt:
systemctl list-unit-files -t service
Zusätzlich zur Farbmarkierung erscheint in der rechten Spalte die Distributionsvorgabe als „Preset“ oder „Vendor Preset“. Somit erkennt man die Vorgaben der Distribution und was am System manuell geändert wurde. Beachten Sie bei dieser Ausgabe der Unit-Dateien auch den Status-Eintrag „static“. Die damit ausgezeichneten Dienste sind systemrelevant und lassen sich nicht deaktivieren.
Die Statusabfrage einer Unit macht unter anderem sofort ersichtlich, ob deren Konfiguration geändert wurde („Drop-In“).
Die Unit-Klasse „Target“
Systemd-Targets sind keine aktiven Prozesse, sondern definierte Sammlungen von Device-, Service-, Mount-, Path- und Timer-Units, die dann in der Summe einen bestimmten Systemzustand erzielen. Dieser Zustand kann maximal (graphical.target) oder minimal ausfallen (etwa rescue.target). Solche Unit-Kombinationen kann man mit einem einzigen Kommando neu definieren oder ab dem nächsten Systemstart als Standard vorgeben.
Um alle vordefinierten Targets aufzulisten, ist dieser Befehl geeignet:
systemctl -t target
Hier erscheinen dann unter anderem „basic“, „emergency“, „graphical“, „multi-user“, „rescue“ oder „shutdown“. Welche Unit-Sammlung ein Target konkret enthält, ist auf Dateiebene (/lib/systemd/system) schwer zu ermitteln, weil Target-Konfigurationsdateien nur die speziellen Units des Targets direkt auflisten und ansonsten auf integrierte Targets verweisen. Der Befehl
systemctl list-dependencies basic.target
macht das anschaulicher.
Der praktische Einsatz dieser Targets sieht so aus, dass man mit einem einzigen „isolate“-Befehl alles abschalten kann, was nicht in der Unit-Sammlung des angesprochenen Targets enthalten ist. Der am Desktop gestartete Befehl
sudo systemctl isolate rescue.target
führt sofort in die Wiederherstellungskonsole. Was immer am System läuft oder noch nicht gespeichert ist, wird weggeschossen. Zurück zur Anmeldung geht’s mit Strg-D (Abbruch der Konsole) oder mit diesem Befehl:
sudo systemctl isolate graphical.target
Die Aktion „isolate“ ist nicht für jedes Target erlaubt. Verantwortlich dafür ist die Eigenschaft „AllowIsolate“ der Target-Unit.
Dauerhaftes Umschalten: Was der Unterbefehl „isolate“ interaktiv ausführt, kann „set-default“ ab dem nächsten Systemstart dauerhaft als Standard setzen. Dafür kommen aber nur zwei Targets ernsthaft in Betracht – das umfangreichste „graphical.target“ und das Target „multi-user.target“ für Server ohne Desktop. Der Wechsel dieser beiden Targets ist vor allem für Platinenrechner interessant. Dort ist es typisch, dass der Desktop zwar zur ersten Einrichtung willkommen, danach aber überflüssig ist. Wer nur noch die Serverdienste braucht (Samba, SSH, Apache), kann mit
sudo systemctl set-default multi-user.target
die Oberfläche abschalten. Mit
sudo systemctl set-default graphical.target
ist der Desktop bei Bedarf wieder zu aktivieren.
Achtung: Anders als bei „isolate“ ist Systemd beim Setzen des Default-Targets indifferent. Wenn Sie mit
sudo systemctl set-default rescue.target
die Wiederherstellungskonsole zum Systemstandard machen, sehen Sie den Desktop erst mal nicht wieder, solange Sie auf der Notfallkonsole nicht wieder das „graphical.target“ als Standard setzen. Auch destruktive Aktionen sind nicht untersagt. Nach
sudo systemctl set-default basic.target
geht gar nichts mehr. Aber da das Grub-Menü über „Erweiterte Optionen“ und den „Recovery Mode“ das rescue.target einschalten kann, gibt es von hier über die root-Konsole und
systemctl set-default graphical.target
wieder einen Weg zurück.
Die Unit-Klasse „Slice“
Slices sind Sammlungen aktiver Prozesse, die zu einer Verwaltungseinheit gebündelt werden (auf der Basis von Linux-Control-Groups). Das klingt verkopft, eröffnet aber in der Praxis großes Optimierungspotential. Die Nachfrage mit
systemctl -t slice
wird eine Reihe von Slice-Units anzeigen, unter anderem je eine Slice („Scheibe“) für jedes Benutzerkonto. Die Eigenschaften sind dann wie auch sonst mit
systemctl show user-1000.slice
zu erfragen. Daher können Ressourcenlimits auf Slice-Ebene gesetzt werden, die alle darin enthaltenen Prozesse begrenzen:
Der Befehl muss tatsächlich so lauten, obwohl die Eigenschaft eigentlich „CPUQuotaPerSecUSec“ heißt. Auf einem Serversystem mit bescheidener Hardware könnte man daher nicht nur einen einzelnen Benutzer, sondern die komplette User-Scheibe mit
deutlich limitieren, um die Systemdienste zu priorisieren.
Interaktiv, sofort und gravierend: Limitierende Eingriffe in die Ressourcenverteilung von Slice-Units sind unmittelbar spürbar (hier für Konto-UID 1001).
Die Unit-Klasse „Scope“
Die Klasse der Scopes („Erweiterungen“) ist technisch interessant, aber für die meisten Nutzer wahrscheinlich zu akademisch. Es geht darum, beliebige externe Programme (etwa Browser oder Bildbearbeitung) in die Systemd-Verwaltung zu integrieren. Das ist nur interaktiv und temporär während einer Sitzung möglich und benötigt den Befehl systemd-run. Der gehört eigentlich in den nachfolgenden Beitrag („Die Armee der Systemd-Tools“), ist aber hier notwendig, um die Scope-Klasse zu erklären. Nachdem eine temporäre Scope-Unit mit
die Eigenschaften wie bei Systemd-Prozessen abfragen und mit
systemctl set-property ff.scope MemoryLimit=400M
auch nach Bedarf steuern.
Weitere Units: Timer, Path & mehr
Systemd kennt eine Reihe weiterer Unit-Klassen wie Device, Mount, Path, Timer, Snapshot, Socket. Praxisrelevante Optionen dazu kommen im dritten Beitrag dieses Specials noch zu Wort. Dieser Artikel zeigt Beispiele, wie man eigene Dienste anlegt und wie die dafür nötigen Konfigurationsdateien strukturiert sind. Für Anwender kaum ergiebig sind die Klassen Device, Snapshot und Swap. Für Swap (Auslagerungsdatei) bleibt Systemctl auf die übliche „status“-Abfrage mit
systemctl status swapfile.swap
beschränkt, die Pfad und aktuelle/maximale Größe der Datei anzeigt, ferner kann mit
sudo systemctl stop swapfile.swap
das Swapping interaktiv abgeschaltet, mit „start“ wieder aktiviert werden. Weitere Zugriffe mit „enable“ und „disable“ (dauerhaft abschalten) funktionieren auf vielen Systemen nicht.
Die Unit-Klasse Snapshot fehlt bei der Mehrzahl der Distributionen. Es handelt sich um eine interne Systemd-Sicherungsfunktion (etwa sudo systemctl snapshot 2025_Juni), die den aktuellen Systemd-Zustand speichert und später mit „isolate“ restaurieren kann.
Systemd: Die Unit-Klassen
Automount (*.automount)
dynamische Dateisystem-Mounts
Device (*.device)
Vermittlungsschicht zwischen Hardware und Systemd
Mount (*.mount)
statische Dateisystem-Mounts
Path (*.path)
Ordnerüberwachung
Scope (*.scope)
Anwendungsprogramme als Systemd-Prozesse
Service (*.service)
Systemdienste (snapd, ssh, gdm, apache2 etc.)
Snapshot (*.snapshot)
Systemd-Sicherungsfunktion (fehlt meistens)
Slice (*.slice)
Ressourcensteuerung für Prozessgruppen (user, system)
Socket (*.socket)
Netzwerküberwachung und Service-Starts bei Ereignis
Swap (swapfile.swap)
Kontrolle und Steuerung der Auslagerungsdatei
Target (*target)
Unit-Sammlungen für definierte Systemzustände
Timer (*.timer)
Zeitsteuerung für Dienste und Autostarts
Pfade der Unit-Scripts
/etc/systemd/system/
benutzerdefinierte Units oder Anpassungen (priorisiert)
/lib/systemd/system/
Systemstandards
/usr/lib/systemd/system/
Systemstandards
Systemctl: Wichtige Kommandos
Listen und Kontrolle
Erklärung
systemctl [list-units]
Liste aller geladenen Units
systemctl [list-units] -all
Liste aller geladenen Units (auch inaktive)
systemctl -t service
Liste geladener Units einer bestimmten Klasse
systemctl -t service –all
Liste geladener Units einer bestimmten Klasse (auch inaktive)
systemctl list-dependencies ssh.service
alle Abhängigkeiten einer Unit anzeigen
systemctl list-unit-files
keine Prozessliste: Liste der Systemd-Konfigurationsdateien
systemctl list-unit-files -t service
keine Prozessliste: Konfigurationsdateien einer bestimmten Klasse
Unit-Steuerung (am Beispiel SSH)
systemctl status ssh.service
Statusabfrage
systemctl start ssh.service
Dienst starten
systemctl stop ssh.service
Dienst anhalten
systemctl restart ssh.service
Dienst-Neustart nach Konfigurationsänderung
systemctl disable ssh.service
Dienst deaktivieren
systemctl enable ssh.service
Dienst aktivieren
systemctl mask ssh.service
Dienst endgültig verbergen
systemctl unmask ssh.service
verborgenen Dienst wieder aktivieren
Unit-Änderungen (am Beispiel user.slice)
systemctl show user.slice
Eigenschaften einer Unit auflisten
systemctl set-property user.slice CPUQuota=50%
Eigenschaft einer Unit interaktiv (sofort) ändern
systemctl edit user.slice
Eigenschaft einer Unit dauerhaft ändern
systemctl revert user.slice
Änderungen an einer Unit wieder löschen
systemctl preset user.slice
Unit-Konfiguration auf Distributionsstandard setzen
systemctl preset-all (VORSICHT!)
komplettes Zurücksetzen auf Distributionsstandard
Spezielle Befehle für Targets
systemctl -t target
Liste aktiver Target-Units
systemctl get-default
Standard-Target ermitteln
systemctl set-default graphical.target
Standard-Target setzen
systemctl isolate rescue (VORSICHT!)
interaktiv (sofort) Target wechseln
Generelle Systemkommandos
systemctl daemon-reload
Neustart von systemd (nach Änderungen)
systemctl poweroff | reboot | suspend
System-Targets zum Beenden
systemctl rescue | emergency | default
System-Targets für (oder nach) Reparaturen
Die Armee der Systemd-Tools
Das im vorigen Artikel erklärte Systemctl ist das Fundament der Kommunikation mit Systemd. Das Init-System bringt aber inzwischen eine ganze Armee weiterer nutzwertiger Tools mit. Wenn Sie sich unter Debian/Ubuntu mit dem Befehl
dpkg-query -L systemd
über den Umfang von Systemd informieren oder mit
ls /usr/bin/systemd-*
ls /usr/bin/*ctl
direkt auf Dateiebene die einschlägigen Werkzeuge besichtigen, dann sehen Sie, dass es viel zu tun gibt (der zweite Befehl ist nicht ganz präzise und liefert auch einige Systemd-unabhängige Tools). Dieser Artikel erklärt die interessantesten Systemd-Tools. Die meisten fußen auf Systemd-eigenen Diensten, die wiederum mit
systemctl -t service | grep -i "systemd-"
abzufragen sind. So ist etwa das Tool Journalctl auf die Arbeit des Dienstes systemd-journald angewiesen.
Die „*CTL“-Verwaltungstools
Die Unterscheidung in Systemd-Verwaltungsprogramme mit „ctl“ am Ende des Namens und weiteren Hilfsprogrammen mit „systemd-“ am Beginn ist zumindest für die Verwaltungstools à la Systemctl konsistent (bei Systemd-*-Programmen nicht, weil auch einige Dienste so benannt sind). Wir beschreiben die CTL-Tools weder systematisch noch vollständig, sondern nach ihrem vermutlichen Nutzwert für Desktop-Nutzer.
Journalctl verwaltet auf Basis des Dienstes systemd-journald die Systemprotokolle. Das scheint langweilig, aber nur so lange Systeme problemlos laufen. Wenn nicht, dann sind die zahlreichen und präzisen Filteroptionen von Journalctl ein Segen. Die Befehle
journalctl --boot
journalctl –-since today
liefern nur die Meldungen seit dem letzten Systemstart oder des heutigen Tages. Ebenfalls systematisch ist die Eingrenzung nach einem Systemdatum
journalctl --since 2025-07-18
oder ganz kurzfristig für die letzten Minuten:
journalctl --since 15:00
Um harmlose Ereignislevel wegzufiltern, kann die Ausgabe auf ein bestimmtes Ereignislevel (emerg, alert, crit) reduziert werden:
journalctl –-priority crit –-since today
Priority-Level können durch ein Schlüsselwort oder durch eine Kennziffer übergeben werden: „emerg“ (0), „alert“ (1), „crit“ (2), „err“ (3), „warning“ (4), „notice“ (5), „info“ (6), „debug“ (7). Ein Level kumuliert immer alle Meldungen der niedrigeren Stufen, das heißt: „crit“ (2) präsentiert auch die noch ernsteren Levels 0 und 1.
Mit Schalter „“–dmesg“ filtert das Tool ausschließlich die Kernel-Meldungen und ersetzt somit das Tool dmesg:
journalctl --dmesg --since 19:00
Wer weiß, wo er ein Problem zu suchen hat, kann auch gleich nach dem betreffenden Dienst („unit“) eingrenzen. Die Protokollausgabe von
journalctl --unit apache2 --since today
zeigt alle Meldungen des Apache-Servers ab dem angegebenen Datum. Nicht zuletzt kann journalctl den Umfang der Protokollierung begrenzen. Wenn
journalctl --disk-usage
Gigabyte-Tonnen alter Protokolle meldet, dann können Sie mit
das Journal dauerhaft auf 300 MB reduzieren oder auf die Protokollmenge der letzten 10 Tage kürzen. Besonders auf Desktop-Systemen sind keine monatelangen Protokolle erforderlich.
Networkctl zeigt und steuert alle Eigenschaften der Netzwerkadapter und kann die meisten Leistungen externer Netzwerktools wie ip, ifconfig oder vnstat übernehmen. Die nachfolgenden Aufgaben erledigt das Tool weitgehend ohne den (oft inaktiven) Dienst systemd-networkd, aber eventuell mit notorischer Fehlermeldung. Wen diese stört, sollte diesen Basisdienst mit Systemctl starten. Der Befehl
networkctl [list]
zeigt die Schnittstellen. Für einen dort gemeldeten Ethernetadapter „enp2s0“ ermittelt dann
networkctl status enp2s0
alle Parameter von der IP- und MAC-Adresse bis zu MTU, Speed und Gateway-Adresse (Router). Noch ausführlicher ist diese Variante:
networkctl status enp2s0 --stats
Hier meldet der Befehl auch die am Adapter gesendeten und empfangenen Bytes („Rx Bytes“ und „Tx Bytes“). Mit den Unterbefehlen „up“ und „down“ schaltet das Tool einen Adapter ein oder aus.
Resolvectl ist das Verwaltungstool auf Basis des Dienstes systemd-resolved und zuständig für die Auflösung von Rechnernamen zu IP-Adressen. Das ältere Tool systemd-resolve ist aus Kompatibilitätsgründen oft ebenfalls noch vorhanden, sollte aber vermieden werden, wenn resolvectl vorliegt. Die beiden Varianten machen genau dasselbe, unterscheiden sich aber in der Handhabung. Resolvectl macht diverse Netzwerktools überflüssig:
Diese Kommandos liefern den Domain- oder Hostnamen einer IP-Adresse oder umgekehrt die IP-Adresse eines Domain- oder Hostnamens.
Homectl ist vielversprechend und daher eine Erläuterung wert, obwohl es noch nirgends Standard ist. Aktuelle Distributionen haben nämlich den Basisdienst systemd-homed nicht vorinstalliert. Das gleichnamige Paket ist aber optional nachinstallierbar, wonach Homectl verschlüsselte und portable (kopierbare) Home-Verzeichnisse verwalten kann. Systemd-Homes liegen nicht als Verzeichnisse vor, sondern als Images unter /home (theoretisch auch anderswo) und werden bei der Anmeldung des passenden Kontos automatisch in das übliche /home/[user] gemountet. Die Daten kann auch root nicht einsehen. Zum Erstellen eines solchen „Homes“ genügt (Beispiel):
sudo homectl sepp
Das Konto darf noch nicht existieren: Systemd-Homes können also neben üblichen Homes existieren, aber nicht für ein und dasselbe Systemkonto. Wer ein Systemd-Home mit der Absicht anlegt, dieses später auf andere Systeme zu portieren, sollte dessen Größe mit (Beispiel)
sudo homectl resize sepp 200G
von vornherein sinnvoll dimensionieren, denn Homectl erstellt sonst je nach verfügbaren Plattenplatz ein riesiges (leeres) Home-Image, das unnötige Kopiergrößen fordert. Das Benutzerkonto eines solchen Homes wird in aktuellen Distributionen nicht am Anmeldebildschirm auftauchen, muss also dort manuell eingegeben werden. Die weitere Systemnutzung ist dann wie gewohnt.
Das komplette Home liegt als eine einzige Datei „/home/sepp.home“ (Beispiel) vor und kann kopiert und auf ein anderes System übertragen werden. Aus dem Systemd-Konto heraus funktioniert das allerdings nicht: Dieses muss abgemeldet sein, und das Konto, das die Kopie erledigt, muss root/sudo-Recht besitzen. Das Zielsystem wiederum muss natürlich systemd-homed installiert haben. Dann genügt dort die Kopie in das Verzeichnis /home und dieser Befehl:
homectl activate
Danach sollte dort die Anmeldung mit dem kopierten Systemd-Konto gelingen.
Hostnamectl ist funktionsarm und zeigt ohne Parameter
hostnamectl
nur den Hostnamen des Rechners sowie Basisinfos zu System, Kernel und Architektur. Praktisch ist aber dieser Befehl:
hostnamectl set-hostname maxx
Das vergibt umstandslos einen neuen Rechnernamen (hostname).
Loginctl liefert Informationen über die aktuellen Systemanmeldungen:
loginctl [list-sessions]
Mit der hier gelieferten Info der Session-Zahl kann man dann genauer nachfragen (Beispiel):
loginctl session-status 5
Zu den Systemanmeldungen gehört beim Desktopsystem in erster Linie die grafische Oberfläche, zu der es fundamentale Infos wie Anmeldezeit, Benutzerkonto, genutzter Desktop, Displaymanager und Fenstersystem gibt. Anmeldungen auf virtuellen Konsolen oder SSH erscheinen ebenfalls. Über die Befehle
kann eine Anmeldung gesperrt oder gewaltsam beendet werden.
Weitere CTL-Verwaltungstools nennen wir nur noch summarisch: Localectl und Timedatectl zeigen die aktuelle Systemsprache beziehungsweise Zeit und Zeitzone und können diese auch neu einstellen (Beispiel):
localectl set-locale de_DE.UTF-8
Das Werkzeug Bootctl ist nur aktiv, wenn statt Grub die Boot-Methode systemd-boot installiert und verwendet wird. Auf einem laufenden Multibootsystem ist von einer Umstellung dringend abzuraten. Systemd-boot ist zwar schneller, aber bislang kaum automatisiert, sodass eine vorherige Multiboot-Umgebung manuell umgestellt werden muss. Systemd-boot vorausgesetzt, zeigt bootctl (ohne Parameter) detailliert alle Infos zum Uefi-Boot, TPM-Chip, Secure Boot und die installierten Systeme inklusive EFI-Datei.
Busctl ist ein Tool für das Debugging von D-Bus-Kommunikation (Desktop-Bus) und nur für Anwendungsentwickler relevant. Ähnlich speziell ist Machinectl, das die Installation von systemd-container voraussetzt und dann virtuelle Maschinen (nur KVM) verwaltet.
Netzwerkabfragen mit networkctl: Hier wie in vielen anderen Belangen macht ein Systemd-Werkzeug traditionelle Tools weitgehend überflüssig.
Nicht intuitiv, aber spannend: Systemd-homed und sein Tool Homectl erstellen verschlüsselte Home-Container, die bei der Benutzeranmeldung (mit Systemd-Konto) geladen werden.
Die „Systemd-*“-Hilfsprogramme
Die nachfolgenden Tools haben nicht annähernd den Funktionsumfang der größeren CTL-Verwaltungsprogramme. Kennen sollte man sie trotzdem: Besonders die zuerst genannten sind auf jedem Linux-Desktop nützlich.
Systemd-analyze hat gewisse Popularität erreicht, da es Startprobleme und Verzögerungen des Systemstarts offenlegt. Da Systemd die Startzeiten des Systems selbst protokolliert, bietet das Tool die präziseste Kontrolle. Die simpelste Form
systemd-analyze
zeigt nur eine knappe Angabe zur Dauer des Systemstarts, differenziert aber bereits Bios/Firmware, Bootloader, Kernel und Benutzerkonto. Die Befehle
bringen in unterschiedlicher Darstellung die millisekundengenaue Abfolge des Systemstarts, wobei die Option „blame“ für normale Anwender genügen sollte. Die Ausgabe als SVG-Diagramm kann mit jedem Browser gelesen werden.
erscheinen abgeschaltete Dienste („masked“) sowie Konfigurationsfehler in „Override“-Anpassungen.
Anfang und Ende einer Startanalyse: Systemd-analyze entwickelt sich zum Standard, um Startverzögerungen von Linux-Systemen zu entlarven.
Systemd-run ist das Werkzeug, um temporär beliebige Programme zu laden, die dann innerhalb der Systemd-Verwaltung laufen und deren Steuerung gehorchen. Ein Beispiel, um ein grafisches Programm als Scope-Unit anzulegen, hat bereits der vorherige Beitrag gezeigt:
Danach ist der Prozess über die Optionen von systemctl steuerbar. Es geht aber auch direkter, sofern es sich um ein Script oder um ein Hintergrundprogramm handelt: Dann kann vorab einfach die gewünschte Eigenschaft definiert werden:
Das bedeutet, dass die Indexaktualisierung für das Terminalsuchprogramm Locate nur minimale Systemlast (5 Prozent) erzeugen soll. Terminalprogramme mit sichtbarer Ausgabe benötigen ein Pseudo-Terminal („–pty“):
systemd-run --pty --property=MemoryMax=2M htop
Beispiel für systemd-run: Das ist vor allem für größere Terminalroutinen (hier rsync) eine coole Methode, den Ressourcenbedarf zu steuern.
Systemd-mount kann bekannte Werkzeuge wie lsblk und blkid, im Prinzip auch mount weitgehend ersetzen. Der Befehl
systemd-mount –list
zeigt alle Datenträger inklusive UUID, Label, Dateisystem. Die Mount-Pfade zeigt es allerdings nur, wenn Laufwerke mit systemd-mount eingehängt wurden. Für aktives Mounten mit systemd-mount gibt es zahlreiche Optionen ähnlich dem klassischen mount, wobei aber auch einfachste Varianten funktionieren:
systemd-mount /dev/sdb1 /mnt/usb4TB
Für das Aushängen muss dann der Befehl systemd-umount
systemd-umount /mnt/usb4TB
genutzt werden, weil das klassische umount die so eingehängten Datenträger nicht kennt.
Systemd-cgtop ist der Prozessmonitor von systemd, der den Verbrauch von Systemd-Control-Groups zusammenfasst, also den Ressourcenverbrauch von „User“- und „System“-Units. Einzelne Anwendungsprogramme erscheinen hier nicht. Die Sortierung nach CPU, RAM, IO-Last lässt sich per Parameter ebenso steuern wie das Update-Intervall. Ohne Parameter gestartet
systemd-cgtop
sortiert das Tool nach CPU-Last. Relevant ist solche Kontrolle praktisch nur auf Linux-Servern, wo die Lastverteilung zugunsten eines Serverdienstes optimiert werden soll. Wie das mit „systemctl set-property“ oder durch Editieren von Unit-Dateien erfolgt, ist im vorangehenden Beitrag skizziert.
Systemd-delta ist hauptsächlich für Admins relevant, die tief in der Systemd-Konfiguration stecken und eigene Units erstellt oder Anpassungen vorgenommen haben. Der Befehl
systemd-delta
liefert einen detaillierten Überblick über zeigt abgeschaltete Units („masked“), originale Zustände („equivalent“) und sämtliche Konfigurationsänderungen („overridden“) im Detail. Die Anzeige abgeschalteter Units kann auch für normale Desktop-Nutzer relevant sein, die zwar keine Dienste geändert, aber mit systemctl mask […] abgeschaltet haben.
Kleiner, feiner Helfer: Systemd-delta verschafft Durchblick bei geänderten Systemdiensten.
Weitere systemd-Hilfsprogramme sind ganz unscheinbare kleine Systemtool wie Systemd-path. Der einfache Befehl
systemd-path
kennt keine weiteren Schalter und liefert eine detaillierte Übersicht über allgemeine Systemordner und spezielle Systemd-Pfade. Ein weiteres Mini-Tool Systemd-cat kann für Systemnotizen nützlich sein. Eigentlich ist systemd-cat ein interner Befehl für systemd-Dienste, um an das Journal zu berichten. Der Benutzer kann das aber auch manuell tun:
systemd-cat cat /etc/fstab
Hier wird der aktuelle Inhalt der Datei fstab an das Journal angehängt und kann später mit journalctl jederzeit wieder abgefragt werden. Hierbei kann man sogar mit Schalter „-p“ Priority-Levels (0 bis 7) mitgeben. Ebenfalls eher marginal ist Systemd-tmpfiles, das mit dem Schalter „—clean“ einige temporäre Dateien beseitig.
Systemd-Units erstellen
Das Anlegen von einfacheren Timer-, Service- oder Mount-Units unter Systemd ist keine Geheimwissenschaft, braucht aber Übung und nicht selten korrigierende Detailrecherche. Systemd fordert Präzision und ist nicht auskunftsfreudig, wenn etwas nicht funktioniert. Wer aber die Prinzipien einmal beherrscht, wird durch zahlreiche Zeitoptionen, neue Möglichkeiten der Systemautomatisierung und minutiöse Details der Prozesssteuerung belohnt.
Jede Menge Anschauungsmaterial Bevor man den ersten eigenen Timer oder Service baut, ist der Blick in vorhandene und funktionierende Beispiele nützlich. Der erste Artikel (ab Seite 40) hat nur gezeigt, wie systemctl edit […] Detailänderungen erledigen kann. Wer eine Unit-Datei nur lesen will, verwendet (Beispiel)
systemctl cat samba.service
und der Befehl
sudo systemctl edit --full samba.service
erlaubt Änderungen an der Originaldatei (statt eine zusätzliche Override-Anweisung anzulegen).
Die Durchsicht einiger Dateien mit systemctl cat ist für Einsteiger zwiespältig: Unit-Dateien sind kurz und mit ihrer Sektions-Struktur gut lesbar. Andererseits finden Sie in jeder Datei andere und neue Anweisungsdirektiven, deren Bedeutung und Relevanz sich nicht erschließt. Es ist keine schlechte Idee, mit Timer-Units zu starten. Erstens sind zeitgesteuerte Jobs ein häufiges Anliegen, zweitens sind die Unit-Dateien für Timer recht leicht nachvollziehbar: Die Sektions-Struktur „[Unit]“ (so beginnt jede Unit-Datei), „[Timer]“ (das ist der Unit-Typ und kann auch Service, Mount, Automount lauten) und „[Install]“ ist zuverlässig, und die ganze Datei enthält oft nur eine Handvoll relevanter Anweisungen. Unter „[Install]“ steht bei (System-) Timern immer:
[Install]
WantedBy=timers.target
Da oben unter „[Unit]“ nur die Zeile „Description=“ notwendig, aber beliebig zu füllen ist, geht es letztlich nur noch um die Zeitangaben unter „[Timer]“.
Timer: So einfach wie möglich
Der sicherste Weg, eigene Unit-Datei anzulegen, ist dieser Aufruf (Beispiel)
sudo systemctl edit --full --force auto-off.timer
Dann müssen Sie sich nicht um den richtigen Ort kümmern, und Systemctl öffnet eine temporäre Datei.#auto-off.timer[Hex-Ziffer], die nach dem Speichern /etc/systemd/system/auto-off.timer heißen wird. Hier tragen Sie die drei Sektionen „[Unit]“ mit beliebiger „Description“, „[Timer]“ und „[Install]“ mit der Standardanweisung „WantedBy=timers.target“ ein. Die Zeitangabe unter „[Timer]“ erledigen Sie mit der Anweisung „OnCalendar=“. Es gibt viele absolute und relative Zeitangaben, die Systemd-Timer akzeptieren. In diesem Beispiel tragen wir
OnCalendar=*-*-* 23:00:00
ein. Das bedeutet „jedes Jahr, jeden Monat, jeden Tag“ um 23 Uhr. Das ist schon alles, denn Systemd vermischt nichts: Was zu diesem Zeitpunkt konkret geschehen soll, muss in einer anderen Unit-Klasse definiert werden – als Service. Die Beziehung zwischen Timer und Service ist in den beiden Unit-Dateien nicht definiert. Sie entsteht schlicht dadurch, dass der Dateiname der Service-Unit exakt identisch sein muss mit jenem der Timer-Unit (hier „auto-off“) – daher:
In diese Datei muss nur der Titel „[Unit]“ mit der zweiten Zeile „Description=“ (Inhalt beliebig), darunter die Sektion „[Service]“ mit der Anweisung „ExecStart=“. Das ist der Befehl, der zu dem Zeitpunkt ausgeführt werden soll, die im Timer definiert ist. Dieses Beispiel fordert mit
ExecStart=/usr/sbin/rtcwake -m off -s 28800
einen Shutdown des Systems, das acht Stunden später wieder starten soll (28800 Sekunden). Da der Shutdown um 23 Uhr erfolgt, läuft das System um 7 Uhr wieder an.
Das Beispiel mit Rtcwake ist vielleicht nicht das einfachst mögliche, alle Systemd-betreffenden Anweisungen sind aber auf das absolute Minimum reduziert, was ein funktionierender Timer benötigt. Sie müssen nach dem Speichern von Timer- und Service-Unit den Timer lediglich noch scharf schalten. Dies ist nur einmal zur Ersteinrichtung erforderlich:
Um die Service-Unit müssen Sie sich nicht kümmern, das erledigt der Timer zur gegebenen Zeit. Die beiden neuen Units werden nach
systemctl status auto-off.timer
systemctl status auto-off.service
für den Service melden, dass er aktuell „tot“ ist, aber „Triggered“ vom Timer. Der Timer hingegen meldet sich als „aktiv“ und zeigt eine Frist, wann er den Service starten wird.
Shutdown-Timer: Die wenigen Zeilen für Timer und Service sind weitgehend selbsterklärend. Der Timer feuert täglich um 23 Uhr, der Service enthält den nötigen Befehl.
Timer: Elaborierte Optionen und User-Kontext
Systemd-Timer kennen neben festen „OnCalendar=“-Zeiten zahlreiche relative Angaben wie „OnBootSec=10m“ (Beispiel für einen Timer, der 10 Minuten nach Anmeldung zuschlägt). Für periodische Wiederholungen gibt es vereinfachte Angaben wie „hourly“, „daily“, „weekly“ (also etwa „OnCalendar=daily“). Sehr hilfreich ist ferner, dass man mehrere „OnCalendar=“-Zeilen untereinander setzen. Und noch ein entscheidender Vorteil gegenüber Cron: Die Anweisung
Persistent=true
unterhalb der Sektion „[Timer]“ erledigt das, wofür neben Cron noch der Hilfsdienst Anacron arbeiten muss: Sie sorgt dafür, dass ein Termin nachgeholt wird, falls der Rechner zum geplanten Timer-Zeitpunkt nicht eingeschaltet war.
Das folgende Beispiel geht auf weitere Timer-Details nicht näher ein, führt aber ein bislang vernachlässigtes Großthema ein. Die Aufgabe des Beispiel-Timers scheint einfach: Ein Systemd-Timer soll an jedem Monatsbeginn durch ein „notify-send“ an die Erledigung der Umsatzsteuervoranmeldung erinnern. Notify-send ist ein grafisches Tool und muss daher im Benutzerkontext laufen (theoretisch kann auch ein System-Timer plus Service grafische Programme starten, aber das ist knifflig und unzuverlässig).
Systemd-Timer und Dienste können auch mit Benutzerrecht angelegt und genutzt werden. Es funktionieren alle erläuterten Systemctl-Kommandos, hier aber ohne „sudo“ und mit dem Schalter „–user“. Beim Erstellen überlässt man die Wahl des richtigen Pfades am besten wieder Systemctl:
systemctl --user edit --full --force ustva.timer
Wie bei einer System-Unit erfolgt die Erstellung (oder Nachbearbeitung) der Init-Datei mit einer temporären Datei, hier im User-Pfad ~/.config/systemd/user. Als die ersten beiden Zeilen stehen wieder das obligatorische „[Unit]“ und eine „Description“. Unter „[Timer]“ könnte nun etwa
folgen, um den Timer am ersten Tag jeden Monats um 10:00 auszulösen. Die „Persistent“-Zeile sorgt dafür, dass der Timer nachgeholt wird, falls der Rechner an diesem Ersten des Monats nicht läuft. Um die Flexibilität der Timer-Units zu zeigen, ändern wir den Zeitplan insofern, dass der Timer nur noch quartalsweise zuschlagen soll (Januar, April, Juli, Oktober). Das sind für kleine Solo-Selbständige die üblichen Termine für die Umsatzsteuer. Das ist ganz einfach mit diesen vier Zeilen erledigt:
[Unit]
Description=Umsatzsteuer-Voranmeldung
Wants=graphical.target
After=graphical.target
[Service]
ExecStart=/usr/bin/notify-send "Umsatzsteuer bis 10. des Monats erledigen!"
Da ein grafisches Programm ausgelöst wird, ist in der Unit-Sektion das „graphical.target“ als benötigt (Wants) und gestartet (After) angegeben.
Timer-Test: Ob Timer und Dienst funktionieren, kann man am einfachsten durch zusätzliche Dummy-Termine ermitteln, die man danach wieder entfernt.
Path-Unit für Auto-Backup
Path-Units von Systemd können Ordner überwachen und Aufgaben automatisch auslösen, sobald sich Ordnerinhalte ändern. Die Kombination von Path-Unit und gleichnamiger Service-Unit ist ganz ähnlich wie bei Timer und Service, nur dass hier der Auslöse-Trigger kein zeitlicher, sondern eine Änderung im Dateisystem ist. Path-Units sollten gut überlegt sein, weil allzu umfangreiche Aktionen in frequentierten Ordern hohe und vielleicht unnötige Systemlast erzeugen. Bei Systemd muss man sich aber immerhin keine Gedanken machen, dass ein Service mehrfach läuft: Dies verhindert Systemd automatisch. Unser Beispiel zeigt, wie sich mit einer Path-Unit mehrere wichtige Ordner so überwachen lassen, dass bei allen Änderungen automatisch ein Rsync-Backup ausgelöst wird.
Der erste Schritt ist wieder das Erzeugen der Unit-Datei, hier mit
sudo systemctl edit --full --force auto-sync.path
für die Path-Klasse. „[Unit]“-Header und „Description“ oben sind problemlos, unter „[Install]“ binden wir die Unit an das multi-user.target:
WantedBy=multi-user.target
Das liegt bei der hier genutzten Serverplatine nahe, genügt aber auch bei einem Desktopsystem, weil der Vorgang keine grafischen Ressourcen benötigt. Wesentlich sind die Pfadangaben nach „PathChanged=“. Wie die Abbildung zeigt, sind diverse solche Einträge möglich und oft sinnvoll, weil Path-Units keine Unterverzeichnisse berücksichtigen. „PathChanged“ reagiert auf alle Datenänderungen im angegebenen Pfad.
Notwendig – und im Vergleich zu Timer-Units etwas irritierend – ist in der Sektion „[Path]“ die explizite Angabe der zugehörigen Service-Datei (mit gleichem Namen):
die Service-Datei an. Unser Beispiel sichert per SSH auf ein anderes Gerät im Netzwerk und erfordert daher ein geladenes „network.target“, was in der ersten Sektion unter „[Unit]“ vermerkt wird. Die entscheidende Anweisung unter „[Service]“ ist wie üblich „Exec-Start=“. Die beiden weiteren Anweisungen sind optional, aber sinnvoll: Sie begrenzen die Systemlast der Aktion („CPUQuota“) und stellen mit „ExecCondition=“ eine Bedingung:
ExecCondition=/usr/bin/ping -c 1 192.168.0.110
Wenn der Rechner mit der genannten IP nicht erreichbar ist, stoppt der Service sofort. „ExecCondition“ ist sehr flexibel, insofern es den Exitcode ($?) eines beliebigen Bash-Tools auswertet. Nur bei Exitcode „0“ startet der Dienst.
Nach dem Speichern der beiden Unit-Dateien folgt wieder die übliche Einrichtung:
Die Service-Unit wird nicht aktiviert. Das erledigt künftig die Path-Unit automatisch, sobald sich in den hinterlegten Pfaden etwas ändert.
Path-Unit mit zugehörigem Service: Systemd überwacht hier einige Ordner und startet bei Änderungen automatisch eine Rsync-Sicherung.
Automount: Wozu ist das gut?
Die Datei /etc/fstab scheint eine Altlast, nachdem Systemd deren Laufwerkeinträge schon seit vielen Jahren in seine eigenen Mount-Units übersetzt (systemd-fstab-generator). Da aber von der Umstellung der systemkritischen Verzeichnisse Root (/) und Boot (/boot) auf Systemd-Mount-Units nach wie vor abgeraten wird, behält die fstab vorerst weiter ihr Existenzrecht. Damit bringt es keinen Vorteil, Datenlaufwerke aus der fstab zu nehmen und explizit als Systemd-Mount umzuwandeln.
Gute Motive für Mount- und Automount-Units gibt es aber für mobile USB-Datenträger. An das Automount von grafischen Systemen unter /media/[User] kann man sich sicher gewöhnen, aber vielleicht will man den Mountpunkt selbst bestimmen? Noch überzeugender ist ein Mount-Automount-Gespann auf einem (Platinen-) Server ohne Desktop: Wer hier alle paar Wochen mal ein bestimmtes USB-Gerät anschließen will, kommt an einem manuellen Einhängen nicht vorbei. Das kann Systemd deutlich vereinfachen.
Eine Automount-Unit benötigt immer eine zugehörige Mount-Unit mit demselben Namen. Automount ist – ähnlich wie Timer und Path – ein wartender Trigger, der beim Eintreten des Ereignisses die eigentliche Mount-Unit auslöst. Das Ereignis ist in diesem Fall der Zutritt in das Mount-Verzeichnis – ob per Klick im Dateimanager oder per Terminalbefehl (cd, ls, mc…), spielt dabei keine Rolle.
Eine erste wichtige Vorbereitung ist der Mount-Pfad. Der sollte sprechend, aber nicht lang und kompliziert sein (Leerzeichen besser vermeiden), weil die Unit-Dateinamen den Pfad exakt wiedergeben müssen. Für einen Mountpfad /srv/Archiv wäre dann die Unit-Namen srv-Archiv.mount und srv-Archiv.automount zutreffend. Im Zweifel liefert Systemd sogar das Mini-Tool
systemd-escape "/srv/Archiv/"
mit, um für einen Pfad den korrekten Unit-Namen zu ermitteln. Ist der Mountpfad angelegt, kann der Automount-Trigger erstellt werden (hier im System-Kontext):
Die wenigen Zeilen können Sie der Abbildung entnehmen. Entscheidend ist die Pfadangabe nach „Where=“, den die Unit künftig überwacht. Die Option „TimeOutIdleSec=“ ist optional, aber ressourcensparend. Unter „[Install]“ wird die Unit an das multi-user.target gebunden, was auch am grafischen Desktop ausreicht. Danach erstellt der Befehl
die zugehörige Mount-Unit. Die Angabe „Where=“ muss erneut den gewünschten Mountpfad definieren, während „What=“ die Hardware bezeichnet: Besser als etwa „/dev/sdb1“ ist die eindeutige UUID, die man vorher mit lsblk -f ermittelt. Der Rest ist nicht viel anders als beim Mount-Befehl oder in fstab. Auf grafischen Systemen ist bei den „Options=“ der zusätzliche Eintrag „x-gvfs-show“ keine schlechte Idee, weil der Dateimanager Systemd-Automounts nur dann in der Navigation anzeigt. Die Mount-Unit erhält keine „[Install]“-Sektion, da sie ausschließlich von der komplementären Automount-Unit gestartet wird.
Nach dem Speichern der Dateien müssen Sie den Automount-Trigger noch scharf schalten. Daher folgt abschließend die übliche Ersteinrichtung der Unit:
Um die Mount-Unit müssen Sie sich nicht weiter kümmern.
Was passiert künftig, wenn Sie das USB-Laufwerk anschließen? Gar nichts – denn Automount ist keine Hardware-Erkennung, sondern eine Ordnerüberwachung. Erst sobald der Mount-Pfad betreten, wird die Mount-Unit ausgelöst und – mit leichter Verzögerung – stehen die Inhalte des Datenträgers zur Verfügung. Sehr praktisch! Noch ein Hinweis: Wenn Sie mit dem Tool
systemd-unmount /srv/Archiv/
das Laufwerk auswerfen, wertet Systemd dies als Ansage, dass Sie die Automount-Unit nicht mehr brauchen und deaktiviert sie.
((303_4_Automount.png))
Automount- und Mount-Unit: Besonders praktisch ist diese Methode bei Servern ohne Desktop für USB-Geräte, die nicht dauerhaft angeschlossen sind.
SYSTEMD–Unit-Dateien
DIE WICHTIGSTEN REGELN
[Unit]
SEKTION 1 (notwendige und statische Startzeile „[Unit]“)
Description=
notwendig, aber Inhalt beliebig
Requires= | After= | Wants=
optionale Target-Angaben, falls die Unit z. B. „network.target“ oder „graphical“ benötigt
[Service] | [Timer] | [Path] | Mount]
SEKTION 2: Angabe der Unit-Klasse
[Service]
ExecStart=
notwendig: zu startendes Programm
Type=
optional, Standard „simple“ genügt oft
WorkingDirectory=
optional, aber oft nützlich, um Shellscript zu ersparen
Restart=
optional: z. B. „on-failure“, um den Dienst nach Fehler neu zu starten
ExecCondition=
optional: Shell-Befehl wie ping o. test, der Errorcode liefert (Dienst startet nur bei $?=0)
User= | Group=
optional: höhere Sicherheit, weil der Systemdienst dann nur in diesem Konto laufen darf
[Timer]
OnCalendar=
notwendig ist mindestens eine Zeitangabe, z. B. „–-* 15:00:00″ oder „hourly“
OnBootSec=
alternative relative Zeitangabe – etwa „20m“ (20 Minuten nach Anmeldung)
Persistent=
optional: „true“ holt den Timer nach, falls der Rechner zur geplanten Zeit nicht lief
[Path]
PathChanged=
notwendig ist mindestens eine Pfadangabe, „PathChanged“ reagiert auf alle Änderungen
PathExistsGlob=
erlaubt Filter nach Dateinamen oder Extensionen – etwa „/srv/data/*.pdf“
[Mount]
What=
notwendig: Gerätekennung wie „/dev/sda1“ oder „UUID=[…]“
Where=
notwendig: Mountordner im Dateisystem
Type=
optional, aber zu empfehlen: Dateisystem wie „ext4“ oder „ntfs“
Options=
optional, aber oft notwendig – etwa „username=sepp,password=sepp“
[Automount]
Where=
notwendig: muss exakt der Where-Zeile in der zugehörigen Mount-Unit entsprechen
TimeOutIdleSec=
optional: Abschaltzeit, falls kein Zugriff stattfindet – etwa „600“ (10 Minuten)
[Install]
SEKTION 3: Unit installieren (an Target binden)
WantedBy=
Target-Klasse wie multi-user.target oder timers.target
Das angegebene Target erhält einen Symlink zu dieser Unit und startet es mit.
Sektion 3 entfällt bei Mount-Units und Services, die von Timer- oder Path-Units gestartet werden
Seit Erscheinen des Raspberry-Modells 4 ist es für andere Platinenhersteller eine echte Herausforderung, zu einem angemessenen Preis ein überzeugendes Konkurrenzprodukt anzubieten. Der neue Odroid M1 will mit Sata-3-Port und NVMe-Slot punkten.
Die Platinenfamilie Odroid des koreanischen Herstellers Hardkernel (www.hardkernel.com) gehört seit Jahren zu den größten Raspberry-Konkurrenten. Die Odroid-Hardware ist robust und in der Regel ausgewogen konzipiert. Das einfache Grundkonzept war schon immer, für etwas mehr Geld mehr Leistung als der gerade aktuelle Raspberry zu liefern oder andere Anschlussmöglichkeiten als dieser. Die bisherige Palette mit Odroid XU4, Odroid HC4, Odroid N2 und Odroid H3 wird neuerdings ergänzt durch die Platine Odroid M1.
Odroid M1: Schnell ausverkauft
Mit 160 Euro muss man mindestens rechnen, sofern man neben der eigentlichen Platine (etwa 120 € oder 140 € mit 4 GB oder 8 GB RAM) das unentbehrliche Netzteil (etwa 7 Euro), ein Gehäuse (etwa 13 Euro) und ein Kabel- und Montage-Set für Sata (etwa 13 Euro) benötigt. Und Achtung: Dies waren die Preise einschlägiger Elektronik-Versandhändler wie Pollin oder Reichelt im April und Mai 2022. Seit der Odroid M1 in erster Marge schnell vergriffen war, stiegen umgehend die Preise.
Die nachfolgenden Eckdaten versprechen in der Tat ein besonders flott laufendes Betriebssystem dank Installation auf NVMe, Sata oder eMMC sowie einen rasanten Serverbetrieb dank Sata-Laufwerk. Ein Sorglospaket für Einsteiger ist die Platine im Unterschied zum universellen Raspberry 4 indes nicht: WLAN- und Bluetooth-Chip fehlen, beim Einsatz eines Sata-Laufwerks gibt es Bedingungen, die man vorab kennen sollte, und auch bei USB ist nicht jede beliebige Anschlussoption möglich. Nicht zuletzt gibt es vorläufig nur ein schmales Angebot bei der Systemsoftware, sodass der Käufer bei der Auswahl des Betriebssystems eventuell Kompromisse eingehen muss. Aber das lohnt die Hardware allemal.
Anschlussfreudiger Odroid M1: Die Standardports oben bieten Gigabit-Ethernet, HDMI, je zweimal USB 2.0 und USB 3.0. Darunter gibt es den Slot für eine NVMe-SSD, rechts unten Sata-Datenport und Sata-Stromversorgung, unten Mitte den eMMC-Anschluss. GPIO-Pins und Audio-Klinkenbuchse sind ebenfalls vertreten.
Odroid M1: Die technischen Eckdaten
Die ARM-Hardware läuft mit einem leicht angepassten Rockchip-Prozessor (RK3568B2) mit vier Cortex A55-Kernen und einer Taktfrequenz von knapp 2 GHz. Diese CPU bringt die Platine in die Liga des Raspberry 4, erreicht dessen Leistung aber nicht ganz (siehe Kasten „Mini-Benchmark“ auf der letzten Seite). Für den festverbauten LPDDR4-Arbeitsspeicher gibt es zwei Varianten der Platine mit vier oder acht GB RAM. Der Preisunterschied beträgt gut 20 Euro. Nach unserer Marktbeobachtung wurde die 8-GB-Variante am schnellsten ausverkauft und fordert derzeit auch die längeren Wartezeiten auf die nächsten Margen. Im Prinzip sollten für typische Serverrollen im Heimnetz aber auch vier GB RAM völlig ausreichen.
Für den Netzwerkanschluss ist ein Gigabit-Ethernet-Port vorhanden und zur Monitorausgabe ein HDMI-Anschluss. Für die sehr ordentliche bis gute Soundausgabe kann neben HDMI auch ein 3,5-Millimeter-Klinkenstecker dienen. Für Bastler und Industrieeinsatz kommt ferner noch ein DSI-Anschluss für einen kleinen LCD-Bildschirm hinzu. Ebenfalls für Bastlerprojekte kann eine Kamera über CSI angeschlossen werden. Auch die vom Raspberry bekannte 40-Pin-GPIO-Leiste ist verbaut.
Interessant für den Servereinsatz wird es bei den Anschlüssen für Datenträger: USB darf nicht fehlen und ist im Prinzip fünfmal vertreten – zweimal USB 3.0, zweimal USB 2.0 sowie ein Micro-USB-Anschluss (OTG). Der untere der beiden USB-3.0-Ports wird allerdings deaktiviert, falls der kleine OTG-Anschluss genutzt wird. Das ist kein großes Limit, aber man sollte dieses Detail nicht vergessen. Für an USB 3.0 angeschlossene Laufwerke gilt wie bei allen ähnlichen Platinen die Empfehlung, besser Datenträger mit eigener Stromversorgung anzuschließen. Zwei 2,5-Zoll-Laufwerke an USB und eventuell noch ein zusätzliches Sata-Laufwerk kann das Netzteil der Platine nicht stabil versorgen.
Das optionale Sata-Laufwerk versorgen die zwei Standardanschlüsse für das Daten- und das Stromkabel. Letzterer ist ein 5-Volt-Anschluss für 2,5-Zoll-HDDs oder SSDs. Eine große 3,5-Platte mit 12-Volt-Anschluss kann die Platine folglich nicht versorgen, diese müsste dann also mit externem Netzteil betrieben werden. Das von Hardkernel angebotene Sata-Montage-Set für circa 13 Euro umfasst nur die beiden Standardkabel und einen Hartplastik-„HDD-Holder“, um die Sata-Platte mit der Platine zu verschrauben. Das Zubehör ist verzichtbar, sofern Standardkabel vorliegen und der Datenträger nicht befestigt werden muss.
Für das Betriebssystem (oder Daten) gibt es neben dem üblichen Slot für eine Micro-SD-Karte und dem Sata-Laufwerk noch weitere Optionen: Es ist ein eMMC-Slot vorhanden (Embedded Multimedia Card) sowie ein Anschluss für ein SSD-Laufwerk vom Typ NVMe M.2. Letzteres muss eine PCIe-NVMe sein, eine NVMe mit Sata-Controller funktioniert dort nicht.
Odroid M1 mit NVMe-SSD im M.2-Slot: Es muss sich um eine PCIe-SSD handeln (Stichwort „M-Key“ oder „Key M“). Ebenfalls im M.2-Faktor erhältliche Sata-Laufwerke funktionieren nicht.Odroid M1 mit montierter SSD: Das Montage-Set für etwa 13 Euro ist unter Umständen entbehrlich, wenn Sata-Standardkabel vorrätig sind. Das Standardgehäuse ist bei einem Sata-Einbau in jedem Fall überflüssig, weil es dafür keinen Platz bietet.
Wichtige Infos zur Systeminstallation
Auf https://wiki.odroid.com/odroid-m1/odroid-m1 gibt es bislang nur einige wenige Systemimages zum Download (siehe dort „os_images“), die dann mit einschlägigen Tools wie Etcher oder Gnome-Disks auf SD-Karte zu übertragen sind. Zum Redaktionsschluss war die Auswahl verfügbarer System noch sehr bescheiden und überdies unglücklich gewählt: Wer – naheliegend – die Hardware für Serveraufgaben nutzen will, wird nicht unbedingt zu Android 11 greifen. Ansonsten gibt es ein Ubuntu 20.04 ausgerechnet mit der anspruchsvollen Gnome-Oberfläche, die für die Hardware nicht angemessen erscheint. Zum Zeitpunkt des Produkttests erschien uns daher als einzig passende Wahl ein purer Ubuntu Server 20.04, auf den wir anschließend ein sparsames XFCE nachinstallierten. Die Zugangsdaten für fertige Odroid-Images lauten seit jeher „odroid“ mit Kennwort „odroid“.
Klassische Images auf https://wiki.odroid.com: Dieser Weg eignet sich nur für den Transport auf SD-Karte. Eine Installation auf Sata oder NVMe muss über das Minisystem Petitboot erfolgen.
Diese traditionelle Systembestückung für Platinenrechner ist aber auf SD-Karten (eventuell noch eMMC) beschränkt. Wer das System auf Sata oder NVMe installieren will, muss einen anderen Weg einschlagen. Und dieser Weg erweist sich insgesamt als der klügere, weil er ein sauberes System ohne „odroid“-Konto, eine größere Systemauswahl, eine individuelle Desktop-Auswahl und vor allem die freie Wahl des Systemdatenträgers eröffnet.
Beim Start der Platine (mit oder ohne installiertes Betriebssystem) meldet sich das integrierte Minimalsystem Petitboot, das einige wesentliche Systeminfos anzeigt und ferner eine Multiboot-Auswahl des Betriebssystems erlaubt (falls etwa auf SD, Sata und NVMe verschiedene Systeme bereitstehen). Entscheidender ist aber die Fähigkeit von Petitboot, Betriebssysteme über das Internet zu laden und zu installieren. Diese Fähigkeit wird bei Hardkernel- oder Vertreiber-Dokumentationen lapidar vorausgesetzt, ist aber bislang nirgendwo prominent dokumentiert.
Um die im Netz verfügbaren Systeme aufzulisten, müssen Sie in Petitboot zunächst die unterste Option „Exit to shell“ wählen und dann die folgenden zwei Befehle eingeben:
udhcpc
netboot_default
Der erste stellt die Verbindung zum Netzwerk sicher, der zweite setzt die Bootpriorität auf die Netzwerkinstallation. Nach „exit“ und Verlassen der Mini-Shell zeigt das Petitboot-Menü oben die verfügbaren Betriebssysteme. Dies sind mehr als die Downloadseite als traditionelle Images anbietet, allerdings ist von Kandidaten mit dem Hinweis „Work in Progress“ oder „Experimental“ eher abzuraten, da dies in unserem Fall prompt in einem fatalen Boothänger nach dem ersten Systemstart endete. Zum Zeitpunkt dieser Recherche waren nur Ubuntu 20.04 und Debian 10 als stabile Kandidaten erreichbar. Mindestens Ubuntu 22.04 und Debian 11 werden umgehend folgen.
Die weiteren Vorteile dieser Installationsweise sind offensichtlich: In den bekannten, textbasierten Installern von Ubuntu und Debian sorgen Sie vorab für eine saubere Lokalisierung des Systems, für ein individuelles Systemkonto und entscheiden gegen Ende der Installation im Tasksel-Dialog über Desktop und gewünschte Serverdienste (SSH, Apache). Für den Systemdatenträger gibt es beim Partitionierungsdialog kein Verbot – SD-Karte, NVMe-, Sata-, eMMC- oder auch USB-Laufwerke sind möglich.
Besser und flexibler als ein Image-Download: Im integrierten Odroid-Minimalsystem können Sie die Netboot-Option freischalten und dann das gewünschte System aus dem Internet beziehen.Mit Petitboot gestarteter Netinstaller (hier Debian): Damit bringen Sie das Betriebssystem auf jedes beliebige Laufwerk, das an der Odroid-Platine angeschlossen ist.
Odroid M1: Praxis, Tipps und Einordnung
Die Platine arbeitet lüfterlos und somit absolut lautlos. Ähnlich dem Odroid N2 sitzt die gesamte Hardware auf einem großen passiven Kühlkörper, und nach Ausweis des Sensor-Tools des von uns genutzten XFCE-Desktops erreicht die Platine selbst bei Last kaum 40 Grad. Dies bestätigen auch eine haptische Kontrolle sowie der sehr niedrige Stromverbrauch: Wir messen etwa zwei Watt im Leerlauf und bringen den Odroid M1 selbst unter hoher Last nicht über 3,5 Watt Leistungsaufnahme – eventuelle mechanische Laufwerke oder Displays sind hier natürlich nicht eingerechnet.
Tipp zur Desktop-Wahl: Sofern man dem allzu anspruchsvollen Desktop Gnome aus dem Weg geht, arbeitet der Mini-Rechner mit einem XFCE, LXDE oder LXQT jederzeit auch mit grafischer Oberfläche flüssig. Selbst für einen Odroid M1 in reiner Serverrolle empfehlen wir die Installation eines Desktops, der dann per HDMI oder VNC neben der SSH-Fernwartung auch eine bequeme Oberfläche anbietet. Bei vier oder sogar acht GB RAM fällt der meist ungenutzte Desktop kaum ins Gewicht.
Tipp für Datenfreigaben: Mechanische Sata-HDDs, auch wenn sie ausschließlich als Datenfreigabe dienen, sollten unbedingt mit dem Standarddateisystem Ext4 formatiert werden. Das von Hardkernel früh angebotene Ubuntu 20.04 hat einen relativ betagten Kernel mit mäßiger NTFS-Unterstützung. Der Datendurchsatz kommt damit kaum über 30 bis 40 MB/s und liegt damit sogar unter den etwa 80 MB/s, die per USB angeschlossene Datenträger erreichen. Es wäre daher kontraproduktiv, die M1-Platine wegen der Sata-Schnittstelle zu erwerben und dann mit NTFS auszubremsen. SSDs am Sata-Port sind hingegen mit jedem beliebigen Dateisystem schnell genug, um im Gigabit-Netzwerk die Daten mit den maximalen 110 bis 120 MB/s auszuliefern.
Tipp zum Zubehör: Für den Odroid M1 gibt es ein hübsches, blaues Aluminiumgehäuse, das als Staubschutz prinzipiell zu empfehlen wäre. Es wird einfach auf die passende Rille des großen Kühlkörpers aufgeschoben und dann auf beiden Seiten mit Endabdeckungen verschraubt. Ganz zu Ende gedacht ist das nicht, weil sich das Gehäuse mit dem interessantesten Hardware-Angebot der Platine nicht verträgt: Ein Sata-Laufwerk bringen Sie nämlich nicht unter, wenn Sie das Gehäuse nutzen. Es ist nicht einmal möglich, die Sata-Kabel nach außen zu legen und das Laufwerk außerhalb zu nutzen, denn allein schon die eingesteckten Sata-Kabel machen es unmöglich, das Gehäuse auf die Platine zu schieben. Kurz: Wer vorhat, am Odroid M1 ein Sata-Laufwerk anzuschließen, kann sich den Kauf des Gehäuses von vornherein sparen.
Einordnung: Im Umfeld des Raspberry Pi 4 und den weiteren aktuellen Odroid-Platinen wird das Modell Odroid M1 aufgrund seiner Flexibilität mühelos seinen Platz finden. Daran lässt sich praktisch alles anschließen und einbauen, was man in der Schublade liegen hat. Da wird dann die kleine SSD, die für den Desktoprechner längst unterdimensioniert war, zum idealen Systemdatenträger. Als Datenserver garantiert die Platine jederzeit volle Gigabit-Leistung (120 MB/s), wenn die Daten auf einem Sata-Laufwerk liegen. Laufwerke an USB 3.0 liefern die Daten nicht schneller, aber auch nicht langsamer aus als beim Raspberry Pi 4 – also je nach Datengrößen mit 60 bis 90 MB/s.
Mini-Benchmark mit Raspberry und Odroid
Ein kleiner Vergleich mit der simplen arithmetischen Iteration
time $(i=0; while (( i < 9999999 )); do (( i ++ )); done)
auf etlichen Geräten ordnet die CPU-Leistung des neuen Odroid M1 ganz gut ein. Diese primitive Methode haben wir gewählt, weil auf den diversen Geräten mit diversen Betriebssystemen eine andere einheitliche Methode zu viel Aufwand erfordert hätte. Über die Aussagekraft des simplen Benchmarks lässt sich streiten, aber die Rangfolge deckt sich mit unserer praktischen Alltagserfahrung mit diesen Geräten. Der Raspberry Pi 4 liegt vor der neuen Odroid-Platine, deutlicher noch der Odroid N2 und der nicht mehr erhältliche Odroid H2. Der Fokus des neuen Raspberry-Konkurrenten Odroid M1 liegt eindeutig beim Angebot der Datenträgeranschlüsse, nicht bei der CPU-Leistung.
Das jüngste Endeavour OS 22.6 (ab hier kurz „EOS“) hat vor allem die ARM-Unterstützung für Raspberry- und Odroid-Platinen ausgebaut. EOS ist Nachfolger des eingestellten Antergos und hat denselben Anspruch wie das bekanntere Manjaro, nämlich mit einem grafischen Installer den Zugang zu Arch Linux zu vereinfachen.
Laut Distrowatch hat EOS Manjaro inzwischen den Rang abgelaufen und liegt aktuell auf Platz 2 vor Mint, Manjaro, Ubuntu, Debian & Co. Generell scheinen Arch-Derivate und deren Rolling-Release-Modell derzeit hoch im Kurs: Sie gelten als besonders schnell und stets aktuell. Nachteile sind gelegentliche Paketkonflikte, eine Fokussierung auf das Terminal und eventuell nicht vollständig deutsch lokalisierte Komponenten. Die Frage dieses Artikels ist daher, ob sich EOS als das derzeit wohl beste Arch als Alltags-Desktop eignet?
Schnelles Arch: Das reaktionsfreudige Endeavour OS (hier mit XFCE) ist komfortabel zu installieren, fordert aber früher oder später Terminalkompetenz.
Bezug und Installation
Das Installations-ISO und Livesystem erhalten Sie auf https://endeavouros.com/latest-release (1,8 GB). Dieser Live-Installer bringt standardmäßig den XFCE-Desktop mit, jedoch sind Sie nicht zwingend auf diese Oberfläche festgelegt. Der „Welcome“-Dialog des Livesystems zeigt mehrere Optionen, und im Normalfall wird die Installation mit „Start the Installer“ ausgelöst. Alle anderen Optionen können Sie ignorieren, allenfalls die Option „Endeavour community editions“ ist für Nutzer interessant, die sich für exotische bis experimentelle Oberflächen interessieren (Sway, Qtile, Openbox sowie die Endeavour-Eigenentwicklung Worm).
Die primäre Option „Start the Installer“ eröffnet dann wiederum die zwei Möglichkeiten „Offline“ und „Online“. Wer den mitgelieferten XFCE möchte, kann „Offline“ rein vom Installationsmedium installieren. Dies ist der schnellste und einfachste Weg. „Online“ bezieht Teile des Systems aus dem Web und erlaubt die Auswahl zwischen neun prominenten Oberflächen (Gnome, KDE, Cinnamon etc.).
Verantwortlich für das Setup ist der Calamares-Installer, den auch Manjaro und einige Ubuntu-Varianten nutzen. Die typischen Fragen betreffen Sprache, Zeitzone, Tastatur, Partitionierung (mit optionaler System-Verschlüsselung) und Erstbenutzer. Setzt man hier, wie vorgeschlagen, das Benutzerpasswort mit dem des Administrators identisch, erzielt man ein sudo-Verhalten genau wie bei Ubuntu & Co.
„Welcome“ im EOS-Livesystem: „Start the Installer“ startet das Setup mit Calamares wahlweise „Offline“ oder „Online“ mit Desktop-Wahl.
EOS: Ein erster Rundgang
Das System präsentiert sich am XFCE-Desktop und allen installierten Programmen komplett deutschsprachig mit ganz wenigen Ausnahmen bei EOS-eigenen Tools. Thema der neuen „Artemis“-Version ist die Apollo-Mission und Standardhintergrund am Anmeldebildschirm und am Desktop dazu passend eine steil startende Rakete: Hier wird der Mythos vom schnellen Arch gepflegt, der sich dann tatsächlich bestätigt: Das System bootet auf einem älteren Rechner (allerdings auf SSD) in 10 Sekunden. Da kann ein Ubuntu 22.04 nicht mithalten (13 Sekunden). Wie flink ein klassisch installierter Firefox agieren kann, wird Snap-geschädigte Ubuntu-Nutzer ebenfalls positiv überraschen. Auch der Start von Software-Schwergewichten wie Gimp ist praktisch per Mausklick geschehen. Wir kennen mit Bodhi Linux nur ein einziges Debian/Ubuntu mit vergleichbaren Reaktionszeiten.
Ressourcen-technisch fordert EOS mit dem Standarddesktop XFCE nicht mehr, aber auch nicht weniger als ein Debian/Ubuntu, nämlich etwa 650 MB ab Anmeldung. Auf der Festplatte bleibt es nach der Installation deutlich unter 5 GB, sollte aber für den Dauerbetrieb wie jedes Linux wenigstens 50 bis 100 GB auf der Systempartition vorfinden (Benutzerdaten nicht eingerechnet).
Hardware-technisch gibt es mit den von uns genutzten Standardkomponenten keinerlei Einschränkungen. EOS verwendet Kernel 5.18 und arbeitet problemlos im Multimonitorbetrieb, erkennt alle Medien, akzeptiert Linux-bewährte WLAN-Adapter, beherrscht ACPI-Ruhezustände und erkennt Funktions-Sondertasten auf Notebooks.
Nach der Anmeldung meldet sich der komplett deutsch lokalisierte „Welcome“-Dialog (eos-welcome). Die Angebote „Spiegelserver“ und „System-Update“ sollte man nach der Installation umgehend aufgreifen. EOS ist Terminal-dominiert, aber viele Aktionen wie eben auch die Systemaktualisierung kann man sich mit „Welcome“ vereinfachen. Es handelt sich um eine umfangreiche Kommando- und Scriptsammlung, die man als Autostart zwar abschalten („Nicht mehr starten“), aber als Favorit im Menü oder in der Systemleiste bereithalten sollte.
EOS arbeitet wie die allermeisten neueren Distributionen mit dem Init-Dienst systemd. Komponenten und Kommandos von systemctl, journalctl funktionieren daher wie gewohnt.
Paketmanager und Installationen
EOS nutzt die Arch-Paketquellen, bietet für den Software-Bezug aber nur ein sehr einfaches grafisches Programm. eos-quickstart („EndeavourOS Quickstart Installer“) zeigt eine kategorisierte Auswahl prominenter Software, die nach Markierung und „Install Now“ umstandslos installiert wird. Schwergewichte wie Chromium, Gimp, Libre Office, Thunderbird, VLC sind hier in jedem Fall anzutreffen. Im Dauerbetrieb und für die Installation speziellerer Tools wird das aber nicht ausreichen: Schon die Suche nach einem SSH-Server oder einem Werkzeug wie Filezilla bleibt hier vergeblich.
Basiskommandos des Terminal-Paketmanagers pacman sind daher unerlässlich. Dieser bezieht die Software aus den offiziellen Arch-Quellen. Ein zweiter Paketmanager yay kann zusätzlich die inoffiziellen AUR-Quellen nutzen. Wir empfehlen Arch-Einsteigern, zunächst bei den Arch-Quellen und bei pacman zu bleiben. Fürs Erste genügt (Beispiel)
pacman -Ss filezilla
zur Suche nach Software, ferner
sudo pacman -S filezilla
zur Installation und
sudo pacman -R filezilla
zur Deinstallation. Das komplette Systemupdate mit
sudo pacman -Syu
kann man alternativ auch mit dem Terminal-Link im Hauptmenü „System -> UpdateInTerminal“ erledigen oder mit dem freundlichen „Welcome“. Letzteres weist unter „Assistent -> Alle Arch-Pakete durchsuchen“ außerdem auf das Inventar unter https://archlinux.org/packages, das eine bequeme Online-Suche erlaubt. Passendes kann dann mit pacman -S […] installiert werden.
Systemverwaltung und Desktop
Systemverwaltung und Desktop
Neben den genannten grafischen EOS-Werkzeugen eos-quickstart (limitierter Software-Installer) und eos-welcome (wichtige klickfreundliche Scriptsammlung) bleibt es Arch-typisch spartanisch. Nahezu alles, was unter /usr/bin/eos-* an Systemprogrammen zu finden ist, sind Terminal-nahe Helfer. An grafischen EOS-Tools, die auch im Menü auftauchen, ist neben den bereits genannten nur noch der eos-update-notifier zu erwähnen, der die Frequenz der Systemaktualisierung einstellen kann. Im Übrigen überlässt EOS die grafische Systemverwaltung dem jeweils benutzten Desktop. Wer Terminal-Defizite hat, ist daher mit Desktops wie Gnome, KDE oder Cinnamon am besten beraten, die eine große Reichweite auch in Richtung Systemverwaltung besitzen. Nutzern ohne Terminal-Affinität wird man diese beeindruckend schnelle Distribution dennoch nicht empfehlen können.
„Welcome“ im installierten System: Diese nützliche Sammlung von URLs und Verwaltungskommandos erspart einige Terminalausflüge.
Die Filterbefehle Grep, Awk, Xargs & Co sind unentbehrlich, um den Textoutput von Terminalbefehlen zielsicher zu filtern. Der Beitrag erklärt die wichtigsten Filter und die Prinzipien der Benutzung.
Grep: Der horizontale Zeilenfilter
Grep ist der häufigste Textfilter, um eine eventuell seitenlange Liste auf die relevante(n) Zeile(n) abzukürzen. Grep ist relativ eingängig, weil man einfach den Textstring angibt, den die benötigten Zeilen enthalten müssen (oder nicht enthalten dürfen).
Im einfachsten Fall geht es im interaktiven Terminal nur darum, die Ausgabe übersichtlich zu halten. So zeigt etwa der mount-Befehl auf Ubuntu-Systemen mit zahlreichen Snaps überwiegend Mountpunkte, die für den Benutzer irrelevant sind. Der Befehl
mount | grep "/dev/sd"
verkürzt auf die physischen Laufwerke. In manchen Fällen ist es sinnvoll, den Filter mit „-v“ umzudrehen, um nur die Zeilen zu erhalten, wo der String nicht vorkommt:
apt list --installed | grep -v "automatisch"
Dies zeigt alle installierten Software-Pakete, die manuell nachinstalliert wurden, also nicht zum „automatisch“ mitgelieferten Umfang gehören.
Für Scripts ist es oft erforderlich, genau eine einzige Ausgabezeile eines Standardbefehls auszuwerten. Der Suchstring muss dann entsprechend eindeutig ausfallen:
free -m | grep "Speicher:"
Die weitere Auswertung der verbleibenden Zeile kann dann das Werkzeug Awk übernehmen (siehe unten). Für Scripts ist ferner die Tatsache wichtig, dass Grep den Errorlevel „1“ zurückmeldet (abzufragen mit „$?“), wenn der Textstring nicht gefunden wird:
echo $file | grep -i ".7z"
if [ $? -eq 0 ] then …
Im Prinzip eignet sich Grep auch für die Textrecherche in vielen Dateien. Das Kommando
grep -r "Bunsenlabs" .
durchsucht ab dem aktuellen Verzeichnis rekursiv alle Dateien nach dem Suchstring. Da es sich aber um reine Textdateien handeln muss, wenn die Ausgabe lesbar sein soll, bleibt der Nutzwert von Grep als Desktopsuche begrenzt. Textprofis werden dafür eher zu Recoll oder Docfetcher greifen. Die Parameter „–after-context=“ und „–before-context=“, die auf Wunsch Zeilen nach und vor dem Suchtreffer ausgeben, zielen ebenfalls auf solche Textrecherche und seien hier zumindest erwähnt.
Hinweis: Die Varianten Egrep, Fgrep, Rgrep bleiben hier unberücksichtigt. Sie sind allesamt über Grep-Schalter zu erreichen.
Grep macht Datenfluten übersichtlich: Hier kontrolliert der String „deleting“, was ein rsync-Befehl bei tatsächlicher Ausführung löschen würde.
Sort: Zeilenreihenfolge umstellen
Sort ist ein Filter, der die Datenmenge insgesamt unverändert lässt (Ausnahme Schalter „-u“). Das Sortieren kann aber die Daten in völlig neue Zusammenhänge setzen, die besseren Überblick und schnelle Auswertung ermöglichen.
Sort sortiert die Ausgaben anderer Befehle alphabetisch (Standard) oder numerisch (Schalter „-n“), bei Bedarf auch nach der gewünschten Spalte (Schalter „-k“). Vor allem die Sortierung von Listen nach einer beliebigen Spalte bringt rückt Informationen zusammen, die aus den ursprünglichen Daten nie ersichtlich wären: Der Befehl tree -isa listet alle Dateien unterhalb des aktuellen Verzeichnisses mit Bytezahl auf. Mit
tree -isa |sort -k2 -n
wird die Liste numerisch („-n“) nach dieser Größenangabe sortiert, sodass die größten Dateien am Ende erscheinen. Sortiert werden muss – etwas irritierend – nach Spalte 2, weil die beginnende Klammer „[ “ als erste Spalte zählt.
Als weiteres Beispiel sei der Befehl ps –A angeführt, der alle laufenden Prozesse zeigt. Die Ausgabe ist standardmäßig nach der PID (Prozess-ID) sortiert, was bei der Suche nach einem bestimmten Programm unübersichtlich ist. Sort macht daraus mit
ps –A | sort –k4
eine alphabetische Liste:
Sort kann nicht nur nach einer bestimmten Spalte sortieren („-k“), sondern dies auch dort, wo ungewöhnliche Spalten- und Feldbegrenzer vorliegen (Schalter „-t“). Typisch ist etwa das Semikolon in CSV-Dateien:
cat Buchungen.csv | sort -t ";" -n -k7
Wenn Spalte 7 die Buchungsbeträge enthält, wird die komplette Tabelle numerisch nach diesen Werten sortiert.
Mit Schalter „-u“, der ausschließlich horizontal und zeilenbezogen arbeitet, filtert Sort bei der Ausgabe langer Listen oder Dateien doppelte, identische Zeilen weg:
cat .bash_history | sort -u
Wer diesen Räumdienst direkt in der Originaldatei übernehmen will, nutzt am besten Sponge:
cat .bash_history | sort -u | sponge
Dies erspart den lästigen Umweg über eine sekundäre, temporäre Datei.
Hinweis Uniq: „sort -u“ macht das kleine Hilfsprogramm Uniq weitgehend überflüssig. Der Mehrwert gegenüber „sort -u“ liegt allenfalls bei der Analyse, zumal Uniq grundsätzlich nur funktioniert, wenn ein Sort-Filter vorangestellt wird:
cat .bash_history | sort | uniq -c
Dies zeigt alle Zeilen mit der Anzahl eventueller Wiederholungen. Jeder Wert größer als „1“ bedeutet einen doppelten oder vielfachen Eintrag.
Sort schafft Ordnung: Wichtige Eigenschaften sind die Sortierung nach Spalten (-k) und der Schalter für numerische Werte (-n).
Awk: Der vertikale Spaltenfilter
Awk ist das umfangreichste Filterwerkzeug und zerlegt die Textausgabe von Terminalkommandos in Spalten und Felder. Damit können Sie Spalten einer Liste ausblenden oder umstellen oder in einer Ausgabezeile genau einen bestimmten, einzelnen Wert ermitteln und weiterverarbeiten. Awk kann außerdem vorgefundene Werte gleich mathematisch verrechnen und etwa Additionen oder Divisionen erledigen.
Awk ist ein selbständiges Programmiertool. Die folgenden Beispiele können diesen Umfang nicht annähernd wiedergeben und fokussieren sich auf wichtige Aufgaben im interaktiven Einsatz oder für einfache Bash-Alias oder Funktionen. Die Arbeitsweise von Awk zeigt ein ganz simples Beispiel:
echo Anna Sepp Hans Berta | awk '{print $1 $4 $3 $2}'
Die Felder (hier Namen) werden umgestellt, sind aber ohne Trenner schlecht lesbar – also:
echo Anna Sepp Hans Berta | awk '{print $1 "\t" $4 "\t" $3 "\t" $2}'
Dies setzt einen Tabulator zwischen die Felder.
Nun wird es ernster: Awk soll aus dem Standardbefehl Top die aktuelle CPU-Last abgreifen und nur diesen einzigen Wert anzeigen:
top -n1 | grep "CPU(s)" | awk '{print 100-$8"%"}'
Feld 8 in der Zeile „CPU(s)“, die Grep vorfiltert, enthält den aktuellen Idle-Wert. Von 100 subtrahiert, ergibt sich die aktuelle CPU-Last.
Eigentlich ist Awk in diesem Fall gar nicht auf Grep angewiesen: Wenn eine Befehlsausgabe wie der Header von Top genau normiert ist, also von vornherein klar, in welcher Zeile welche Information erscheint, dann kann Awk auf die Nachhilfe von horizontalen Filtern verzichten. Mit „NR==“ lässt sich die exakte Zeilennummer einstellen und nachfolgend auswerten. Das folgende Beispiel ermittelt die aktuelle RAM-Belegung aus Zeile 4 des Top-Kommandos:
top -n1 | awk 'NR==4 {print int($8) " MB belegt von " int($4) " MB"}'
Dies wird ein Ergebnis wie „524 MB belegt von 3732 MB“ erzeugen. Die Funktion „int“ ist nicht zwingend, bereinigt aber auf gut lesbare Ganzzahlen.
Auf diese Weise wird es relativ einfach, gesuchte Werte nicht nur auszugeben, sondern als Bash-Variable zur Weiterverarbeitung abzulegen:
RAM_used=$(top -n1 | awk 'NR==4 {print int($8)}')
Danach steht die Variable $RAM_used für Scripts oder Funktionen zur Verfügung.
Awk kann auch eine Zeilennummerierung ausführen:
find . | awk '{print NR "\t" $0}'
Hier will offenbar jemand wissen, wie viele Dateien sich im aktuellen Ordner befinden: Awk nummeriert die Zeilen und hängt nach Tabulator die komplette Zeile an, wie sie Find anliefert („$0“ bedeutet die gesamte Zeile ohne Feldauswahl).
Wenn statt einer klaren Tabellenstruktur die Felder durch Trenner wie Semikolon, Doppelpunkt oder Slash definiert sind, dann hilft der Awk-Schalter „-F“ („Field“):
cat /etc/passwd | awk -F: '{print $3 "\t" $1}'
Die Datei /etc/passwd nutzt den Doppelpunkt als Feldtrenner, daher „-F:“. Die Ausgabe wird dann auf Username und UID reduziert, die Spalten umgedreht (Name zuerst) und zur besseren Lesbarkeit ein Tabulator zwischengeschaltet (Tipp: Der Backslash ist das typische Signal für Sonderzeichen in Bash-Filtern – hier „\t“ für den Tabulator).
Das letzte Beispiel zeigt zugleich noch einmal, dass Awk die Spalten eines Ausgangbefehls beliebig umstellen und unnötige Spalten ausblenden kann.
Awk pickt sich jeden Wert aus Zeilen und Spalten. Dieser Filter ist für Scripts und Aliases absolut unentbehrlich.
Column: Spaltenzerlegung
Dieses Tool verbessert die Lesbarkeit unformatierter Listen signifikant. Wer Awk beherrscht, wird Column zwar nicht oft brauchen, aber das Tool ist handlich und setzt passende Tabulatoren nach Berechnung aller Daten. Es kann auch als Vorbereitung dienen, um eine weitere Zerlegung durch Awk zu erleichtern.
Vergleichen Sie die überaus schlecht lesbare Ausgabe von mount mit dieser Variante
mount | column -t
oder den Befehl cat /etc/passwd mit dieser Tabellendarstellung:
cat /etc/passwd | column -s: -t
Column ersetzt hier das Trennzeichen „:“ (Schalter „-s“ steht für Separator) durch Tabulatoren. Sortiert man das Ganze dann noch mit
cat /etc/passwd | column -s: -t | sort -n -k3
numerisch nach der User-ID in Spalte 3, ist das Resultat mit der Originaldatei kaum noch zu vergleichen. Anders als Awk oder Sed, die ebenfalls Tabulatoren einsetzen können, errechnet Column eine passende Tabulatorweite für alle Spalten der gesamten Datenmenge.
Column schafft aber auch Felder, wo vorher keine waren. Der schon früher genannte Befehl
apt list --installed
trennt die Paketnamen durch einen „/“-Slash von der nachfolgenden Paketquelle. Mit
apt list --installed | column -s/ -t
wandeln Sie den Slash-Trenner um in eine gut lesbare Tabelle und mit
bleiben nur noch die Paketnamen der ersten Spalte übrig, die sich dann für eine Masseninstallation verwenden lässt. Hierfür ist das Tool Xargs einschlägig (siehe unten).
Hinweis: Für genau dasselbe Ergebnis des letzten Befehls reicht mit
apt list --installed | awk -F/ '{print $1}'
auch das begabte Awk allein.
Column macht Listen mit seltsamen Trennzeichen lesbar und ist vor allem zur Darstellung größerer Tabellen die optisch ansprechendste Lösung.
Cut: Spalten definieren und entfernen
Column und vor allem Awk bieten alle Möglichkeiten, um vertikale Spalten und Felder darzustellen, zu analysieren oder bei Bedarf durch Umwandlung von Trennzeichen erst herzustellen. Das Tool Cut ist technisch weitaus einfacher, aber gerade deswegen oft die unkompliziertere Alternative.
Cut eignet sich ideal, um eine bestimmte Spalte aus einer Liste zu filtern, die ihre Felder mit einem Delimiter-Zeichen wie Semikolon, Komma, Doppelpunkt, Bindestrich oder Slash trennt. Die wichtigsten Schalter von Cut sind „-d“ (Delimiter), der das Trennzeichen definiert, und „-f“ für die Angabe der gewünschten Spalten (Fields). Der Befehl
echo Anna Sepp Hugo | cut -d" " -f2
wird folglich mit „Sepp“ antworten. Das letzte Beispiel oben, das mit Column und Awk eine Paketliste erstellte, ist daher mit dem Tool Cut noch einfacher zu realisieren:
apt list --installed | cut -d/ -f1
Mit dem Schalter „-d“ wird hier der Slash „/“ als Spaltentrenner definiert und mit „-f1“ nur noch die erste Spalte angezeigt, also die puren Paketnamen. Im folgenden Beispiel
cut -d: -f1,3 /etc/passwd
reduziert Cut die genannte Datei auf die zwei Felder Usernamen und UID.
Cut ist ein relativ einfaches Tool, um gezielt eine oder mehrere Spalte(n) einer Liste zu isolieren.
Sed: Zeichen ersetzen oder löschen
Der Streameditor Sed eignet sich sowohl zur Dateibearbeitung als auch zur Korrektur des Terminaloutputs. Er ersetzt einzelne Zeichen oder Zeichenfolgen durch einen anderen String, löscht störende Zeichen oder fügt zusätzliche ein.
Sed kann automatische Textersetzungen oder Löschungen in allen Dateien des aktuellen Verzeichnisses erledigen. Ferner kann es auch als Kosmetik für schlecht lesbare Terminalbefehle dienen. Wenn das mächtige Werkzeug viele Dateien bearbeiten soll, ist Vorsicht geboten und zumindest ein vorhergehender Test zu empfehlen, der nur im Terminal angezeigt wird:
sed 's/domain.org/neue.domain.de/g' *.html
Jedes Vorkommen von „domain.org“ wird durch die neue Adresse korrigiert. Mit zusätzlichem Schalter „-i“ (oder „–in-place“) erledigt Sed die Aktion tatsächlich.
Hocheffizient, aber auch riskant sind Löschkommandos mit „d“:
sed -i '/bind /d' ~/.bashrc
Hier wird jede Zeile der angegebenen Datei gelöscht, die mit dem Kommando „bind “ beginnt.
Sed ist aber auch für die interaktive Kosmetik am Terminaloutput nützlich. Die Ausgabe des Systempfads mit
echo $PATH
trennt die Ordner bekanntlich schlecht lesbar mit Doppelpunkt. Folgende Alternative
echo $PATH | sed 's/:/\n/g'
ersetzt alle Doppelpunkte durch einen Zeilenumbruch („\n“) und macht die Ausgabe übersichtlich. Wie schon bei Awk angemerkt, ist der Backslash wieder das typische Signal für ein nachfolgendes Sonderzeichen.
Streameditor Sed: Das Tool ist ein phänomenaler Zeitsparer, erfordert aber sehr präzise und eindeutige Angaben.
Xargs: Andere Befehle füttern
Das Tool Xargs gehört in diesen Kontext, obwohl es selbst keine Filterleistung bietet. Aber es gibt vorher gefilterte Argumente oder den Inhalt einer Dateiliste direkt an einen anderen Befehl weiter. Damit ist es eine nützliche Abkürzung, die eine weitaus umständlichere Scriptverarbeitung erspart.
Im ersten einfachen Beispiel wird eine vorher angelegte Paketliste
apt-mark showmanual > liste.txt
später an diesem oder auf einem anderen System mit
cat liste.txt | xargs apt install
in einem Rutsch installiert. Xargs übergibt einfach den kompletten Inhalt der Textdatei an den Paketmanager.
Diese beiden nachfolgenden Befehle sind funktionsidentisch:
Das zeilenweise Abarbeiten mit „-n 1“ ist notwendig, wenn die Listendatei für jedes Argument eine eigene Zeile nutzt. Xargs kann auch für eine besser lesbarere oder ergänzte Terminalausgabe sorgen:
Die Ausgabe von free wird auf die Zeile mit „Speicher“ gekürzt. Awk filtert dort die Werte für den Gesamtspeicher ($2) und den benutzten Speicher ($3) und berechnet den belegten Prozentwert (bereinigt durch „int“ auf eine Ganzzahl). Damit nicht die bloße Zahl geliefert wird, übergibt Xargs den Wert an Echo. Weil der vorher ermittelte Wert nicht am Ende des Echo-Befehls steht, muss Xargs mit Schalter „-i“ verwendet werden. Die Klammern „{}“ definieren dann die Stelle für den Übergabewert.
Xargs ist ein Wertelieferant und gibt die von Bash-Filtern gesammelten Infos an einen anderen Befehl weiter (hier nur an Echo).
Bash-Filter: More & Less
Es gibt eine Reihe weiterer (Mengen-) Filter wie More und Less zum zeilenweisen Blättern in der Ausgabe, Head und Tail zur Reduktion der Ausgabe auf die ersten oder letzten Zeilen. Dies nur der Vollständigkeit halber – denn dieser letzte Abschnitt ist eher ein Fazit.
In der Bash-Shell geht mit den genannten Tools im Prinzip alles. Wie bei allen textbasierten Shells ist es aber kein Vergnügen. Die Erbsenzählerei zum benötigten Feld für eine Awk-Auswertung ist mühsam, aber immerhin lohnend. Richtig ärgerlich ist, dass Bash-Tools keine einheitlichen Schalter haben und etwa einen Spaltentrennzeichen mal mit „-F“, mit „-d“ oder mit „-t“ definieren. Eine weitere Herausforderung ist es, dass Tools ähnliche Funktionen enthalten, die unterschiedliche Lösungen für ein und dasselbe Problem bieten. Unterm Strich sollten Grep, Sort und Awk alle Aufgaben erledigen – sofern man sie richtig beherrscht. Sed ist ein Editierautomat, der sich vornehmlich an Script- und Webentwickler richtet.
Wie lautet gleich wieder das Kennwort für das Gast-WLAN? Wie ist die öffentliche IP-Adresse? Router wie die Fritzbox verwalten so viele Infos, geben sie aber nur her, wenn man sich durch die Konfigurationsoberfläche klickt. Oder?
Gut Informierte wissen wahrscheinlich, dass sich die Fritzbox-Konfiguration durch PHP-Scripts auslesen und in vielen Belangen sogar steuern lässt. Theoretisch genügen dafür relativ komplizierte Befehle der Download- und Upload-Tools wget und curl. Komfortabler ist das Paket miniupnpc mit seinem Programm upnpc – dies allerdings mit eng begrenzter Reichweite. Das umfangreichste PHP-Projekt zur Fritzbox-Steuerung ist die Sammlung fb_tools (Fritzbox-Tools) von Michael Engelke. Was man damit alles anstellen kann, zeigt dieser Beitrag.
Fritzbox-Abfragen: Der Einblick in das Systemprotokoll und die Traffic-Statistik („Online-Zähler“) gehört zu einfacheren Kommandos der Fritzbox-Tools.
Definition und Umfang
Die Fritzbox-Tools sind eine umfangreiche Sammlung von PHP-Scripts, die über Terminalbefehle ausgelöst werden. Je nach Befehl kann man Informationen aus der Fritzbox auslesen, Konfigurationsbackups anlegen und wieder zurückschreiben und viele Einzelfunktionen von außen starten, so etwa Smarthome-Aktoren von AVM oder die LED-Anzeige der Fritzbox.
Um Missverständnissen vorzubeugen: Die Fritzbox-Tools können – mit einigen wenigen Ausnahmen – nicht mehr als das, was ein zutrittsberechtigter Fritzbox-Nutzer im Normalfall auf der Konfigurationsoberfläche erledigt. Ihre Reichweite ist sogar begrenzter als die Fritzbox-Oberfläche, weil AVM nicht alle Funktionen für PHP-Scripting offenlegt (so offenbar der gesamte Bereich WLAN/Funknetz). Der entscheidende Vorteil der Fritzbox-Tools ist es, dass Informationen wie die öffentliche IP-Adresse, die aktuelle Anrufliste oder der Online-Zähler mit einem vorbereiteten Terminalbefehl in zwei Sekunden ausgelesen sind. Und mehr noch: Als Terminalbefehl lassen sich solche Aktionen auch automatisch erledigen, etwa als Cronjob oder Autostart auf einem beliebigen Linuxsystem im Netzwerk.
Einfache Installation auf Debian/Ubuntu
Die Fritzbox-Tools laufen im Prinzip auf jedem Betriebssystem. Weil aber PHP installiert sein muss, ist die Einrichtung auf Linux am einfachsten. Auf jedem Update-gepflegten Linux wird eine PHP-Version 7.x für die Konsole („cli“) nämlich bereits vorliegen. Außerdem gibt es mindestens eine interessante Funktion der Tools, die Open SSL benötigt – und auch dies ist Standard unter Linux. Für Debian/Ubuntu-basierte Distributionen genügt daher der Download des winzigen DEB-Pakets „fb-tools.deb“ von www.mengelke.de/Projekte/FritzBox-Tools (nur 90 KB) und die Installation per Doppelklick oder im Terminal:
sudo dpkg -i fb-tools.deb
Für Linux-affine Windows-Nutzer ist genau derselbe Weg zu empfehlen, sofern sie ein Debian oder Ubuntu im „Windows Subsystem für Linux“ (WSL) verwenden. Dies ist wesentlich einfacher, als der Anleitung für die Installation unter Windows zu folgen.
Erste Umschau: Auf den typischen Hilfeschalter „-h“
fb_tools -h
meldet die Toolsammlung die verfügbaren Hauptbefehle (Modes). Einige dieser Befehle besitzen wieder diverse Unterbefehle (Funktionen), wovon Sie sich mit
fb_tools konfig -h
fb_tools smarthome -h
überzeugen können. Es gibt nun einige einfache Modes (ohne Unterbefehle), die ohne jede Benutzer-Authentifizierung sofort Antworten liefern:
fb_tools boxinfo
fb_tools systemstatus
Damit erhalten Sie die Basisdaten über Modell, Hardwarerevision, Provider, Laufzeit, Neustarts. Ebenfalls selbsterklärend ist die Abfrage der öffentlichen IP-Adresse:
fb_tools getip
Bei anderen Modes wie „traffic, anrufliste, led, konfig, smarthome“ werden Sie hingegen keinen Erfolg haben. Das Tool meldet dann „Anmeldung fehlgeschlagen, SID.lua ist ungültig“. Das bedeutet, dass Sie sich für diese Modes und Funktionen an der Fritzbox anmelden müssen.
Anmeldung und Fritzbox-Einstellung
Alle wirklich interessanten Funktionen setzen eine Anmeldung voraus. Die verläuft aber denkbar einfach innerhalb des Kommandos:
fb_tools Geh3im@fritz.box anrufliste
Dies genügt, falls der Router nur durch ein allgemeines Passwort geschützt ist. Wenn Sie in der Fritzbox Benutzerkonten angelegt haben, benötigen Sie folgende Syntax
fb_tools sepp:Geh3im@fritz.box anrufliste
mit der Abfolge „[Konto:Kennwort@Gerät]“. Und noch ein akademisches Detail: Wer sich in mehreren Netzen befindet, muss den angesprochenen Router statt mit „fritz.box“ genau adressieren (was aber auch sonst nie schadet):
fb_tools sepp:Geh3im@192.168.178.1 anrufliste
Mit dieser Syntax und somit korrekter Anmeldung sind aber auf jüngeren Fritzboxen immer noch nicht sämtliche Funktionen realisierbar. Die Lösung dafür liegt in der Fritzbox-Konfiguration unter „System → Fritz!Box-Benutzer → Zusätzliche Bestätigung → Ausführung bestimmter Einstellungen und Funktionen zusätzlich bestätigen”. Die Option ist standardmäßig aktiviert und verhindert einige Kommandos der Fritzbox-Tools. Es ist Ermessensfrage, ob man dies dauerhaft abschalten will. Zumindest vorübergehend ist das nötig, um einen der interessantesten Befehle abzusetzen:
Dieses Kommando liest im Klartext sämtliche Verbindungsdaten aus, unter anderem Provider-Zugangsdaten, WLAN-Passwörter, Telefonie-Passwörter, Internet- und MyFritz-Onlinezugangsdaten. Diese Daten sind in dieser Form und Vollständigkeit weder über die Fritzbox-Oberfläche noch in der (verschlüsselten) Konfigurationssicherung erreichbar.
Weitere Beispiele
Mit dem Mode „konfig“ können Sie interaktiv oder automatisiert Konfgurationssicherungen des Routers ausführen:
Mit „konfig import“ lässt sich eine Sicherung später wieder zurückspeichern.
Der einfache Mode „traffic“ hat keine Unterfunktionen und spuckt nach
fb_tools […] traffic
die Zusammenfassung aus, die in der Konfigurationsoberfläche unter „Internet -> Online-Monitor -> Online-Zähler“ zu finden ist. Der Mode „Ereignisse“ bietet das Systemprotokoll („System -> Ereignisse“) und hat dabei genau dieselben optionalen Filter wie die Oberfläche:
fb_tools […]ereignisse filter:system
Einfache, aber mindestens im zweiten Fall interessante Aktionen lösen folgende Kommandos aus:
fb_tools […] led off
fb_tools […] reconnect
Die LED-Leuchten lassen mit „on“ jederzeit wieder aktivieren. „reconnect“ darf als weiteres Highlight der Toolsammlung gelten, weil die Fritzbox-Oberfläche zur Neuverbindung nur den kompletten und zeitaufwändigen Gerätestart vorsieht – obendrein verbuddelt unter „System -> Sicherung -> Neustart“. Dass „reconnect“ die Fritzbox tatsächlich in Sekunden neu verbindet, können Sie dem Systemprotokoll entnehmen („System -> Ereignisse“ oder das entsprechende Kommando der fb_tools).
Besonders ergiebig ist der Mode „SmartHome“, der mit
fb_tools sepp:Geh3im@192.168.178.1 smarthome list
alle Smarthome-Komponenten („Aktoren“) mit AIN-Kennziffer anzeigt (AIN=Aktor Identifikationsnummer). Einschränkend ist zu bemerken, dass solche Steuerung eine homogene und ausschließliche Nutzung von AVM-Produkten voraussetzt. Da der Verfasser solche Funksteckdosen und Sensoren nicht nutzt, vertrauen wir an dieser Stelle auf Aussagen des Tool-Entwicklers und von Kommentaren im Web.
Auf Basis der mit „smarthome list“ ermittelten Gerätekennungen, lässt sich die betreffende Hardware dann detailliert steuern: Ein AVM-Thermostat mit der AIN „18“ kann dann etwa mit folgendem Befehl
fb_tools […] smarthome set 18 20
auf exakt 20 Grad gesetzt werden oder mit
fb_tools […] smarthome set 18 spar
auf eine in der Fritzbox („Smart Home -> Geräteverwaltung“) hinterlegte Spartemperatur.
Oracle Virtualbox kann alles – und viel mehr, als dieser knappe Beitrag zeigen kann. Hier geht es nur um die Grundlagen – die Installation der Software, die Einrichtungsschritte für virtuelle Maschinen (VMs) und die allerwichtigsten Optimierungsmöglichkeiten.
1. Installation: Vollständig mit Erweiterungspaket
Die aktuelle Version (7.0.4) von Virtualbox erhalten Sie für alle Betriebssysteme unter www.virtualbox.org/wiki/Downloads. Zu den Varianten für die unterschiedlichen Linux-Distributionen führt dort der Link „Linux distributions“. Den Download installieren Sie dann nach Rechtsklick mit dem Paketmanager der Distribution, unter Windows durch Doppelklick des EXE-Programms. Anders als die Linux-Varianten bietet der Windows-Installer eine Selektion von Komponenten, wobei aber außer der Python-Unterstützung alle Optionen zu empfehlen sind.
Exkurs: Virtualbox ist selbstverständlich auch in den Paketquellen der Distributionen erhältlich. Dies aber in älteren Versionen 6.x, sodass der Vorteil einer automatischen Aktualisierung in diesem Fall keiner ist: Die Updates erstrecken sich nämlich nur auf die veraltete Hauptversionsnummer „6“. Eine weitere Installationsoption unter Linux wäre es noch, die Oracle-Paketquelle einzubinden und auf diesem Weg Updates für Version 7 zu erhalten. Dies führen wir hier nicht näher aus (siehe www.virtualbox.org/wiki/Linux_Downloads), da die Heft-DVD dafür eine Komplettlösung anbietet. Das dort vertretene Ubuntu 22.04.1 hat ein vorinstalliertes Virtualbox 7, das sich via Systemaktualisierung aktuell hält.
Erweiterungspaket: Auf der allgemeinen Downloadseite erscheint auch das „Oracle VM VirtualBox Extension Pack“. Dieses darf aus lizenzrechtlichen Gründen nicht mit dem freien Virtualbox ausgeliefert werden, ist aber für private Nutzung frei und kostenlos. Nach dem Download dieses Erweiterungspakets starten Sie Virtualbox und gehen im Virtualbox Manager auf „Werkzeuge“. Im mittleren Hauptfenster klicken Sie dann auf die Schaltfläche „Installieren“ und navigieren zum Download. Da der Dialog nur Dateien mit der Extension „.vbox-extpack“ anzeigt, ist die Auswahl einfach und eindeutig. Nach einem Warnhinweis startet die Installation.
Das Erweiterungspaket ist zwar optional, aber für häufige Virtualbox-Nutzung uneingeschränkt zu empfehlen. Hauptgrund ist die Unterstützung für USB 2.0 und 3.0, aber auch RDP-Fernsteuerung für Windows-VMs kann ein wichtiges Motiv sein. Das Erweiterungspaket bietet noch weitere Extra-Funktionen wie Netboot oder AES-Festplattenverschlüsselung.
Gruppenzuweisung: Eine letzte Aktion vervollständigt die Installation unter Linux (unter Windows unnötig): Fügen Sie die Systembenutzer, die Virtualbox verwenden sollen, zur Gruppe „vboxusers“ hinzu:
sudo adduser [User] vboxusers
„[User]“ ersetzen Sie durch den Kontonamen des Benutzers. Wiederholen Sie den Befehl für alle gewünschten Konten. Melden Sie sich dann bei Linux ab und wieder an oder starten Sie das System neu. Diese vollständige Installation mit Erweiterung und Gruppenzuweisung ist für eine sporadische Nutzung von Virtualbox nicht zwingend, erspart aber eventuelle spätere Irritationen – insbesondere beim Versuch, USB-Geräte in einer VM zu nutzen.
Erweiterungspaket für Virtualbox: Das Zusatzpaket ist optional, bietet aber unter anderem den Zugriff auf USB 2.0/3.0. Am besten integrieren Sie es sofort nach der Virtualbox-Installation.
2. Allgemeine Einstellungen
Der Start von Virtualbox am Desktop öffnet den „Oracle VM VirtualBox Manager“ – zunächst nur mit dem Eintrag „Werkzeuge“. Über eine grundsätzliche Einstellung können Sie vorab entscheiden, dies aber bei Bedarf auch später umstellen: Unter „Datei -> Einstellungen -> Allgemein“ ist der Pfad vorgegeben, wo Virtualbox seine Dateien ablegen wird. Da dies viel Kapazität fordern wird, ist hier eventuell von vornherein ein Ort jenseits von „/home“ besser geeignet.
Unter “ Datei -> Einstellungen -> Eingabe -> Virtuelle Maschine“ lohnt sich in jedem Fall eine Durchsicht der Standard-Hotkeys. Den „Host“-Key mit Kombinationen wie Host-C, Host-L, Host-F, Host-Pos1 werden Sie ständig benötigen, um die VM-Darstellung (Vollbild; Skaliert, Fenster) zu ändern oder das VM-Fenstermenü zu aktivieren (Host-Pos1). Voreingestellter Host-Key ist die rechte Strg-Taste. Alle Hotkeys sind individuell einstellbar, auch der Host-Key.
3. Eine virtuelle Maschine einrichten
Mit der Schaltfläche „Neu“ oder „Maschine -> Neu“ erstellen Sie eine VM. Den „Namen“ vergeben Sie beliebig. Als „Ordner“ ist voreingestellt, was unter „Datei -> Einstellungen -> Allgemein“ als Standard gilt. Wichtig ist das „ISO Abbild“, mit dem die Installation des neuen Systems erfolgt. Navigieren Sie hier über „Ändern“ zum Installationsmedium des Systems. Dabei handelt es sich über die typischen Live- und Installer-Downloads für Linux-Distributionen oder um das Installations-ISO einer Windows-Version. Sobald dieses Medium eingetragen ist, erkennt Virtualbox automatisch „Typ“ und „Version“ dieses Systems. Falls nicht, wählen Sie „Typ“ und „Version“ manuell. Für Linux sind viele, aber nicht alle Distributionen aufgeführt. Nehmen Sie den Eintrag, der dem System am nächsten kommt, etwa „Ubuntu (64-bit)“ für ein Linux Mint oder „Arch Linux (64 Bit)“ für ein Endeavour OS.
Wenngleich der Assistent die Hardware-Einstellungen von dieser Auswahl abhängig macht, ist diese Aktion – sofern überhaupt nötig – nicht kritisch, denn alle Voreinstellungen lassen sich durch manuelle Änderungen anpassen. Sie sollten aber für beste Kontrolle stets die Option „Unbeaufsichtigte Installation überspringen“ anklicken.
Mit „Vorwärts“ geht es zur RAM-Ausstattung und CPU-Vergabe für die VM. Vier GB und zwei CPU-Kerne sind für die meisten VMs ausreichend. Zum Teil genügt weniger. Die Einstellung hängt nicht zuletzt von der Hardware des Hostsystems ab und von der Frage, ob Virtualbox eventuell künftig sogar mehr als eine VM gleichzeitig mit Ressourcen versorgen soll. Kritisch sind auch diese Vorgaben nicht, da sie sich später – bei ausgeschalteter VM – jederzeit anpassen lassen.
Nach „Vorwärts“ kommt der Punkt „Virtuelle Festplatte“ mit drei Optionen. Im einfachsten Fall brauchen Sie überhaupt keine Festplatte („Keine Festplatte hinzufügen“), dann nämlich, wenn die VM nur ein Linux-Livesystem starten soll. Dann genügt das bereits vorher eingestellte ISO-Image. Soll das System hingegen ordentlich installiert werden, wählen Sie die oberste Option „Jetzt eine virtuelle Festplatte erstellen“. Die Kapazität wählen Sie umso großzügiger, je länger die VM voraussichtlich laufen soll (Updates, Installationen). 30 bis 50 GB sind für Linuxsysteme realistisch, 50 bis 100 GB für Windows.
Wer sich hier nicht sicher ist, sollte die Option „Volle Größe erzeugen“ immer inaktiv belassen (Standard) und damit eine dynamische virtuelle Festplatte erzeugen. Das hat zwei Vorteile – und einen Nachteil:
* Eine dynamische virtuelle Festplatte (VDI-Datei) fordert nur den aktuell nötigen Platz und wächst bis zum angegebenen Maximum. Sie belegt also eventuell nur 10 GB, obwohl 50 GB eingestellt sind.
* Eine dynamische VDI lässt sich später ohne Aufwand erweitern. Unter „Werkzeuge -> Medien -> Festplatten“ gibt es einen Schieberegler wie bei der Ersteinrichtung.
* Eine statische VDI („Volle Größe erzeugen“) ist im späteren Betrieb schneller.
Nach Abschluss des Schrittes „Virtuelle Festplatte“ und „Vorwärts“ ist die Definition der VM beendet und der grafische Assistent zeigt die Zusammenfassung.
Hinweis: Auf die dritte Option „vorhandene virtuelle Festplatte“ gehen wir später ein (Punkt 9).
Anlegen einer neuen VM: Das „ISO-Abbild“ mit dem Installationsmedium des gewünschten Systems ist in Virtualbox 7 eine erste und wichtigste Entscheidung..
Anlegen der Festplatte: Dynamische Festplatten belegen anfänglich wenig Platz, lassen sich später leicht vergrößern, sind aber langsamer als Laufwerke mit statischer Größe („Volle Größe“).
4. Anpassungen der virtuellen Maschine
Die VM-Einrichtung via Virtualbox-Assistent führt in aller Regel zu einer sofort lauffähigen VM, lässt aber interessante Optionen außen vor. Es lohnt sich praktisch immer, vor dem ersten Start auf das Angebot „Ändern“ zu klicken und alle Optionen durchzugehen. Die Mehrzahl dieser Optionen setzt entweder das allgemeine Erweiterungspaket (Punkt 1) oder die Gasterweiterungen (Punkt 6) voraus:
Nicht optional, sondern unentbehrlich ist im Punkt „Anzeige“ ein hoher Wert für „Grafikspeicher“, am besten immer „128 MB“. Bei manchen Linux-Gastsystemen wählt Virtualbox den Wert so unterdimensioniert, dass die grafische Oberfläche nicht startet. Aktivieren Sie an dieser Stelle außerdem die Option „3D-Beschleunigung aktivieren“.
Unter „Allgemein -> Erweitert“ können Sie durch die „Gemeinsame Zwischenablage“ und „bidirektional“ Inhalte zwischen Host- und Gastsystem über die Zwischenablage austauschen. Dies lohnt sich ebenfalls für „Drag’n’Drop“, um Dateien vom Dateimanager des Hostsystems in den Dateimanager des Gastsystems zu ziehen.
Unter „USB“ sollte nicht nur der USB-Controller aktiviert sein, sondern auch die richtige USB-Version. Diese Angabe orientiert sich am Hostsystem und am USB-Port, wo Sie eventuelle USB-Datenträger voraussichtlich nutzen wollen.
„Ändern“ der VM nach absolviertem Assistenten: Mindestens der Punkt „Anzeige“ verdient fast immer eine Korrektur beim „Grafikspeicher“.
5. Installation des virtuellen Systems
Nach dem Start der VM bootet diese über das virtuelle DVD-Laufwerk das Installationsmedium. Eventuell erwarten Sie von dieser VM gar nicht mehr als den Start eines typischen Linux-Livesystems und eine Installation entfällt somit. Wo dies zutrifft, sollte eine solche VM ausdrücklich „Live“ im Namen tragen (etwa „Knoppix-Live“), um es in der Virtualbox-Liste von installierten VMs zu unterscheiden.
In der Regel wird die VM aber eine virtuelle Festplatte enthalten, auf welche Sie nun das System ordentlich installieren. Der Vorgang unterscheidet sich in keiner Weise von einer normalen, physischen Installation. Er ist allenfalls einfacher, weil nur eine (virtuelle) Festplatte vorhanden ist. Nach Abschluss der Installation und Herunterfahren der VM sollten Sie – wie nach jeder Installation – das Installations-ISO aus der VM-Konfiguration nehmen. Dies erledigen Sie über „Ändern“ im Virtualbox Manager. Entfernen Sie unter „Massenspeicher“ aber nicht das komplette DVD-Laufwerk, sondern nur das eingehängte ISO-Image. Das geht mit der Klickbox ganz rechts neben „Optisches Laufwerk“ und der Option „Entfernt das virtuelle Medium…“. Das virtuelle DVD-Laufwerk selbst kann später noch anderweitig nützlich sein, insbesondere aber für die Installation der Gasterweiterungen.
6. Gasterweiterungen in die VM installieren
Im Unterschied zum allgemeinen Virtualbox-Erweiterungspaket werden die Gasterweiterungen in die jeweilige VM installiert. Gasterweiterungen sind optional, aber mindestens für häufiger genutzte VMs zu empfehlen. Sie enthalten Treiber für die Maus und den virtuellen Grafikadapter, verbessern damit Bildschirmauflösung, Skalierung, Mausverhalten und erlauben direkte Ordnerfreigaben zwischen Hostsystem und Gast-VM.
Die Gasterweiterungen lädt Virtualbox in das virtuelle DVD-Laufwerk einer laufenden VM, wenn Sie auf das VM-Fenstermenü „Geräte -> Gasterweiterungen einlegen“ klicken. Falls die Menüleiste im Vollbild oder im skalierten Anzeigemodus nicht zugänglich ist, verwenden Sie den Hotkey Host-Pos1 (also standardmäßig Strg-Rechts-Pos1). Das Installationspaket erscheint dann im DVD-Laufwerk der VM, und in einer Windows-VM genügt dann der Doppelklick auf „VBoxWindowsAdditions.exe“. Unter Linux müssen eventuell mit dem Terminal zum Pfad des DVD-Ordners navigieren und dann mit
sudo ./VboxLinuxAdditions.run
die Installation starten.
Optionale Gasterweiterungen (hier für Windows-VM): Über das Menü „Geräte“ lädt Virtualbox das Paket in das virtuelle DVD-Laufwerk. Von hier wird es dann in die VM installiert.
7. VM im Netzwerk: Netzwerkbrücke statt NAT
Standardmäßig gilt für VMs wie bei allen Virtualisierern der „NAT“-Modus im Netzwerk: Dabei dient Virtualbox selbst als virtueller Router und weist der VM eine zufällige IP-Adresse zu. Damit kommt die VM ins Internet, bleibt aber im lokalen Heimnetz isoliert. Es ist der VM zwar möglich, sich über die IP-Adressen des Heimnetzes mit Samba- oder SSH-Server zu verbinden, umgekehrt ist aber keine Verbindung zur VM möglich (SSH, Samba, VNC, RDP, Apache…).
Wenn eine VM einen Dienst im Heimnetz anbieten soll, ist eine andere Einstellung erforderlich. Möglichkeiten gibt es mehrere, aber die einfachste erfordert nur einen einzigen Klick und sollte in den meisten Fällen genügen. Gehen Sie bei einer eingerichteten VM nach „Ändern“ auf das „Netzwerk“. Hier finden Sie unter „Netzwerk -> Angeschlossen an“ eine Reihe weiterer Optionen. Mit „Netzwerkbrücke“ verbindet sich eine VM direkt mit dem Heimnetz. Die VM erhält also vom Heimrouter via DHCP eine lokale IP-Adresse genau wie ein physischer Rechner. Das macht die VM zum gleichberechtigten Mitglied des lokalen Netzes, und sie kann dann von jedem anderen Gerät erreicht werden. Die Umstellung von „NAT“ zu „Netzwerkbrücke“ kann im Virtualbox Manager jederzeit und auch für eine aktuell laufende VM erfolgen.
Wichtige Netzwerkeinstellung: Wenn die VM wie ein gleichberechtigter Rechner im lokalen Netz arbeiten soll (etwa als Server), hilft die Umstellung von „NAT“ auf „Netzwerkbrücke“.
8. Virtuelle Maschinen umziehen
Bei längerer Benutzung von Virtualbox summieren sich schnell einige VMs, die mit großen virtuellen Festplatten die Kapazität der Systempartition überfordern. Wenn alternative Datenträger zur Verfügung stehen, dann ist der Umzug von VMs kein Problem: Sie klicken einfach im Virtualbox Manager mit rechter Maustaste auf die betreffende VM und wählen dann „Verschieben“. Die Option ist nur aktiv, wenn die VM aktuell ausgeschaltet ist. Danach müssen Sie nur noch zum gewünschten, neuen Zielordner navigieren. Virtualbox verschiebt dabei den Ordner mit dem Namen der VM inklusive Konfigurationsdatei (.vbox) und virtueller Festplatte (.vdi).
Wenn Sie ab einem bestimmten Zeitpunkt aus Platzgründen alle neu hinzukommenden VMs an einer anderen Stelle ablegen wollen, dann ändern Sie im Virtualbox Manager mit „Datei -> Einstellungen -> Allgemein“ den voreingestellten Standardpfad für die VMs. Die VMs aus dem bisherigen Standardpfad funktionieren weiterhin.
9. Virtuelle Festplatten von Vmware
Virtualbox kann die virtuellen Festplatten des Vmware Player (*.vmdk) direkt und ohne Konvertierung nutzen. Beim Erstellen einer VM wählen Sie beim Punkt „Virtuelle Festplatte“ die Option „Eine vorhandene virtuelle Festplatte verwenden“ und navigieren dann zur VMDK-Datei. Klicken Sie auf die erste, unbezifferte und kleinste dieser Dateien. Das ist der Verwaltungszeiger auf eventuell zahlreiche Inhaltsdateien einer dynamischen Festplatte. Die restliche Einrichtung der VM verläuft unverändert.
10. Virtualbox via Terminal
Virtualbox ist lückenlos – ohne grafischen Virtualbox Manager – über Terminalbefehle zu bedienen. Ein Motiv dafür werden Desktop-Nutzer angesichts der komfortablen Oberfläche zunächst nicht sehen. Im Netzwerk und mit SSH-Verbindung zum Hostsystem kann diese Option aber nützlich werden. Dann ist nämlich nach SSH-Anmeldung am Hostsystem eine VM etwa mit
vboxmanage startvm "Cent-OS"
übers Netzwerk zu starten. Die auf dem Host vorhandenen VMs und deren genaue Namen kann der Befehl vboxmanage list vms ermitteln. Mit
vboxmanage controlvm "Cent-OS" poweroff
ist eine VM per SSH-Befehl auch wieder zu beenden. Für grafische VM-Desktops ist solche Fernbedienung kaum relevant, wohl aber für VMs, die im Netzwerk eine Serverfunktion erfüllen. Und auf dem lokalen Hostsystem kann die Terminalmethode nützlich sein, um eine VM per Autostart automatisch zu laden.
Einfacher Import: Eine komplette VM im OVA-Format enthält das Festplattenabbild plus Konfiguration des virtuellen PCs. Letztere können Sie bei Bedarf anpassen.
11. Fertige virtuelle VMs
Virtuelle Maschinen muss man nicht zwingend in Virtualbox konfigurieren, danach manuell installieren und mit Software und Diensten ausstatten. Windows, zahlreiche Linux-Desktops und viele Linux-Server gibt es komplett vorkonfiguriert zum Download. Im Prinzip ersparen Sie sich damit die Hardware-Einrichtung in Virtualbox, die anschließende Installation des Systems und eventuell die Konfiguration eines komplexen Serverdienstes. Ob und wo sich das wirklich lohnt, hängt aber vom Verwendungszweck und vom Nutzer-Knowhow ab.
OVA-Format: Eingepackte PCs
Die standardisierte Hardware virtueller Maschinen macht es möglich, komplette Systeme einzupacken (Appliance) und diese auf jedem anderen Rechner via Virtualisierer zu starten. Als Virtualbox-Nutzer werden Sie theoretisch selbst mühelos zum Appliance-Entwickler, indem Sie eine sorgfältig konfigurierte VM mit dem Menü „Datei -> Appliance exportieren“ als Appliance sichern und weitergeben können. Das Resultat der Aktion ist eine OVA-Datei (Open Virtual Appliance), im Prinzip ein gepacktes TAR-Archiv. Vmware kennt die Methode analog und verwendet dabei das Format OVF (Open Virtualization Format). Dieses kann Virtualbox ebenso wie sein natives OVA-Format mit „Datei -> Appliance importieren“ importieren.
Virtuelle Appliances werden aber nicht immer im OVA-Format angeboten: Die Seite www.osboxes.org liefert zum Beispiel grundsätzlich nur die virtuelle Festplatte aus, also VDI-Dateien für Virtualbox. Was ist der Unterschied zu OVA? Virtuelle Maschinen für Virtualbox bestehen im Wesentlichen nur aus dem VDI-Festplattenabbild und einer kleinen XML-Konfigurationsdatei mit der Endung „.vbox“. Folglich genügt eigentlich die virtuelle Festplatte, denn die Konfiguration für ein System ist mit dem Virtualbox Manager in drei Minuten erstellt. Das OVA-Paket hat daher gegenüber einem puren VDI-Abbild nur den kleinen Vorteil, die Konfiguration mitzuliefern, und als zweiten Vorteil eine reduzierte Downloadgröße dank Komprimierung.
Schlüsselfertige Desktop-VMs
Die schon genannte Site www.osboxes.org bietet nur die Festplattenabbilder. Klicken Sie dort auf „VM Images“ und wählen Sie das benötigte Format – VDI für das hier bevorzugte Virtualbox. Die zahlreichen virtuellen Festplatten sind standardmäßig 7z-gepackt. Unter Windows muss daher der Packer 7-Zip vorliegen (www.7-zip.de), unter Linux ist 7z-Unterstützung in der Regel Standard und im Bedarfsfall mit
sudo apt install p7zip p7zip-full
schnell nachgerüstet. Die VDI-Images lassen sich dann einbinden, indem Sie in Virtualbox eine neue virtuelle Maschine erstellen und bei der Festplattenkonfiguration „Eine vorhandene virtuelle Festplattendatei verwenden“. Dazu klicken Sie auf das Ordnersymbol und navigieren zur heruntergeladenen VDI-Datei (der Pfad ist im Prinzip beliebig, aber für bessere Übersicht empfiehlt sich ein Sammelordner für solche VDIs). Nach Auswahl und „Hinzufügen“ ist die VM schon startklar.
Bei den Osboxes-Images handelt es sich überwiegend um Linux-Desktops (von „Android x86“ bis „Zorin OS“), die Sie anschließend beliebig anpassen können. Ganz ohne Pflegeaufwand sind sie dennoch nicht: Wenn Ihnen das voreingestelle Standardkonto – meist „osboxes“ mit Kennwort „osboxes.org“ – nicht zusagt, müssen Sie ein neues Konto einrichten. Oberfläche, Tastatur, Zeitzone sind grundsätzlich US-amerikanisch, was in den Regions- und Sprach-Einstellungen des jeweiligen Systems geändert werden muss.
Weitere Eigenheiten einer Appliance sind nie auszuschließen. Der Download einer fertigen Desktop-Appliance garantiert zwar den besonders schnellen Einsatz, bleibt aber eher eine Empfehlung für die unkomplizierte Wegwerf-VM. Zudem bietet www.osboxes.org nicht durchgehend aktuelle Versionen, sondern zum Teil auch ältere Systeme. Wer eine Desktop-VM für den nachhaltigen Dauerbetrieb einrichten will, nimmt vielleicht doch besser die Mühe der Installation mit dem Originalsystem in Kauf.
Windows-Appliance von Microsoft
Microsoft bietet virtuelle Windows-Maschinen unter https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ kostenlos zum Download an. Das Angebot richtet sich an Entwickler, die Webseiten mit Edge testen wollen. Es handelt sich aber um komplette Windows-Systeme, die 90 Tage ohne Einschränkung laufen. Das verfügbare Windows 10 („MsEdge on Win10 (x64) Stable 1809“) hat eine Downloadgröße von 6,7 GB. Unter „Select platform“ stellen Sie „Virtualbox“ ein. Den gezippten Download entpacken Sie, öffnen die OVA-Datei per Doppelklick in Virtualbox oder wählen dort „Datei -> Importieren“.
Microsoft gibt auf der Website den Tipp, vor dem ersten Start einen Schnappschuss der VM zu erstellen. Stellen Sie diesen vor Ablauf der 90 Tage wieder her, dann lässt sich die Windows-Appliance weitere 90 Tage nutzen. Dieser Hinweis und weitere Tipps zum Verlängern der Laufzeit erscheinen auch beim ersten Start der VM unübersehbar als Wallpaper. Für Linux-Anwender, die Windows vorübergehend für spezielle Software benötigen, ist die Appliance die eindeutig einfachere Alternative gegenüber der Installation des Windows-10-Enterprise-ISOs.
Ohne Nachbearbeitung geht es aber nicht: Das Wallpaper mit den Tipps wird früher oder später lästig. Eventuell wollen Sie auch das Standardkonto „IEUser“ mit Passwort „Passw0rd!“ ändern. Und auch die englischsprachige Oberfläche sowie die Zeitzone müssen über die „Einstellungen“ (Win-I) und „Time & Language -> Region“ erst auf Deutsch und europäische Zeitzone gesetzt werden.
Die kostenlosen Windows-VMs von Microsoft sind primär für Webentwickler gedacht, enthalten aber ein vollständiges Windows für jeden Einsatzzweck.
Server-Appliances von Bitnami & Co
Auf Serversysteme spezialisiert sind die Sites www.bitnami.com und www.turnkeylinux.org. Hier erhalten Sie – überwiegend in OVA-Format – CMS-Systeme wie Drupal, Typo3, Joomla und WordPress sowie eine Vielzahl von Shop- und Entwicklungssystemen. Die VMs sind mit allem ausgestattet, was zum Betrieb notwendig ist, und ersparen Installation und Konfiguration von Apache/Nginx, Mysql und PHP. Das ist für alle, erst recht für unerfahrene Nutzer ein unschätzbarer Gewinn. Natürlich sind auch die Netzwerkeinstellungen der VM gleich so gesetzt („Netzwerkbrücke“), dass Serveranwendungen sofort funktionieren.
Eher an Entwickler und Firmen richtet sich das Appliance-Angebot von Vmware (https://marketplace.vmware.com/vsx). Das Portal bietet vorkonfigurierte Spezialsysteme. Nicht alle virtuelle PCs sind hier frei verfügbar, einige erfordern eine Registrierung oder eine Gebühr.
Eine einmal optimierte VM als OVA-Paket oder als VDI-Image weiterzugeben, ist denkbar einfach. Daher lohnt sich die Suche nach einem solchen Angebot auch bei vielen Einzelprojekten, wie folgende, eher zufällig gewählte Beispiele abschließend zeigen sollen:
Only Office: Im Downloadbereich www.onlyoffice.com/de/download-docs.aspx lässt sich nach einem Klick auf „Community“ die „Univention-Anwendung“ wahlweise mit Nextcloud oder Owncloud als VM herunterladen und in Virtualbox importieren.
Whonix: Das anonymisierende Surfsystem ist in der Zielsetzung mit dem Livesystem Tails vergleichbar, hat aber als Virtualbox-Appliance einen anderen Ansatz mit zwei parallelen VMs. Die OVA-Appliance mit circa 2,2 GB gibt es unter www.whonix.org/wiki/VirtualBox/XFCE. Nach dem Import in Virtualbox erscheinen zwei neue VMs, wovon Sie immer erst das Gateway, danach die Workstation starten. Das Konstrukt erscheint aufwändig, läuft aber auf jedem durchschnittlichen Rechner mühelos.
Die aus England stammende KDE Neon User Edition bietet auf Ubuntu-Basis einen immer hochaktuellen KDE-Plasma-Desktops – in diesem Fall KDE Plasma 5.14.5. Im Unterschied zum bekannteren und nicht weit entfernten Kubuntu steht hier KDE absolut im Fokus. Die Desktop-Komponenten erhalten laufende Updates, während die Ubuntu-Systembasis beim erprobten Stand der 18.04-LTS-Ausgabe bleibt.
Die delikate, neueste KDE-Plasma-Oberfläche ist per se eine Bedienerführung für Feinschmecker und mit ihrer Flexibilität ein Gegenentwurf zum simplifizierenden Gnome und seiner Abkömmlinge. KDE Neon User Edition spricht daher in erster Linie anspruchsvolle Nutzer an: Die Anpassungsmöglichkeiten der Kontrollleiste(n), der Desktop-Designs, der Plasma-Widgets und der exzellenten KDE-Standards wie des Dateimanager Dolphin dürften Einsteiger überfordern, Systembastler hingegen begeistern. Nichtsdestotrotz liefert diese Distribution ab Installation einen eleganten, modernen Desktop mit klassischem Menü und Dateiablage, mit dem auch ein Windows-Umsteiger klarkommt. Zudem hat das ehemals sehr anspruchsvolle KDE seinen Ressourcenhunger gezähmt und fordert heute weniger RAM als ein Gnome oder Cinnamon.
KDE Neon nutzt zur Einrichtung aus dem Livesystem den bewährten Ubuntu-Installer, wenngleich dieser optisch angepasst wurde und daher deutlich anders aussieht. Die Software-Nachrüstung erfolgt über die exzellente Programmverwaltung Discover oder mit apt get install […] im Terminal. Alle Anpassungsoptionen versammeln die „Systemeinstellungen“, während Leistenänderungen und Desktop-Widgets direkt am Objekt über Kontextmenüs erfolgen.
Delikates KDE Neon für Ästheten: Schicke, dezente Effekte, kontrastreiche Designs, logisch organisierte Systemzentralen und reiche Anpassungsdetails sprechen vor allem Poweruser an.
Schnelle Terminal-Dateisuche ist auf Servern unerlässlich, aber auch auf dem Desktop willkommen. Tool der Wahl ist aufgrund seiner Geschwindigkeit locate, das auf Ubuntu-Systemen mit
sudo apt install plocate
schnell nachgerüstet ist (das ältere mlocate wird heute überwiegend durch das schnellere plocate ersetzt). Das Paket enthält neben diesem Suchkommando locate auch das Indexierungstool updatedb. Damit die Dateiliste aktuell bleibt, muss je nach Rechnernutzung täglich oder auch häufiger der Befehl
sudo updatedb
ausgeführt werden. Das ist wieder ein Fall für einen Cronjob des root-Kontos (crontab -e):
0 10 * * * /usr/bin/updatedb
locate sucht nur nach Dateinamen, aber ein Befehl wie
locate -A -i steuer 2020
liefert sofort alle passenden Dateien mit komplettem Pfad – auch bei sehr großen Datenbeständen. Die lästige Eingabe der fast immer notwendigen Parameter „-A“ (alle Wörter müssen im Dateinamen vorkommen) und „-i“ (Groß/Kleinschreibung ignorieren) können Sie sich mit einem Alias
alias loc='locate -A -i'
in der Datei ~/.bashrc ersparen.
Standardmäßig berücksichtigt locate keine USB-Laufwerke. Um dies zu ändern, muss in der Konfigurationsdatei „/etc/updatedb.conf“ nach „PRUNEFS=…“ (ausgeschlossene Dateisysteme) der Eintrag „usbfs“ gelöscht werden, und bei dieser Gelegenheit bei Bedarf noch weitere Eintäge dieser Zeile.
Locate-Statistik: Einige hunderttausend Dateien sind für das indexbasierte Tool keine beschwerliche Aufgabe. Die Ergebnisse einer locate-Namenssuche erscheinen sofort.
Cubic (Custom Ubuntu ISO Creator) ist ein grafisches Frontend für die Linux-Fähigkeiten, in gemountete ISO-Images mit einer Chroot-Umgebung neue Dateien einzubauen und danach ein geändertes ISO zu schreiben. Der Schritt-für-Schritt-Assistent ist vorbildlich übersichtlich, erweitert die Standard-Live-Medien von Ubuntu & Co mühelos um Software und Benutzerdateien und baut optimierte Livesysteme. Detailliertere Anpassungen sind möglich, setzen aber auch mit Cubic gute Kenntnis der Verzeichnishierarchie des Livesystems voraus.
Wie auf der Porjektseite https://launchpad.net/cubic beschreiben, installieren Sie das Tool mit folgenden Terminalbefehlen:
sudo apt-add-repository ppa:cubic-wizard/release
sudo apt update
sudo apt install cubic
Nach dem Start geben Sie erst ein (beliebiges) „Project Directory“ an, wo Cubic das Livesystem zusammenbauen soll. Nach „Next“ und „Select“ wählen Sie zunächst das ISO-Image des originalen Livesystems. Weitere Änderungen sind in diesem Dialog nicht nötig und nach „Next“ wird das Dateisystem des ISO-Abbilds temporär ausgepackt.
Nach weiterem „Next“ wird es spannend: In chroot-Konsole können Sie jetzt alle Anpassungen erledigen. Mit apt install […] rüsten Sie alles nach, was dem originalen Livesystem nach Ihrer Meinung fehlt. Benutzer- und Konfigurationsdateien können Sie einfach per Drag & Drop vom laufenden System in die chroot-Konsole von Cubic ziehen und dann mit der „Copy“-Schaltfläche in das Livesystem integrieren. Beachten Sie dabei, vorher mit cd in der chroot-Konsole in das gewünschte Verzeichnis zu wechseln – genau dort werden die Dateien später vorliegen. Sie können auch mit mkdir Ordner erstellen, um das Livesystem zu optimieren. Im konkreten Beispiel des von uns gewählten Lubuntu lautet das Live-Konto „lubuntu“, jedoch existiert kein Home-Ordner für dieses Konto. Wenn Sie dieses mit
mkdir /home/lubuntu
anlegen, können Sie es mit weiteren Ordner bestücken (etwa „Desktop“, „Bilder“) und diese wiederum mit Benutzerdateien sowie Konfigurationsdateien füllen (.bashrc. etc), aber auch mit einer kompletten Thunderbird-Konfiguration. Um Ordner und Dateien richtig anzulegen, sollten Sie die Ordnerstruktur des originalen Livesystems gut kennen oder parallel vor sich haben. Mit „Next“ verlassen Sie die chroot-Konsole, mit weiterem „Next“ die Paketübersicht. Danach wird das angepasste System zusammengebaut. Das fertige ISO können Sie mit den üblichen Werkzeugen auf DVD brennen oder auf USB schreiben.
Trotz Beschränkung auf Ubuntu & Co ist Cubic aktuell das wohl komfortabelste Tool, um Livesysteme individuell aufzubessern. Das im nächsten Punkt beschriebene Systemback ist im Prinzip noch flexibler, wird aber nicht mehr aktualisiert und hat technische Hürden.
Cubic – der erste und der letzte Schritt: Das Tool schreibt angepasste Ubuntu-Livesysteme mit einem sehr übersichtlichen Schritt-für-Schritt-Assistenten.
