* 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
------------------
----
The configuration files are simple text files. You can edit them using a normal
-text editor (`vi`, `nano`, etc).
+text editor, for example, `vi` or `nano`.
This is sometimes useful to do small corrections, but keep in mind that you
need to restart the container to apply such changes.
For that reason, it is usually better to use the `pct` command to generate and
modify those files, or do the whole thing using the GUI.
Our toolkit is smart enough to instantaneously apply most changes to running
-containers. This feature is called "hot plug", and there is no need to restart
+containers. This feature is called ``hot plug'', and there is no need to restart
the container in that case.
-In cases where a change cannot be hot plugged, it will be registered as a
+In cases where a change cannot be hot-plugged, it will be registered as a
pending change (shown in red color in the GUI).
They will only be applied after rebooting the container.
projects / pve-docs.git / blobdiff