2 Commits (b95cae16698e948f2ead5fa9adea7f76bbe9b265)

Author	SHA1	Message	Date
nexxo	db125781ed	Release v1.3.88 — die Vorlage baut sich selbst ... Der letzte Handgriff in der Host-Übernahme fällt weg. VerifyVmTemplate meldete bisher nur, dass eine Vorlage fehlt, weil niemand entschieden hatte, was in die goldene Vorlage gehört. Entschieden ist es längst und steht in deploy/bootstrap/lib/template.sh — der neue Schritt BuildVmTemplate lädt genau diese Datei auf den Host und führt sie dort aus, statt ihre Prüfungen ein zweites Mal in PHP zu haben. Er läuft abgekoppelt und wird abgefragt: Abbild laden und drei virt-customize-Läufe brauchen zehn bis zwanzig Minuten, ein einzelner SSH-Aufruf liefe gegen den Befehlszeitablauf von 2000 s. "Läuft noch" heißt dabei, dass der Prozess lebt (kill -0 gegen die hinterlegte PID) — in der Statusdatei steht "running" auch dann noch, wenn niemand mehr da ist, der sie ändert. Fünf Fehler, die dabei aufgefallen sind und Geld gekostet hätten: - qm importdisk hängte die Platte unter ${storage}:vm-9000-disk-0 ein. Der Name gilt nur bei Block-Ablagen; auf einer Verzeichnis-Ablage heißt sie local:9000/vm-9000-disk-0.qcow2 — also genau auf dem per Debian aufgesetzten Proxmox, um das es hier geht. Jetzt qm set --import-from, und Proxmox benennt selbst. - growpart war nie installiert. GrowGuestFilesystem ruft es auf, und es lief bisher, weil Debians Cloud-Abbild es zufällig mitbringt. Fiele es heraus, läge jedes gekaufte Kontingent über einem Dateisystem, das nie gewachsen ist. Jetzt ausdrücklich eingebaut und als vierte Falle nachgewiesen. - local nimmt ab Werk keine Platten an. Ohne das stirbt nicht nur der Bau, RegisterCapacity meldet danach Kapazität 0: ein Host, der fertig aussieht und nie einen Kunden tragen kann. ensure_image_storage greift nur ein, wenn keine Ablage Platten annimmt, hängt images an die vorhandene Liste an statt sie zu ersetzen, und schreibt über pvesm set statt in die pmxcfs-Datei. - Ein abgebrochener Download blieb unter dem Zielnamen liegen und wäre beim nächsten Lauf ungeprüft weiterbenutzt worden. Jetzt .part, umbenannt erst nach geprüfter Summe. - VerifyVmTemplate und VmTemplateCheck fragten nur, ob VMID 9000 existiert. Ein abgebrochener Bau hinterlässt eine gewöhnliche VM mit dieser Nummer, und beide sagten dazu "passt" — der Fehler kam beim ersten bezahlten Klon zurück. Jetzt template: 1. isTemplate() stellt zwei Anfragen, weil die falsche Antwort hier etwas zerstört: false heißt "Vorlage fehlt", und der Bau fängt mit qm destroy --purge an. Proxmox beantwortet die Konfiguration einer nicht vorhandenen VM mit 500 — demselben Code wie einen Knoten in Not. Die VM-Liste klärt deshalb die Abwesenheit, alles darunter wirft und landet im Wiederholungs-Zweig. Aufgeben beendet erst die Prozessgruppe, dann räumt es auf, und gebaut wird nur die Fehlliste: create_proxmox_template räumt eine VMID weg, bevor es sie anlegt, also hätte "alles Verlangte" eine gesunde zweite Vorlage auf dem Weg zerstört. Geprüft: 2267 Tests grün, Pint sauber, sh -n über alle drei Shell-Dateien, die storage.cfg-Auswertung gegen eine echte Beispieldatei durchgespielt, und jeder Befehl, den der Schritt absetzt, geht durch sh -n — keine andere Prüfung führt diese Shell je aus. Drei Codex-Runden (R15), alle Befunde behoben. Nicht geprüft: nichts davon lief je gegen echte Hardware. Die erste Übernahme auf einem Proxmox-Host ist die Abnahme. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 05:01:44 +02:00
nexxo	336ca9d88c	Make host onboarding survive the machine it runs on ... Nine defects in the host pipeline, every one of which either stopped an install or let a host reach `active` while it could not do its job. The install-stoppers: - InstallProxmoxVe hard-coded `bookworm`. A server ordered today boots Debian 13 trixie, so it added the PVE 8 repo and keyring to a trixie base. The codename now comes from /etc/os-release, the suite and keyring are looked up per release, and an unknown one fails naming what it found instead of guessing. Keys land in /usr/share/keyrings with Signed-By rather than in the deprecated trusted.gpg.d, where they would vouch for every other repository on the machine too. - keyLogin() dialled wg_ip whenever it was filled, but wg_ip is persisted inside the allocation lock BEFORE the handshake is ever proven. Attempt 1 reserved the address and failed at the handshake; every later attempt, including a console Retry, died connecting to a tunnel that did not work — before reaching the only code that could repair wg0.conf. Recovery meant nulling hosts.wg_ip by hand. SSH now uses the tunnel only once the `wg_peer` breadcrumb proves a handshake succeeded, which also rescues the same shape in RebootIntoPveKernel, ConfigureProxmox, CreateAutomationToken and SecureHostFirewall. Not a hole: 22 on the public IP is open until SecureHostFirewall runs, that step runs last, and by then the tunnel is necessarily proven. And nothing validated the hub key/endpoint, so renderConfig() would emit `PublicKey = ` — now refused before anything is installed, allocated or written. - `systemctl enable --now wg-quick@wg0 || wg-quick up wg0` brought the interface up without the enablement, so the tunnel did not come back after the step-6 reboot; on the next attempt both halves failed with "wg0 already exists" and the step retried forever on a working tunnel. The three states are handled separately now, and a changed wg0.conf is actually applied instead of only written. - RebootIntoPveKernel removed the Debian kernel with `|| true`, ignored update-grub's exit status, and rebooted. A /boot that filled up during the full-upgrade could leave a machine only the provider's console can reach. The pve kernel image, its initramfs and update-grub's exit status are all proven first; anything missing fails loudly and does not reboot. - ConfigureProxmox ran `ip link show vmbr0` and threw the result away (its comment claimed it recorded the absence; it recorded nothing), then repeated a rm -f, and always advanced. Proxmox on top of Debian does not create vmbr0, so onboarding reported `active` with no bridge. It now fails with the default route in the message and deliberately does not build the bridge over the primary NIC from a remote shell. The things that were quietly inert: - Proxmox applies a guest's firewall rules only while the firewall is enabled at datacenter level, and it ships disabled — so applyFirewall()'s "80/443 only" rules were inert on every customer VM. Enabling it blindly is the opposite trap (input policy defaults to DROP, node firewall defaults to on, and its management ipset is seeded from the PUBLIC subnet, not the tunnel), so: policy ACCEPT and the node firewall off first, master switch last, read back to confirm. nftables stays the one owner of the host's input policy. - role_privs lacked Sys.Modify, which POST /cluster/backup requires (pve-manager's PVE/API2/Backup.pm), so RegisterBackup 403'd and failed EVERY customer run. And `pveum role add … || true` only ever applied the privilege list on the run that created the role — it converges now, above the token short-circuit so a replay reaches it. - The nftables ruleset dropped all ICMP and ICMPv6. On a real host that breaks IPv6 outright once the neighbour cache expires and black-holes large transfers through PMTUD. Both families accept the types they need, policy drop stays, and a DHCP client reply is allowed so a rebind cannot lose the IPv4 address. - api_token_ref used the `encrypted` cast, i.e. APP_KEY, against SecretVault's own written rule. One rotation would have made every host's Proxmox token undecryptable at once. Moved onto SecretCipher with a migration that leaves any value it cannot read exactly as it is and says so, rather than destroying a credential that exists nowhere else. - Every plan version points at template_vmid 9000 and nothing created or verified it, so the first paid order died in CloneVirtualMachine after the customer had paid. VerifyVmTemplate reports that during onboarding instead. It does not build a template: what goes into the golden image is a product decision. Three tests that proved nothing, fixed: `ran(…emergency-open-firewall.sh)` only ever matched the `chmod 700` above it, because putFile() is not recorded — the script's contents are now asserted, including that nothing in it reopens the firewall on a timer or in the background. The port policy was tested one-sidedly, so a mutation adding `tcp dport { 8006 } accept` passed the suite; the ruleset is now read as a list of what it opens to an unrestricted source. And the end-to-end test says in writing that it proves sequencing only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 00:54:16 +02:00