Ubuntu Manpage: portablectl - Portierbare Diesteabbilder anhängen, abhängen oder untersuchen

BEZEICHNUNG

       portablectl - Portierbare Diesteabbilder anhängen, abhängen oder untersuchen

ÜBERSICHT

       portablectl [OPTIONEN…] {BEFEHL} [NAME…]

BESCHREIBUNG

portablectl kann zum Anhängen, Abhängen und Untersuchen von portablen Diensteabbildern
verwandt werden. Es ist primär eine Befehlsschnittstelle zu systemd-portabled.service(8).

Portierbare Diensteabbilder enthalten einen Dateisystembaum eines Betriebssystems zusammen
mit systemd(1)-Unit-Dateiinformationen. Ein Diensteabbild kann an das lokale System
»angehängt« sein. Falls angehängt, wird eine Gruppe von Unit-Dateien von dem Abbild zum
Rechner kopiert und mit der Zuweisung RootDirectory= oder RootImage= erweitert (im Falle
von Dienste-Units), die auf die Abbild-Datei oder das Abbild-Verzeichnis zeigen. Damit ist
sichergestellt, dass die Dienste innerhalb des Dateisystemkontextes des Abbildes
ausgeführt werden.

Portierbare Diensteabbilder stellen eine effiziente Art dar, mehrere zusammengehörige
Dienste und andere Units zu bündeln und sie als ganzes zwischen Maschinen zu übertragen.
Wenn diese Abbilder an das lokale System angebunden werden, können die enthaltenen Units
größtenteils wie reguläre, vom System bereitgestellte Units ausgeführt werden, abhängig
von der ausgewählten Konfiguration entweder mit kompletten Privilegien oder innerhalb
einer strengen Sandbox-Umgebung. Für weitere Details siehe Portable Dienste[1].

Portierbare Diensteabbilder können insbesondere von folgendem Typ sein:

• Verzeichnisbäume, die ein Betriebssystem enthalten, einschließlich der Verzeichnisse
auf oberster Ebene wie /usr/, /etc/ usw.

• Btrfs-Teildatenträger, die Betriebssystembäume enthalten, ähnlich zu normalen
Verzeichnisbäumen.

• Binäre »rohe« Plattenabbilder, die eine MBR- oder GPT-Partitionstabelle und
Linux-Dateisystempartitionen enthalten. (Dies müssen reguläre Dateien mit der Endung
.raw sein.)

BEFEHLE

Die folgenden Befehle werden verstanden:

list
Listet verfügbare portierbare Diensteabbilder auf. Dies listet alle in dem
(nachfolgend beschriebenen) Suchpfad für portierbare Diensteabbilder gefundenen
portierbaren Diensteabbilder auf, zusammen mit kurzen Metadaten- und
Zustandsinformationen. Beachten Sie, dass viele der nachfolgenden Befehle auf Abbilder
innerhalb und außerhalb der Suchpfade agieren können. Dieser Befehl ist deshalb
hauptsächlich eine Bequemlichkeitsoption, die Befehle sind im Allgemeinen nicht darauf
beschränkt, was diese Liste zeigt.

attach ABBILD [PRÄFIX…]
Hängt ein portierbares Diensteabbild an das System an. Erwartet als erstes Argument
einen Dateisystempfad zu dem portierbaren Diensteabbild oder dem Verzeichnis. Falls
der angegebene Pfad keinen Schrägstrich (»/«) enthält, wird dies als Abbilddateiname
aufgefasst, nach dem in den (nachfolgend beschriebenen) Suchpfaden für portierbare
Diensteabbilder gesucht wird. Um auf eine Datei im aktuellen Arbeitsverzeichnis zu
verweisen, stellen Sie dem Dateinamen »./« voran, um diese Suchpfadlogik zu vermeiden.

Wenn ein portierbarer Dienst angehängt wird, erfolgen vier Aktionen:

