shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-23 17:34:00 +03:00
Code
2f89304490
systemd-stable/man/systemd.nspawn.xml

579 lines
28 KiB
XML
Raw Normal View History

man: drop mode line in file headers This is already included in .dir-locals, so we don't need it in the files themselves.
2018-07-03 00:15:39 +03:00
<?xml version='1.0'?>
man: use same header for all files The "include" files had type "book" for some raeason. I don't think this is meaningful. Let's just use the same everywhere. $ perl -i -0pe 's^..DOCTYPE (book|refentry) PUBLIC "-//OASIS//DTD DocBook XML V4.[25]//EN"\s+"http^<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"\n "http^gms' man/*.xml
2019-03-14 16:40:58 +03:00
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY % entities SYSTEM "custom-entities.ent" >
%entities;
]>
license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 07:23:58 +03:00
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<refentry id="systemd.nspawn">
<refentryinfo>
<title>systemd.nspawn</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>systemd.nspawn</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>systemd.nspawn</refname>
<refpurpose>Container settings</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para><filename>/etc/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para>
<para><filename>/run/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para>
<para><filename>/var/lib/machines/<replaceable>machine</replaceable>.nspawn</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
man: refer to systemd.syntax(7) from systemd.nspawn(5) systemd.nspawn(5) contained a partial repeat of the stuff that is now in the dedicated man page. Let's just refer to that. While at it, do s/searched/searched for/ where appropriate and reword some sentences for brevity.
2019-11-24 18:14:52 +03:00
<para>An nspawn container settings file (suffix <filename>.nspawn</filename>) contains runtime
configuration for a local container, and is used used by
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
Files of this type are named after the containers they define settings for. They are optional, and only
required for containers whose execution environment shall differ from the defaults. Files of this type
mostly contain settings that may also be set on the <command>systemd-nspawn</command> command line, and
make it easier to persistently attach specific settings to specific containers. The syntax of these files
is inspired by <filename>.desktop</filename> files, similarly to other configuration files supported by
the systemd project. See
<citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> for an
overview.</para>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
</refsect1>
<refsect1>
<title><filename>.nspawn</filename> File Discovery</title>
man: refer to systemd.syntax(7) from systemd.nspawn(5) systemd.nspawn(5) contained a partial repeat of the stuff that is now in the dedicated man page. Let's just refer to that. While at it, do s/searched/searched for/ where appropriate and reword some sentences for brevity.
2019-11-24 18:14:52 +03:00
<para>Files are searched for by appending the <filename>.nspawn</filename> suffix to the machine name of
the container, as specified with the <option>--machine=</option> switch of
<command>systemd-nspawn</command>, or derived from the directory or image file name. This file is first
searched for in <filename>/etc/systemd/nspawn/</filename> and
<filename>/run/systemd/nspawn/</filename>. If found there, the settings are read and all of them take
full effect (but may still be overridden by corresponding command line arguments). Otherwise, the file
will then be searched for next to the image file or in the immediate parent of the root directory of the
container. If the file is found there, only a subset of the settings will take effect however. All
settings that possibly elevate privileges or grant additional access to resources of the host (such as
files or directories) are ignored. To which options this applies is documented below.</para>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
doc: correct orthography, word forms and missing/extraneous words
2014-08-03 09:11:37 +04:00
<para>Persistent settings files created and maintained by the
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
administrator (and thus trusted) should be placed in
<filename>/etc/systemd/nspawn/</filename>, while automatically
downloaded (and thus potentially untrusted) settings files are
placed in <filename>/var/lib/machines/</filename> instead (next to
the container images), where their security impact is limited. In
order to add privileged settings to <filename>.nspawn</filename>
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
files acquired from the image vendor, it is recommended to copy the
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
settings files into <filename>/etc/systemd/nspawn/</filename> and
edit them there, so that the privileged options become
doc: correct orthography, word forms and missing/extraneous words
2014-08-03 09:11:37 +04:00
available. The precise algorithm for how the files are searched and
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
interpreted may be configured with
<command>systemd-nspawn</command>'s <option>--settings=</option>
switch, see
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for details.</para>
</refsect1>
<refsect1>
<title>[Exec] Section Options</title>
tree-wide: drop quotes from around [section] For users, the square brackets already serve as markup and clearly delineate the section name from surrounding text. Putting additional markup around that only adds clutter. Also, we were very inconsistent in using the quotes. Let's just drop them altogether.
2020-07-06 12:00:06 +03:00
<para>Settings files may include an [Exec]
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
section, which carries various execution parameters:</para>
man: add a new directives section for .nspawn They is quite a bit of those directives and they were in "MISCELLANEOUS" because they don't quite fit anywhere. When the OCI-compat stuff is merged, there'll be even more, so let's make a separate section for them.
2019-02-13 12:57:49 +03:00
<variablelist class='nspawn-directives'>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varlistentry>
<term><varname>Boot=</varname></term>
nspawn: optionally run a stub init process as PID 1 This adds a new switch --as-pid2, which allows running commands as PID 2, while a stub init process is run as PID 1. This is useful in order to run arbitrary commands in a container, as PID1's semantics are different from all other processes regarding reaping of unknown children or signal handling.
2016-02-03 22:32:06 +03:00
<listitem><para>Takes a boolean argument, which defaults to off. If enabled, <command>systemd-nspawn</command>
will automatically search for an <filename>init</filename> executable and invoke it. In this case, the
specified parameters using <varname>Parameters=</varname> are passed as additional arguments to the
<filename>init</filename> process. This setting corresponds to the <option>--boot</option> switch on the
<command>systemd-nspawn</command> command line. This option may not be combined with
man: mention quoting in description of Parameters= Also add a short example how to translate nspawn command line to .nspawn settings. Fixes #12703.
2019-06-04 14:44:46 +03:00
<varname>ProcessTwo=yes</varname>. This option is specified by default in the
<filename>systemd-nspawn@.service</filename> template unit.</para></listitem>
nspawn: optionally run a stub init process as PID 1 This adds a new switch --as-pid2, which allows running commands as PID 2, while a stub init process is run as PID 1. This is useful in order to run arbitrary commands in a container, as PID1's semantics are different from all other processes regarding reaping of unknown children or signal handling.
2016-02-03 22:32:06 +03:00
</varlistentry>
add ephemeral to nspawn-settings.
2018-10-22 20:26:05 +03:00
<varlistentry>
<term><varname>Ephemeral=</varname></term>
<listitem><para>Takes a boolean argument, which defaults to off, If enabled, the container is run with
a temporary snapshot of its file system that is removed immediately when the container terminates.
This is equivalent to the <option>--ephemeral</option> command line switch. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
about the specific options supported.</para></listitem>
</varlistentry>
nspawn: optionally run a stub init process as PID 1 This adds a new switch --as-pid2, which allows running commands as PID 2, while a stub init process is run as PID 1. This is useful in order to run arbitrary commands in a container, as PID1's semantics are different from all other processes regarding reaping of unknown children or signal handling.
2016-02-03 22:32:06 +03:00
<varlistentry>
<term><varname>ProcessTwo=</varname></term>
<listitem><para>Takes a boolean argument, which defaults to off. If enabled, the specified program is run as
PID 2. A stub init process is run as PID 1. This setting corresponds to the <option>--as-pid2</option> switch
on the <command>systemd-nspawn</command> command line. This option may not be combined with
<varname>Boot=yes</varname>.</para></listitem>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
</varlistentry>
<varlistentry>
<term><varname>Parameters=</varname></term>
man: mention quoting in description of Parameters= Also add a short example how to translate nspawn command line to .nspawn settings. Fixes #12703.
2019-06-04 14:44:46 +03:00
<listitem><para>Takes a whitespace-separated list of arguments. Single (<literal>'</literal>) and
double (<literal>"</literal>) quotes may be used around arguments with whitespace. This is either a
command line, beginning with the binary name to execute, or – if <varname>Boot=</varname> is enabled
– the list of arguments to pass to the init process. This setting corresponds to the command line
parameters passed on the <command>systemd-nspawn</command> command line.</para>
<para>Note: <option>Boot=no</option>, <option>Parameters=a b "c c"</option> is the same as
<command>systemd-nspawn a b "c c"</command>, and <option>Boot=yes</option>, <option>Parameters=b 'c c'</option>
is the same as <command>systemd-nspawn --boot b 'c c'</command>.</para></listitem>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
</varlistentry>
<varlistentry>
<term><varname>Environment=</varname></term>
<listitem><para>Takes an environment variable assignment
consisting of key and value, separated by
<literal>=</literal>. Sets an environment variable for the
main process invoked in the container. This setting may be
used multiple times to set multiple environment variables. It
corresponds to the <option>--setenv=</option> command line
switch.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>User=</varname></term>
<listitem><para>Takes a UNIX user name. Specifies the user
name to invoke the main process of the container as. This user
must be known in the container's user database. This
corresponds to the <option>--user=</option> command line
nspawn: add new --chdir= switch Fixes: #2192
2016-02-02 03:52:01 +03:00
switch.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>WorkingDirectory=</varname></term>
<listitem><para>Selects the working directory for the process invoked in the container. Expects an absolute
path in the container's file system namespace. This corresponds to the <option>--chdir=</option> command line
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
switch.</para></listitem>
</varlistentry>
nspawn: Add support for sysroot pivoting (#5258) Add a new --pivot-root argument to systemd-nspawn, which specifies a directory to pivot to / inside the container; while the original / is pivoted to another specified directory (if provided). This adds support for booting container images which may contain several bootable sysroots, as is common with OSTree disk images. When these disk images are booted on real hardware, ostree-prepare-root is run in conjunction with sysroot.mount in the initramfs to achieve the same results.
2017-02-08 18:54:31 +03:00
<varlistentry>
<term><varname>PivotRoot=</varname></term>
<listitem><para>Selects a directory to pivot to <filename>/</filename> inside the container when starting up.
Takes a single path, or a pair of two paths separated by a colon. Both paths must be absolute, and are resolved
in the container's file system namespace. This corresponds to the <option>--pivot-root=</option> command line
switch.</para></listitem>
</varlistentry>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varlistentry>
<term><varname>Capability=</varname></term>
<term><varname>DropCapability=</varname></term>
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
<listitem><para>Takes a space-separated list of Linux process
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
capabilities (see
man: fix references to a few external man pages Noticed in pull request #2067.
2016-01-26 01:56:42 +03:00
<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
for details). The <varname>Capability=</varname> setting
specifies additional capabilities to pass on top of the
man: typo fixes
2015-09-07 21:06:58 +03:00
default set of capabilities. The
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varname>DropCapability=</varname> setting specifies
capabilities to drop from the default set. These settings
correspond to the <option>--capability=</option> and
<option>--drop-capability=</option> command line
switches. Note that <varname>Capability=</varname> is a
privileged setting, and only takes effect in
<filename>.nspawn</filename> files in
<filename>/etc/systemd/nspawn/</filename> and
<filename>/run/system/nspawn/</filename> (see above). On the
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
other hand, <varname>DropCapability=</varname> takes effect in
nspawn: allow Capability=all in systemd.nspawn [EXEC] section Just like --capability=all is allowed in the systemd-nspawn command line.
2019-11-29 12:08:05 +03:00
all cases. If the special value <literal>all</literal> is passed, all
systemd-nspawn: Allow setting ambient capability set The old code was only able to pass the value 0 for the inheritable and ambient capability set when a non-root user was specified. However, sometimes it is useful to run a program in its own container with a user specification and some capabilities set. This is needed when the capabilities cannot be provided by file capabilities (because the file system is mounted with MS_NOSUID for additional security). This commit introduces the option --ambient-capability and the config file option AmbientCapability=. Both are used in a similar way to the existing Capability= setting. It changes the inheritable and ambient set (which is 0 by default). The code also checks that the settings for the bounding set (as defined by Capability= and DropCapability=) and the setting for the ambient set (as defined by AmbientCapability=) are compatible. Otherwise, the operation would fail in any way. Due to the current use of -1 to indicate no support for ambient capability set the special value "all" cannot be supported. Also, the setting of ambient capability is restricted to running a single program in the container payload.
2020-12-04 13:27:12 +03:00
capabilities are retained (or dropped).</para>
<para>These settings change the bounding set of capabilities which
also limits the ambient capabilities as given with the
<varname>AmbientCapability=</varname>.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>AmbientCapability=</varname></term>
<listitem><para>Takes a space-separated list of Linux process
capabilities (see
<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
for details). The <varname>AmbientCapability=</varname> setting
specifies capability which will be passed to to started program
in the inheritable and ambient capability sets. This will grant
these capabilities to this process. This setting correspond to
the <option>--ambient-capability=</option> command line switch.
</para>
<para>The value <literal>all</literal> is not supported for this
setting.</para>
<para>The setting of <varname>AmbientCapability=</varname> must
be covered by the bounding set settings which were established by
<varname>Capability=</varname> and <varname>DropCapability=</varname>.
</para>
<para>Note that <varname>AmbientCapability=</varname> is a privileged
setting (see above).</para></listitem>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
</varlistentry>
nspawn: add a new --no-new-privileges= cmdline option to nspawn This simply controls the PR_SET_NO_NEW_PRIVS flag for the container. This too is primarily relevant to provide OCI runtime compaitiblity, but might have other uses too, in particular as it nicely complements the existing --capability= and --drop-capability= flags.
2018-05-07 20:35:48 +03:00
<varlistentry>
<term><varname>NoNewPrivileges=</varname></term>
<listitem><para>Takes a boolean argument that controls the <constant>PR_SET_NO_NEW_PRIVS</constant> flag for
the container payload. This is equivalent to the
<option>--no-new-privileges=</option> command line switch. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para>
</listitem>
</varlistentry>
man: document missing KillSignal= .nspawn option Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
2016-03-15 08:18:23 +03:00
<varlistentry>
man: move KillSignal in the right section in directives list
2016-04-01 16:07:17 +03:00
<term><varname>KillSignal=</varname></term>
man: document missing KillSignal= .nspawn option Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
2016-03-15 08:18:23 +03:00
<listitem><para>Specify the process signal to send to the
container's PID 1 when nspawn itself receives SIGTERM, in
order to trigger an orderly shutdown of the container.
Defaults to SIGRTMIN+3 if <option>Boot=</option> is used
(on systemd-compatible init systems SIGRTMIN+3 triggers an
orderly shutdown). For a list of valid signals, see
<citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
</varlistentry>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varlistentry>
<term><varname>Personality=</varname></term>
<listitem><para>Configures the kernel personality for the
container. This is equivalent to the
<option>--personality=</option> switch.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>MachineID=</varname></term>
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
<listitem><para>Configures the 128-bit machine ID (UUID) to pass to
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
the container. This is equivalent to the
<option>--uuid=</option> command line switch. This option is
privileged (see above). </para></listitem>
</varlistentry>
man: document the new user namespacing options
2016-04-22 14:46:23 +03:00
<varlistentry>
<term><varname>PrivateUsers=</varname></term>
<listitem><para>Configures support for usernamespacing. This is equivalent to the
<option>--private-users=</option> command line switch, and takes the same options. This option is privileged
nspawn: improve man page (#3577) This change documents the existance of the systemd-nspawn@.service template unit file, which was previously not mentioned at all. Since the unit file uses slightly different default than nspawn invoked from the command line, these defaults are now explicitly documented too. A couple of further additions and changes are made, too. Replaces: #3497
2016-06-23 00:30:36 +03:00
(see above). This option is the default if the <filename>systemd-nspawn@.service</filename> template unit file
is used.</para></listitem>
man: document the new user namespacing options
2016-04-22 14:46:23 +03:00
</varlistentry>
nspawn: introduce --notify-ready=[no|yes] (#3474) This the patch implements a notificaiton mechanism from the init process in the container to systemd-nspawn. The switch --notify-ready=yes configures systemd-nspawn to wait the "READY=1" message from the init process in the container to send its own to systemd. --notify-ready=no is equivalent to the previous behavior before this patch, systemd-nspawn notifies systemd with a "READY=1" message when the container is created. This notificaiton mechanism uses socket file with path relative to the contanier "/run/systemd/nspawn/notify". The default values it --notify-ready=no. It is also possible to configure this mechanism from the .nspawn files using NotifyReady. This parameter takes the same options of the command line switch. Before this patch, systemd-nspawn notifies "ready" after the inner child was created, regardless the status of the service running inside it. Now, with --notify-ready=yes, systemd-nspawn notifies when the service is ready. This is really useful when there are dependencies between different contaniers. Fixes https://github.com/systemd/systemd/issues/1369 Based on the work from https://github.com/systemd/systemd/pull/3022 Testing: Boot a OS inside a container with systemd-nspawn. Note: modify the commands accordingly with your filesystem. 1. Create a filesystem where you can boot an OS. 2. sudo systemd-nspawn -D ${HOME}/distros/fedora-23/ sh 2.1. Create the unit file /etc/systemd/system/sleep.service inside the container (You can use the example below) 2.2. systemdctl enable sleep 2.3 exit 3. sudo systemd-run --service-type=notify --unit=notify-test ${HOME}/systemd/systemd-nspawn --notify-ready=yes -D ${HOME}/distros/fedora-23/ -b 4. In a different shell run "systemctl status notify-test" When using --notify-ready=yes the service status is "activating" for 20 seconds before being set to "active (running)". Instead, using --notify-ready=no the service status is marked "active (running)" quickly, without waiting for the 20 seconds. This patch was also test with --private-users=yes, you can test it just adding it at the end of the command at point 3. ------ sleep.service ------ [Unit] Description=sleep After=network.target [Service] Type=oneshot ExecStart=/bin/sleep 20 [Install] WantedBy=multi-user.target ------------ end ------------
2016-06-10 14:09:06 +03:00
<varlistentry>
<term><varname>NotifyReady=</varname></term>
nspawn: implement configurable syscall whitelisting/blacklisting Now that we have ported nspawn's seccomp code to the generic code in seccomp-util, let's extend it to support whitelisting and blacklisting of specific additional syscalls. This uses similar syntax as PID1's support for system call filtering, but in contrast to that always implements a blacklist (and not a whitelist), as we prepopulate the filter with a blacklist, and the unit's system call filter logic does not come with anything prepopulated. (Later on we might actually want to invert the logic here, and whitelist rather than blacklist things, but at this point let's not do that. In case we switch this over later, the syscall add/remove logic of this commit should be compatible conceptually.) Fixes: #5163 Replaces: #5944
2017-09-11 18:45:21 +03:00
<listitem><para>Configures support for notifications from the container's init process. This is equivalent to
man: fix typos (#7029)
2017-10-10 22:59:03 +03:00
the <option>--notify-ready=</option> command line switch, and takes the same parameters. See
nspawn: implement configurable syscall whitelisting/blacklisting Now that we have ported nspawn's seccomp code to the generic code in seccomp-util, let's extend it to support whitelisting and blacklisting of specific additional syscalls. This uses similar syntax as PID1's support for system call filtering, but in contrast to that always implements a blacklist (and not a whitelist), as we prepopulate the filter with a blacklist, and the unit's system call filter logic does not come with anything prepopulated. (Later on we might actually want to invert the logic here, and whitelist rather than blacklist things, but at this point let's not do that. In case we switch this over later, the syscall add/remove logic of this commit should be compatible conceptually.) Fixes: #5163 Replaces: #5944
2017-09-11 18:45:21 +03:00
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
about the specific options supported.</para></listitem>
nspawn: introduce --notify-ready=[no|yes] (#3474) This the patch implements a notificaiton mechanism from the init process in the container to systemd-nspawn. The switch --notify-ready=yes configures systemd-nspawn to wait the "READY=1" message from the init process in the container to send its own to systemd. --notify-ready=no is equivalent to the previous behavior before this patch, systemd-nspawn notifies systemd with a "READY=1" message when the container is created. This notificaiton mechanism uses socket file with path relative to the contanier "/run/systemd/nspawn/notify". The default values it --notify-ready=no. It is also possible to configure this mechanism from the .nspawn files using NotifyReady. This parameter takes the same options of the command line switch. Before this patch, systemd-nspawn notifies "ready" after the inner child was created, regardless the status of the service running inside it. Now, with --notify-ready=yes, systemd-nspawn notifies when the service is ready. This is really useful when there are dependencies between different contaniers. Fixes https://github.com/systemd/systemd/issues/1369 Based on the work from https://github.com/systemd/systemd/pull/3022 Testing: Boot a OS inside a container with systemd-nspawn. Note: modify the commands accordingly with your filesystem. 1. Create a filesystem where you can boot an OS. 2. sudo systemd-nspawn -D ${HOME}/distros/fedora-23/ sh 2.1. Create the unit file /etc/systemd/system/sleep.service inside the container (You can use the example below) 2.2. systemdctl enable sleep 2.3 exit 3. sudo systemd-run --service-type=notify --unit=notify-test ${HOME}/systemd/systemd-nspawn --notify-ready=yes -D ${HOME}/distros/fedora-23/ -b 4. In a different shell run "systemctl status notify-test" When using --notify-ready=yes the service status is "activating" for 20 seconds before being set to "active (running)". Instead, using --notify-ready=no the service status is marked "active (running)" quickly, without waiting for the 20 seconds. This patch was also test with --private-users=yes, you can test it just adding it at the end of the command at point 3. ------ sleep.service ------ [Unit] Description=sleep After=network.target [Service] Type=oneshot ExecStart=/bin/sleep 20 [Install] WantedBy=multi-user.target ------------ end ------------
2016-06-10 14:09:06 +03:00
</varlistentry>
nspawn: implement configurable syscall whitelisting/blacklisting Now that we have ported nspawn's seccomp code to the generic code in seccomp-util, let's extend it to support whitelisting and blacklisting of specific additional syscalls. This uses similar syntax as PID1's support for system call filtering, but in contrast to that always implements a blacklist (and not a whitelist), as we prepopulate the filter with a blacklist, and the unit's system call filter logic does not come with anything prepopulated. (Later on we might actually want to invert the logic here, and whitelist rather than blacklist things, but at this point let's not do that. In case we switch this over later, the syscall add/remove logic of this commit should be compatible conceptually.) Fixes: #5163 Replaces: #5944
2017-09-11 18:45:21 +03:00
<varlistentry>
<term><varname>SystemCallFilter=</varname></term>
<listitem><para>Configures the system call filter applied to containers. This is equivalent to the
<option>--system-call-filter=</option> command line switch, and takes the same list parameter. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: add new --rlimit= switch, and always set resource limits explicitly for our container payloads This ensures we set the various resource limits of our container explicitly on each invocation so that we inherit less from our callers into the payload. By default resource limits are now set to the same values Linux generally passes to the host PID 1, thus minimizing needless differences between host and container environments. The limits are now also configurable using a new --rlimit= switch. This is preparation for teaching nspawn native OCI runtime support as OCI permits setting resource limits for container payloads, and it hence probably makes sense if we do too.
2018-05-07 18:59:18 +03:00
<varlistentry>
<term><varname>LimitCPU=</varname></term>
<term><varname>LimitFSIZE=</varname></term>
<term><varname>LimitDATA=</varname></term>
<term><varname>LimitSTACK=</varname></term>
<term><varname>LimitCORE=</varname></term>
<term><varname>LimitRSS=</varname></term>
<term><varname>LimitNOFILE=</varname></term>
<term><varname>LimitAS=</varname></term>
<term><varname>LimitNPROC=</varname></term>
<term><varname>LimitMEMLOCK=</varname></term>
<term><varname>LimitLOCKS=</varname></term>
<term><varname>LimitSIGPENDING=</varname></term>
<term><varname>LimitMSGQUEUE=</varname></term>
<term><varname>LimitNICE=</varname></term>
<term><varname>LimitRTPRIO=</varname></term>
<term><varname>LimitRTTIME=</varname></term>
<listitem><para>Configures various types of resource limits applied to containers. This is equivalent to the
<option>--rlimit=</option> command line switch, and takes the same arguments. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: make the hostname of the container explicitly configurable with a new --hostname= switch Previously, the container's hostname was exclusively initialized from the machine name configured with --machine=, i.e. the internal name and the external name used for and by the container was synchronized. This adds a new option --hostname= that optionally allows the internal name to deviate from the external name. This new option is mainly useful to ultimately implement the OCI runtime spec directly in nspawn, but it might be useful on its own for some other usecases too.
2018-05-07 19:37:32 +03:00
nspawn: add a new --oom-score-adjust= command line switch This is primarily useful in order to provide comprehensive OCI runtime compatibility with nspawn, but might have uses outside of it.
2018-05-07 22:17:09 +03:00
<varlistentry>
<term><varname>OOMScoreAdjust=</varname></term>
<listitem><para>Configures the OOM score adjustment value. This is equivalent to the
<option>--oom-score-adjust=</option> command line switch, and takes the same argument. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: add a new --cpu-affinity= switch Similar as the other options added before, this is primarily useful to provide comprehensive OCI runtime compatbility, but might be useful otherwise, too.
2018-05-07 22:47:15 +03:00
<varlistentry>
<term><varname>CPUAffinity=</varname></term>
<listitem><para>Configures the CPU affinity. This is equivalent to the <option>--cpu-affinity=</option> command
line switch, and takes the same argument. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: make the hostname of the container explicitly configurable with a new --hostname= switch Previously, the container's hostname was exclusively initialized from the machine name configured with --machine=, i.e. the internal name and the external name used for and by the container was synchronized. This adds a new option --hostname= that optionally allows the internal name to deviate from the external name. This new option is mainly useful to ultimately implement the OCI runtime spec directly in nspawn, but it might be useful on its own for some other usecases too.
2018-05-07 19:37:32 +03:00
<varlistentry>
<term><varname>Hostname=</varname></term>
<listitem><para>Configures the kernel hostname set for the container. This is equivalent to the
<option>--hostname=</option> command line switch, and takes the same argument. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: add greater control over how /etc/resolv.conf is handled Fixes: #8014 #1781
2018-05-12 22:50:57 +03:00
<varlistentry>
<term><varname>ResolvConf=</varname></term>
<listitem><para>Configures how <filename>/etc/resolv.conf</filename> in the container shall be handled. This is
equivalent to the <option>--resolv-conf=</option> command line switch, and takes the same argument. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: make --link-journal= configurable through .nspawn files, too
2018-05-12 23:17:16 +03:00
nspawn: similar to the previous patches, also make /etc/localtime handling more configurable Fixes: #9009
2018-05-17 06:43:03 +03:00
<varlistentry>
<term><varname>Timezone=</varname></term>
<listitem><para>Configures how <filename>/etc/localtime</filename> in the container shall be handled. This is
man/systemd.nspawn: fix reference to --timezone argument (#10403)
2018-10-15 00:16:43 +03:00
equivalent to the <option>--timezone=</option> command line switch, and takes the same argument. See
nspawn: similar to the previous patches, also make /etc/localtime handling more configurable Fixes: #9009
2018-05-17 06:43:03 +03:00
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: make --link-journal= configurable through .nspawn files, too
2018-05-12 23:17:16 +03:00
<varlistentry>
<term><varname>LinkJournal=</varname></term>
<listitem><para>Configures how to link host and container journal setups. This is equivalent to the
<option>--link-journal=</option> command line switch, and takes the same parameter. See
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details.</para></listitem>
</varlistentry>
nspawn: implement configurable syscall whitelisting/blacklisting Now that we have ported nspawn's seccomp code to the generic code in seccomp-util, let's extend it to support whitelisting and blacklisting of specific additional syscalls. This uses similar syntax as PID1's support for system call filtering, but in contrast to that always implements a blacklist (and not a whitelist), as we prepopulate the filter with a blacklist, and the unit's system call filter logic does not come with anything prepopulated. (Later on we might actually want to invert the logic here, and whitelist rather than blacklist things, but at this point let's not do that. In case we switch this over later, the syscall add/remove logic of this commit should be compatible conceptually.) Fixes: #5163 Replaces: #5944
2017-09-11 18:45:21 +03:00
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
</variablelist>
</refsect1>
<refsect1>
<title>[Files] Section Options</title>
tree-wide: drop quotes from around [section] For users, the square brackets already serve as markup and clearly delineate the section name from surrounding text. Putting additional markup around that only adds clutter. Also, we were very inconsistent in using the quotes. Let's just drop them altogether.
2020-07-06 12:00:06 +03:00
<para>Settings files may include a [Files]
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
section, which carries various parameters configuring the file
system of the container:</para>
man: add a new directives section for .nspawn They is quite a bit of those directives and they were in "MISCELLANEOUS" because they don't quite fit anywhere. When the OCI-compat stuff is merged, there'll be even more, so let's make a separate section for them.
2019-02-13 12:57:49 +03:00
<variablelist class='nspawn-directives'>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varlistentry>
<term><varname>ReadOnly=</varname></term>
doc: correct orthography, word forms and missing/extraneous words
2014-08-03 09:11:37 +04:00
<listitem><para>Takes a boolean argument, which defaults to off. If
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
specified, the container will be run with a read-only file
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
system. This setting corresponds to the
<option>--read-only</option> command line
switch.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Volatile=</varname></term>
<listitem><para>Takes a boolean argument, or the special value
<literal>state</literal>. This configures whether to run the
container with volatile state and/or configuration. This
option is equivalent to <option>--volatile=</option>, see
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for details about the specific options
supported.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Bind=</varname></term>
<term><varname>BindReadOnly=</varname></term>
<listitem><para>Adds a bind mount from the host into the
container. Takes a single path, a pair of two paths separated
by a colon, or a triplet of two paths plus an option string
separated by colons. This option may be used multiple times to
configure multiple bind mounts. This option is equivalent to
the command line switches <option>--bind=</option> and
<option>--bind-ro=</option>, see
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for details about the specific options supported. This setting
is privileged (see above).</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>TemporaryFileSystem=</varname></term>
<listitem><para>Adds a <literal>tmpfs</literal> mount to the
container. Takes a path or a pair of path and option string,
man: typo fixes
2015-09-07 21:06:58 +03:00
separated by a colon. This option may be used multiple times to
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
configure multiple <literal>tmpfs</literal> mounts. This
option is equivalent to the command line switch
<option>--tmpfs=</option>, see
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for details about the specific options supported. This setting
is privileged (see above).</para></listitem>
</varlistentry>
man: document the new user namespacing options
2016-04-22 14:46:23 +03:00
man: document the various new options nspawn learnt
2018-07-31 14:18:55 +03:00
<varlistentry>
<term><varname>Inaccessible=</varname></term>
tree-wide: fixes for assorted grammar and spelling issues Fixes #16363. Also includes some changes where I generalized the pattern.
2020-07-06 11:49:59 +03:00
<listitem><para>Masks the specified file or directory in the container, by over-mounting it with an empty file
codespell: fix spelling errors
2019-04-27 03:22:40 +03:00
node of the same type with the most restrictive access mode. Takes a file system path as argument. This option
man: document the various new options nspawn learnt
2018-07-31 14:18:55 +03:00
may be used multiple times to mask multiple files or directories. This option is equivalent to the command line
switch <option>--inaccessible=</option>, see
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
about the specific options supported. This setting is privileged (see above).</para></listitem>
</varlistentry>
nspawn: add ability to configure overlay mounts to .nspawn files Fixes: #4634
2016-11-30 01:55:04 +03:00
<varlistentry>
<term><varname>Overlay=</varname></term>
<term><varname>OverlayReadOnly=</varname></term>
<listitem><para>Adds an overlay mount point. Takes a colon-separated list of paths. This option may be used
multiple times to configure multiple overlay mounts. This option is equivalent to the command line switches
<option>--overlay=</option> and <option>--overlay-ro=</option>, see
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
about the specific options supported. This setting is privileged (see above).</para></listitem>
</varlistentry>
man: document the new user namespacing options
2016-04-22 14:46:23 +03:00
<varlistentry>
man: document new nspawn ID mapping mounts features
2021-04-27 19:31:24 +03:00
<term><varname>PrivateUsersOwnership=</varname></term>
man: document the new user namespacing options
2016-04-22 14:46:23 +03:00
man: document new nspawn ID mapping mounts features
2021-04-27 19:31:24 +03:00
<listitem><para>Configures whether the ownership of the files and directories in the container tree
shall be adjusted to the UID/GID range used, if necessary and user namespacing is enabled. This is
equivalent to the <option>--private-users-ownership=</option> command line switch. This option is
privileged (see above).</para></listitem>
man: document the new user namespacing options
2016-04-22 14:46:23 +03:00
</varlistentry>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
</variablelist>
</refsect1>
<refsect1>
<title>[Network] Section Options</title>
tree-wide: drop quotes from around [section] For users, the square brackets already serve as markup and clearly delineate the section name from surrounding text. Putting additional markup around that only adds clutter. Also, we were very inconsistent in using the quotes. Let's just drop them altogether.
2020-07-06 12:00:06 +03:00
<para>Settings files may include a [Network]
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
section, which carries various parameters configuring the network
connectivity of the container:</para>
man: add a new directives section for .nspawn They is quite a bit of those directives and they were in "MISCELLANEOUS" because they don't quite fit anywhere. When the OCI-compat stuff is merged, there'll be even more, so let's make a separate section for them.
2019-02-13 12:57:49 +03:00
<variablelist class='nspawn-directives'>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varlistentry>
<term><varname>Private=</varname></term>
doc: correct orthography, word forms and missing/extraneous words
2014-08-03 09:11:37 +04:00
<listitem><para>Takes a boolean argument, which defaults to off. If
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
enabled, the container will run in its own network namespace
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
and not share network interfaces and configuration with the
host. This setting corresponds to the
<option>--private-network</option> command line
switch.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>VirtualEthernet=</varname></term>
nspawn: improve man page (#3577) This change documents the existance of the systemd-nspawn@.service template unit file, which was previously not mentioned at all. Since the unit file uses slightly different default than nspawn invoked from the command line, these defaults are now explicitly documented too. A couple of further additions and changes are made, too. Replaces: #3497
2016-06-23 00:30:36 +03:00
<listitem><para>Takes a boolean argument. Configures whether to create a virtual Ethernet connection
(<literal>veth</literal>) between host and the container. This setting implies
<varname>Private=yes</varname>. This setting corresponds to the <option>--network-veth</option> command line
switch. This option is privileged (see above). This option is the default if the
<filename>systemd-nspawn@.service</filename> template unit file is used.</para></listitem>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
</varlistentry>
nspawn: add new --network-veth-extra= switch for defining additional veth links The new switch operates like --network-veth, but may be specified multiple times (to define multiple link pairs) and allows flexible definition of the interface names. This is an independent reimplementation of #1678, but defines different semantics, keeping the behaviour completely independent of --network-veth. It also comes will full hook-up for .nspawn files, and the matching documentation.
2015-11-12 23:54:28 +03:00
<varlistentry>
<term><varname>VirtualEthernetExtra=</varname></term>
man: document that VirtualEthernetExtra= has nothing to do with Bridge= Fixes: #15402
2020-04-22 17:42:38 +03:00
<listitem><para>Takes a colon-separated pair of interface names. Configures an additional virtual
Ethernet connection (<literal>veth</literal>) between host and the container. The first specified
name is the interface name on the host, the second the interface name in the container. The latter
may be omitted in which case it is set to the same name as the host side interface. This setting
implies <varname>Private=yes</varname>. This setting corresponds to the
<option>--network-veth-extra=</option> command line switch, and maybe be used multiple times. It is
independent of <varname>VirtualEthernet=</varname>. Note that this option is unrelated to the
<varname>Bridge=</varname> setting below, and thus any connections created this way are not
automatically added to any bridge device on the host side. This option is privileged (see
above).</para></listitem>
nspawn: add new --network-veth-extra= switch for defining additional veth links The new switch operates like --network-veth, but may be specified multiple times (to define multiple link pairs) and allows flexible definition of the interface names. This is an independent reimplementation of #1678, but defines different semantics, keeping the behaviour completely independent of --network-veth. It also comes will full hook-up for .nspawn files, and the matching documentation.
2015-11-12 23:54:28 +03:00
</varlistentry>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varlistentry>
<term><varname>Interface=</varname></term>
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
<listitem><para>Takes a space-separated list of interfaces to
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
add to the container. This option corresponds to the
<option>--network-interface=</option> command line switch and
implies <varname>Private=yes</varname>. This option is
privileged (see above).</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>MACVLAN=</varname></term>
<term><varname>IPVLAN=</varname></term>
doc: correct punctuation and improve typography in documentation
2014-08-03 09:11:12 +04:00
<listitem><para>Takes a space-separated list of interfaces to
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
add MACLVAN or IPVLAN interfaces to, which are then added to
the container. These options correspond to the
<option>--network-macvlan=</option> and
<option>--network-ipvlan=</option> command line switches and
imply <varname>Private=yes</varname>. These options are
privileged (see above).</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>Bridge=</varname></term>
<listitem><para>Takes an interface name. This setting implies
<varname>VirtualEthernet=yes</varname> and
<varname>Private=yes</varname> and has the effect that the
host side of the created virtual Ethernet link is connected to
the specified bridge interface. This option corresponds to the
<option>--network-bridge=</option> command line switch. This
option is privileged (see above).</para></listitem>
</varlistentry>
man: add documentation for the new --network-zone= concept of nspawn
2016-05-06 22:04:52 +03:00
<varlistentry>
<term><varname>Zone=</varname></term>
<listitem><para>Takes a network zone name. This setting implies <varname>VirtualEthernet=yes</varname> and
<varname>Private=yes</varname> and has the effect that the host side of the created virtual Ethernet link is
connected to an automatically managed bridge interface named after the passed argument, prefixed with
<literal>vz-</literal>. This option corresponds to the <option>--network-zone=</option> command line
switch. This option is privileged (see above).</para></listitem>
</varlistentry>
nspawn: add new .nspawn files for container settings .nspawn fiels are simple settings files that may accompany container images and directories and contain settings otherwise passed on the nspawn command line. This provides an efficient way to attach execution data directly to containers.
2015-09-06 02:22:14 +03:00
<varlistentry>
<term><varname>Port=</varname></term>
<listitem><para>Exposes a TCP or UDP port of the container on
the host. This option corresponds to the
<option>--port=</option> command line switch, see
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for the precise syntax of the argument this option takes. This
option is privileged (see above).</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>
Copy Permalink