Files

T

florian.wildeandClaude Opus 5.5 7beeafd2f6 fix(templates): cloud-init-Laufwerk an scsi1 statt ide2

q35 hängt IDE an den SATA-Controller; der Cloud-Kernel von Debian 12 kennt ihn nicht, cloud-init fand keine Datenquelle. Gefunden bei der Abnahme von #021 auf pve-demo: Template-Bau über die Bau-Adresse und eine Debian-12-VM daraus, beides ohne SSH zum Node.

Closes #021

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-12 20:25:45 +02:00

2.4 KiB

Raw Permalink Blame History

#021 Template-Bau ohne SSH (Bau-Adresse)

Status: erledigt Meilenstein: v0.3.0 Labels: feature, proxmox Geschätzt: 3 h Tatsächlich: 0 h 19 min + 0 h 35 min Abnahme

Ziel

Templates auch auf Servern ohne SSH zum Node bauen. Der Guest-Agent wird dann nicht per Snippet, sondern über SSH in die Vorbereitungs-VM eingebaut.

Aufgaben

Server-Einstellung bauNetz: statische IP/CIDR, Gateway, DNS (Bridge/VLAN wie beim Template-Bau gewählt)
Vorbereitungsstart mit cloud-init ipconfig0 = Bau-Adresse und ProxDeploys Bereitstellungsschlüssel in sshkeys
SSH in die VM (Host-Key aus der Konsole nicht prüfbar → Schlüssel nur für diese eine Verbindung), qemu-guest-agent installieren, Maschinen-ID leeren, cloud-init clean, ausschalten
Fähigkeitserkennung: „Template-Bau per API ohne SSH möglich, wenn Bau-Adresse gesetzt“

Akzeptanzkriterien

Template-Bau auf pve-demo mit abgeschaltetem SSH (2026-10-12, Bau-Adresse 10.0.10.180): Template 9003 tpl-debian-12; daraus VM 111 pd-deb12 ebenfalls ohne Node-SSH ausgerollt, Agent aus dem Template, eigene Maschinen-ID

Abhängigkeiten

#007

Notizen / Entscheidungen

Fähigkeitserkennung war zu optimistisch: „Template-Bau per API“ stand auch ohne Node-SSH da, obwohl der Guest-Agent dann nicht hineinkam. Jetzt: per API nur mit Snippet-Weg oder Bau-Adresse.
Der Bereitstellungsschlüssel kommt per cloud-init an den Standardbenutzer des Images; danach werden alle authorized_keys, ciuser, sshkeys und die feste Adresse entfernt.
Host-Key der frischen VM ist vorher unbekannt (TOFU, nur für diese eine Verbindung).
Aus #007 ausgegliedert, damit Etappe 2 nicht wartet: der Testhost hat SSH, und VM-Deployments aus vorhandenen Templates laufen ohnehin ohne SSH.
Abnahme fand einen echten Fehler: Das cloud-init-Laufwerk hing als ide2 an der q35-Maschine (also am SATA-Controller). Der „cloud“-Kernel von Debian 12 hat dafür keinen Treiber – cloud-init fand keine Datenquelle, die VM bootete als „localhost“ ohne Adresse. Debian 13 und Ubuntu kennen den Controller, deshalb fiel es bisher nicht auf. Neue Templates hängen das Laufwerk an scsi1 (virtio-SCSI wie die System-Disk). Vorhandene Templates bleiben, wie sie sind.
Bau-Adresse per Ping- und ARP-Probe vom Testhost gewählt (10.0.10.150–199 stumm, Florians Freigabe „such dir eine IP“).

2.4 KiB Raw Permalink Blame History Unescape Escape