1. Alle Unit-Dateien der Typen .service, .socket, .target, .timer und .path, die auf
das angegebene Unit-Dateinamenpräfix passen, werden vom Abbild in das Verzeichnis
/etc/systemd/system.attached/ (oder /run/systemd/system.attached/, abhängig davon,
ob --runtime angegeben wurde, siehe oben) kopiert. Dieses Verzeichnis ist Teil des
eingebauten Unit-Suchpfades für den Systemdiensteverwalter.

2. Für Unit-Dateien vom Typ .service wird eine Ergänzungsdatei zu diesen Kopien
hinzugefügt, die RootDirectory=- oder RootImage=-Einstellungen hinzufügt (siehe
systemd.unit(5) für Details), um sicherzustellen, dass diese Dienste innerhalb des
Dateisystems des ursprünglichen portierbaren Diensteabbildes ausgeführt werden.

3. Es wird eine zweite Ergänzungsdatei erstellt: die »Profil«-Ergänzung, die
zusätzliche Sicherheitseinstellungen (und andere Einstellungen) enthalten kann.
Standardmäßig sind eine Reihe von Profilen verfügbar, aber der Administrator kann
auch seine eigenen definieren. Mehr Informationen nachfolgend.

4. Falls die portierbare Diensteabbilddatei noch nicht im (nachfolgend beschriebenen)
Suchpfad ist, wird darauf in /etc/portables/ oder /run/portables/ ein symbolischer
Link erstellt, damit die Aufnahme sichergestellt ist.

Standardmäßig werden alle Unit-Dateien, deren Namen mit einem aus der Abbilddatei
erstellten Präfix beginnen, rauskopiert. Das Präfix wird konkret aus dem Abbildnamen
bestimmt, wobei jede Endung wie ».raw« entfernt wird und der Name beim ersten
Auftreten eines Unterstrichs (»_«) abgeschnitten wird, falls einer vorhanden ist. Die
Unterstrich-Logik soll der Versionierung dienen, so dass eine Abbilddatei
»foobar_47.11.raw« zu einer Unit-Datei, die auf das Präfix »foobar« passt, führt.
Dieses Präfix wird dann mit allen Unit-Dateien, die im Abbild in den gewöhnlichen
Verzeichnissen enthalten sind, verglichen, aber nur Unit-Dateinamen, bei denen auf das
Präfix »-«, ».« oder »@« folgen, werden betrachtet. Beispiel: Falls eine portierbare
Diensteabbilddatei den Namen »foobar_47.11.raw« trägt, dann werden standardmäßig alle
seine Unit-Dateien mit Namen wie foobar-quux-waldi.service, foobar.service or
foobar@.service in Betracht gezogen. Es ist möglich, das Vergleichspräfix außer Kraft
zu setzen: alle Zeichenketten, die auf der Befehlszeile nach dem Abbildnamen
aufgeführt sind, werden als Präfix betrachtet und setzen damit die implizite Logik
außer Kraft, bei der das Präfix aus dem Abbilddateinamen abgeleitet wird.

Standardmäßig wird die Konfiguration des Diensteverwalters neugestartet, nachdem die
Unit-Dateien angehängt wurden, außer --no-reload ist angegeben (siehe oben). Dies
stellt sicher, dass die neuen Units, die dem Diensteverwalter zur Verfügung gestellt
wurden, von diesem auch gesehen werden.

Falls --now und/oder --enable übergeben werden, werden der oder die portierbaren
Dienst(e) sofort gestartet (blockieren, außer --no-block wurde übergeben) und/oder
aktiviert, nachdem das Abbild angehängt wurde.

detach ABBILD [PRÄFIX…]
Hängt ein portierbares Diensteabbild vom Rechner ab. Dies macht die von dem oben
beschriebenen Befehl attach vorgenommenen Aktionen rückgängig und entfernt die
Unit-Datei-Kopien, Ergänzungen und Abbild-Symlinks wieder. Dieser Befehl erwartet
einen Abbilddateinamen oder -pfad als Parameter. Beachten Sie, dass bei der reinen
Angabe eines Pfades nur die letzte Komponente davon (d.h. die Datei oder der
Verzeichnisname selbst, nicht der Pfad dahin) zum Finden von passenden Unit-Dateien
verwandt wird. Dies ist eine Bequemlichkeitsfunktion, um alle Argumente, die an attach
übergeben wurden, auch bei detach zu verwenden.

