shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-02-24 17:57:34 +03:00
Code

Merge pull request #4273 from keszybz/docs

Browse Source 
Routing-domains-manpage tweak and NEWS update
This commit is contained in:
Martin Pitt 2016-10-04 15:34:08 +02:00 committed by GitHub
commit bbe4743ba7
5 changed files with 85 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Makefile.am
View File

@ -6556,7 +6556,7 @@ print-%:
@echo $($*)
git-contrib:
@git shortlog -s `git describe --abbrev=0`.. | cut -c8- | awk '{ print $$0 "," }' | sort -u
@git shortlog -s `git describe --abbrev=0`.. | cut -c8- | sed 's/ / /g' | awk '{ print $$0 "," }' | sort -u
EXTRA_DIST += \
tools/gdb-sd_dump_hashmaps.py

76
NEWS
View File

@ -5,6 +5,36 @@ CHANGES WITH 232 in spe
* The new RemoveIPC= option can be used to remove IPC objects owned by
the user or group of a service when that service exits.
* ProtectSystem= option gained a new value "strict", which causes the
whole file system tree with the exception of /dev, /proc, and /sys,
to be remounted read-only for a service.
The new ProtectedKernelTunables= options can be used to disable
modification of configuration files in /sys and /proc by a service.
Various directories and files are remounted read-only, so access is
restricted even if the file permissions would allow it.
The new ProtectControlGroups= option can be used to disable write
access by a service to /sys/fs/cgroup.
* Various systemd services have been hardened with
ProtectKernelTunables=yes, ProtectControlGroups=yes,
RestrictAddressFamilies=.
In particular, systemd-udevd.service is now run in a Seccomp-based
sandbox that prohibits access to AF_INET and AF_INET6 sockets and
thus access to the network. This might break code that runs from udev
rules that tries to talk to the network. Doing that is generally a
bad idea and unsafe due to a variety of reasons. It's also racy as
device management would race against network configuration. It is
recommended to rework such rules to use the SYSTEMD_WANTS property on
the relevant devices to pull in a proper systemd service (which can
be sandboxed differently and ordered correctly after the network
having come up). If that's not possible consider reverting this
sandboxing feature locally by removing the RestrictAddressFamilies=
setting from the systemd-udevd.service unit file, or adding AF_INET
and AF_INET6 to it.
* Support for dynamically creating users for the lifetime of a service
has been added. If DynamicUser=yes is specified, user and group IDs
will be allocated from the range 61184..65519 for the lifetime of the
@ -12,7 +42,9 @@ CHANGES WITH 232 in spe
module. The module must be enabled in /etc/nsswitch.conf. Services
started in this way have PrivateTmp= and RemoveIPC= enabled, so that
any resources allocated by the service will be cleaned up when the
service exits.
service exits. They also have ProtectHome=read-only and
ProtectSystem=strict enabled, so they are not able to make any
permanent modifications to the system.
The nss-systemd module also always resolves root and nobody, making
it possible to have no /etc/passwd or /etc/group files in minimal
@ -54,7 +86,7 @@ CHANGES WITH 232 in spe
mount the EFI partition on systems where /boot is used for something
else.
* disk/by-id symlinks are now created for NVMe drives.
* disk/by-id and disk/by-path symlinks are now created for NVMe drives.
* Two new user session targets have been added to support running
graphical sessions under the systemd --user instance:
@ -93,6 +125,9 @@ CHANGES WITH 232 in spe
* systemd-run gained a new --wait option that makes service execution
synchronous.
systemctl gained a new --wait option that causes the start command to
wait until the units being started have terminated again.
* A new journal output mode "short-full" has been added which uses
timestamps with abbreviated English day names and adds a timezone
suffix. Those timestamps include more information and can be parsed
@ -106,6 +141,12 @@ CHANGES WITH 232 in spe
from a single IP can be limited with MaxConnectionsPerSource=,
extending the existing setting of MaxConnections.
* systemd-networkd gained support for vcan ("Virtual CAN") interface
configuration.
* .netdev and .network configuration can now be extended through
drop-ins.
* UDP Segmentation Offload, TCP Segmentation Offload, Generic
Segmentation Offload, Generic Receive Offload, Large Receive Offload
can be enabled and disabled using the new UDPSegmentationOffload=,
@ -118,6 +159,10 @@ CHANGES WITH 232 in spe
new STP=, Priority=, AgeingTimeSec=, and DefaultPVID= settings in the
[Bridge] section of .netdev files.
The route table to which routes received over DHCP or RA should be
added can be configured with the new RouteTable= option in the [DHCP]
and [IPv6AcceptRA] sections of .network files.
Address Resolution Protocol can be disabled on links managed by
systemd-networkd using the ARP=no setting in the [Link] section of
.network files.
@ -125,11 +170,24 @@ CHANGES WITH 232 in spe
* $SERVICE_RESULT, $EXIT_CODE, $EXIT_STATUS are set for ExecStop= and
ExecStopPost= commands.
* systemd-sysctl will now configure kernel parameters in the order
they occur in the configuration files. This mathes what sysctl
has been traditionally doing.
* kernel-install "plugins" that are executed to perform various
tasks after a new kernel is added and before an old one is removed
can now return a special value to terminate the procedure and
prevent any later plugins from running.
* Journald's SplitMode=login setting has been deprecated. It has been
removed from documentation, and it's use is discouraged. In a future
release it will be completely removed, and made equivalent to current
default of SplitMode=uid.
* Storage=both option setting in /etc/systemd/coredump.conf has been
removed. With fast LZ4 compression storing the core dump twice is not
useful.
* The --share-system systemd-nspawn option has been replaced with an
(undocumented) variable $SYSTEMD_NSPAWN_SHARE_SYSTEM, but the use of
this functionality is discouraged. In addition the variables
@ -137,20 +195,6 @@ CHANGES WITH 232 in spe
$SYSTEMD_NSPAWN_SHARE_NS_UTS may be used to control the unsharing of
individual namespaces.
* systemd-udevd.service is now run in a Seccomp-based sandbox that
prohibits access to AF_INET and AF_INET6 sockets and thus access to
the network. This might break code that runs from udev rules that
tries to talk to the network. Doing that is generally a bad idea and
unsafe due to a variety of reasons. It's also racy as device
management would race against network configuration. It is
recommended to rework such rules to use the SYSTEMD_WANTS property on
the relevant devices to pull in a proper systemd service (which can
be sandboxed differently and ordered correctly after the network
having come up). If that's not possible consider reverting this
sandboxing feature locally by removing the RestrictAddressFamilies=
setting from the systemd-udevd.service unit file, or adding AF_INET
and AF_INET6 to it.
CHANGES WITH 231:
* In service units the various ExecXYZ= settings have been extended

