* Container setup from host (network, DNS, storage, etc.)
-Security Considerations
------------------------
-
-Containers use the kernel of the host system. This creates a big attack surface
-for malicious users. This should be considered if containers are provided to
-untrustworthy people. In general, full virtual machines provide better
-isolation.
-
-However, LXC uses many security features like AppArmor, CGroups and kernel
-namespaces to reduce the attack surface.
-
-AppArmor profiles are used to restrict access to possibly dangerous actions.
-Some system calls, i.e. `mount`, are prohibited from execution.
-
-To trace AppArmor activity, use:
-
-----
-# dmesg | grep apparmor
-----
-
-Guest Operating System Configuration
-------------------------------------
-
-{pve} tries to detect the Linux distribution in the container, and modifies
-some files. Here is a short list of things done at container startup:
-
-set /etc/hostname:: to set the container name
-
-modify /etc/hosts:: to allow lookup of the local hostname
-
-network setup:: pass the complete network setup to the container
-
-configure DNS:: pass information about DNS servers
-
-adapt the init system:: for example, fix the number of spawned getty processes
-
-set the root password:: when creating a new container
-
-rewrite ssh_host_keys:: so that each container has unique keys
-
-randomize crontab:: so that cron does not start at the same time on all containers
-
-Changes made by {PVE} are enclosed by comment markers:
-
-----
-# --- BEGIN PVE ---
-<data>
-# --- END PVE ---
-----
-
-Those markers will be inserted at a reasonable location in the file. If such a
-section already exists, it will be updated in place and will not be moved.
-
-Modification of a file can be prevented by adding a `.pve-ignore.` file for it.
-For instance, if the file `/etc/.pve-ignore.hosts` exists then the `/etc/hosts`
-file will not be touched. This can be a simple empty file created via:
-
-----
-# touch /etc/.pve-ignore.hosts
-----
-
-Most modifications are OS dependent, so they differ between different
-distributions and versions. You can completely disable modifications by
-manually setting the `ostype` to `unmanaged`.
-
-OS type detection is done by testing for certain files inside the
-container:
-
-Ubuntu:: inspect /etc/lsb-release (`DISTRIB_ID=Ubuntu`)
-
-Debian:: test /etc/debian_version
-
-Fedora:: test /etc/fedora-release
-
-RedHat or CentOS:: test /etc/redhat-release
-
-ArchLinux:: test /etc/arch-release
-
-Alpine:: test /etc/alpine-release
-
-Gentoo:: test /etc/gentoo-release
-
-NOTE: Container start fails if the configured `ostype` differs from the auto
-detected type.
-
-
[[pct_container_images]]
Container Images
----------------
and documentation see the example script under
`/usr/share/pve-docs/examples/guest-example-hookscript.pl`.
+Security Considerations
+-----------------------
+
+Containers use the kernel of the host system. This exposes an attack surface
+for malicious users. In general, full virtual machines provide better
+isolation. This should be considered if containers are provided to unkown or
+untrusted people.
+
+To reduce the attack surface, LXC uses many security features like AppArmor,
+CGroups and kernel namespaces.
+
+AppArmor profiles are used to restrict access to possibly dangerous actions.
+Some system calls, i.e. `mount`, are prohibited from execution.
+
+To trace AppArmor activity, use:
+
+----
+# dmesg | grep apparmor
+----
+
+Guest Operating System Configuration
+------------------------------------
+
+{pve} tries to detect the Linux distribution in the container, and modifies
+some files. Here is a short list of things done at container startup:
+
+set /etc/hostname:: to set the container name
+
+modify /etc/hosts:: to allow lookup of the local hostname
+
+network setup:: pass the complete network setup to the container
+
+configure DNS:: pass information about DNS servers
+
+adapt the init system:: for example, fix the number of spawned getty processes
+
+set the root password:: when creating a new container
+
+rewrite ssh_host_keys:: so that each container has unique keys
+
+randomize crontab:: so that cron does not start at the same time on all containers
+
+Changes made by {PVE} are enclosed by comment markers:
+
+----
+# --- BEGIN PVE ---
+<data>
+# --- END PVE ---
+----
+
+Those markers will be inserted at a reasonable location in the file. If such a
+section already exists, it will be updated in place and will not be moved.
+
+Modification of a file can be prevented by adding a `.pve-ignore.` file for it.
+For instance, if the file `/etc/.pve-ignore.hosts` exists then the `/etc/hosts`
+file will not be touched. This can be a simple empty file created via:
+
+----
+# touch /etc/.pve-ignore.hosts
+----
+
+Most modifications are OS dependent, so they differ between different
+distributions and versions. You can completely disable modifications by
+manually setting the `ostype` to `unmanaged`.
+
+OS type detection is done by testing for certain files inside the
+container. {pve} first checks the `/etc/os-release` file
+footnote:[/etc/os-release replaces the multitude of per-distribution
+release files https://manpages.debian.org/stable/systemd/os-release.5.en.html].
+If that file is not present, or it does not contain a clearly recognizable
+distribution identifier the following distribution specific release files are
+checked.
+
+Ubuntu:: inspect /etc/lsb-release (`DISTRIB_ID=Ubuntu`)
+
+Debian:: test /etc/debian_version
+
+Fedora:: test /etc/fedora-release
+
+RedHat or CentOS:: test /etc/redhat-release
+
+ArchLinux:: test /etc/arch-release
+
+Alpine:: test /etc/alpine-release
+
+Gentoo:: test /etc/gentoo-release
+
+NOTE: Container start fails if the configured `ostype` differs from the auto
+detected type.
+
+
Backup and Restore
------------------
projects / pve-docs.git / blobdiff