Container with INCUS (6)

TOC

Here is a series of memos of me trying to use LXC/LXD and INCUS on Debian 12 (bookworm).

What is LXD and Incus

It has been some time since Container with LXC/LXD (1).

• Upstream Incus (0.6 released 2024-02-23) is at https://github.com/lxc/incus by linuxcontainers.org
  • “Incus 0.6 has been released” announcement gives explanations on technical changes.
    • The command name has been changed to incus.
    • コンテナと仮想マシンのマネージャ"Incus" (Japanese) also gives a nice overview.
• Incus is available for Debian 12 from Zabbly package repository.
  • APT setup is at Zabbly package repository as README.md.
  • First steps with Incus – incus-admin group allows full control over Incus.

Now, I decided to purge LXD and try Incus on Debian 12.

Installation of Incus to Debian 12

On a Debian 12 system with its /var/lib on btrfs, I run following commands to install Incus.

 ... setup APT
 $ sudo aptitude install incus incus-ui-canonical
 $ sudo adduser osamu incus-admin
 $ poweroff
...
 $ incus admin init --minimal
  ... go with defaults

This seems to create the /var/lib/incus/images/ directory.

Tracing “First steps with Incus”

I traced “First steps with Incus”.

Getting system images for Incus

Since manpage for incus is missing, let’s see:

 $ incus launch -h
Description:
  Create and start instances from images

Usage:
  incus launch [<remote>:]<image> [<remote>:][<name>] [flags]
...

Full list of remote is available by:.

 $ incus remote list
+-----------------+------------------------------------+---------------+-------------+--------+--------+--------+
|      NAME       |                URL                 |   PROTOCOL    |  AUTH TYPE  | PUBLIC | STATIC | GLOBAL |
+-----------------+------------------------------------+---------------+-------------+--------+--------+--------+
| images          | https://images.linuxcontainers.org | simplestreams | none        | YES    | NO     | NO     |
+-----------------+------------------------------------+---------------+-------------+--------+--------+--------+
| local (current) | unix://                            | incus         | file access | NO     | YES    | NO     |
+-----------------+------------------------------------+---------------+-------------+--------+--------+--------+

Let me create and start instances from images for “Ubuntu 22.04” and “Debian 12”.

 $ incus launch images:ubuntu/22.04 u1
 $ incus launch images:debian/12 d1

System images specified as images:ubuntu/22.04 or images:debian/12 are downloaded to /var/lib/incus/images/. Each of these seems to be made of 2 files. One for rootfs and another for templates(?) sharing the same hash value as a part of their file name. These images seems to be offered in a squashfs. The hash values are listed by incus images ls. The same hash values are used for the directory name under /var/lib/lxd/storage-pools/default/images/ too.

The first invocation of incus launch for an image seems to download it while its subsequent invocations seems to use the previously downloaded corresponding image.

Local instance names are u1 and d1 here. They seem to be created under /var/lib/incus/containers/. These instance names are listed by incus ls and also used for the directory name under /var/lib/incus/storage-pools/default/containers

Here:incus launch ... = incus init ... + incus start ...

Inspect instances

Let me inspect instances.

 $ incus list
+------+---------+------+----------------------------------------------+-----------+-----------+
| NAME |  STATE  | IPV4 |                     IPV6                     |   TYPE    | SNAPSHOTS |
+------+---------+------+----------------------------------------------+-----------+-----------+
| d1   | RUNNING |      | fd42:4c3b:8e2d:60d:216:3eff:fe19:8160 (eth0) | CONTAINER | 0         |
+------+---------+------+----------------------------------------------+-----------+-----------+
| u1   | RUNNING |      | fd42:4c3b:8e2d:60d:216:3eff:fe1e:7fb7 (eth0) | CONTAINER | 0         |
+------+---------+------+----------------------------------------------+-----------+-----------+

Let me stop these instances, and inspect them:

 $ incus stop d1
 $ incus stop u1
 $ incus list
+------+---------+------+------+-----------+-----------+
| NAME |  STATE  | IPV4 | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+------+------+-----------+-----------+
| d1   | STOPPED |      |      | CONTAINER | 0         |
+------+---------+------+------+-----------+-----------+
| u1   | STOPPED |      |      | CONTAINER | 0         |
+------+---------+------+------+-----------+-----------+

So far, no difference from LXD except for the command name being changed from lxc to incus and image repository to use.

Access container

 $ incus start d1
 $ incus exec d1 -- bash
 root@d1:~# id
uid=0(root) gid=0(root) groups=0(root)
 root@d1:~# adduser osamu
 ... ^D

Let’s login:

 $ incus console d1
To detach from the console, press: <ctrl>+a q

d1 login: osamu
Password:
Linux d1 6.5.0-0.deb12.4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.10-1~bpo12+1 (2023-11-23) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
osamu@d1:~$ id
uid=1000(osamu) gid=1000(osamu) groups=1000(osamu),100(users)
 ...

This looked like the weird group ID issue has been resolved in the upstream image. But as I checked closely, the image I downloaded is non-cloud image images:debian/12 without any user setup. Cloud image images:debian/12/cloud still seems to suffer the same problem.

Getting IPv4 working with firewalld

I have enabled a firewall system for my workstation based on firewalld

I configure my system with its GUI firewall-config as follows:

• Connection incusbr0 has to be in the trusted zone instead of public zone.
• public zone has to be set to “Masquerade zone”.

/etc/subuid and /etc/subgid

Although non essential, I have removed 2nd normal user and updated /etc/subuid and /etc/subgid as follows:

root:1000:1
root:1000000:1000000000
osamu:100000:65536

The definition are username:start_id:range.

The first 2 lines are for incus which runs as root.

• By the first line, idmap for the primary user UID/GID=1000 enabled by allowing to map root to 1000.
• By the second line, incus can create many (Full UID/GID space of 256*256=65,536) since ID starts from 1,000,000 which span 1,000,000,000.

Interesting technical background is “Converting from lxd”.

The last line is for podman.

• Since ID starts from 100,000 beyond the normal UID range 0-65,535.
  • For the second user with UID=1001, you add second_user:165536:65536 (or second_user:200000:65536).
  • For the third user with UID=1002, you add third_user:231072:65536 (or third_user:300000:65536).
  • There are enough IDs before ID 1,000,000 used by incus to ensure non-overlapping range.

Important thing is non-overlapping range.

Summary of transition from lxc ... commands to incus ... commands

• Becoming incus-admin group member now allows a user to perform all activities.
• lxd init transition from lxc ... commands to incus ... commands now incus admin init.
• All other lxc ... commands are incus ....
• The main remote repository to use is images: provided by https://linuxcontainers.org/ only (No more ubuntu:).
• Update firewall configuration with IP masquerade for IPv4.