1
TODO
View File

@ -821,6 +821,7 @@ Features:
or interface down
- some servers don't do rapid commit without a filled in IA_NA, verify
this behavior
- RouteTable= ?
External:

3
man/systemd.netdev.xml
View File

@ -173,8 +173,7 @@
<entry>A Virtual Routing and Forwarding (<ulink url="https://www.kernel.org/doc/Documentation/networking/vrf.txt">VRF</ulink>) interface to create separate routing and forwarding domains.</entry></row>
<row><entry><varname>vcan</varname></entry>
<entry>The virtual CAN driver (vcan). Similar to the network loopback devices,
vcan offers a virtual local CAN interface.</entry></row>
<entry>The virtual CAN driver (vcan). Similar to the network loopback devices, vcan offers a virtual local CAN interface.</entry></row>
</tbody>
</tgroup>

37
man/systemd.network.xml
View File

@ -467,24 +467,31 @@
<varlistentry>
<term><varname>Domains=</varname></term>
<listitem>
<para>The domains used for DNS host name resolution on this link. Takes a list of DNS domain names which
are used as search suffixes for extending single-label host names (host names containing no dots) to become
fully qualified domain names (FQDNs). If a single-label host name is resolved on this interface, each of
the specified search domains are appended to it in turn, converting it into a fully qualified domain name,
until one of them may be successfully resolved.</para>
<para>A list of domains which should be resolved using the DNS servers on this link. Each item in the list
should be a domain name, optionally prefixed with a tilde (<literal>~</literal>). The domains with the
prefix are called "routing-only domains". The domains without the prefix are called "search domains" and
are first used as search suffixes for extending single-label host names (host names containing no dots) to
become fully qualified domain names (FQDNs). If a single-label host name is resolved on this interface,
each of the specified search domains are appended to it in turn, converting it into a fully qualified
domain name, until one of them may be successfully resolved.</para>
<para>The specified domains are also used for routing of DNS queries: look-ups for host names ending in the
domains specified here are preferably routed to the DNS servers configured for this interface. If a domain
name is prefixed with <literal>~</literal>, the domain name becomes a pure "routing" domain, the DNS server
is used for the given domain names only and is not used in the described domain search logic. By specifying a
routing domain of <literal>~.</literal> (the tilde indicating definition of a routing domain, the dot
referring to the DNS root domain which is the implied suffix of all valid DNS names) it is possible to
route all DNS traffic preferably to the DNS server specified for this interface. The route domain logic is
particularly useful on multi-homed hosts with DNS servers serving particular private DNS zones on each
interface.</para>
<para>Both "search" and "routing-only" domains are used for routing of DNS queries: look-ups for host names
ending in those domains (hence also single label names, if any "search domains" are listed), are routed to
the DNS servers configured for this interface. The domain routing logic is particularly useful on
multi-homed hosts with DNS servers serving particular private DNS zones on each interface.</para>
<para>The "routing-only" domain <literal>~.</literal> (the tilde indicating definition of a routing domain,
the dot referring to the DNS root domain which is the implied suffix of all valid DNS names) has special
effect. It causes all DNS traffic which does not match another configured domain routing entry to be routed
to DNS servers specified for this interface. This setting is useful to prefer a certain set of DNS servers
if a link on which they are connected is available.</para>
<para>This setting is read by
<citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
<citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
"Search domains" correspond to the <varname>domain</varname> and <varname>search</varname> entries in
<citerefentry><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
Domain name routing has no equivalent in the traditional glibc API, which has no concept of domain
name servers limited to a specific link.</para>
</listitem>
</varlistentry>
<varlistentry>