shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-05-23 02:50:21 +03:00
Code

man: document the new --resolv-conf= options

Browse Source
This commit is contained in:
Lennart Poettering 2020-04-21 18:56:30 +02:00
parent 86775e3524
commit e309b929ba
1 changed files with 54 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
man/systemd-nspawn.xml
View File

@ -1099,29 +1099,60 @@
<varlistentry> <varlistentry>
<term><option>--resolv-conf=</option></term> <term><option>--resolv-conf=</option></term>
<listitem><para>Configures how <filename>/etc/resolv.conf</filename> inside of the container (i.e. DNS <listitem><para>Configures how <filename>/etc/resolv.conf</filename> inside of the container shall be
configuration synchronization from host to container) shall be handled. Takes one of <literal>off</literal>, handled (i.e. DNS configuration synchronization from host to container). Takes one of
<literal>copy-host</literal>, <literal>copy-static</literal>, <literal>bind-host</literal>, <literal>off</literal>, <literal>copy-host</literal>, <literal>copy-static</literal>,
<literal>bind-static</literal>, <literal>delete</literal> or <literal>auto</literal>. If set to <literal>copy-uplink</literal>, <literal>copy-stub</literal>, <literal>replace-host</literal>,
<literal>off</literal> the <filename>/etc/resolv.conf</filename> file in the container is left as it is <literal>replace-static</literal>, <literal>replace-uplink</literal>,
included in the image, and neither modified nor bind mounted over. If set to <literal>copy-host</literal>, the <literal>replace-stub</literal>, <literal>bind-host</literal>, <literal>bind-static</literal>,
<filename>/etc/resolv.conf</filename> file from the host is copied into the container. Similar, if <literal>bind-uplink</literal>, <literal>bind-stub</literal>, <literal>delete</literal> or
<literal>bind-host</literal> is used, the file is bind mounted from the host into the container. If set to <literal>auto</literal>.</para>
<literal>copy-static</literal> the static <filename>resolv.conf</filename> file supplied with
<citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> is <para>If set to <literal>off</literal> the <filename>/etc/resolv.conf</filename> file in the
copied into the container, and correspondingly <literal>bind-static</literal> bind mounts it there. If set to container is left as it is included in the image, and neither modified nor bind mounted over.</para>
<literal>delete</literal> the <filename>/etc/resolv.conf</filename> file in the container is deleted if it
exists. Finally, if set to <literal>auto</literal> the file is left as it is if private networking is turned on <para>If set to <literal>copy-host</literal>, the <filename>/etc/resolv.conf</filename> file from the
(see <option>--private-network</option>). Otherwise, if <filename>systemd-resolved.service</filename> is host is copied into the container, unless the file exists already and is not a regular file (e.g. a
connectible its static <filename>resolv.conf</filename> file is used, and if not the host's symlink). Similar, if <literal>replace-host</literal> is used the file is copied, replacing any
<filename>/etc/resolv.conf</filename> file is used. In the latter cases the file is copied if the image is existing inode, including symlinks. Similar, if <literal>bind-host</literal> is used, the file is
writable, and bind mounted otherwise. It's recommended to use <literal>copy</literal> if the container shall be bind mounted from the host into the container.</para>
able to make changes to the DNS configuration on its own, deviating from the host's settings. Otherwise
<literal>bind</literal> is preferable, as it means direct changes to <filename>/etc/resolv.conf</filename> in <para>If set to <literal>copy-static</literal>, <literal>replace-static</literal> or
the container are not allowed, as it is a read-only bind mount (but note that if the container has enough <literal>bind-static</literal> the static <filename>resolv.conf</filename> file supplied with
privileges, it might simply go ahead and unmount the bind mount anyway). Note that both if the file is bind <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
mounted and if it is copied no further propagation of configuration is generally done after the one-time early (specifically: <filename>/usr/lib/systemd/resolv.conf</filename>) is copied or bind mounted into the
initialization (this is because the file is usually updated through copying and renaming). Defaults to container.</para>
<para>If set to <literal>copy-uplink</literal>, <literal>replace-uplink</literal> or
<literal>bind-uplink</literal> the uplink <filename>resolv.conf</filename> file managed by
<filename>systemd-resolved.service</filename> (specifically:
<filename>/run/systemd/resolve/resolv.conf</filename>) is copied or bind mounted into the
container.</para>
<para>If set to <literal>copy-stub</literal>, <literal>replace-stub</literal> or
<literal>bind-stub</literal> the stub <filename>resolv.conf</filename> file managed by
<filename>systemd-resolved.service</filename> (specifically:
<filename>/run/systemd/resolve/stub-resolv.conf</filename>) is copied or bind mounted into the
container.</para>
<para>If set to <literal>delete</literal> the <filename>/etc/resolv.conf</filename> file in the
container is deleted if it exists.</para>
<para>Finally, if set to <literal>auto</literal> the file is left as it is if private networking is
turned on (see <option>--private-network</option>). Otherwise, if
<filename>systemd-resolved.service</filename> is connectible its stub
<filename>resolv.conf</filename> file is used, and if not the host's
<filename>/etc/resolv.conf</filename> file is used. In the latter cases the file is copied if the
image is writable, and bind mounted otherwise.</para>
<para>It's recommended to use <literal>copy-…</literal> or <literal>replace-…</literal> if the
container shall be able to make changes to the DNS configuration on its own, deviating from the
host's settings. Otherwise <literal>bind</literal> is preferable, as it means direct changes to
<filename>/etc/resolv.conf</filename> in the container are not allowed, as it is a read-only bind
mount (but note that if the container has enough privileges, it might simply go ahead and unmount the
bind mount anyway). Note that both if the file is bind mounted and if it is copied no further
propagation of configuration is generally done after the one-time early initialization (this is
because the file is usually updated through copying and renaming). Defaults to
<literal>auto</literal>.</para></listitem> <literal>auto</literal>.</para></listitem>
</varlistentry> </varlistentry>