Provided by: manpages-de_4.27.0-1_all 
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 die
Portable-Dienste[1].
Portierbare Diensteabbilder können 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.
Hinzugefügt in Version 239.
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 unten)
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 unteunten). 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 die portierbaren Dienste sofort gestartet
(blockieren, außer --no-block wurde übergeben) und/oder aktiviert, nachdem das Abbild angehängt
wurde.
Anstelle des Abbildpfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
systemd.v(7) zu Details.
Anstelle des Verzeichnispfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
systemd.v(7) zu Details.
Hinzugefügt in Version 239.
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 die portierbaren Dienste 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.
Hinzugefügt in Version 239.
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 die portierbaren Dienste 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.
Hinzugefügt in Version 248.
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.
Hinzugefügt in Version 239.
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. │
└──────────────────┴───────────────────────────────────────┘
Hinzugefügt in Version 239.
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.
Hinzugefügt in Version 239.
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.
Hinzugefügt in Version 239.
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.
Hinzugefügt in Version 239.
OPTIONEN
Die folgenden Optionen werden verstanden:
-q, --quiet
Unterdrückt bei der Ausführung zusätzliche informative Ausgaben.
Hinzugefügt in Version 239.
-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.
Hinzugefügt in Version 239.
--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« (Dateien werden kopiert), »symlink« (um
das Anlegen von Symlinks zu bevorzugen), »auto« für einen Zwischenmodus, bei dem für
Sicherheitsprofilergänzungsdateien und Abbilder Symlinks angelegt und Unit-Dateien kopiert werden
oder »mixed« (seit v256), bei dem für Sicherheitsprofilergänzungsdateien Symlinks angelegt und
Abbilder 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.
Hinzugefügt in Version 239.
--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.
Hinzugefügt in Version 239.
--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.
Hinzugefügt in Version 239.
--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.
Hinzugefügt in Version 239.
--enable
Aktiviert/Deaktiviert den portierbaren Dienst nach dem An-/Abhängen sofort.
Hinzugefügt in Version 245.
--now
Startet/Stoppt/Neustartet den portierbaren Dienst sofort nach dem Anhängen/vor dem Abhängen/nach dem
Upgrade.
Hinzugefügt in Version 245.
--no-block
Blockiert beim Warten auf den Abschluss einer Anhängung mit --now nicht.
Hinzugefügt in Version 245.
--clean
Beim Abhängen sicherstellen, dass die Konfiguration, der Zustand, die Protokolle, der
Zwischenspeicher und die Laufzeitdatenverzeichnisse von dem portierbaren Dienst aus dem Hauptsystem
entfernt werden.
Hinzugefügt in Version 256.
--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 die Werkzeuge
systemd-sysext(8) und systemd-confext(8) festgelegten Regeln folgt. 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 der Portable-Dienste[1].
Beachten Sie, dass die gleichen Erweiterungen, in der gleichen Reihenfolge, bei Anhängen und Abhängen
angegeben werden müssen.
Anstelle des Abbildpfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
systemd.v(7) zu Details.
Anstelle des Verzeichnispfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
systemd.v(7) zu Details.
Hinzugefügt in Version 249.
--force
Sicherheitsüberprüfung überspringen und Abbilder an- oder abhängen (mit Erweiterungen), ohne zuerst
sicherzustellen, dass die Units nicht laufen. Es wird nicht darauf bestanden, dass die Datei
extension-release.NAME im Erweiterungsabbild auf den Dateinamen des Abbildes passt.
Hinzugefügt in Version 252.
-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-Name, abgetrennt
durch »/«, folgen, 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. Setzen 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 für ausgegebene Meldungen (Meldungen mit einer höheren
Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Akzeptiert eine Kommata-getrennte
Liste von Werten. Ein Wert kann einer der folgenden sein (in Reihenfolge absteigender Bedeutung):
emerg, alert, crit, err, warning, notice, info, debug oder eine Ganzzahl im Bereich 0…7. Siehe
syslog(3) für weitere Informationen. Jedem Wert kann optional eine Zeichenkette aus console, syslog,
kmsg oder journal gefolgt von einem Doppelpunkt vorangestellt werden, um die maximale
Protokollierstufe für dieses spezielle Protokollierziel zu setzen (d.h.
SYSTEMD_LOG_LEVEL=debug,console:info legt fest, dass auf der Stufe »debug« protokolliert werden soll,
außer beim Protokollieren auf die Konsole, die auf Stufe »info« erfolgen soll). Beachten Sie, dass
die globale maximale Protokollierstufe Priorität gegenüber jeder zielbezogenen maximalen
Protokollierstufe hat.
$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls true, 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 true, 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.
$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls true, wird den Protokollnachrichten ein Dateiname 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 true, wird den Nachrichten die aktuelle numerische Thread-Kennung (TID)
vorangestellt.
Beachten Sie, dass diese Informationen sowieso als Metadaten 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_LOG_RATELIMIT_KMSG
Ob Kmsg ratenlimitiert werden soll oder nicht. Akzeptiert einen logischen Wert. Standardmäßig »true«.
Falls deaktiviert, wird Systemd die nach Kmsg geschriebenen Meldungen nicht ratenlimitieren.
$SYSTEMD_PAGER, $PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist. Falls gesetzt, wird
$SYSTEMD_PAGER verwandt, andernfalls $PAGER. setzt $PAGER außer Kraft. Falls weder $SYSTEMD_PAGER
noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter Implementierungen von Textanzeigeprogrammen
der Reihe nach ausprobiert, einschließlich less(1) und more(1), bis eines gefunden wird. Falls keine
Implementierung eines Textanzeigeprogramms gefunden wird, wird keines aufgerufen. Setzen dieser
Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist äquivalent zur Übergabe von
--no-pager.
Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, können $SYSTEMD_PAGER und $PAGER nur zum
Deaktivieren des Seitenanzeigeprogramms (mit »cat« oder »«) verwandt werden und werden ansonsten
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.
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESS keine Auswirkungen auf die
Ausführung von less(1) durch systemd(1)-Werkzeuge hat.
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.
Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf
die Ausführungen von less(1) durch systemd(1)-Werkzeuge hat.
$SYSTEMD_PAGERSECURE
Typische Seitenanzeigeprogramme wie less(1) unterstützen nebem dem seitenweisen Anzeigen (d.h. dem
Durchlaufen der Ausgabe) das Öffnen von oder Schreiben in andere Dateien und die Ausführung von
beliebigen Shell-Befehlen. Werden Befehle mit erhöhten Berechtigungen, beispielsweise unter sudo(8)
oder pkexec(1), aufgerufen, wird das Seitenanzeigeprogramm zur Sicherheitsgrenze. Es muss darauf
geachtet werden, dass nur Programme mit streng begrenzter Funktionalität als Seitenanzeigeprogramm
verwandt werden und unerwünschte interaktive Funktionalitäten wie das Öffnen oder Erstellen von neuen
Dateien oder das Starten von Subprozessen nicht erlaubt sind. Der »Sichere Modus« für das
Seitenanzeigeprogramm kann wie nachfolgend beschrieben aktiviert werden, falls das
Seitenanzeigeprogramm dies unterstützt (die meisten Seitenanzeigeprogramme sind nicht so geschrieben,
dass sie dies berücksichtigen). Es wird empfohlen, den »Sicheren Modus« explizit zu aktivieren oder
das Seitenanzeigeprogramm komplett mittels --no-pager oder PAGER=cat zu deaktivieren, wenn nicht
vertrauenswürdigen Benutzern die Ausführung von Programmen mit erhöhten Privilegien erlaubt wird.
Diese Option akzeptiert ein logisches Argument. Ist es auf »true« gesetzt, wird der »Sichere Modus«
des Seitenanzeigeprogramms aktiviert. Im »Sicheren Modus« wird LESSSECURE=1 beim Aufruf des
Seitenanzeigeprogramms gesetzt. Dies weist das Seiteanzeigeprogramm an, Befehle zum Öffnen oder
Erstellen von neuen Dateien sowie das Starten von Subprozessen zu deaktivieren. Derzeit ist nur von
less(1) bekannt, dass es diese Variable versteht und den »Sicheren Modus« implementiert.
Ist diese Variable auf »false« gesetzt, unterliegt das Seitenanzeigeprogramm keinen Beschränkungen.
Setzen auf SYSTEMD_PAGERSECURE=0 oder das Beibehalten der Variable von der geerbten Umgebung könnte
den Benutzern die Ausführung beliebiger Befehle erlauben.
Ist $SYSTEMD_PAGERSECURE nicht gesetzt, versuchen die Systemd-Werkzeuge automatisch herauszufinden,
ob der »Sicheren Modus« aktiviert werden soll und ob das Seitenanzeigeprogramm dies unterstützt. Der
»Sichere Modus« wird aktiviert, falls die effektive UID nicht mit der UID des Eigentümers der
Anmeldesitzung übereinstimmt, siehe geteuid(2) und sd_pid_get_owner_uid(3), oder wenn die Ausführung
unter Werkzeugen wie sudo(8) oder ähnlichem erfolgt ($SUDO_UID ist gesetzt [2]). In diesen Fällen
wird SYSTEMD_PAGERSECURE=1 gesetzt und Seitenanzeigeprogramme, von denen nicht bekannt ist, dass sie
den »Sicheren Modus« unterstützen, werden überhaupt nicht verwandt. Beachten Sie, dass diese
automatische Erkennung nur die typischsten Mechanismen zur Erlangung von Privilegien abdeckt und dem
Komfort dient. Es wird empfohlen, explizit $SYSTEMD_PAGERSECURE zu setzen oder das
Seitenanzeigeprogramm zu deaktivieren.
Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt sein muss, damit die Variablen $SYSTEMD_PAGER
oder $PAGER (außer zum Deaktivieren des Seitenanzeigeprogramms) berücksichtigt werden.
$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn true, 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), importctl(1)
ANMERKUNGEN
1. Portable Dienste
https://systemd.io/PORTABLE_SERVICES
2. Es wird für andere Werkzeuge empfohlen, $SUDO_UID geeignet zu setzen und zu überprüfen und es als
allgemeine Schnittstelle zu behandeln.
Ü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 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.
systemd 257.6 PORTABLECTL(1)