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>
2.4 KiB
2.4 KiB
#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 insshkeys - 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
ide2an 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 anscsi1(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“).