Falls --now und/oder --enable übergeben werden, werden der oder die portierbaren
Dienst(e) sofort gestoppt (blockierende Aktion) und/oder deaktiviert, bevor das Abbild
abgehängt wird. Präfix(e) werden auch für den Fall akzeptiert, dass die Unit-Namen
nicht auf die Abbildnamen (siehe die Beschreibung bei attach) passen.

reattach ABBILD [PRÄFIX…]
Hängt ein bestehendes portierbares Diensteabbild vom Rechner ab und hängt es sofort
wieder an. Dies ist nützlich, falls das Abbild ersetzt wurde. Während des Vorgangs
werden ausgeführte Units nicht gestoppt. Teilweiser Vergleich wird unterstützt, um
verschiedene Versionen im Abbildnamen zu erlauben: nur der Teil vor dem ersten
»_«-Zeichen wird verglichen. Falls das neue Abbild nicht existiert, wird das
bestehende nicht abgehängt. Die Parameter folgen der gleichen Syntax wie beim Befehl
attach.

Falls --now und/oder --enable übergeben werden, werden der oder die portierbaren
Dienst(e) sofort gestoppt, falls sie entfernt werden und/oder aktiviert, falls sie
hinzugefügt werden, oder neugestartet, falls sie aktualisiert werden. Präfix(e) werden
auch akzeptiert, wie im Fall attach.

inspect ABBILD [PRÄFIX…]
Extrahiert die verschiedenen Metadaten aus einem portierbaren Diensteabbild und zeigt
sie dem Aufrufenden. Es werden insbesondere die Datei os-release(5) des Abbildes sowie
alle passenden Unit-Dateien angezeigt. Standardmäßig wird eine kurze Zusammenfassung
der relevantesten Metadaten in Kombination mit einer Liste der passenden Unit-Dateien
(d.h. der Unit-Dateien, die attach im System installieren würde) angezeigt. Falls mit
--cat (siehe oben) kombiniert, werden die Daten aus »os-release« und die Unit-Dateien
unverändert angezeigt. Dieser Befehl ist nützlich, um zu bestimmen, ob das Abbild sich
als portierbares Diensteabbild eignet und welche Unit-Dateien enthalten sind. Der
Befehl erwartet einen Pfad zu dem Abbild als Parameter, optional von einer Liste von
zu betrachtenden Unit-Dateipräfixen gefolgt, ähnlich wie beim oben beschriebenen
Befehl attach.

is-attached ABBILD
Bestimmt, ob das angegebene Abbild derzeit angehängt ist oder nicht. Dies zeigt einen
kurzen Zustandskennzeichner für das Abbild, außer es wurde mit dem Schalter --quiet
kombiniert. Konkret:

