gian/incus-mirror
1
0
Fork 0
mirror of https://github.com/lxc/incus synced 2026-08-02 05:26:46 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

doc: Remove mentions of snap/snapd

Browse Source 
Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
This commit is contained in:
Stéphane Graber 2023-10-06 23:36:16 -04:00
parent e572012cbc
commit d0bfce9b39
No known key found for this signature in database
GPG Key ID: C638974D64792D67
23 changed files with 93 additions and 208 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/authentication.md
View File

@ -104,8 +104,8 @@ To enable PKI mode, complete the following steps:
1. Add the {abbr}`CA (Certificate authority)` certificate to all machines:
- Place the `client.ca` file in the clients' configuration directories (`~/.config/incus` or `~/snap/lxd/common/config` for snap users).
- Place the `server.ca` file in the server's configuration directory (`/var/lib/incus` or `/var/snap/lxd/common/lxd` for snap users).
- Place the `client.ca` file in the clients' configuration directories (`~/.config/incus`).
- Place the `server.ca` file in the server's configuration directory (`/var/lib/incus`).
1. Place the certificates issued by the CA on the clients and the server, replacing the automatically generated ones.
1. Restart the server.

29
doc/backup.md
View File

@ -24,7 +24,7 @@ If you use only the `default` profile, or only the standard `lxdbr0` network bri
## Full backup
To create a full backup of all contents of your Incus server, back up the `/var/snap/lxd/common/lxd` (for snap users) or `/var/lib/incus` (otherwise) directory.
To create a full backup of all contents of your Incus server, back up the `/var/lib/incus` directory.
This directory contains your local storage, the Incus database, and your configuration.
It does not contain separate storage devices, however.
@ -36,33 +36,18 @@ If your Incus server uses any external storage (for example, LVM volume groups,
See {ref}`howto-storage-backup-volume` for instructions.
```
To back up your data, create a tarball of `/var/snap/lxd/common/lxd` (for snap users) or `/var/lib/incus` (otherwise).
If you are not using the snap package and your source system has a `/etc/subuid` and `/etc/subgid` file, you should also back up these files.
To back up your data, create a tarball of `/var/lib/incus`.
If your system uses `/etc/subuid` and `/etc/subgid` file, you should also back up these files.
Restoring them avoids needless shifting of instance file systems.
To restore your data, complete the following steps:
1. Stop Incus on your server (for example, with `sudo snap stop lxd`).
1. Delete the directory (`/var/snap/lxd/common/lxd` for snap users or `/var/lib/incus` otherwise).
1. Stop Incus on your server (for example, with `sudo systemctl stop incus.service incus.socket`).
1. Delete the directory (`/var/lib/incus/`).
1. Restore the directory from the backup.
1. Delete and restore any external storage devices.
1. If you are not using the snap, restore the `/etc/subuid` and `/etc/subgid` files.
1. Restart Incus (for example, with `sudo snap start lxd` or by restarting your machine).
### Export a snapshot
If you are using the Incus snap, you can also create a full backup by exporting a snapshot of the snap:
1. Create a snapshot:
sudo snap save lxd
Note down the ID of the snapshot (shown in the `Set` column).
1. Export the snapshot to a file:
sudo snap export-snapshot <ID> <output_file>
See [Snapshots](https://snapcraft.io/docs/snapshots) in the Snapcraft documentation for details.
1. Restore the `/etc/subuid` and `/etc/subgid` files if present.
1. Restart Incus (for example, with `sudo systemctl start incus.socket incus.service` or by restarting your machine).
## Partial backup

2
doc/contributing.md
View File

@ -36,7 +36,7 @@ git push myfork [name_of_your_new_branch]
### Important notes for new Incus contributors
- Persistent data is stored in the `Incus_DIR` directory, which is generated by `incus admin init`.
The `Incus_DIR` defaults to `/var/lib/incus`, or `/var/snap/lxd/common/lxd` for snap users.
The `Incus_DIR` defaults to `/var/lib/incus`.
- As you develop, you may want to change the `Incus_DIR` for your fork of Incus so as to avoid version conflicts.
- Binaries compiled from your source will be generated in the `$(go env GOPATH)/bin` directory by default.
- You will need to explicitly invoke these binaries (not the global `lxd` you may have installed) when testing your changes.

2
doc/database.md
View File

@ -21,7 +21,7 @@ When using Incus as a single machine and not as a cluster, the Dqlite database e
## File location
The database files are stored in the `database` sub-directory of your Incus data directory (thus `/var/snap/lxd/common/lxd/database/` if you use the snap, or `/var/lib/incus/database/` otherwise).
The database files are stored in the `database` sub-directory of your Incus data directory (`/var/lib/incus/database/`).
Upgrading Incus to a newer version might require updating the database schema.
In this case, Incus automatically stores a backup of the database and then runs the update.

15
doc/debugging.md
View File

@ -29,12 +29,6 @@ utility:
curl --unix-socket /var/lib/incus/unix.socket incus/1.0 | jq .
```
or for snap users:
```bash
curl --unix-socket /var/snap/lxd/common/lxd/unix.socket lxd/1.0 | jq .
```
See the [RESTful API](rest-api.md) for available API.
## REST API through HTTPS
@ -44,8 +38,7 @@ client certificate that is generated on first [`incus remote add`](incus_remote_
certificate should be passed to connection tools for authentication
and encryption.
If desired, `openssl` can be used to examine the certificate (`~/.config/incus/client.crt`
or `~/snap/lxd/common/config/client.crt` for snap users):
If desired, `openssl` can be used to examine the certificate (`~/.config/incus/client.crt`):
```bash
openssl x509 -text -noout -in client.crt
@ -60,9 +53,6 @@ Among the lines you should see:
```bash
wget --no-check-certificate --certificate=$HOME/.config/incus/client.crt --private-key=$HOME/.config/incus/client.key -qO - https://127.0.0.1:8443/1.0
# or for snap users
wget --no-check-certificate --certificate=$HOME/snap/lxd/common/config/client.crt --private-key=$HOME/snap/lxd/common/config/client.key -qO - https://127.0.0.1:8443/1.0
```
### With browser
@ -83,8 +73,7 @@ After that, opening [`https://127.0.0.1:8443/1.0`](https://127.0.0.1:8443/1.0) s
## Debug the Incus database
The files of the global {ref}`database <database>` are stored under the `./database/global`
sub-directory of your Incus data directory (e.g. `/var/lib/incus/database/global` or
`/var/snap/lxd/common/lxd/database/global` for snap users).
sub-directory of your Incus data directory (`/var/lib/incus/database/global`).
Since each member of the cluster also needs to keep some data which is specific
to that member, Incus also uses a plain SQLite database (the "local" database),

6
doc/explanation/projects.md
View File

@ -65,11 +65,9 @@ Client certificates
A client that connects using a restricted certificate can see only the project or projects that the client has been granted access to.
Multi-user Incus daemon
: The Incus snap contains a multi-user Incus daemon that allows dynamic project creation on a per-user basis.
You can configure a specific user group other than the `lxd` group to give restricted Incus access to every user in the group.
: A multi-user Incus daemon allows dynamic project creation on a per-user basis.
This is usually used for users that are a member of the `incus` group but aren't in the more privileged `incus-admin` group.
When a user that is a member of this group starts using Incus, Incus automatically creates a confined project for this user.
If you're not using the snap, you can still use this feature if your distribution supports it.
See {ref}`projects-confine` for instructions on how to enable and configure the different authentication methods.

2
doc/explanation/storage.md
View File

@ -61,7 +61,7 @@ Incus can create a loop file on your main drive and have the selected storage dr
This method is functionally similar to using a disk or partition, but it uses a large file on your main drive instead.
This means that every write must go through the storage driver and your main drive's file system, which leads to decreased performance.
The loop files reside in `/var/snap/lxd/common/lxd/disks/` if you are using the snap, or in `/var/lib/incus/disks/` otherwise.
The loop files reside in `/var/lib/incus/disks/`.
Loop files usually cannot be shrunk.
They will grow up to the configured limit, but deleting instances or images will not cause the file to shrink.

2
doc/faq.md
View File

@ -62,7 +62,7 @@ In addition, creating a `/.dockerenv` file in your container can help Docker ign
## Where does the Incus client (`incus`) store its configuration?
The [`incus`](incus.md) command stores its configuration under `~/.config/incus`, or in `~/snap/lxd/common/config` for snap users.
The [`incus`](incus.md) command stores its configuration under `~/.config/incus`.
Various configuration files are stored in that directory, for example:

36
doc/howto/benchmark_performance.md
View File

@ -11,18 +11,14 @@ If you run this tool repeatedly with different configurations, you can compare t
## Get the tool
If you’re using the snap, the benchmarking tool is automatically installed.
It is available as `lxd.benchmark`.
If the incus-benchmark tool isn't provided with your installation, you can build it from source.
Make sure that you have `go` (version 1.20 or later) installed and install the tool with the following command:
Otherwise, if you have installed Incus through your distribution's package manager or built from source, the tool should be available as `lxd-benchmark`.
If it isn't, make sure that you have `go` (version 1.18 or later) installed and install the tool with the following command:
go install github.com/lxc/incus/lxd-benchmark@latest
go install github.com/lxc/incus/incus-benchmark@latest
## Run the tool
Run `lxd.benchmark [action]` to measure the performance of your Incus setup.
(This command assumes that you are using the snap; otherwise, replace `lxd.benchmark` with `lxd-benchmark`, also in the following examples.)
Run `incus-benchmark [action]` to measure the performance of your Incus setup.
The benchmarking tool uses the current Incus configuration.
If you want to use a different project, specify it with `--project`.
@ -30,7 +26,7 @@ If you want to use a different project, specify it with `--project`.
For all actions, you can specify the number of parallel threads to use (default is to use a dynamic batch size).
You can also choose to append the results to a CSV report file and label them in a certain way.
See `lxd.benchmark help` for all available actions and flags.
See `incus-benchmark help` for all available actions and flags.
### Select an image
@ -39,23 +35,23 @@ Before you run the benchmark, select what kind of image you want to use.
Local image
: If you want to measure the time it takes to create a container and ignore the time it takes to download the image, you should copy the image to your local image store before you run the benchmarking tool.
To do so, run a command similar to the following and specify the fingerprint (for example, `2d21da400963`) of the image when you run `lxd.benchmark`:
To do so, run a command similar to the following and specify the fingerprint (for example, `2d21da400963`) of the image when you run `incus-benchmark`:
incus image copy images:ubuntu/22.04 local:
You can also assign an alias to the image and specify that alias (for example, `ubuntu`) when you run `lxd.benchmark`:
You can also assign an alias to the image and specify that alias (for example, `ubuntu`) when you run `incus-benchmark`:
incus image copy images:ubuntu/22.04 local: --alias ubuntu
Remote image
: If you want to include the download time in the overall result, specify a remote image (for example, `images:ubuntu/22.04`).
The default image that `lxd.benchmark` uses is the latest Ubuntu image (`images:ubuntu`), so if you want to use this image, you can leave out the image name when running the tool.
The default image that `incus-benchmark` uses is the latest Ubuntu image (`images:ubuntu`), so if you want to use this image, you can leave out the image name when running the tool.
### Create and launch containers
Run the following command to create a number of containers:
lxd.benchmark init --count <number> <image>
incus-benchmark init --count <number> <image>
Add `--privileged` to the command to create privileged containers.
@ -66,13 +62,13 @@ For example:
* - Command
- Description
* - `lxd.benchmark init --count 10 --privileged`
* - `incus-benchmark init --count 10 --privileged`
- Create ten privileged containers that use the latest Ubuntu image.
* - `lxd.benchmark init --count 20 --parallel 4 images:alpine/edge`
* - `incus-benchmark init --count 20 --parallel 4 images:alpine/edge`
- Create 20 containers that use the Alpine Edge image, using four parallel threads.
* - `lxd.benchmark init 2d21da400963`
* - `incus-benchmark init 2d21da400963`
- Create one container that uses the local image with the fingerprint `2d21da400963`.
* - `lxd.benchmark init --count 10 ubuntu`
* - `incus-benchmark init --count 10 ubuntu`
- Create ten containers that use the image with the alias `ubuntu`.
```
@ -80,11 +76,11 @@ For example:
If you use the `init` action, the benchmarking containers are created but not started.
To start the containers that you created, run the following command:
lxd.benchmark start
incus-benchmark start
Alternatively, use the `launch` action to both create and start the containers:
lxd.benchmark launch --count 10 <image>
incus-benchmark launch --count 10 <image>
For this action, you can add the `--freeze` flag to freeze each container right after it starts.
Freezing a container pauses its processes, so this flag allows you to measure the pure launch times without interference of the processes that run in each container after startup.
@ -93,7 +89,7 @@ Freezing a container pauses its processes, so this flag allows you to measure th
To delete the benchmarking containers that you created, run the following command:
lxd.benchmark delete
incus-benchmark delete
```{note}
You must delete all existing benchmarking containers before you can run a new benchmark.

8
doc/howto/cluster_manage.md
View File

@ -115,15 +115,9 @@ All members must be upgraded to the same version of Incus.
```{caution}
Do not attempt to upgrade your cluster if any of its members are offline.
Offline members cannot be upgraded, and your cluster will end up in a blocked state.
Also note that if you are using the snap, upgrades might happen automatically, so to prevent any issues you should always recover or remove offline members immediately.
```
To upgrade a single member, simply upgrade the Incus package on the host and restart the Incus daemon.
For example, if you are using the snap then refresh to the latest version and cohort in the current channel (also reloads Incus):
sudo snap refresh lxd --cohort="+"
If the new version of the daemon has database schema or API changes, the upgraded member might transition into a "blocked" state.
In this case, the member does not serve any Incus API requests (which means that `incus` commands don't work on that member anymore), but any running instances will continue to run.
@ -137,7 +131,7 @@ When you upgrade the last member, the blocked members will notice that all serve
In a Incus cluster, the API on all servers responds with the same shared certificate, which is usually a standard self-signed certificate with an expiry set to ten years.
The certificate is stored at `/var/snap/lxd/common/lxd/cluster.crt` (if you use the snap) or `/var/lib/incus/cluster.crt` (otherwise) and is the same on all cluster members.
The certificate is stored at `/var/lib/incus/cluster.crt` and is the same on all cluster members.
You can replace the standard certificate with another one, for example, a valid certificate obtained through ACME services (see {ref}`authentication-server-certificate` for more information).
To do so, use the [`incus cluster update-certificate`](incus_cluster_update-certificate.md) command.

12
doc/howto/cluster_recover.md
View File

@ -32,9 +32,8 @@ To do so, complete the following steps:
1. Pick one of the listed database members that is still online as the new leader.
Log on to the machine (if it differs from the one you are already logged on to).
1. Make sure that the Incus daemon is not running on the machine.
For example, if you're using the snap:
sudo snap stop lxd
sudo systemctl stop incus.service incus.socket
1. Log on to all other cluster members that are still online and stop the Incus daemon.
1. On the server that you picked as the new leader, run the following command:
@ -42,9 +41,8 @@ To do so, complete the following steps:
sudo incus admin cluster recover-from-quorum-loss
1. Start the Incus daemon again on all machines, starting with the new leader.
For example, if you're using the snap:
sudo snap start lxd
sudo systemctl start incus.socket incus.service
The database should now be back online.
No information has been deleted from the database.
@ -70,9 +68,8 @@ You can edit the {ref}`clustering-member-roles` of the different members, but wi
Log on to each cluster member and complete the following steps:
1. Stop the Incus daemon.
For example, if you're using the snap:
sudo snap stop lxd
sudo systemctl stop incus.service incus.socket
1. Run the following command:
@ -101,9 +98,8 @@ Log on to each cluster member and complete the following steps:
You can edit the addresses and the roles.
After doing the changes on all cluster members, start the Incus daemon on all members again.
For example, if you're using the snap:
sudo snap start lxd
sudo systemctl start incus.socket incus.service
The cluster should now be fully available again with all members reporting in.
No information has been deleted from the database.

4
doc/howto/disaster_recovery.md
View File

@ -45,12 +45,12 @@ This Incus server currently has the following storage pools:
Would you like to recover another storage pool? (yes/no) [default=no]: yes
Name of the storage pool: default
Name of the storage backend (btrfs, ceph, cephfs, cephobject, dir, lvm, zfs): zfs
Source of the storage pool (block device, volume group, dataset, path, ... as applicable): /var/snap/lxd/common/lxd/storage-pools/default/containers
Source of the storage pool (block device, volume group, dataset, path, ... as applicable): /var/lib/incus/storage-pools/default/containers
Additional storage pool configuration property (KEY=VALUE, empty when done): zfs.pool_name=default
Additional storage pool configuration property (KEY=VALUE, empty when done):
Would you like to recover another storage pool? (yes/no) [default=no]:
The recovery process will be scanning the following storage pools:
- NEW: "default" (backend="zfs", source="/var/snap/lxd/common/lxd/storage-pools/default/containers")
- NEW: "default" (backend="zfs", source="/var/lib/incus/storage-pools/default/containers")
Would you like to continue with scanning for lost volumes? (yes/no) [default=yes]: yes
Scanning for unknown volumes...
The following unknown volumes have been found:

2
doc/howto/instances_access_files.md
View File

@ -63,7 +63,6 @@ To push a directory with all contents, enter the following command:
You can mount an instance file system into a local path on your client.
To do so, make sure that you have `sshfs` installed.
Then run the following command (note that if you're using the snap, the command requires root permissions):
incus file mount <instance_name>/<path_to_directory> <local_location>
@ -73,7 +72,6 @@ You can then access the files from your local machine.
Alternatively, you can set up an SSH SFTP listener.
This method allows you to connect with any SFTP client and with a dedicated user name.
Also, if you're using the snap, it does not require root permission.
To do so, first set up the listener by entering the following command:

6
doc/howto/instances_troubleshoot.md
View File

@ -17,12 +17,6 @@ To troubleshoot the problem, complete the following steps:
incus console <instance_name> --show-log
Detailed server information
: The Incus snap includes a tool that collects the relevant server information for debugging.
Enter the following command to run it:
sudo lxd.buginfo
1. Reboot the machine that runs your Incus server.
1. Try starting your instance again.
If the error occurs again, compare the logs to check if it is the same error.

7
doc/howto/migrate_from_lxc.md
View File

@ -13,10 +13,8 @@ However, this tool does not migrate any of the LXC container configuration.
## Get the tool
If you're using the snap, the `lxc-to-incus` is automatically installed.
It is available as `lxc-to-incus`.
Otherwise, make sure that you have `go` (version 1.18 or later) installed and get the tool with the following command:
If the tool isn't provided alongside your Incus installation, you can build it yourself.
Make sure that you have `go` (version 1.18 or later) installed and get the tool with the following command:
go install github.com/lxc/incus/cmd/lxc-to-incus@latest
@ -36,7 +34,6 @@ Before you start the migration process, stop the LXC containers that you want to
## Start the migration process
Run `sudo lxc-to-incus [flags]` to migrate the containers.
(This command assumes that you are using the snap; otherwise, replace `lxc-to-incus` with `lxc-to-incus`, also in the following examples.)
For example, to migrate all containers:

8
doc/howto/move_instances.md
View File

@ -58,13 +58,7 @@ For containers, there is limited support for live migration using [{abbr}`CRIU (
However, because of extensive kernel dependencies, only very basic containers (non-`systemd` containers without a network device) can be migrated reliably.
In most real-world scenarios, you should stop the container, move it over and then start it again.
If you want to use live migration for containers, you must enable CRIU on both the source and the target server.
If you are using the snap, use the following commands to enable CRIU:
snap set lxd criu.enable=true
sudo systemctl reload snap.lxd.daemon
Otherwise, make sure you have CRIU installed on both systems.
If you want to use live migration for containers, you must first make sure that CRIU is installed on both systems.
To optimize the memory transfer for a container, set the {config:option}`instance-migration:migration.incremental.memory` property to `true` to make use of the pre-copy features in CRIU.
With this configuration, Incus instructs CRIU to perform a series of memory dumps for the container.

8
doc/howto/network_ovn_setup.md
View File

@ -187,7 +187,7 @@ Complete the following steps to have the OVN controller send its logs to Incus.
1. Paste the following configuration:
OVN_CTL_OPTS=" \
--ovn-controller-log='-vsyslog:info --syslog-method=unix:/var/snap/lxd/common/lxd/syslog.socket'"
--ovn-controller-log='-vsyslog:info --syslog-method=unix:/var/lib/incus/syslog.socket'"
1. Restart the OVN controller:
@ -207,9 +207,9 @@ You can include logs for OVN `northd`, OVN north-bound `ovsdb-server`, and OVN s
To do so, edit `/etc/default/ovn-central`:
OVN_CTL_OPTS=" \
--ovn-northd-log='-vsyslog:info --syslog-method=unix:/var/snap/lxd/common/lxd/syslog.socket' \
--ovn-nb-log='-vsyslog:info --syslog-method=unix:/var/snap/lxd/common/lxd/syslog.socket' \
--ovn-sb-log='-vsyslog:info --syslog-method=unix:/var/snap/lxd/common/lxd/syslog.socket'"
--ovn-northd-log='-vsyslog:info --syslog-method=unix:/var/lib/incus/syslog.socket' \
--ovn-nb-log='-vsyslog:info --syslog-method=unix:/var/lib/incus/syslog.socket' \
--ovn-sb-log='-vsyslog:info --syslog-method=unix:/var/lib/incus/syslog.socket'"
sudo systemctl restart ovn-central.service
```

7
doc/howto/projects_confine.md
View File

@ -47,11 +47,8 @@ However, it does not confine the client to this project.
## Confine projects to specific Incus users
If you use the [Incus snap](https://snapcraft.io/lxd), you can configure the multi-user Incus daemon contained in the snap to dynamically create projects for all users in a specific user group.
To do so, set the `daemon.user.group` configuration option to the corresponding user group:
sudo snap set lxd daemon.user.group=<user_group>
Incus can be configured to dynamically create projects for all users in a specific user group.
This is usually achived by having some users be a member of the `incus` group but not the `incus-admin` group.
Make sure that all user accounts that you want to be able to use Incus are a member of this group.

104
doc/installing.md
View File

@ -3,7 +3,7 @@
The easiest way to install Incus is to {ref}`install one of the available packages <installing-from-package>`, but you can also {ref}`install Incus from the sources <installing_from_source>`.
After installing Incus, make sure you have a `lxd` group on your system.
After installing Incus, make sure you have an `incus-admin` group on your system.
Users in this group can interact with Incus.
See {ref}`installing-manage-access` for instructions.
@ -28,81 +28,37 @@ The client tool ([`incus`](incus.md)) is available on most platforms.
### Linux
The easiest way to install Incus on Linux is to install the {ref}`installing-snap-package`, which is available for different Linux distributions.
The easiest way to install Incus on Linux is to install the {ref}`installing-zabbly-package`, which is available for both Debian and Ubuntu.
If this option does not work for you, see the {ref}`installing-other`.
(installing-zabbly-package)=
#### Debian and Ubuntu package from Zabbly
Currently the easiest way to install Incus is to use the Debian or Ubuntu packages provided by [Zabbly](https://zabbly.com).
There are two repositories available, one for the current stable release and one for daily (untested) builds.
(installing-snap-package)=
#### Snap package
Installation instructions may be found here: [https://github.com/zabbly/incus](https://github.com/zabbly/incus)
Incus publishes and tests [snap packages](https://snapcraft.io/lxd) that work for a number of Linux distributions (for example, Ubuntu, Arch Linux, Debian, Fedora, and OpenSUSE).
If you prefer a different installation method, see {ref}`installing`.
Complete the following steps to install the snap:
1. Allow your user to control Incus
1. Check the [Incus snap page on Snapcraft](https://snapcraft.io/lxd) to see if a snap is available for your Linux distribution.
If it is not, use one of the {ref}`installing-other`.
Access to Incus in the packages above is controlled through two groups:
1. Install `snapd`.
See the [installation instructions](https://snapcraft.io/docs/core/install) in the Snapcraft documentation.
- `incus` allows basic user access, no configuration and all actions restricted to a per-user project.
- `incus-admin` allows full control over Incus.
1. Install the snap package.
For the latest feature release, use:
To control Incus without having to run all commands as root, you can add yourself to the `incus-admin` group:
sudo snap install lxd
sudo adduser YOUR-USERNAME incus-admin
newgrp incus-admin
For the Incus 5.0 LTS release, use:
The `newgrp` step is needed in any terminal that interacts with Incus until you restart your user session.
sudo snap install lxd --channel=5.0/stable
1. Initialize Incus with:
For more information about Incus snap packages (regarding more versions, update management etc.), see [Managing the Incus snap](https://discuss.linuxcontainers.org/t/managing-the-lxd-snap/8178).
incus admin init --minimal
```{note}
On Ubuntu 18.04, if you previously had the Incus deb package installed, you can migrate all your existing data over with the following command:
sudo lxd.migrate
```
(installing-other)=
#### Other installation options
Some Linux distributions provide installation options other than the snap package.
````{tabs}
```{group-tab} Alpine Linux
To install the feature branch of Incus on Alpine Linux, run:
apk add lxd
```
```{group-tab} Arch Linux
To install the feature branch of Incus on Arch Linux, run:
pacman -S lxd
```
```{group-tab} Fedora
Fedora RPM packages for LXC/Incus are available in the [COPR repository](https://copr.fedorainfracloud.org/coprs/ganto/lxc4/).
To install the Incus package for the feature branch, run:
dnf copr enable ganto/lxc4
dnf install lxd
See the [Installation Guide](https://github.com/ganto/copr-lxc4/wiki) for more detailed installation instructions.
```
```{group-tab} Gentoo
To install the feature branch of Incus on Gentoo, run:
emerge --ask lxd
```
````
This will create a minimal setup with default options.
If you want to tune the initialization options, see {ref}`initialize` for more information.
### Other operating systems
@ -118,7 +74,7 @@ Incus publishes builds of the Incus client for macOS through [Homebrew](https://
To install the feature branch of Incus, run:
brew install lxc
brew install incus
```
```{group-tab} Windows
@ -129,7 +85,7 @@ To install it:
1. Install Chocolatey by following the [installation instructions](https://docs.chocolatey.org/en-us/choco/setup).
1. Install the Incus client:
choco install lxc
choco install incus
```
````
@ -179,7 +135,7 @@ future.
```bash
git clone https://github.com/lxc/incus
cd lxd
cd incus
```
This will download the current development tree of Incus and place you in the source tree.
@ -191,8 +147,8 @@ The Incus release tarballs bundle a complete dependency tree as well as a
local copy of `libraft` and `libdqlite` for Incus's database setup.
```bash
tar zxvf lxd-4.18.tar.gz
cd lxd-4.18
tar zxvf incus-0.1.tar.gz
cd incus-0.1
```
This will unpack the release tarball and place you inside of the source tree.
@ -247,7 +203,7 @@ Now you can run the daemon (the `--group sudo` bit allows everyone in the `sudo`
group to talk to Incus; you can create your own group if you want):
```bash
sudo -E PATH=${PATH} LD_LIBRARY_PATH=${LD_LIBRARY_PATH} $(go env GOPATH)/bin/lxd --group sudo
sudo -E PATH=${PATH} LD_LIBRARY_PATH=${LD_LIBRARY_PATH} $(go env GOPATH)/bin/incus --group sudo
```
```{note}
@ -258,14 +214,14 @@ If `newuidmap/newgidmap` tools are present on your system and `/etc/subuid`, `et
## Manage access to Incus
Access control for Incus is based on group membership.
The root user and all members of the `lxd` group can interact with the local daemon.
The root user and all members of the `incus-admin` group can interact with the local daemon.
See {ref}`security-daemon-access` for more information.
If the `lxd` group is missing on your system, create it and restart the Incus daemon.
If the `incus-admin` group is missing on your system, create it and restart the Incus daemon.
You can then add trusted users to the group.
Anyone added to this group will have full control over Incus.
Because group membership is normally only applied at login, you might need to either re-open your user session or use the `newgrp lxd` command in the shell you're using to talk to Incus.
Because group membership is normally only applied at login, you might need to either re-open your user session or use the `newgrp incus-admin` command in the shell you're using to talk to Incus.
````{important}
% Include content from [../README.md](../README.md)
@ -280,7 +236,7 @@ Because group membership is normally only applied at login, you might need to ei
After upgrading Incus to a newer version, Incus might need to update its database to a new schema.
This update happens automatically when the daemon starts up after a Incus upgrade.
A backup of the database before the update is stored in the same location as the active database (for example, at `/var/snap/lxd/common/lxd/database` for the snap installation).
A backup of the database before the update is stored in the same location as the active database (at `/var/lib/incus/database`).
```{important}
After a schema update, older versions of Incus might regard the database as invalid.

25
doc/metrics.md
View File

@ -100,31 +100,30 @@ incus config set core.metrics_authentication false
If you run Prometheus on a different machine than your Incus server, you must copy the required certificates to the Prometheus machine:
- The metrics certificate (`metrics.crt`) and key (`metrics.key`) that you created
- The Incus server certificate (`server.crt`) located in `/var/snap/lxd/common/lxd/` (if you are using the snap) or `/var/lib/incus/` (otherwise)
- The Incus server certificate (`server.crt`) located in `/var/lib/incus/`
Copy these files into a `tls` directory that is accessible to Prometheus, for example, `/var/snap/prometheus/common/tls` (if you are using the snap) or `/etc/prometheus/tls` (otherwise).
Copy these files into a `tls` directory that is accessible to Prometheus, for example, `/etc/prometheus/tls`.
See the following example commands:
```bash
# Create tls directory
mkdir /var/snap/prometheus/common/tls
mkdir /etc/prometheus/tls/
# Copy newly created certificate and key to tls directory
cp metrics.crt metrics.key /var/snap/prometheus/common/tls/
cp metrics.crt metrics.key /etc/prometheus/tls/
# Copy Incus server certificate to tls directory
cp /var/snap/lxd/common/lxd/server.crt /var/snap/prometheus/common/tls/
cp /var/lib/incus/server.crt /etc/prometheus/tls/
# Make the files accessible by prometheus
chown -R prometheus:prometheus /etc/prometheus/tls
```
If you are not using the snap, you must also make sure that Prometheus can read these files (usually, Prometheus is run as user `prometheus`):
chown -R prometheus:prometheus /etc/prometheus/tls
### Configure Prometheus to scrape from Incus
Finally, you must add Incus as a target to the Prometheus configuration.
To do so, edit `/var/snap/prometheus/current/prometheus.yml` (if you are using the snap) or `/etc/prometheus/prometheus.yaml` (otherwise) and add a job for Incus.
To do so, edit `/etc/prometheus/prometheus.yaml` and add a job for Incus.
Here's what the configuration needs to look like:
@ -151,7 +150,7 @@ To verify this, open `server.crt` and check the Subject Alternative Name (SAN) s
For example, assume that `server.crt` has the following content:
```{terminal}
:input: openssl x509 -noout -text -in /var/snap/prometheus/common/tls/server.crt
:input: openssl x509 -noout -text -in /etc/prometheus/tls/server.crt
...
X509v3 Subject Alternative Name:
@ -169,7 +168,7 @@ scrape_configs:
# abydos, langara and orilla are part of a single cluster (called `hdc` here)
# initially bootstrapped by abydos which is why all 3 targets
# share the same `ca_file` and `server_name`. That `ca_file` corresponds
# to the `/var/snap/lxd/common/lxd/cluster.crt` file found on every member of
# to the `/var/lib/incus/cluster.crt` file found on every member of
# the Incus cluster.
#
# Note: the `project` param is are provided when not using the `default` project
@ -229,7 +228,7 @@ scrape_configs:
server_name: 'saturn'
```
After editing the configuration, restart Prometheus (for example, `snap restart prometheus`) to start scraping.
After editing the configuration, restart Prometheus (for example, `systemctl restart prometheus`) to start scraping.
## Set up a Grafana dashboard

4
doc/reference/server_settings.md
View File

@ -7,10 +7,6 @@ The `Value` column contains the suggested value for each parameter.
## `/etc/security/limits.conf`
```{note}
For users of the snap, those limits are automatically raised.
```
Domain | Type | Item | Value | Default | Description
:----- | :--- | :---- | :---------- | :-------- | :----------
`*` | soft | `nofile` | `1048576` | unset | Maximum number of open files

2
doc/reference/storage_dir.md
View File

@ -10,7 +10,7 @@ However, Incus operations are {ref}`not optimized <storage-drivers-features>` fo
The `dir` driver in Incus is fully functional and provides the same set of features as other drivers.
However, it is much slower than all the other drivers because it must unpack images and do instant copies of instances, snapshots and images.
Unless specified differently during creation (with the `source` configuration option), the data is stored in the `/var/snap/lxd/common/lxd/storage-pools/` (for snap installations) or `/var/lib/incus/storage-pools/` directory.
Unless specified differently during creation (with the `source` configuration option), the data is stored in the `/var/lib/incus/storage-pools/` directory.
(storage-dir-quotas)=
### Quotas

6
doc/remotes.md
View File

@ -53,11 +53,7 @@ These remotes are available for every user of the Incus server for which you add
Users can override these system remotes (for example, by running [`incus remote rename`](incus_remote_rename.md) or [`incus remote set-url`](incus_remote_set-url.md)), which results in the remote and its associated certificates being copied to the user configuration.
To configure a global remote, edit the `config.yml` file that is located in one of the following directories:
- the directory specified by `Incus_GLOBAL_CONF` (if defined)
- `/var/snap/lxd/common/global-conf/` (if you use the snap)
- `/etc/lxd/` (otherwise)
To configure a global remote, create or edit a `config.yml` file that is located in `/etc/incus/`.
Certificates for the remotes must be stored in the `servercerts` directory in the same location (for example, `/etc/lxd/servercerts/`).
They must match the remote name (for example, `foo.crt`).