1. Manuals
  2. Tumbleweed
  3. man-pages-de
  4. systemd-journal-remote.service(8)

Scroll to navigation

SYSTEMD-JOURNAL-REMOTE.SERVICE(8) systemd-journal-remote.service SYSTEMD-JOURNAL-REMOTE.SERVICE(8)

BEZEICHNUNG

systemd-journal-remote.service, systemd-journal-remote.socket, systemd-journal-remote - Journal-Meldungen über das Netzwerk empfangen

ÜBERSICHT

systemd-journal-remote.service

systemd-journal-remote.socket

/usr/lib/systemd/systemd-journal-remote [OPTIONEN…] [-o/--output=VERZ|DATEI] [QUELLEN…]

BESCHREIBUNG

systemd-journal-remote ist ein Befehl, um serialisierte Journal-Ereignisse zu empfangen und in Journal-Dateien zu speichern. Eingabedatenströme sind im Journal-Exportformat[1], d.h. wie die Ausgabe von journalctl --output=export. Im Netzwerk wird dieser Datenstrom normalerweise über eine HTTPS-Verbindung transportiert.

systemd-journal-remote.service ist ein Systemdienst, der systemd-journal-remote zum Warten auf Verbindungen verwendet. systemd-journal-remote.socket konfiguriert die Netzwerkadresse, an der systemd-journal-remote.service auf Anfragen wartet. Standardmäßig ist dies Port 19532. Welche Verbindungen akzeptiert werden und wie die empfangenen Daten gespeichert werden, kann mittels der Konfigurationsdatei journal-remote.conf(5) konfiguriert werden.

QUELLEN

Quellen können entweder »aktiv« (systemd-journal-remote fordert die Daten an und lädt sie) oder »passiv« (systemd-journal-remote wartet auf eine Verbindung und empfängt von der anderen Seite übertragene Daten) sein.

systemd-journal-remote kann gleichzeitig mehrere Ereignisdatenströme lesen. Diese werden in der Ausgabedatei verschachtelt. Bei »aktiven« Verbindungen ist jede »Quelle« ein Datenstrom; bei »passiven« Verbindungen kann jede Verbindung zu einem separaten Datenstrom führen. Sockets können im »Akzeptanzmodus« (d.h. nur eine Verbindung) oder im »Wartemodus« (d.h. mehrere Verbindungen, jede führt zu einem Datenstrom), konfiguriert werden.

Wenn es keine Verbindungen mehr gibt und keine mehr erstellt werden können (es gibt keine Sockets, wo auf Anfragen gewartet werden soll), dann beendet sich systemd-journal-remote.

Aktive Quellen können auf die folgenden Arten festgelegt werden:

[QUELLEN…]

Wird - als Positionsargument übergeben, werden die Ereignisse aus der Standardeingabe gelesen. Andere Positionsargumente werden als Dateinamen behandelt, die geöffnet und aus denen gelesen werden soll.

Hinzugefügt in Version 239.

--url=ADRESSE

Mit der Option --url=ADRESSE werden die Ereignisse mittels HTTP aus der ADRESSE abgerufen. Die URL sollte sich auf die Wurzel einer fernen systemd-journal-gatewayd(8)-Instanz beziehen, z.B. http://ein.Rechner:19531/ oder https://ein.Rechner:19531/.

Hinzugefügt in Version 239.

--getter='PROG [OPTIONEN…]'

Programm, das zum Abruf von Daten aufgerufen werden soll. Der Journal-Ereignisdatenstrom muss auf die Standardausgabe erstellt werden.

Beispiele:

--getter='curl "-HAccept: application/vnd.fdo.journal" https://ein.Rechner:19531/'

--getter='wget --header="Accept: application/vnd.fdo.journal" -O- https://ein.Rechner:19531/'

Hinzugefügt in Version 239.

Passive Quellen können auf die folgenden Arten festgelegt werden:

--listen-raw=ADRESSE

ADRESSE muss eine für ListenStream= geeignete Adresse sein (siehe systemd.socket(5)). systemd-journal-remote wird auf diesem Socket auf Anfragen warten. Es wird erwartet, dass jede Verbindung ein Datenstrom mit Journal-Ereignissen ist.

Hinzugefügt in Version 239.

--listen-http=ADRESSE, --listen-https=ADRESSE

ADRESSE muss entweder eine negative Ganzzahl (diese wird dann als die negierte Dateideskriptornummer interpretiert) oder eine für ListenStream= geeignete Adresse (siehe systemd.socket(5)) sein. Im ersten Fall wartet der Server standardmäßig auf Port 19532 und der passende Dateideskriptor muss mittels $LISTEN_FDS/$LISTEN_PID geerbt worden sein. Im zweiten Fall wird auf diesem Port bzw. auf --listen-http= und --listen-https= ein HTTP- oder HTTPS-Server erzeugt werden. Derzeit werden nur POST-Anfragen nach /upload mit »Content-Type: application/vnd.fdo.journal« unterstützt.

Hinzugefügt in Version 239.

$LISTEN_FDS

systemd-journal-remote unterstützt das Protokoll $LISTEN_FDS/$LISTEN_PID. Offene Sockets, die mittels Socket-Aktivierung geerbt wurden, verhalten sich wie die oben beschriebenen mit --listen-raw= geöffneten, außer sie wurden oben als ein Argument in --listen-http=-n oder --listen-https=-n angegeben. In letzterem Fall wird ein HTTP- oder HTTPS-Server unter Verwendung dieses Deskriptors erzeugt und Verbindungen müssen über das HTTP-Protokoll erfolgen.

Hinzugefügt in Version 239.