Tabelle 1. Abbildanhängezustände
┌─────────────────┬──────────────────────────────────┐
│Zustand │ Beschreibung │
├─────────────────┼──────────────────────────────────┤
│detached │ Das Abbild ist derzeit nicht │
│ │ angehängt. │
├─────────────────┼──────────────────────────────────┤
│attached │ Das Abbild ist derzeit │
│ │ angehängt, d.h. seine │
│ │ Unit-Dateien wurden dem System │
│ │ zur Verfügung gestellt. │
├─────────────────┼──────────────────────────────────┤
│attached-runtime │ Wie attached, aber die │
│ │ Unit-Dateien wurden nur │
│ │ vorübergehend verfügbar gemacht, │
│ │ d.h. der Befehl attach wurde mit │
│ │ der Option --runtime aufgerufen. │
├─────────────────┼──────────────────────────────────┤
│enabled │ Das Abbild ist derzeit angehängt │
│ │ und mindestens eine ihr │
│ │ zugeordnete Unit-Datei wurde │
│ │ aktiviert. │
├─────────────────┼──────────────────────────────────┤
│enabled-runtime │ Wie enabled, aber die │
│ │ Unit-Dateien wurden nur │
│ │ vorübergehend verfügbar gemacht, │
│ │ d.h. der Befehl attach wurde mit │
│ │ der Option --runtime aufgerufen. │
├─────────────────┼──────────────────────────────────┤
│running │ Das Abbild ist derzeit angehängt │
│ │ und mindestens eine ihr │
│ │ zugeordnete Unit-Datei wird │
│ │ ausgeführt. │
├─────────────────┼──────────────────────────────────┤
│running-runtime │ Das Abbild ist derzeit │
│ │ vorübergehend angehängt und │
│ │ mindestens eine ihr zugeordnete │
│ │ Unit-Datei wird ausgeführt. │
└─────────────────┴──────────────────────────────────┘

read-only ABBILD [LOGISCH]
Markiert ein portierbares Diensteabbild nur-lesbar oder hebt dies auf. Akzeptiert
einen Abbild-Namen als Argument, gefolgt von einem logischen Wert. Falls der logische
Wert fehlt, wird positiv impliziert, d.h. das Abbild als nur-lesbar markiert.

remove ABBILD…
Entfernt eines oder mehrere portierbare Dienste-Abbilder. Beachten Sie, dass dieser
Befehl nur den angegebenen Abbildpfad selbst entfernt. Ist dieser ein symbolischer
Link, dann wird der Link entfernt und nicht das Abbild, auf den er zeigt.

set-limit [ABBILD] BYTES
Setzt die maximale Anzahl in Byte, auf die ein bestimmtes portables Diensteabbild oder
alle Abbilder auf der Platte anwachsen dürfen (Plattenkontingent). Akzeptiert einen
oder zwei Parameter. Der erste, optionale Parameter bezieht sich auf den Namen des
portablen Diensteabbilds. Falls angegeben, wird die Größenbegrenzung des angegebenen
Abbildes geändert. Falls er fehlt, wird die Gesamtgrößenbeschränkung für die Summe
aller lokal gespeicherten Abbilder geändert. Das abschließende Argument gibt die
Größenbeschränkung in Byte an. Dabei können die üblichen Einheiten K, M, G, T
angehängt werden. Falls die Größenbegrenzung deaktiviert werden soll, verwenden Sie
»-« als Größe.

Beachten Sie, dass die Abbild-bezogenen Größenbeschränkungen nur auf
Btrfs-Dateisystemen unterstützt werden. Auch können, abhängig von der Einstellung
BindPaths= in der portierbaren Dienste-Unit-Datei, Verzeichnisse während der Laufzeit
in der Abbild-Umgebung sichtbar werden, die von dieser Einschränkung nicht betroffen
sind, da nur das Abbild selbst gegenüber der Beschränkung betrachtet wird.

OPTIONEN

Die folgenden Optionen werden verstanden:

-q, --quiet
Unterdrückt bei der Ausführung zusätzliche Informationsausgabe.

-p PROFIL, --profile=PROFIL
Wählt beim Anhängen eines Abbilds das zu verwendende Profil. Standardmäßig wird das
Profil »default« verwandt. Details zu Profilen werden nachfolgend beschrieben.

--copy=
Wählt beim Anhängen eines Abbildes aus, ob Kopieren oder Anlegen von Symlinks zur
Installation von Dateien im System bevorzugt wird. Akzeptiert entweder »copy« (um das
Kopieren zu bevorzugen), »symlink« (um das Anlegen von Symlinks zu bevorzugen) oder
»auto« für einen Zwischenmodus, bei dem für Sicherheitsprofilergänzungsdateien
Symlinks angelegt und Unit-Dateien kopiert werden. Beachten Sie, dass diese Option nur
eine Präferenz ausdrückt: Falls symbolische Links nicht erstellt werden können,
beispielsweise wenn das Abbild, auf dem agiert wird, ein rohes Plattenabbild ist und
daher vom System aus nicht direkt auf dessen Dateisystem referenziert werden kann,
wird bedingungslos kopiert.

