Incus und Debian 13
Zu Incus könnte ich ganze Romane schreiben (glaube ich), Incus ist für mich so etwas wie proxmox auf Steroiden. Man kann unendlich schnell Testinstanzen anlegen, sowohl LXC als auch VM (ist nur eine zusätzliche Option --vm mehr), mit einer vernünftigen Vorbelegung aller Parameter (steuerbar über Profile), es gibt eine Webinterface, wobei ich hier Proxmox einen Punkt geben würde, dessen Webinterface ist deutlich übersichtlicher und mächtiger.
Mit incus ist das aufsetzen eines neuen Debianservers einfach ein Kommando:
incus launch images:debian/13 test
Das erzeugt eine neue Instanz eines Debian 13 Systems als LXC (wie gesagt, füge --vm dazu und schon ist es eine VM) mit dem Namen test mit dem Defaultprofil. Mit
incus shell test
kann man jetzt in das System und sich dort austoben.
Wenn man beim Setup – zu dem ich gleich komme – ein wenig Achtsamkeit walten läßt, kann man ein einfaches und leicht zu duplizierendes Homelab kreieren. Ich habe meine Standardeinrichtungsparameter und damit schon mehrere Server hochgefahren, zwischen denen ich fröhlich LXCs und VMs hin und her schieben/kopieren kann.
Jetz aber mal der Reihe nach.
Installation
Unter Debian 13 (jetzt als Host) gibt es ein einfache und eine etwa kompliziertere Methode. Zunächst die einfache:
apt update && apt install incus
Das war es schon, seit Debian 13 ist Incus im Repository enthalten, allerdings in einer leicht alten (ich glaube, die nennen das LTS) Version, nicht ganz so alt wie beispielsweise docker, aber immerhin doch schon so, daß ich meist die Zabbly Quellen nutze, dass ist das Originalreporsitory der Incusentwickler und das geht so:
mkdir -p /etc/apt/keyrings/
curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-stable.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc
EOF'
apt update && apt install incus
Das fügt im wesentlichen das stable-repository (daily ist mir doch zu heikel) zu den Paketquellen hinzu und jetzt hat man immer die neueste stabile Version.
Einrichtung
Jetzt hat man alles installiert und der Daemon läuft schon, sieht man mit
systemctl status incus
aber es fehlt noch eine Basiseinrichtung. Das ist im wesentlichen das Erzeugen eines Defaultprofils, damit das System weiß, wie es die Instanz zu dimensionieren hat und wo letztendlich die Daten liegen. Dazu gibt es das praktische Kommando
incus admin init
Das spielen wir jetzt mal durch und ich gebe euch meine Antworten mit Begründung, wenn ihr das doof findet und/oder Verbesserungsvorschläge habt, nehme ich die gerne.
Es geht los mit:
Would you like to use clustering? (yes/no) [default=no]:noIch muss gestehen, das ich die Clusterfunktion von incus (eines der Highlights) noch gar nicht erforscht habe und ich hier deswegen immer den Default belasse. Ich betreieb ja kein Profirechenzentrum mit erhöhter Ausfallsicherheit und so. Weiter:
Do you want to configure a new storage pool? (yes/no) [default=yes]:yes
Hier auf jeden Fall immer Ja sagen, ohne einen Storagepool macht incus gar keinen Sinn. Weiter:
Name of the new storage pool [default=default]:default
Das lasse ich so und wenn man das ändert, muss man es sich merken und auf allen anderen Servern, die man so im Laufe des Lebens anlegt, auch so nennen, sonst gibt es später Schwierigkeien beim Kopieren. Weiter:
Name of the storage backend to use (dir, btrfs) [default=btrfs]:btrfs
Die erste richtige Entscheidung, wenn man noch zfs (es gibt wahre Horden von Fanboys da draussen) installiert hat, kann man auch das nehmen, ich nutze eigentlich immer btrfs. Für den Hausgebrauch ist das ausreichend und hat so herrliche Features wie snapshots, was einem das backup später erleichtert. Ich nehme also btrfs, das nutze ich auf meinen Servern sowieso als Hauptfilesystem. Wer sich unsicher ist und erst mal nur probieren will, kann auch dir nutzen (habe ich am Anfang auch gemacht), aber schöner ist es mit btrfs, dann werden alle Instanzen in eigenen Subvolumes angelegt, was hinterher im Handling superpraktisch ist. Weiter:
Create a new BTRFS pool? (yes/no) [default=yes]:no
Hier sage ich Nein, weil ich das btrfs des Hostsystems mitnutze, ich richte meist im Vorfeld ein Subvolume /pool ein, das ich dann als Verzeichnis für meine Daten nutze. Weiter:
Name of the existing BTRFS pool or dataset:/pool
Hier gebe ich dann mein Subvolume /pool ein. Das war's dann schon mit dem Storagepool. Weiter:
Would you like to create a new local network bridge? (yes/no) [default=yes]:yes
Ja, so eine Bridge ist enorm praktisch, weil damit alle Instanzen, die ich so anlege, Zugriff auf das Internet haben werden, also Ja. Weiter:
What should the new bridge be called? [default=incusbr0]:fxbr0
Ich nenne meine immer fxbr0, kann man aber auch so lassen, man muss es nur überall konsistent machen. Weiter:
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:172.23.2.1/24
Wenn man hier einfach weiterklickt, erzeugt er ein Netz im 10er Raum per Zufall, das ist für den Anfang ganz nett, aber wie ich vorher immer wieder sage, zur Übertragbarkeit der Instanzen ist es einfacher, sich auf ein bestimmtes Netzwerksegment zu konzentrieren, das läuft eh nur lokal, also ich nehme hier immer die Adresse 172.23.2.1/24, das macht ein Class C Netz auf mit 254 Adressen, mehr brauche ich zur Zeit nicht. Weiter:
Would you like to NAT IPv4 traffic on your bridge? [default=yes]:yes
Das finde ich sehr nett von incus, dass es das für mich übernimmt, kein Gefummel mit iptables oder nftables (intern macht er das) und das sorgt dafür, das alle Instanzen mit dem Internet reden können. Wer es genauer wissen will, er macht ein sogennates Managed-Netzwerk auf, d.h. er startet auch einen DHCP/DNS Server (...), der sich dann darum kümmert, das die Instanzen IP-Adressen aus dem o.a. Raum erhalten und sich untereinander kennen mit <Instanzname>.incus ... das finde ich sehr praktisch, natürlich können die Netztwerkprofis unter euch auch ein eigenes OVP-Netzwerk aufmachen und das Routing, Firewalling, etc. selbst machen. Für meine Zwecke ist dieses Netzwerk klasse, ich brauche mich um nahezu nichts zu kümmern, der Internetzugang geht von ganz alleine, deswegen sage ich hier Ja. Weiter:
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:none
Das gleiche Spiel hier, aber ich nutze IPv6 selten bis nie, also sage ich hier meistens none. Weiter:
Would you like the server to be available over the network? (yes/no) [default=no]:yesJa, das will ich meistens, damit ich Sachen hin- und herkopieren kann. Deswegen Ja. Weiter:
Address to bind to (not including port) [default=all]:all
Das kann man einschränken, mache ich aber eigentlich nie. Weiter:
Port to bind to [default=8443]:8443
Der muss natürlich frei sein, ansonsten muss man ihn ändern, da Incus immer das erste ist, was ich installiere auf einem neuen Server, ist der immer frei und deswegen nutze ich ihn auch. Weiter:
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]:yes
Will man eigentlich haben, so ein Autoupdate von Images, deswegen Ja. Weiter:
Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]:noMit der Zeit braucht man das nicht mehr, ich mache also hier immer Nein. Aber wenn man Ja sagt kommt das hier raus:
config:
core.https_address: '[::]:8443'
networks:
- config:
ipv4.address: 172.23.2.1/24
ipv4.nat: "true"
ipv6.address: none
description: ""
name: fxbr0
type: ""
project: default
storage_pools:
- config:
source: /pool
description: ""
name: default
driver: btrfs
storage_volumes: []
profiles:
- config: {}
description: ""
devices:
eth0:
name: eth0
network: fxbr0
type: nic
root:
path: /
pool: default
type: disk
name: default
project: default
projects: []
certificates: []
cluster_groups: []
cluster: null
Diese yml-Datei kann man abspeichern später, wenn man mal einen neuen Server aufsetzt, einspielen, dann spart man sich das Frage-/Antwortspiel.
Und das war es auch schon, jetzt kann man fröhlich Instanzen anlegen und andere lustige Dinge damit machen.
Erste Schritte
So, jetzt ist alle konfiguriert, jetzt kann man loslegen.
Installation Debian als LXC
incus launch images:debian/13 debian
Installation Ubuntu in einer VM:
incus launch images:ubuntu/24.04 ubuntu --vm
Anzeigen aller verfügbaren Images:
incus image list images:
Anzeigen der aktuellen Instanzen:
incus listNatürlich kann man sich auf leere Instanzen anlegen und sich eine iso mounten und über die dann booten und installieren, das ginge hier zu weit, das mache ich bei Interesse später noch einmal.
Ich habe inzwischen einen ganzen Zoo an Instanzen am Laufen, ich zeige euch mal mein aktuellen output von incus list auf meinem Hauptrechner:
+-————+———+——————————+——+--—————+--———+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-————+———+——————————+——+--—————+--———+
| arch | STOPPED | | | VIRTUAL-MACHINE | 0 |
+-————+———+——————————+——+--—————+--———+
| awl | RUNNING | 172.23.2.162 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| bc | RUNNING | 172.23.2.58 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| blog | STOPPED | | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| caddy | RUNNING | 172.23.2.2 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| d1 | RUNNING | 172.23.2.8 (enp5s0) | | VIRTUAL-MACHINE | 0 |
+-————+———+——————————+——+--—————+--———+
| dawarich | RUNNING | 172.23.2.100 (eth0) | | CONTAINER | 0 |
| | | 172.18.0.1 (br-58892826ef18) | | | |
| | | 172.17.0.1 (docker0) | | | |
+-————+———+——————————+——+--—————+--———+
| frischux | RUNNING | 172.23.2.161 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| ghost | RUNNING | 172.23.2.123 (eth0) | | CONTAINER | 0 |
| | | 172.18.0.1 (br-1ad7ce5c8518) | | | |
| | | 172.17.0.1 (docker0) | | | |
+-————+———+——————————+——+--—————+--———+
| imapsync | STOPPED | | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| immich | RUNNING | 172.23.2.135 (eth0) | | CONTAINER | 0 |
| | | 172.18.0.1 (br-145ed74dd1ff) | | | |
| | | 172.17.0.1 (docker0) | | | |
+-————+———+——————————+——+--—————+--———+
| jellyfin | RUNNING | 172.23.2.195 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| jitsi | RUNNING | 172.23.2.57 (enp5s0) | | VIRTUAL-MACHINE | 0 |
| | | 172.18.0.1 (br-32f4bb832e16) | | | |
| | | 172.17.0.1 (docker0) | | | |
+-————+———+——————————+——+--—————+--———+
| mailcow | STOPPED | | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| mox | RUNNING | 172.23.2.4 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| nextcloud | RUNNING | 172.23.2.137 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| nexterm | RUNNING | 172.23.2.79 (eth0) | | CONTAINER | 0 |
| | | 172.18.0.1 (br-28256d7c95c1) | | | |
| | | 172.17.0.1 (docker0) | | | |
+-————+———+——————————+——+--—————+--———+
| ntfy | RUNNING | 172.23.2.55 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| ollama | STOPPED | | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| paperless | RUNNING | 172.23.2.160 (eth0) | | CONTAINER | 0 |
| | | 172.18.0.1 (br-21aafef0aa07) | | | |
| | | 172.17.0.1 (docker0) | | | |
+-————+———+——————————+——+--—————+--———+
| stalwart | STOPPED | | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| test | RUNNING | 172.23.3.1 (fxbr0) | | VIRTUAL-MACHINE | 0 |
| | | 172.23.2.140 (enp5s0) | | | |
+-————+———+——————————+——+--—————+--———+
| vaultwarden | RUNNING | 172.23.2.113 (eth0) | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| wallet | STOPPED | | | CONTAINER | 0 |
+-————+———+——————————+——+--—————+--———+
| win11 | STOPPED | | | VIRTUAL-MACHINE | 0 |
+-————+———+——————————+——+--—————+--———+
Ihr seht, es ist ganz schön was los auf meinem Rechner, in der nächsten Folge werde ich darauf eingehen, wie ich meine ganzen Dienste ins Internet bringe, bleibt gespannt.