(→Detailed Description: extend blurb) |
m (typo and grammar fixes) |
||
| Line 21: | Line 21: | ||
== Summary == | == Summary == | ||
Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in | Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. | ||
== Owner == | == Owner == | ||
| Line 58: | Line 58: | ||
with two notable exceptions: arbitrary filtering of messages and forwarding of messages over the network. This Change targets the latter. | with two notable exceptions: arbitrary filtering of messages and forwarding of messages over the network. This Change targets the latter. | ||
The | The high-level goal is to have a mechanism where journal logging can be extended | ||
to keep a copy of logs on a remote server, without requiring any | to keep a copy of logs on a remote server, without requiring any maintenance, done | ||
fairly efficiently and in a secure way. | fairly efficiently and in a secure way. | ||
| Line 65: | Line 65: | ||
* on the receiver side ''systemd-journal-remote'' accepts messages in the [http://www.freedesktop.org/wiki/Software/systemd/export/ Journal Export Format]. The export format is a simple serialization of journal entries, supporting both text and binary fields. This means that the messages are transferred intact, apart from the "cursors", which specify the location in the journal file. Received entries are stored in local journal files underneath /var/log/journal. Those files are subject to normal journald rules for rotation, and the older ones will be removed as necessary to stay within disk usage limits. Once entries have been written to the journal file, they can be read using journalctl and the journal APIs, and are available to all clients, e.g. [https://wiki.gnome.org/Apps/Logs Gnome Logs]. | * on the receiver side ''systemd-journal-remote'' accepts messages in the [http://www.freedesktop.org/wiki/Software/systemd/export/ Journal Export Format]. The export format is a simple serialization of journal entries, supporting both text and binary fields. This means that the messages are transferred intact, apart from the "cursors", which specify the location in the journal file. Received entries are stored in local journal files underneath /var/log/journal. Those files are subject to normal journald rules for rotation, and the older ones will be removed as necessary to stay within disk usage limits. Once entries have been written to the journal file, they can be read using journalctl and the journal APIs, and are available to all clients, e.g. [https://wiki.gnome.org/Apps/Logs Gnome Logs]. | ||
* on the sender side ''systemd-journal-upload'' is a journal client, which exports all available journal messages and uploads them over the network. The (local) cursor of the last | * on the sender side ''systemd-journal-upload'' is a journal client, which exports all available journal messages and uploads them over the network. The (local) cursor of the last message successfully forwarded is stored on disk, so when ''systemd-journal-upload'' is restarted (possibly after a reboot of the machine), it will send all recent messages found in the journal and then new ones as they arrive. | ||
The communication between the two daemons is done over standard HTTPS, following rather simple rules, so it is possible to create alternate implementations without much work. For example, curl can be easily used to upload journal entries from a text file containing entries in the export format. Basically, the data are sent in an HTTP POST to ''/upload'' with ''Content-Type: application/vnd.fdo.journal''. When doing "live" forwarding, the size of the transfer cannot be known in advance, so ''Transfer-Encoding: chunked'' is used. All | The communication between the two daemons is done over standard HTTPS, following rather simple rules, so it is possible to create alternate implementations without much work. For example, curl can be easily used to upload journal entries from a text file containing entries in the export format. Basically, the data are sent in an HTTP POST to ''/upload'' with ''Content-Type: application/vnd.fdo.journal''. When doing "live" forwarding, the size of the transfer cannot be known in advance, so ''Transfer-Encoding: chunked'' is used. All communication is encrypted, and the identity of both sides is verified by checking for appropriate signatures on the certificates. | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 76: | Line 76: | ||
* Proposal owners: | * Proposal owners: | ||
The code in systemd for ''systemd-journal-remote'' and ''systemd-journal-upload'' will have to be added. The first is done, and has already been released in the latest Rawhide systemd package. The second is mostly done, and will be submitted upstream soon. Necessary units will have to be created, and a location | The code in systemd for ''systemd-journal-remote'' and ''systemd-journal-upload'' will have to be added. The first is done, and has already been released in the latest Rawhide systemd package. The second is mostly done, and will be submitted upstream soon. Necessary units will have to be created, and a location with suitable permissions will have to be created so that ''systemd-journal-remote'' can run unprivileged. This means that ''systemd-journal-remote'' should probably be packaged as a separate subpackage, similarly to systemd-journal-gatewayd. ''systemd-journal-upload'' uses libcurl, and thus should be also packaged as a separate subpackage to avoid introducing a new dependency for systemd. | ||
The issues the location of logs received remotely and storage of certificates will have to be figured out. In addition, suitable defaults for timeouts for transfers and maximum accepted entry sizes have to be chosen. | The issues of the location of logs received remotely and storage of certificates will have to be figured out. In addition, suitable defaults for timeouts for transfers and maximum accepted entry sizes have to be chosen. | ||
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Revision as of 08:01, 2 April 2014
Remote Journal Logging
Summary
Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs.
Owner
- Name: Zbigniew Jędrzejewski-Szmek
- Email: zbyszek@in.waw.pl
- Release notes owner:
Current status
- Targeted release: Fedora 21
- Last updated: 2014/03/31
- Tracker bug: <will be assigned by the Wrangler>
The implementation part is mostly done, but integration issues remain. See below.
Detailed Description
Systemd's journal currently provides a replacement for most functionality offered by traditional syslog daemons, with two notable exceptions: arbitrary filtering of messages and forwarding of messages over the network. This Change targets the latter.
The high-level goal is to have a mechanism where journal logging can be extended to keep a copy of logs on a remote server, without requiring any maintenance, done fairly efficiently and in a secure way.
Two new daemons are added as part of the systemd package:
- on the receiver side systemd-journal-remote accepts messages in the Journal Export Format. The export format is a simple serialization of journal entries, supporting both text and binary fields. This means that the messages are transferred intact, apart from the "cursors", which specify the location in the journal file. Received entries are stored in local journal files underneath /var/log/journal. Those files are subject to normal journald rules for rotation, and the older ones will be removed as necessary to stay within disk usage limits. Once entries have been written to the journal file, they can be read using journalctl and the journal APIs, and are available to all clients, e.g. Gnome Logs.
- on the sender side systemd-journal-upload is a journal client, which exports all available journal messages and uploads them over the network. The (local) cursor of the last message successfully forwarded is stored on disk, so when systemd-journal-upload is restarted (possibly after a reboot of the machine), it will send all recent messages found in the journal and then new ones as they arrive.
The communication between the two daemons is done over standard HTTPS, following rather simple rules, so it is possible to create alternate implementations without much work. For example, curl can be easily used to upload journal entries from a text file containing entries in the export format. Basically, the data are sent in an HTTP POST to /upload with Content-Type: application/vnd.fdo.journal. When doing "live" forwarding, the size of the transfer cannot be known in advance, so Transfer-Encoding: chunked is used. All communication is encrypted, and the identity of both sides is verified by checking for appropriate signatures on the certificates.
Benefit to Fedora
This new functionality closes an existing gap in the journal functionality and removes the need to run a local rsyslog instance just to enable remote storage of logs. This should be slightly more efficient. An additional advantage is that native journal format is used throughout, avoiding any loss of fidelity.
Scope
- Proposal owners:
The code in systemd for systemd-journal-remote and systemd-journal-upload will have to be added. The first is done, and has already been released in the latest Rawhide systemd package. The second is mostly done, and will be submitted upstream soon. Necessary units will have to be created, and a location with suitable permissions will have to be created so that systemd-journal-remote can run unprivileged. This means that systemd-journal-remote should probably be packaged as a separate subpackage, similarly to systemd-journal-gatewayd. systemd-journal-upload uses libcurl, and thus should be also packaged as a separate subpackage to avoid introducing a new dependency for systemd.
The issues of the location of logs received remotely and storage of certificates will have to be figured out. In addition, suitable defaults for timeouts for transfers and maximum accepted entry sizes have to be chosen.
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
Upgrade/compatibility impact
This is entirely new functionality, and upgrades are not an issue. systemd-journal-upload may be backported to enable uploading from older Fedora installations, but this is not part of this Change.
Open issues
A port will have to be assigned: systemd-journal-gatewayd uses 19531, so systemd-journal-remote should probably use 19532.
Firewall integration: TCP communication on this port will have to be enabled.
Two new users will have to be created when the packages are installed.
Where should the certificates be stored? systemd-journal-remote currently reads PEM files containing the key, certificate, and CA certificate, but possibly something smarted should be done. Should the certificates be picked up from /etc/pki/systemd/remote automatically?
How To Test
To enable receiving of messages, creating the certificates, creating a hole in the firewall, and 'systemctl enable systemd-journal-remote && systemctl start systemd-journal-remote' should be enough. To enable uploading of messages, creating the certificates and configuring the upload URL and 'systemctl enable systemd-journal-upload && systemctl start systemd-journal-upload' should be enough.
< TBD >
User Experience
N/A (not a System Wide Change)
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: do not ship the two subpackages
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product <-- Applicable for Changes that blocks specific product release/Fedora.next -->
Documentation
http://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html
Release Notes
Journal messages can be forwarded to remote storage, without using a syslog daemon. This functionality is available through the systemd-journal-remote and systemd-journal-upload packages.