--runtime
Wenn angegeben, legt die Unit und Ergänzungsdateien in /run/systemd/system.attached/
statt in /etc/systemd/system.attached/ ab. Mit dieser Option angehängte Abbilder
bleiben daher nur bis zum nächsten Systemneustart angehängt, während sie ansonsten
dauerhaft angehängt bleiben.

--no-reload
Lädt den Diensteverwalter nach An- oder Abhängen eines portierbaren Diensteabbildes
nicht neu. Normalerweise wird der Diensteverwalter neu geladen, um sicherzustellen,
dass er hinzugefügte oder entfernte Unit-Dateien bemerkt.

--cat
Zeigt bei der Untersuchung portabler Diensteabbilder die (unverarbeiteten) Inhalte der
von diesem Abbild hereingezogenen Metadaten statt einer kurzen Zusammenfassung an.
Dies wird insbesondere das os-release(5) und die Unit-Datei-Inhalte des Abbildes
anzeigen.

--enable
Aktiviert/Deaktiviert den portierbaren Dienst nach dem An-/Abhängen sofort.

--now
Startet/Stoppt/Neustartet den portierbaren Dienst sofort nach dem Anhängen/vor dem
Abhängen/nach dem Upgrade.

--no-block
Blockiert beim Warten auf den Abschluss einer Anhängung mit --now nicht.

--extension=PFAD
Fügt ein zusätzlichen Abbild-PFAD als Überlagerung oberhalb von ABBILD beim
Anhängen/Abhängen hinzu. Dieses Argument kann mehrfach angegeben werden, wodurch dann
die Reihenfolge, in der Abbilder abgelegt werden, den in systemd.exec(5) für die
Direktive ExtensionImages= und der für das Werkzeug systemd-sysext(8) festgelegten
Regeln folgt. Das oder die Abbilder müssen eine Datei extension-release mit Metadaten
enthalten, die zu dem passen, was in der os-release von ABBILD definiert ist. Siehe
os-release(5). Abbilder können Block-Abbilder, Btrfs-Teildatenträger oder
Verzeichnisse sein. Für weitere Informationen über portierbare Dienste mit
Erweiterungen siehe den Abschnitt über »Extension Images« in Portable Dienste[1].

Beachten Sie, dass die gleichen Erweiterungen, in der gleichen Reihenfolge, bei
Anhängen und Abhängen angegeben werden müssen.

-H, --host=
Führt die Aktion aus der Ferne aus. Geben Sie den Rechnernamen oder einen
Benutzernamen und Rechnernamen (getrennt durch »@«) an, zu dem verbunden werden soll.
Dem Rechnernamen darf optional ein Port, auf dem SSH auf Anfragen wartet, getrennt
durch »:« und dann ein Container auf dem angegebenen Host angehängt werden, womit
direkt zu einem bestimmten Container auf dem angegebenen Rechner verbunden wird. Dies
verwendet SSH, um mit der Maschinen-Verwalterinstanz auf dem Rechner in der Ferne zu
kommunizieren. Container-Namen dürfen mit machinectl -H RECHNER aufgezählt werden.
Stellen Sie IPv6-Adressen in Klammern.