--key=

Akzeptiert einen Pfad zu einer SSL-Datei für geheime Schlüssel im PEM-Format. Standardmäßig /etc/pki/systemd/private/journal-remote.pem. Diese Option kann mit --listen-https= verwandt werden. Falls sich der Pfad auf ein AF_UNIX-Datenstromsocket in dem Dateisystem bezieht, wird zu diesem eine Verbindung eröffnet und der Schlüssel daraus gelesen.

Hinzugefügt in Version 239.

--cert=

Akzeptiert einen Pfad zu einer SSL-Zertifikatsdatei im PEM-Format. Standardmäßig /etc/pki/systemd/certs/journal-remote.pem. Diese Option kann mit --listen-https= verwandt werden. Falls sich der Pfad auf ein AF_UNIX-Datenstromsocket in dem Dateisystem bezieht, wird zu diesem eine Verbindung eröffnet und das Zertifikat daraus gelesen.

Hinzugefügt in Version 239.

--trust=

Akzeptiert einen Pfad zu einer SSL-CA-Zertifikatsdatei im PEM-Format oder all. Falls all gesetzt ist, dann wird die Zertifikatsprüfung deaktiviert. Standardmäßig /etc/pki/systemd/ca/trusted.pem. Diese Option kann mit --listen-https= verwandt werden. Falls sich der Pfad auf ein AF_UNIX-Datenstromsocket in dem Dateisystem bezieht, wird zu diesem eine Verbindung eröffnet und das Zertifikat daraus gelesen.

Hinzugefügt in Version 239.

--gnutls-log=

Akzeptiert eine Kommata-getrennte Liste von Gnutls-Protokollierungskategorien. Diese Option kann mit --listen-http= oder --listen-https= verwandt werden.

Hinzugefügt in Version 239.

SENKEN

Der Ort des Ausgabe-Journals kann mit -o oder --output= festgelegt werden.

-o DATEI, --output=DATEI

Führt zum Schreiben in diese Journal-Datei. Der Dateiname muss auf .journal enden. Die Datei wird erstellt, falls sie noch nicht existiert. Falls notwendig (Journal-Datei voll oder beschädigt), wird die Datei gemäß der normalen Journald-Regeln umbenannt und eine neue Journal-Datei wird an ihrer Stelle erstellt.

Hinzugefügt in Version 239.

-o VERZEICHNIS, --output=VERZEICHNIS

Führt zur Erstellung von Journal-Dateien unterhalb des Verzeichnisses VERZ. Das Verzeichnis muss existieren. Falls notwendig (Journal-Dateien zu Groß oder beschädigt), werden die Dateien gemäß der normalen Journald-Regeln rotiert. Dateinamen unterhalb VERZ werden gemäß der nachfolgend beschriebenen Regeln erstellt.

Hinzugefügt in Version 239.

Das Ausgabeverzeichnis /var/log/journal/remote/ wird verwandt, falls --output= nicht genutzt wird. Falls die Ausgabedatei nicht festgelegt ist, werden Journal-Dateien unterhalb des ausgewählten Verzeichnisses erstellt. Dateien werden remote-Rechnername.journal genannt, wobei der Teil Rechnername der maskierte Rechnername des Quellendpunktes der Verbindung oder die numerische Adresse ist, falls der Rechnername nicht bestimmt werden konnte.

Falls durch die Positionsargumente »aktive« Quellen oder die Option --getter= übergeben werden, muss der Ausgabedateiname immer explizit angegeben werden.

OPTIONEN

Die folgenden Optionen werden verstanden:

--split-mode

Entweder none oder host. Für Erstere wird nur eine Ausgabe-Journal-Datei verwandt. Für Letztere wird eine separate Ausgabedatei verwandt, basierend auf dem Rechnernamen des anderen Endpunktes einer Verbindung.

Falls »aktive« Quellen als Positionsargumente oder die Option --getter= übergeben werden, muss der Ausgabedateiname immer explizit angegeben werden und nur none ist erlaubt.

Hinzugefügt in Version 239.

--compress [LOGISCH]

Falls dies auf »yes« gesetzt ist, werden die Daten im Journal mittels XZ komprimiert. Die Vorgabe ist »yes«.

Hinzugefügt in Version 239.

--seal [LOGISCH]

Falls dies auf »yes« gesetzt ist, werden die Daten im Journal periodisch mittels »Forward Secure Sealing« signiert. Die Vorgabe ist »no«.

Hinzugefügt in Version 239.

-h, --help

Zeigt einen kurzen Hilfetext an und beendet das Programm.

--version

Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

BEISPIELE

Lokale Journal-Ereignisse in ein anderes Journal-Verzeichnis kopieren:

journalctl -o export | systemd-journal-remote -o /tmp/Verz/foo.journal -

Alle verfügbaren Ereignisse von einer fernen systemd-journal-gatewayd(8)-Instanz abfragen und sie in /var/log/journal/remote/remote-ein.Rechner.journal speichern:

systemd-journal-remote --url http://ein.Rechner:19531/

Aktuelle Systemstartereignisse abfragen und auf neue Ereignisse von einer fernen systemd-journal-gatewayd(8)-Instanz warten und sie in /var/log/journal/remote/remote-ein.Rechner.journal speichern:

systemd-journal-remote --url http://ein.Rechner:19531/entries?boot&follow

SIEHE AUCH

journal-remote.conf(5), journalctl(1), systemd-journal-gatewayd.service(8), systemd-journal-upload.service(8), systemd-journald.service(8)

ANMERKUNGEN

1.
Journal-Exportformat
https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format

Ü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.

systemd 255