]> git.proxmox.com Git - pve-docs.git/blobdiff - pct.adoc
pct: improve template/images section
[pve-docs.git] / pct.adoc
index 2502bcbedbb5e5bcf7725142cee2e857d5c60aba..c52f45e7876209f916936b14ccd302ffbc094d92 100644 (file)
--- a/pct.adoc
+++ b/pct.adoc
@@ -92,11 +92,6 @@ Container Images
 
 Container images, sometimes also referred to as ``templates'' or
 ``appliances'', are `tar` archives which contain everything to run a container.
-`pct` uses them to create a new container, for example:
-
-----
-# pct create 999 local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz
-----
 
 {pve} itself provides a variety of basic templates for the most common Linux
 distributions. They can be downloaded using the GUI or the `pveam` (short for
@@ -104,8 +99,8 @@ distributions. They can be downloaded using the GUI or the `pveam` (short for
 Additionally, https://www.turnkeylinux.org/[TurnKey Linux] container templates
 are also available to download.
 
-The list of available templates is updated daily via cron. To trigger it
-manually:
+The list of available templates is updated daily through the 'pve-daily-update'
+timer. You can also trigger an update manually by executing:
 
 ----
 # pveam update
@@ -144,9 +139,9 @@ system          ubuntu-19.10-standard_19.10-1_amd64.tar.gz
 ----
 
 Before you can use such a template, you need to download them into one of your
-storages. You can simply use storage `local` for that purpose. For clustered
-installations, it is preferred to use a shared storage so that all nodes can
-access those images.
+storages. If you're unsure to which one, you can simply use the `local` named
+storage for that purpose. For clustered installations, it is preferred to use a
+shared storage so that all nodes can access those images.
 
 ----
 # pveam download local debian-10.0-standard_10.0-1_amd64.tar.gz
@@ -160,119 +155,23 @@ downloaded images on storage `local` with:
 local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz  219.95MB
 ----
 
-The above command shows you the full {pve} volume identifiers. They include the
-storage name, and most other {pve} commands can use them. For example you can
-delete that image later with:
-
-----
-# pveam remove local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz
-----
-
-[[pct_container_storage]]
-Container Storage
------------------
-
-The {pve} LXC container storage model is more flexible than traditional
-container storage models. A container can have multiple mount points. This
-makes it possible to use the best suited storage for each application.
-
-For example the root file system of the container can be on slow and cheap
-storage while the database can be on fast and distributed storage via a second
-mount point. See section <<pct_mount_points, Mount Points>> for further
-details.
-
-Any storage type supported by the {pve} storage library can be used. This means
-that containers can be stored on local (for example `lvm`, `zfs` or directory),
-shared external (like `iSCSI`, `NFS`) or even distributed storage systems like
-Ceph. Advanced storage features like snapshots or clones can be used if the
-underlying storage supports them. The `vzdump` backup tool can use snapshots to
-provide consistent container backups.
-
-Furthermore, local devices or local directories can be mounted directly using
-'bind mounts'. This gives access to local resources inside a container with
-practically zero overhead. Bind mounts can be used as an easy way to share data
-between containers.
-
-
-FUSE Mounts
-~~~~~~~~~~~
-
-WARNING: Because of existing issues in the Linux kernel's freezer subsystem the
-usage of FUSE mounts inside a container is strongly advised against, as
-containers need to be frozen for suspend or snapshot mode backups.
-
-If FUSE mounts cannot be replaced by other mounting mechanisms or storage
-technologies, it is possible to establish the FUSE mount on the Proxmox host
-and use a bind mount point to make it accessible inside the container.
-
-
-Using Quotas Inside Containers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Quotas allow to set limits inside a container for the amount of disk space that
-each user can use.
-
-NOTE: This only works on ext4 image based storage types and currently only
-works with privileged containers.
-
-Activating the `quota` option causes the following mount options to be used for
-a mount point:
-`usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0`
+TIP: You can also use the {pve} web interface GUI to download, list and delete
+container templates.
 
-This allows quotas to be used like on any other system. You can initialize the
-`/aquota.user` and `/aquota.group` files by running:
-
-----
-# quotacheck -cmug /
-# quotaon /
-----
-
-Then edit the quotas using the `edquota` command. Refer to the documentation of
-the distribution running inside the container for details.
-
-NOTE: You need to run the above commands for every mount point by passing the
-mount point's path instead of just `/`.
-
-
-Using ACLs Inside Containers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The standard Posix **A**ccess **C**ontrol **L**ists are also available inside
-containers. ACLs allow you to set more detailed file ownership than the
-traditional user/group/others model.
-
-
-Backup of Container mount points
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To include a mount point in backups, enable the `backup` option for it in the
-container configuration. For an existing mount point `mp0`
+`pct` uses them to create a new container, for example:
 
 ----
-mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G
+# pct create 999 local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz
 ----
 
-add `backup=1` to enable it.
+The above command shows you the full {pve} volume identifiers. They include the
+storage name, and most other {pve} commands can use them. For example you can
+delete that image later with:
 
 ----
-mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G,backup=1
+# pveam remove local:vztmpl/debian-10.0-standard_10.0-1_amd64.tar.gz
 ----
 
-NOTE: When creating a new mount point in the GUI, this option is enabled by
-default.
-
-To disable backups for a mount point, add `backup=0` in the way described
-above, or uncheck the *Backup* checkbox on the GUI.
-
-Replication of Containers mount points
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-By default, additional mount points are replicated when the Root Disk is
-replicated. If you want the {pve} storage replication mechanism to skip a mount
-point, you can set the *Skip replication* option for that mount point.
-As of {pve} 5.0, replication requires a storage of type `zfspool`. Adding a
-mount point to a different type of storage when the container has replication
-configured requires to have *Skip replication* enabled for that mount point.
 
 [[pct_settings]]
 Container Settings
@@ -316,25 +215,11 @@ systemd version running inside the container should be equal to or greater than
 Privileged Containers
 ^^^^^^^^^^^^^^^^^^^^^
 
-Security in containers is achieved by using mandatory access control
-('AppArmor'), 'seccomp' filters and namespaces. The LXC team considers this
-kind of container as unsafe, and they will not consider new container escape
-exploits to be security issues worthy of a CVE and quick fix.  That's why
-privileged containers should only be used in trusted environments.
-
-Although it is not recommended, AppArmor can be disabled for a container. This
-brings security risks with it. Some syscalls can lead to privilege escalation
-when executed within a container if the system is misconfigured or if a LXC or
-Linux Kernel vulnerability exists.
-
-To disable AppArmor for a container, add the following line to the container
-configuration file located at `/etc/pve/lxc/CTID.conf`:
-
-----
-lxc.apparmor_profile = unconfined
-----
-
-WARNING: Please note that this is not recommended for production use.
+Security in containers is achieved by using mandatory access control 'AppArmor'
+restrictions, 'seccomp' filters and Linux kernel namespaces. The LXC team
+considers this kind of container as unsafe, and they will not consider new
+container escape exploits to be security issues worthy of a CVE and quick fix.
+That's why privileged containers should only be used in trusted environments.
 
 
 [[pct_cpu]]
@@ -567,6 +452,9 @@ untrusted people.
 To reduce the attack surface, LXC uses many security features like AppArmor,
 CGroups and kernel namespaces.
 
+AppArmor
+~~~~~~~~
+
 AppArmor profiles are used to restrict access to possibly dangerous actions.
 Some system calls, i.e. `mount`, are prohibited from execution.
 
@@ -576,6 +464,25 @@ To trace AppArmor activity, use:
 # dmesg | grep apparmor
 ----
 
+Although it is not recommended, AppArmor can be disabled for a container. This
+brings security risks with it. Some syscalls can lead to privilege escalation
+when executed within a container if the system is misconfigured or if a LXC or
+Linux Kernel vulnerability exists.
+
+To disable AppArmor for a container, add the following line to the container
+configuration file located at `/etc/pve/lxc/CTID.conf`:
+
+----
+lxc.apparmor_profile = unconfined
+----
+
+WARNING: Please note that this is not recommended for production use.
+
+
+// TODO: describe cgroups + seccomp a bit more.
+// TODO: pve-lxc-syscalld
+
+
 Guest Operating System Configuration
 ------------------------------------
 
@@ -647,6 +554,113 @@ NOTE: Container start fails if the configured `ostype` differs from the auto
 detected type.
 
 
+[[pct_container_storage]]
+Container Storage
+-----------------
+
+The {pve} LXC container storage model is more flexible than traditional
+container storage models. A container can have multiple mount points. This
+makes it possible to use the best suited storage for each application.
+
+For example the root file system of the container can be on slow and cheap
+storage while the database can be on fast and distributed storage via a second
+mount point. See section <<pct_mount_points, Mount Points>> for further
+details.
+
+Any storage type supported by the {pve} storage library can be used. This means
+that containers can be stored on local (for example `lvm`, `zfs` or directory),
+shared external (like `iSCSI`, `NFS`) or even distributed storage systems like
+Ceph. Advanced storage features like snapshots or clones can be used if the
+underlying storage supports them. The `vzdump` backup tool can use snapshots to
+provide consistent container backups.
+
+Furthermore, local devices or local directories can be mounted directly using
+'bind mounts'. This gives access to local resources inside a container with
+practically zero overhead. Bind mounts can be used as an easy way to share data
+between containers.
+
+
+FUSE Mounts
+~~~~~~~~~~~
+
+WARNING: Because of existing issues in the Linux kernel's freezer subsystem the
+usage of FUSE mounts inside a container is strongly advised against, as
+containers need to be frozen for suspend or snapshot mode backups.
+
+If FUSE mounts cannot be replaced by other mounting mechanisms or storage
+technologies, it is possible to establish the FUSE mount on the Proxmox host
+and use a bind mount point to make it accessible inside the container.
+
+
+Using Quotas Inside Containers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Quotas allow to set limits inside a container for the amount of disk space that
+each user can use.
+
+NOTE: This only works on ext4 image based storage types and currently only
+works with privileged containers.
+
+Activating the `quota` option causes the following mount options to be used for
+a mount point:
+`usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0`
+
+This allows quotas to be used like on any other system. You can initialize the
+`/aquota.user` and `/aquota.group` files by running:
+
+----
+# quotacheck -cmug /
+# quotaon /
+----
+
+Then edit the quotas using the `edquota` command. Refer to the documentation of
+the distribution running inside the container for details.
+
+NOTE: You need to run the above commands for every mount point by passing the
+mount point's path instead of just `/`.
+
+
+Using ACLs Inside Containers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The standard Posix **A**ccess **C**ontrol **L**ists are also available inside
+containers. ACLs allow you to set more detailed file ownership than the
+traditional user/group/others model.
+
+
+Backup of Container mount points
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To include a mount point in backups, enable the `backup` option for it in the
+container configuration. For an existing mount point `mp0`
+
+----
+mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G
+----
+
+add `backup=1` to enable it.
+
+----
+mp0: guests:subvol-100-disk-1,mp=/root/files,size=8G,backup=1
+----
+
+NOTE: When creating a new mount point in the GUI, this option is enabled by
+default.
+
+To disable backups for a mount point, add `backup=0` in the way described
+above, or uncheck the *Backup* checkbox on the GUI.
+
+Replication of Containers mount points
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By default, additional mount points are replicated when the Root Disk is
+replicated. If you want the {pve} storage replication mechanism to skip a mount
+point, you can set the *Skip replication* option for that mount point.
+As of {pve} 5.0, replication requires a storage of type `zfspool`. Adding a
+mount point to a different type of storage when the container has replication
+configured requires to have *Skip replication* enabled for that mount point.
+
+
 Backup and Restore
 ------------------