iac-provisioner

Legt Gäste an, die in NetBox geplant sind: Du legst in NetBox eine virtuelle Maschine an, der Provisioner erstellt sie als LXC oder VM auf dem Proxmox-Node – mit den öffentlichen Einzeilern von iac (ct.sh/vm.sh). Teil von iac, Konzept: CONCEPT.md, Abschnitt 15a.

NetBox ──Webhook──▶ iac-provisioner ──SSH──▶ Proxmox-Node: ct.sh / vm.sh
   ▲                 + alle 5 min                     │
   └──── Status, Proxmox-ID, MAC, Journal ◀───────────┘

Stand: MVP – nur anlegen. Änderungen an bestehenden Gästen und Löschen übernimmt der Provisioner (noch) nicht.

Installation (auf dem Proxmox-Node)

IAC_NONINTERACTIVE=1 var_netbox_url=https://netbox.example.org var_netbox_token=<token> \
  bash -c "$(curl -fsSL https://iac.heyer.systems/provisioner/ct.sh)"

Danach im Gast cat /etc/iac-provisioner/README – dort stehen die drei Schritte:

1. Token: netbox_url und netbox_token in /etc/iac/settings.env (falls nicht schon beim Anlegen gesetzt), dann update. Ein Token v2 (NetBox 4.5+) steht dort vollständig als nbt_<key>.<token>, ein alter Token v1 nur als Schlüssel. Der Token braucht Schreibrechte auf VMs, Interfaces, MAC-Adressen, Journal-Einträge und Custom-Field-Choice-Sets.
2. SSH: Den öffentlichen Schlüssel /var/lib/iac-provisioner/.ssh/id_ed25519.pub auf jedem Proxmox-Node in /root/.ssh/authorized_keys eintragen. Der Schlüssel gibt root auf den Nodes – der Provisioner gehört ins interne Netz.
3. Webhook (optional): in NetBox ein Webhook auf http://<provisioner>:8686/webhook mit dem Secret aus grep provisioner_webhook_secret /etc/iac/settings.env und eine Event Rule (Virtual Machine, erstellt + geändert). Ohne Webhook schaut er alle 5 Minuten nach.

NetBox vorbereiten

Tag iac-managed, die Custom Fields und ihre Auswahllisten bringt iac-netbox mit dem Modul provisioner mit – beim Anlegen auswählen (var_modules=provisioner) oder im NetBox-Gast nachrüsten: update --add-modules provisioner. Der Provisioner prüft das Schema beim Start und hält die Auswahl der Apps und Module aktuell (aus https://iac.heyer.systems/apps.json und /modules.json). Eine NetBox, die nicht von iac kommt, braucht dasselbe Schema – Vorlage: iac-netbox/roles/provisioner/files/provisioner_schema.py.

Was	Wo in NetBox
Proxmox (Einzel-Node oder Cluster)	Cluster (Typ z. B. proxmox), jeder Node ein Device in diesem Cluster
SSH-Ziel des Nodes	Config Context des Devices iac.ssh_host, sonst Primary IP, sonst Name
Gateway eines Netzes	Custom Field Gateway am Prefix
VLAN	untagged VLAN am Interface, sonst das VLAN des Prefix
Bridge, Storage, DNS, SSH-Keys der Gäste	Config Context, Schlüssel iac (siehe unten)

Config Context, z. B. am Cluster – der des Devices (Node) überschreibt ihn, die lokalen Kontextdaten der VM überschreiben beide:

{
  "iac": {
    "bridge": "vmbr0",
    "storage": "local-zfs",
    "template_storage": "local",
    "nameserver": ["192.168.40.1"],
    "searchdomain": "intra.example.org",
    "ssh_keys": "https://git.example.org/admin.keys"
  }
}

Einen Gast anlegen

Virtuelle Maschine in NetBox:

Feld	Wert
Name	Hostname (ein FQDN wird zu Hostname + Suchdomain)
Status	Planned
Cluster, Device	Cluster und der Node, auf dem der Gast entsteht
Tags	iac-managed
App, Type, Modules	z. B. netbox, LXC; Modules leer = Vorauswahl der App
vCPUs, Memory, Disk	leer = Werte der App; Memory in MB, Disk in MB (NetBox ≥ 4.1, wird auf GB aufgerundet)
Proxmox ID	leer = nächste freie
Interface eth0	mit IP-Adresse (mit Maske) als Primary IPv4, optional MAC

Ablauf: Planned → Staged (in der Warteschlange) → Active (Proxmox-ID und MAC eingetragen) oder Failed. Jeder Schritt steht im Journal der VM, bei einem Fehler mit den letzten Zeilen der Ausgabe. Nach Failed: Ursache beheben, einen übrig gebliebenen Gast auf dem Node prüfen oder löschen und die VM wieder auf Planned setzen.

Update (im Gast)

update

Selbsttest (im Gast)

bash /var/lib/iac/src/core/bin/iac-smoke