-M, --machine=
Führt die Aktion in einem lokalen Container aus. Geben Sie den Namen des Containers
an, zu dem verbunden werden soll. Optional kann diesem ein Benutzername, abgetrennt
durch ein »@«-Zeichen, als der verbunden werden soll, vorangestellt werden. Falls die
besondere Zeichenkette ».host« anstelle des Container-Names verwandt wird, wird eine
Verbindung zu dem lokalen System aufgebaut (das ist nützlich, um sich zu dem
Benutzerbus eines bestimmten Benutzers zu verbinden: »--user --machine=lennart@.host«.
Falls die »@«-Syntax nicht verwandt wird, wird die Verbindung als Benutzer »root«
vorgenommen. Falls die »@«-Syntax verwandt wird, kann entweder die linke oder die
rechte Seite fortgelassen werden (aber nicht beide). In diesem Fall wird der lokale
Benutzername und ».host« angenommen.

--no-pager
Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.

--no-legend
Gibt die Legende nicht aus, d.h. die Spaltenköpfe und die Fußzeile mit Hinweisen.

--no-ask-password
Befragt den Benutzer nicht für Authentifizierung für privilegierte Aktionen.

-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.

--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

DATEIEN UND VERZEICHNISSE

       Portierbare Dienste-Abbilder werden bevorzugt in /var/lib/portables/ gespeichert, werden
       aber auch in /etc/portables/, /run/systemd/portables/, /usr/local/lib/portables/ und
       /usr/lib/portables/ gesucht. Es wird empfohlen, Abbild-Dateien nicht direkt in
       /etc/portables/ oder /run/systemd/portables/ abzulegen (da diese im Allgemeinen nicht zum
       Speichern großer oder nichttextueller Daten geeignet sind), sondern diese Verzeichnisse
       nur zum Verlinken von Abbildern, die sich woanders befinden, in den Suchpfad zu verwenden.

       Wenn ein portierbares Dienste-Abbild angehängt wird, werden passende Unit-Dateien auf den
       Rechner in die Verzeichnisse /etc/systemd/system.attached/ und
       /run/systemd/system.attached/ kopiert. Beim Abhängen des Abbildes werden die Unit-Dateien
       aus diesen Verzeichnissen wieder entfernt.

PROFILE

       Wird ein portierbares Dienste-Abbild angehängt, wird eine »Profil«-Ergänzung
       hereingelinkt, die zur Erzwingung zusätzlicher lokaler Sicherheitsbeschränkungen (und
       weiterer) verwandt werden kann. Standardmäßig sind vier Profilergänzungen definiert und
       werden in /usr/lib/systemd/portable/profile/ ausgeliefert. Zusätzlich können lokale
       Profile definiert werden, indem diese in /etc/systemd/portable/profile/ abgelegt werden.
       Die Standardprofile sind:

       Tabelle 2. Profile
       ┌──────────┬─────────────────────────────────┐
       │Name      │ Beschreibung                    │
       ├──────────┼─────────────────────────────────┤
       │default   │ Dies ist das Standard-Profil,   │
       │          │ falls nicht mit --profile= ein  │
       │          │ anderer Profilname gesetzt ist  │
       │          │ (siehe oben). Es ist recht      │
       │          │ einschränkend, sollte aber für  │
       │          │ typische, nicht privilegierte   │
       │          │ Systemarbeiten geeignet sein.   │
       │          │ Dazu gehören Schreibzugriff auf │
       │          │ das Protokollierungsrahmenwerk  │
       │          │ sowie IPC-Zugriff auf das       │
       │          │ D-Bus-System.                   │
       ├──────────┼─────────────────────────────────┤
       │nonetwork │ Sehr ähnlich zu »default«, aber │
       │          │ Netzwerk ist für alle Dienste   │
       │          │ des portablen Dienste-Abbilds   │
       │          │ abgeschaltet.                   │
       ├──────────┼─────────────────────────────────┤
       │strict    │ Ein Profil mit sehr strengen    │
       │          │ Einstellungen. Dieses Profil    │
       │          │ schließt IPC- (D-Bus) und       │
       │          │ Netzwerkzugriff aus.            │
       ├──────────┼─────────────────────────────────┤
       │trusted   │ Ein Profil mit sehr entspannten │
       │          │ Einstellungen. In diesem Profil │
       │          │ laufen die Dienste mit vollen   │
       │          │ Privilegien.                    │
       └──────────┴─────────────────────────────────┘

       Für Details über diese Profile und ihre Auswirkungen schauen Sie bitte auf ihre genauen
       Definitionen, z.B. /usr/lib/systemd/portable/profile/default/service.conf und ähnliche.

EXIT-STATUS

       Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.

UMGEBUNGSVARIABLEN

$SYSTEMD_LOG_LEVEL
Die maximale Protokollierstufe ausgesandter Nachrichten (Nachrichten mit einer höheren
Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Sie muss (in
absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug oder
eine Ganzzahl im Bereich 0…7 sein. Siehe syslog(3) für weitere Informationen.

$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
ihrer Priorität eingefärbt.

Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal
geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen,
selbständig Nachrichten gemäß ihrer Protokollierungsstufe einfärben.

$SYSTEMD_LOG_TIME
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein
Zeitstempel vorangestellt.

Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal oder
in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die
Protokolle anzeigen, selbständig Zeitstempel basierend auf ihren Metadaten den
Nachrichten anhängen werden.

$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und eine
Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.

Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den
Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der
Fehlersuche in Programmen dennoch praktisch sein.

$SYSTEMD_LOG_TID
Ein logischer Wert. Falls wahr, wird den Nachrichten die aktuelle numerische
Thread-Kennung (TID) vorangestellt.

Beachten Sie, dass diese Informationen sowieso als Metadatan an Journal-Einträge
angehängt wird. Die Aufnahme direkt im Nachrichtentext kann aber trotzdem bei der
Fehlersuche in Programmen praktisch sein.

$SYSTEMD_LOG_TARGET
Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
die Vorgabe) oder null (die Protokollierung deaktivieren).

$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist; setzt $PAGER
außer Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe
wohlbekannter Textanzeigeprogrammimplementierungen der Reihe nach ausprobiert,
einschließlich less(1) und more(1), bis eines gefunden wird. Falls keine
Textanzeigeprogrammimplementierung gefunden wird, wird keines aufgerufen. Setzen der
Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist äquivalent zur
Übergabe von --no-pager.

Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER
(sowie $PAGER) ohne Rückmeldung ignoriert.

$SYSTEMD_LESS
Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.

Benutzer könnten insbesondere zwei Optionen ändern wollen:

K
Diese Option weist das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C
zu beenden. Um less die Handhabung von Strg-C selbst zum Umschalten auf die
Eingabeaufforderung zu erlauben, setzen Sie diese Option zurück.

Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene
Textanzeigeprogramm ist, wird Strg+C durch das Programm ignoriert und muss durch
das Textanzeigeprogramm selbst gehandhabt werden.

X
Diese Option weist das Textanzeigeprogramm an, keine Termcap-Initialisierungs- und
-Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist standardmäßig
gesetzt, damit die Darstellung von Befehlen selbst nach dem Beenden des
Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch einige Funktionen
des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist das Scrollen in der
Ausgabe mit der Maus nicht möglich.

Siehe less(1) für weitere Ausführungen.

$SYSTEMD_LESSCHARSET
Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das
aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.

$SYSTEMD_PAGERSECURE
Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
Seitenanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
$SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt und das
Seitenanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder
erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen unbekannt ist,
ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert nur
less(1) einen sicheren Modus.)

Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels
sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass
keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus
für das Seitenanzeigeprogramm kann wie oben beschrieben automatisch aktiviert werden.
Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus
der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige Befehle auszuführen.
Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen
$SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein,
stattdessen den Seitenanzeiger komplett mit --no-pager zu deaktivieren.

$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
zu setzen.

$SYSTEMD_URLIFY
Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
Bedingungen trifft, außer Kraft zu setzen.

SIEHE AUCH

       systemd(1), systemd-sysext(8), org.freedesktop.portable1(5), systemd-portabled.service(8)

ANMERKUNGEN

        1. Portable Dienste
           https://systemd.io/PORTABLE_SERVICES

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
       <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
       Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.