diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml index b269b991703..8c9dbe52ef5 100644 --- a/man/systemd-nspawn.xml +++ b/man/systemd-nspawn.xml @@ -1099,29 +1099,60 @@ - Configures how /etc/resolv.conf inside of the container (i.e. DNS - configuration synchronization from host to container) shall be handled. Takes one of off, - copy-host, copy-static, bind-host, - bind-static, delete or auto. If set to - off the /etc/resolv.conf file in the container is left as it is - included in the image, and neither modified nor bind mounted over. If set to copy-host, the - /etc/resolv.conf file from the host is copied into the container. Similar, if - bind-host is used, the file is bind mounted from the host into the container. If set to - copy-static the static resolv.conf file supplied with - systemd-resolved.service8 is - copied into the container, and correspondingly bind-static bind mounts it there. If set to - delete the /etc/resolv.conf file in the container is deleted if it - exists. Finally, if set to auto the file is left as it is if private networking is turned on - (see ). Otherwise, if systemd-resolved.service is - connectible its static resolv.conf file is used, and if not the host's - /etc/resolv.conf file is used. In the latter cases the file is copied if the image is - writable, and bind mounted otherwise. It's recommended to use copy if the container shall be - able to make changes to the DNS configuration on its own, deviating from the host's settings. Otherwise - bind is preferable, as it means direct changes to /etc/resolv.conf 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 + Configures how /etc/resolv.conf inside of the container shall be + handled (i.e. DNS configuration synchronization from host to container). Takes one of + off, copy-host, copy-static, + copy-uplink, copy-stub, replace-host, + replace-static, replace-uplink, + replace-stub, bind-host, bind-static, + bind-uplink, bind-stub, delete or + auto. + + If set to off the /etc/resolv.conf file in the + container is left as it is included in the image, and neither modified nor bind mounted over. + + If set to copy-host, the /etc/resolv.conf file from the + host is copied into the container, unless the file exists already and is not a regular file (e.g. a + symlink). Similar, if replace-host is used the file is copied, replacing any + existing inode, including symlinks. Similar, if bind-host is used, the file is + bind mounted from the host into the container. + + If set to copy-static, replace-static or + bind-static the static resolv.conf file supplied with + systemd-resolved.service8 + (specifically: /usr/lib/systemd/resolv.conf) is copied or bind mounted into the + container. + + If set to copy-uplink, replace-uplink or + bind-uplink the uplink resolv.conf file managed by + systemd-resolved.service (specifically: + /run/systemd/resolve/resolv.conf) is copied or bind mounted into the + container. + + If set to copy-stub, replace-stub or + bind-stub the stub resolv.conf file managed by + systemd-resolved.service (specifically: + /run/systemd/resolve/stub-resolv.conf) is copied or bind mounted into the + container. + + If set to delete the /etc/resolv.conf file in the + container is deleted if it exists. + + Finally, if set to auto the file is left as it is if private networking is + turned on (see ). Otherwise, if + systemd-resolved.service is connectible its stub + resolv.conf file is used, and if not the host's + /etc/resolv.conf file is used. In the latter cases the file is copied if the + image is writable, and bind mounted otherwise. + + It's recommended to use copy-… or replace-… if the + container shall be able to make changes to the DNS configuration on its own, deviating from the + host's settings. Otherwise bind is preferable, as it means direct changes to + /etc/resolv.conf 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 auto.