mirrors/systemd
0
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-28 21:03:52 +08:00
Code Issues Packages Projects Releases Wiki Activity
b5487fa0b6
systemd/units/systemd-journal-gatewayd.service.in

37 lines
1.0 KiB
SYSTEMD
Raw Normal View History

journal: add minimal journal gateway daemon based on GNU libmicrohttpd This minimal HTTP server can serve journal data via HTTP. Its primary purpose is synchronization of journal data across the network. It serves journal data in three formats: text/plain: the text format known from /var/log/messages application/json: the journal entries formatted as JSON application/vnd.fdo.journal: the binary export format of the journal The HTTP server also serves a small HTML5 app that makes use of the JSON serialization to present the journal data to the user. Examples: This downloads the journal in text format: # systemctl start systemd-journal-gatewayd.service # wget http://localhost:19531/entries Same for JSON: # curl -H"Accept: application/json" http://localhost:19531/entries Access via web browser: $ firefox http://localhost:19531/
2012-09-28 06:46:32 +08:00
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Journal Gateway Service
journal-remote: add documents in the unit files
2015-12-15 09:51:12 +08:00
Documentation=man:systemd-journal-gatewayd(8)
journal: add minimal journal gateway daemon based on GNU libmicrohttpd This minimal HTTP server can serve journal data via HTTP. Its primary purpose is synchronization of journal data across the network. It serves journal data in three formats: text/plain: the text format known from /var/log/messages application/json: the journal entries formatted as JSON application/vnd.fdo.journal: the binary export format of the journal The HTTP server also serves a small HTML5 app that makes use of the JSON serialization to present the journal data to the user. Examples: This downloads the journal in text format: # systemctl start systemd-journal-gatewayd.service # wget http://localhost:19531/entries Same for JSON: # curl -H"Accept: application/json" http://localhost:19531/entries Access via web browser: $ firefox http://localhost:19531/
2012-09-28 06:46:32 +08:00
Requires=systemd-journal-gatewayd.socket
[Service]
ExecStart=@rootlibexecdir@/systemd-journal-gatewayd
units: restore User=systemd-journal-gateway in systemd-journal-gatewayd.service (#7005) After the discussions around #7003 I think we should restore the User=systemd-journal-gateway line for systemd-journal-gatewayd.service, too, so that we continue to use the state user if it exists, and create it as dynamic user only when it does not. Note that undoes part of a change made after 234, i.e. a never released change.
2017-10-05 21:05:02 +08:00
User=systemd-journal-gateway
journal: make gatewayd run under its own user ID
2013-03-06 02:15:31 +08:00
SupplementaryGroups=systemd-journal
units,sysusers: use DynamicUser= for journal-gatewayd and drop user systemd-journal-gateway from sysusers
2017-07-28 11:28:17 +08:00
DynamicUser=yes
core: enable PrivateNetwork= for a number of our long running services where this is useful
2014-03-20 06:08:39 +08:00
PrivateDevices=yes
PrivateNetwork=yes
core: rename ReadOnlySystem= to ProtectSystem= and add a third value for also mounting /etc read-only Also, rename ProtectedHome= to ProtectHome=, to simplify things a bit. With this in place we now have two neat options ProtectSystem= and ProtectHome= for protecting the OS itself (and optionally its configuration), and for protecting the user's data.
2014-06-05 00:07:55 +08:00
ProtectHome=yes
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 19:23:27 +08:00
ProtectControlGroups=yes
ProtectKernelTunables=yes
units: turn on ProtectKernelModules= for most long-running services
2017-02-09 18:09:50 +08:00
ProtectKernelModules=yes
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 19:23:27 +08:00
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
units: restrict namespace for a good number of our own services Basically, we turn it on for most long-running services, with the exception of machined (whose child processes need to join containers here and there), and importd (which sandboxes tar in a CLONE_NEWNET namespace). machined is left unrestricted, and importd is restricted to use only "net"
2017-02-09 17:28:23 +08:00
RestrictNamespaces=yes
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 19:23:27 +08:00
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
units: set SystemCallArchitectures=native on all our long-running services
2017-02-09 05:32:37 +08:00
SystemCallArchitectures=native
units: set LockPersonality= for all our long-running services (#6819) Let's lock things down. Also, using it is the only way how to properly test this to the fullest extent.
2017-09-15 01:45:40 +08:00
LockPersonality=yes
journal: add minimal journal gateway daemon based on GNU libmicrohttpd This minimal HTTP server can serve journal data via HTTP. Its primary purpose is synchronization of journal data across the network. It serves journal data in three formats: text/plain: the text format known from /var/log/messages application/json: the journal entries formatted as JSON application/vnd.fdo.journal: the binary export format of the journal The HTTP server also serves a small HTML5 app that makes use of the JSON serialization to present the journal data to the user. Examples: This downloads the journal in text format: # systemctl start systemd-journal-gatewayd.service # wget http://localhost:19531/entries Same for JSON: # curl -H"Accept: application/json" http://localhost:19531/entries Access via web browser: $ firefox http://localhost:19531/
2012-09-28 06:46:32 +08:00
journal: bump RLIMIT_NOFILE when journal files to 16K (if possible) When there are a lot of split out journal files, we might run out of fds quicker then we want. Hence: bump RLIMIT_NOFILE to 16K if possible. Do these even for journalctl. On Fedora the soft RLIMIT_NOFILE is at 1K, the hard at 4K by default for normal user processes, this code hence bumps this up for users to 4K. https://bugzilla.redhat.com/show_bug.cgi?id=1179980
2015-01-08 10:17:50 +08:00
# If there are many split upjournal files we need a lot of fds to
# access them all and combine
LimitNOFILE=16384
journal: add minimal journal gateway daemon based on GNU libmicrohttpd This minimal HTTP server can serve journal data via HTTP. Its primary purpose is synchronization of journal data across the network. It serves journal data in three formats: text/plain: the text format known from /var/log/messages application/json: the journal entries formatted as JSON application/vnd.fdo.journal: the binary export format of the journal The HTTP server also serves a small HTML5 app that makes use of the JSON serialization to present the journal data to the user. Examples: This downloads the journal in text format: # systemctl start systemd-journal-gatewayd.service # wget http://localhost:19531/entries Same for JSON: # curl -H"Accept: application/json" http://localhost:19531/entries Access via web browser: $ firefox http://localhost:19531/
2012-09-28 06:46:32 +08:00
[Install]
Also=systemd-journal-gatewayd.socket
Reference in New Issue Copy Permalink