8 Commits (133b2cf5521c9404268f61844d4ced451ab86fca)

Author	SHA1	Message	Date
nexxo	669045021a	EnsureNetworkBridge in die Pipeline: nach dem Neustart, vor der Nachpruefung ... Der Schritt haengt jetzt zwischen RebootIntoPveKernel und ConfigureProxmox. Nach dem Neustart, weil dort ifupdown2 steht und der Tunnel gerade bewiesen hat, dass er einen Neustart ueberlebt. Vor ConfigureProxmox, dessen refuseWithoutBridge() unveraendert stehen bleibt und damit zur Nachpruefung wird — bauen UND pruefen, dasselbe Paar wie BuildVmTemplate -> VerifyVmTemplate. Beschriftung in beiden Sprachen, und ein Test verlangt das kuenftig von JEDEM Pipeline-Schritt statt nur vom neuen: wer einen einhaengt und die Sprachdateien vergisst, faellt im Test auf statt in der Konsole. bridge.sh und bridge-run.sh gehoeren ins Bootstrap-Archiv — es ist der einzige Weg, auf dem das Skript auf eine nackte Maschine kommt. Der End-to-End-Test lief rot, und zu Recht: sein Attrappen-Host sagte nichts ueber sein Netz, also lehnte der neue Schritt ab. Das war der Beweis, dass er wirklich haengt. Er bekommt jetzt einen Host, der seine Bruecke schon hat — den Bau-Pfad kann eine Attrappe nicht nachstellen, er lebt davon, dass die Verbindung abreisst und wiederkommt. Dafuer gibt es die Schritt-Tests und die drei Sandkasten-Laeufe. scriptBridgeState/scriptBridgeStatus liegen in tests/Pest.php, nicht in einer einzelnen Testdatei — zwei Dateien brauchen sie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
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	b9fb401823	Release v1.3.85 — Handshake-Prüfung hing an einem Programm, das es nicht gibt ... Die Übernahme brach in "WireGuard einrichten" ab: fünf Wiederholungen, "WireGuard handshake not up yet". Geprüft wurde mit `ping -c1 -W2 <hub-ip>`. Das fragte drei Dinge auf einmal und nannte nur eines: ob der Handshake steht, ob ICMP durchkommt — und ob es `ping` auf der Maschine überhaupt GIBT. Auf Hetzners `Debian-trixie-latest-amd64-base` gibt es das nicht. `iputils-ping` ist im Image nicht dabei, und PrepareBaseSystem installiert `curl gnupg ifupdown2 chrony`. Der Schritt scheiterte damit über einem Tunnel, der stehen konnte. Auf dem alten Proxmox-Image war ping dabei, deshalb lief es dort durch — dieselbe Pipeline, anderes Grundsystem. Gefragt wird jetzt WireGuard selbst: `date +%s; wg show wg0 latest-handshakes`. Die Uhr des HOSTS kommt in derselben Antwort mit, weil `latest-handshakes` eine absolute Zeit ausgibt und ein Vergleich gegen UNSERE Uhr eine Zeitverschiebung zwischen zwei Maschinen als Tunnelzustand läse. `date` ist in coreutils und überall da. Codex, zwei Runden: - P1: `> 0` hiesse "hat jemals". WireGuard behält den Zeitstempel unbegrenzt, also meldete ein Wiederholungslauf über einem toten Tunnel "steht", und die Schritte danach wählten die Tunneladresse für SSH. Jetzt muss der Handshake frisch sein (180 s) und vom KONFIGURIERTEN Hub kommen — ein fremder Peer auf wg0 ist kein Beweis dafür, dass wir erreichbar sind. - P1: Der neue Host-Versatz (.100) liess die Vergabe in einem Subnetz kleiner als /26 "erschöpft" melden, obwohl unten alles frei war. Der Versatz ist eine Bevorzugung, keine Bedingung: zweiter Durchgang von vorn. Ausserdem, wie gewünscht: Hosts bekommen ihre Tunneladresse ab .100 (CLUPILOT_WG_HOST_OFFSET), Personen zählen weiter von unten. Fortlaufend vergeben landete der erste Host zwischen zwei Notebooks, und wer eine Adresse in einem Protokoll las, konnte nicht sagen, ob dahinter ein Mensch oder eine Maschine steht. 2243 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 03:00:19 +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
nexxo	ed4167eba3	Close SSH and the Proxmox UI to the world once the tunnel is proven up	2026-07-28 23:57:07 +02:00
nexxo	fbe87d99d5	fix(engine): honour backoff timing + don't double-count Proxmox storage ... - RunRunner returns early for a waiting run whose next_attempt_at is in the future, so stale/duplicate jobs can't bypass backoff. - RegisterCapacity takes the largest VM-capable datastore instead of summing overlapping pools (local + local-lvm), preventing placement overcommit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 10:32:14 +02:00
nexxo	65717bd3bd	fix(engine): address Codex review (auth token bootstrap, tunnel recheck, ssh) ... - CreateAutomationToken now bootstraps the pveum role/user/token over the authenticated SSH session (a fresh host has no API token yet); ProxmoxClient is read-only in A. - ConfigureWireguard re-verifies the handshake on the idempotent replay path, never advancing over a dead tunnel. - PhpseclibRemoteShell treats a missing SSH exit status as failure (255). - connectWithKey verifies the pinned host key fingerprint on later logins. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 10:20:59 +02:00
nexxo	ac3d17cd6a	feat(engine): 11-step host onboarding pipeline (SSH -> WG -> Proxmox) ... Idempotent steps: validate, ssh-trust (deploy key + scrub password), prepare base, wireguard (hub peer), install proxmox-ve, reboot-into-pve (retry-poll), configure, automation token, verify api, register capacity, complete. StartHostOnboarding action. 22 tests incl. mocked end-to-end + crash idempotency. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 10:04:39 +02:00