80 Commits (133b2cf5521c9404268f61844d4ced451ab86fca)

Author	SHA1	Message	Date
nexxo	133b2cf552	Codex-Runde 2: der Gateway-Fix erreichte den Produktivpfad nicht ... Zwei Befunde, beide echt, und der erste ist ein Patzer: detect_network_style wurde auf default_gateway() umgestellt, bridge-run.sh blieb auf awk '{ print }'. Der Treiber reichte also weiter den KARTENNAMEN als Gateway an build_bridge, und in der Strophe stand 'gateway ens3' — der Fix half genau der Stelle nicht, fuer die er gedacht war. Meine Sandkiste konnte das nicht sehen: sie hatte immer ein via. Jetzt ist sie parametrisiert, und ein Test faehrt bridge-run.sh mit einer via-losen Standardroute durch und liest die geschriebene Strophe. Der Beweis laeuft ueber den Produktivpfad, nicht ueber eine Einzelfunktion. Zweitens: default_gateway suchte das erste via IRGENDWO in der Ausgabe, detect_primary_interface das dev der ERSTEN Zeile. Bei zwei Standardrouten baute das eine Bruecke ueber die Karte der einen mit dem Gateway der anderen. Beide haengen jetzt an primary_default_route mit head -1 — eine Route, eine Quelle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	0bb61d39bd	Codex-Runde 1: drei P1 an der Rueckfahrkarte, plus ein Gateway ohne via ... Die Ruecknahme konnte Erfolg melden, ohne einen zu haben. Drei Wege dorthin, alle behoben: - Sie schaltete den entmachteten Netzverwalter nicht wieder ein. Die Sicherung umfasst nur /etc/network/interfaces*; kam die Verbindung von cloud-init, networkd oder NetworkManager, spielte die Ruecknahme eine Datei zurueck, die die Maschine nie getragen hat, und liess den Verwalter abgeschaltet. Genau der tote Host, den der Zeitgeber verhindern soll. disown_network_manager hinterlaesst jetzt eine Notiz (WAS entmachtet, WELCHE Strophen verdraengt), die das Ruecknahme-Skript beim Feuern liest — aufgeschrieben statt eingebacken, weil der Zeitgeber vor dem Entmachten gestellt wird. - Sie setzte 'rolled-back' auch, wenn tar oder ifreload scheiterten. Das urspruengliche network.sh hatte dafuer set -e; beim Umbau ist es verlorengegangen. Jetzt bricht jeder Fehlschlag ab, bevor die Marke entsteht — CluPilot pollt dann bis zur Frist statt 'ist zurueck' zu glauben. - Eine verdraengte interfaces.d-Strophe wurde nur umbenannt. Der Stern in 'source interfaces.d/*' fasst sie weiter; das versteckte die Kollision vor dem Leser, statt sie zu loesen. Jetzt wandert sie aus dem Verzeichnis heraus, und die Ruecknahme holt sie zurueck. Dazu ein eigener Fund: das Gateway wurde mit awk '{print }' gelesen. Bei 'default dev ens3 scope link' ist das der KARTENNAME, woraus 'gateway ens3' in der Strophe wuerde. default_gateway() liest jetzt hinter dem via, und eine Standardroute ohne via wandert als eigene up-Zeile mit, statt verlorenzugehen. Zurueckgewiesen: der P2 zu extra_routes. 'ip route show dev X' laesst das dev-Feld WEG (im Container nachgemessen), das angehaengte 'dev vmbr0' ist also richtig. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
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	ba7e25da54	EnsureNetworkBridge: abbestellen nach der Nachpruefung, aufgeben ohne die Rueckfahrkarte wegzuwerfen ... Drei Enden, und jedes hat eine Reihenfolge: - Abbestellt wird erst, NACHDEM die Bruecke nachgeprueft ist. Dass der Zweig erreicht wird, ist der Beweis: SSH kam ueber den Tunnel an und vmbr0 traegt Standardroute und Adresse — bridge_proven, von aussen gefragt. Und nur, wenn DIESER Lauf den Zeitgeber auch gestellt hat; ohne Termin im Kontext gehoeren die Unit-Dateien jemand anderem. - awaitRollback pollt, bis 'rolled-back' liegt, statt sofort zu scheitern. Solange der Zeitgeber aussteht, steckt die Maschine mitten in einer Umstellung, und ein fail() liesse sie dort liegen. Gedeckelt durch die Schritt-Frist, die das Dreifache der Zeitgeber-Frist ist. - giveUp loescht den Termin (sonst wird jedes Retry nach einem Fehlschlag zum sofortigen zweiten Fehlschlag), behaelt bridge_attempts (sonst ist der Deckel von zwei Versuchen keiner) und bestellt den Zeitgeber NICHT ab — er ist die Rueckfahrkarte, und steht er noch, hat er seinen Grund. Der sh-n-Test ist gegengeprobt: mit absichtlich kaputtem Quoting faellt er. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	712422c161	EnsureNetworkBridge: Start abgekoppelt, und der Verbindungsabriss wird gepollt statt gezaehlt ... Die tragende Zeile ist das try/catch um keyLogin. RunRunner:102 verwandelt jede geworfene Ausnahme in ein retry(), und retry verbraucht das Versuchskonto — ungefangen brennt der erwartete Verbindungsabriss die fuenf Versuche in wenigen Minuten durch und laesst den Lauf scheitern, BEVOR der Host wieder da ist. Genau der Unterschied zwischen 'Wiederholung' und 'toter Server'. Unterschieden wird am Termin im Run-Kontext: ohne ihn hat dieser Lauf nichts angefasst, dann ist ein Verbindungsfehler ein gewoehnlicher und darf einen Versuch kosten. Mit ihm laeuft gerade eine Umstellung, dann wird gepollt. bridge.sh und bridge-run.sh gehen wortgleich hoch (Test vergleicht Byte fuer Byte gegen die Repo-Datei), env traegt den Hub-Schluessel mit, damit der Treiber den Handshake gegen den RICHTIGEN Peer prueft. Start per nohup setsid, PID-Datei abgewartet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	786dd54257	EnsureNetworkBridge: schon da heisst nichts anfassen, und keine Bruecke auf einer Bruecke ... Der Schritt, aber erst sein billigster Teil. Zwei Zusicherungen: - Traegt vmbr0 schon Standardroute UND Adresse, dann advance() ohne einen einzigen veraendernden Befehl. pve-fns-1 hat die Bruecke von Hand; ein Wiederanlauf, der sie umbaut, baut ein funktionierendes Netz um. - Ist die Karte mit der Standardroute keine physische (Bond, Bridge, VLAN), dann fail() mit Klartext statt bauen. bridge_ports darauf waere falsch, und was dabei herauskommt, ist aus der Ferne nicht mehr zu reparieren. readBridgeState fragt beides in einem Rundlauf und leitet aus dem LAUFENDEN Zustand ab (ip, /sys/class/net), nie aus der Datei des Anbieters. 'up' sind absichtlich alle drei Fakten: eine vmbr0 ohne Adresse und ohne Standardroute ist eine Bruecke im Sinne von 'ip link' und sonst nichts. Start, Poll und Abbestellen folgen. Bis dahin steht dort ein fail() — gefahrlos, weil der Schritt noch nicht in der Pipeline haengt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	b0761de1eb	bridge-run.sh: der Treiber, und der Zeitgeber steht vor jeder Aenderung ... Verdrahtet bridge.sh in der einen Reihenfolge, die stimmen muss: sichern -> Zeitgeber -> uebernehmen -> umstellen -> nachsehen. Alles davor stellt nur fest und veraendert nichts; ab 'sichern' gibt es einen Weg zurueck, und erst ab dann darf ueberhaupt etwas angefasst werden. Abgekoppelt ist hier Bedingung, nicht Optimierung: ifreload -a nimmt die Leitung, ueber die der Befehl laeuft. PID als allererstes, damit ein frueher Poll nicht 'running aber nicht lebendig' liest und einen gesunden Lauf fuer tot erklaert. Der Treiber bestellt den Zeitgeber NIE ab — das tut CluPilot nach dem Wiederverbinden. Ein Test haelt das fest. Dazu die Fremdverwalter-Erkennung in bridge.sh: cloud-init, networkd, NetworkManager werden benannt und entmachtet, Unbekanntes fuehrt zum Abbruch statt zu einem Versuch ins Blaue. Der Zeitgeber faengt diesen Fall NICHT ab — zu seiner Zeit war alles in Ordnung, und die Bruecke verschwaende erst beim naechsten Neustart, mit Kunden darauf. Drei Tests fahren den Treiber in einer Sandkiste WIRKLICH durch, statt nur seinen Text zu lesen: die ip-Attrappe antwortet vor dem ifreload anders als danach. Sie belegen ok, failed-ohne-Bruecke und failed-mit-schalem-Tunnel — und in allen drei Faellen, dass die Rueckfahrkarte stehen bleibt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	e963821eb4	bridge.sh: nachsehen in beide Richtungen, und kein ping ... Nur 'komme ich raus' zu pruefen ist notwendig und NICHT hinreichend. Der Fehlerfall: ifreload bringt vmbr0 sauber hoch, die Maschine erreicht das Internet, der Treiber waere zufrieden — aber wg0 kommt nicht zurueck. Dann lebt der Host oeffentlich, CluPilot ist ausgesperrt, und wer hier abbestellt, hat die Rueckfahrkarte weggeworfen. wg0.conf enthaelt keine Geraetebindung; der Tunnel haengt an der Quelladresse, die die Routing-Tabelle hergibt — und genau das ist die Groesse, die der Umbau anfasst. Das macht den Fall nicht unwahrscheinlicher, nur unauffaelliger: kein Fehler im Protokoll, nur ein Handshake, der ausbleibt. Ist der Handshake schal, wird wg-quick@wg0 EINMAL neu gestartet und nochmal nachgesehen. Gefahrlos, weil ifreload die SSH-Sitzung ohnehin schon mitgenommen hat — und es verwandelt einen haengenden Tunnel in einen laufenden statt in eine Ruecknahme. Kein ping: Hetzners Debian-Basis hat keins, PrepareBaseSystem installiert es nicht, und network.sh:190 haette damit immer 'nicht erreichbar' gesagt. Ein Test haelt bridge.sh ping-frei. Nebenbei ein Fehler in den Tests selbst behoben: 'if gibtsnicht; then … else echo NEIN; fi' ist in sh unwahr, also war jeder Test, der NEIN erwartete, gruen SOLANGE die Funktion fehlte. verdictBody() meldet jetzt FEHLT und trennt 'falsch' von 'gibt es nicht'. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	0005d321a3	bridge.sh: die Rueckfahrkarte, und der Grund steht vor dem Zurueckspielen ... Der Zeitgeber ist eine systemd-Einheit und kein 'sleep &': ein Hintergrundlauf stirbt mit seiner Sitzung, und die Sitzung ist genau das, was abreisst, wenn die Umstellung schiefgeht. Zwei Dinge gegenueber der Fassung, die in network.sh stand: - render_rollback_script ist vom Stellen getrennt, damit die Reihenfolge darin ohne systemd pruefbar ist. Und die Reihenfolge ist der Punkt: 'failed' samt Grund wird geschrieben, BEVOR zurueckgespielt wird — ein halb gegluecktes Zurueckspielen soll das Urteil trotzdem hinterlassen. 'rolled-back' kommt zuletzt und ist das Signal, auf das CluPilot wartet. - Der Zeitgeber raeumt seine Unit-Dateien nach dem Feuern selbst weg. Sonst sieht eine abgeschlossene Ruecknahme beim naechsten Hinsehen aus wie eine ausstehende. Der Treiber bestellt NICHT ab. Das tut CluPilot, nachdem es sich ueber den Tunnel neu verbunden hat — ein Skript auf dem Host kann ueber seine eigene Erreichbarkeit von aussen nur raten. Geprueft: der Zeitgeber steht vor dem ersten veraendernden Aufruf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	b630c079ca	bridge.sh: die Strophe, gegen vier Anbieterfaelle geprueft ... write_bridge_stanza ist von build_bridge getrennt: das Schreiben ist das, was eine Maschine umbringt, und so ist es pruefbar, ohne dafuer ein Netz neu laden zu muessen. Beide Pfade sind ueberschreibbar (CLUPILOT_INTERFACES_FILE, CLUPILOT_IFRELOAD), dieselbe Technik wie CLUPILOT_STORAGE_CFG beim Vorlagenbau. Drei Dinge kann die Fassung mehr als die alte in network.sh: - hwaddress festgenagelt. Eine Bruecke waehlt sonst die kleinste MAC ihrer Ports; bei einem Port ist das dieselbe, aber 'ist dieselbe' und 'bleibt dieselbe' sind zweierlei. - Zusatzrouten des Anbieters wandern mit. Ausgelassen bleiben die Kernel-Route zum eigenen Subnetz und die Link-Route zum Gateway — beide entstehen von selbst, und ein gescheitertes 'up' nimmt bei ifreload die ganze Strophe mit. - IPv6, aber nur statisch und global. SLAAC/DHCPv6 werden bewusst nicht nachgebaut (forwarding=1 laesst den Kernel RAs ohne accept_ra=2 verwerfen) — dafuer gibt es eine Zeile ins Protokoll statt eines stillen Verlusts. Geprueft gegen echte sh: Hetzner /32 routed mit pointopoint, netcup Subnetz ohne, DHCP ohne Adresse, statisches IPv6 mit fe80::1, SLAAC faellt weg, Zusatzrouten kommen mit. network.sh hat sein eigenes build_bridge abgegeben; ein Test haelt jetzt jede der sieben Brueckenfunktionen auf genau einer Stelle im Repo fest. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	81df08aaa6	bridge.sh: die Erkennung herausgeloest und allein lauffaehig gemacht ... Die Bruecken-Erkennung stand in network.sh, geschrieben fuer den stillgelegten Rettungssystem-Weg, und borgte sich vier Dinge von woanders: detect_primary_interface aus proxmox.sh, log, http_get und CLUPILOT_PROBE_URL aus clupilot-bootstrap.sh. Der Debian-Weg laedt die Bibliothek EINZELN auf den Host und faehrt sie dort — geborgte Helfer waeren dann nicht da. Also allein lauffaehig, mit log und http_get unter einem command-v-Schutz, damit der Bootstrap seine eigenen behaelt. Neu und aus dem laufenden Zustand abgeleitet: - interface_is_physical — bridge_ports auf einem Bond oder einer bestehenden Bridge ist falsch, und aus der Ferne nicht reparierbar. - address_is_dynamic — der Kernel markiert eine geleaste Adresse, das steht bei jedem Anbieter gleich da. Die Datei des Anbieters ist nur noch das Zweitsignal. Geprueft gegen eine echte sh mit aufgezeichneten ip-Ausgaben, plus die Zusicherung, dass es detect_primary_interface im Repo genau einmal gibt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 13:44:47 +02:00
nexxo	dc35e5310f	Release v1.3.93 — die Seite konnte den Host gar nicht fragen ... Auf echter Hardware blieb jede Messkachel leer, während der Host sichtbar online war und vor zwei Minuten geantwortet hatte. Kein Zufall und kein Aussetzer: ein Entwurfsfehler. Nur der queue-provisioning-Container hängt im WireGuard-Netz — NET_ADMIN, /dev/net/tun, das wireguard-Volume. Der app-Container, der die Konsole rendert, hat überhaupt keine Route zu 10.66.0.x. Ich hatte den Proxmox-Aufruf in render() gelegt, also in den einen Container, der die Management-Adresse nicht erreichen kann. Ein Aufruf von dort konnte nie etwas anderes sein als eine Zeitüberschreitung. PingHosts schreibt dieselbe Regel seit Langem in seinen Kopf: "runs on the provisioning queue, which is where the Proxmox credentials are usable." Ich habe sie gelesen und nicht angewendet. Verschlimmert hat es mein eigenes catch (Throwable): der Grund wurde verschluckt, und die Kachel sagte "keine Messwerte" — ununterscheidbar davon, dass der Host schweigt. Auf dem Testhost fiel nichts auf, weil TEST-NET ohnehin nie antwortet. Jetzt zwei Hälften: - HostLoadSeries::collect() holt und legt ab, aus Jobs\CollectHostLoad auf der provisioning-Warteschlange, minütlich — der Takt, in dem Proxmox einen frischen Messwert schreibt. Ein Fehlschlag wird protokolliert, mit Host, Node und Grund. - HostLoadSeries::forHost() liest nur aus dem Zwischenspeicher und öffnet nie eine Verbindung. Ein Test hält das mit Http::assertNothingSent() fest. Der Eintrag lebt fünf Minuten bei minütlichem Sammeln: länger als der Takt, damit ein ausgefallener Lauf keine Seite leert, die eine Sekunde vorher in Ordnung war — und kurz genug, dass ein stehengebliebener Sammler die Zahlen mitnimmt, statt eine alte Stunde als aktuell stehenzulassen. Der Sammler ist ShouldBeUnique (Codex-Befund, P1). Die provisioning-Warteschlange ist DIESELBE, auf der Kunden-Bereitstellung läuft; ein stiller Host kostet den vollen HTTP-Zeitablauf, und ohne diese Sperre stauten sich minütlich neue Läufe hinter dem alten und verzögerten bezahlte Arbeit. Dasselbe Mittel, das CollectInstanceTraffic nebenan schon benutzt. Dazu: der Zustands-Punkt war mit 62 px so groß wie der Speicher-Ring nebenan. Eine gefüllte Scheibe wiegt optisch weit mehr als ein dünner Ring und erschlug die Kachel — jetzt 32 px. Und ein Test, der aus Versehen recht behielt: die Kachel-Prüfung verglich mit "50", was auch die 500 GB in der Instanzenliste darunter trifft. Sie prüft jetzt Zahlen, die sonst nirgends auf der Seite vorkommen. Noch offen, nicht hier angefasst: VmTemplateCheck fragt die Proxmox-API ebenfalls aus dem app-Container heraus, von der Bereitschaftsseite aus. Selber Fehler, Bestand, eigener Punkt. Geprüft: 2299 Tests grün, Pint sauber, Codex ohne Befund. Im Browser mit eingespielten Messwerten: sechs gefüllte Kacheln, Zustands-Scheibe in Proportion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:23:00 +02:00
nexxo	589489a9fc	Release v1.3.92 — sechs Kacheln statt dreier ungleicher Kästen ... Nach der Vorlage des Besitzers. Zustand, Speicher und die gemeinsame Kurve standen nebeneinander: zwei davon halb leer, die dritte überfüllt, und die gemeinsame Kurve brauchte eine Legende, um zu sagen, welche Linie welche ist. Eine Reihe je Kachel löst alle drei Beschwerden auf einmal. Die Beschriftung der Kachel benennt die Reihe, also braucht es keine Legende mehr. Die Höhen sind durch das Raster gleich statt zufällig. Und der leere Platz ist mit Messwerten gefüllt, die es ohnehin schon gab: Proxmox' Aufzeichnung liefert Netzdurchsatz in beide Richtungen mit, ungefragt. Sechs Kacheln: CPU-Auslastung, RAM-Auslastung, Speicher (als Ring), Eingehend, Ausgehend, Zustand. Gebaut mit x-ui.metric, x-ui.spark und x-ui.ring — die gab es alle schon, und der Kopfkommentar von x-ui.metric sagt selbst "exactly as the approved template draws it". Nichts daneben neu gebaut. Die öffentliche IP steht jetzt auf der Seite. Sie stand vorher NUR klein unter der Überschrift — die Adresse, unter der der Host wirklich erreichbar ist, war in der Detailseite nirgends ein Feld. Sie führt jetzt die Ausstattungs-Tafel an, und die Reserve-Eingabe ist mit dorthin gezogen: die Kacheln zeigen, was gemessen wurde, die Tafel, was eingestellt ist. Ein Eingabefeld zwischen Messwerten sähe aus, als ließe sich eine Messung ändern. Alle vier Verlaufslinien tragen denselben Ton. Die Regel steht im Bauteil selbst — "muted where the figure is observed, accent where it can be acted on" —, und hier ist keine Zahl anzufassen. Vier verschiedene Töne nebeneinander behaupten einen Unterschied, den es nicht gibt. Zwei Funde aus der Prüfung -------------------------- - x-ui.spark warf fehlende Messwerte per array_filter heraus und verband die Nachbarn. Zwei Fehler auf einmal: die Linie behauptete eine Messung, die es nicht gab, und alles danach rutschte nach links — eine Stunde mit zwei Lücken zeichnete sich als achtundfünfzig Minuten. Die x-Lage kommt jetzt aus dem Platz in der URSPRÜNGLICHEN Reihe, und zusammenhängende Messwerte werden als eigene Züge gezeichnet. Eine saubere Reihe ergibt genau einen Zug und dasselbe Bild wie vorher, was alle bisherigen Aufrufer liefern. - Der Zwischenspeicher überlebt einen Deploy. Ein Eintrag aus v1.3.91 kennt netin/netout nicht, und die Host-Seite wäre 55 Sekunden lang an einem fehlenden Schlüssel gestorben — genau in der Minute, in der jemand nachsieht, ob das Update durch ist. Der Schlüssel heißt jetzt host-load:v2:<id> und wandert mit der Form mit. Und einer, den kein Prüfer gemeldet hat: beim Zerlegen in Züge stand im Flächenpfad ein `L` unmittelbar vor einem `M`. Gültig gelesen, nicht gezeichnet — die Füllung verschwand still. Aufgefallen ist es beim Ansehen der Seite, nicht durch eine Meldung; jetzt prüft ein Test, dass jeder Flächenpfad mit M anfängt, mit Z endet und keinen Befehl direkt hinter einem anderen trägt. x-ui.chart behält seinen update-on-Weg, obwohl diese Seite ihn nicht mehr benutzt: er ist eine geprüfte Fähigkeit des gemeinsamen Bauteils, und der darunterliegende Fix (Instanz aus dem reaktiven Alpine-Objekt) gilt für jeden Chart. Geprüft: 2291 Tests grün, Pint sauber, Codex ohne Befund. Im Browser mit eingespielten Messwerten: sechs Kacheln, Lücke als echte Aussparung in Linie UND Fläche, Leerzustand zeigt "—" statt einer Null, null Konsolenfehler über einen vollen Poll-Zyklus. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 11:02:55 +02:00
nexxo	665a0c4e08	Release v1.3.91 — die Host-Seite zeigt Last statt Ausstattung ... Die Karte "Rechenleistung" zeigte keine Leistung. 12 Kerne und 63 GB sind die Ausstattung des Blechs und ändern sich nie — sie standen aber im selben Kartenraster wie "Zustand" und "Speicher", die beide leben. Wer die Seite öffnete, um zu sehen, wie es dem Host geht, las dort eine Zahl, die das nie sagen konnte. An ihrer Stelle steht jetzt die Last: CPU und RAM als Stundenkurve, beide in Prozent auf EINER Achse, dazu die aktuellen Werte als beschriftete Zahlen. Die Geschichte kommt aus Proxmox' eigener Aufzeichnung (/nodes/{node}/rrddata), nicht aus einem eigenen Sampler. Ein Sampler hieße neue Tabelle, minütlicher Job, Aufräum-Job und ~1440 Zeilen je Host und Tag — um weniger genau nachzubauen, was ohnehin auf der Platte liegt. Die RRD ist ab der ersten Sekunde gefüllt, auch für die Stunde vor dem ersten Hinsehen, und kann nicht von dem abweichen, was Proxmox' eigene Oberfläche zeigt. Eine Lücke bleibt eine Lücke: ein Punkt ohne Messwert wird null, nie 0, und spanGaps steht auf false. Dieselbe Regel wie in instance_metrics. Antwortet der Host gar nicht, sagt die Tafel das in einem Satz, statt eine ruhige Stunde zu zeichnen — auf dem Testhost live bestätigt. Der Fehler, den das ans Licht gebracht hat ------------------------------------------ x-ui.chart steht überall unter wire:ignore, sonst zerstört Livewire das Canvas. Ein Poll erreicht den Chart also nie. Dafür bekam das Bauteil ein optionales update-on: es hört auf ein Fenster-Ereignis und tauscht die Daten IM bestehenden Chart.js-Objekt. Das lief nicht. Die Zahlen neben der Kurve wanderten, die Kurve nicht, und chart.update() starb still im Legenden-Plugin: TypeError: Cannot set properties of undefined (setting 'fullSize') Grund: die Chart.js-Instanz lag als Eigenschaft im Alpine-Objekt und wurde damit reaktiv umhüllt. Chart.js' Plugin-Innenleben überlebt das Proxy nicht. Gemessen statt geschlossen: dieselbe Instanz wirft über das Proxy und läuft über Alpine.raw(). Sie liegt jetzt in der Closure. Aufgefallen ist es nie, weil bis zum ersten Live-Chart kein einziger Chart in diesem Repo je update() gerufen hat — konstruieren und Erstzeichnen gehen durch die Hülle noch. tests/Feature/ChartLiveUpdateTest.php hält die Regel fest, damit der nächste Live-Chart nicht denselben Nachmittag kostet. Der Rest -------- - Version lesbar: "Proxmox VE 9.2.6" statt pve-manager/9.2.6/7f8d…, mitten in der Bau-Kennung abgeschnitten. Die Kennung steht klein darunter. Eine unerwartete Form wird unverändert durchgereicht statt verschluckt. - Vier Kleinkarten (Mgmt-IP, Node, Version, Instanzen) sind eine Ausstattungs-Tafel geworden. Die Instanzen-Anzahl steht in der Überschrift der Liste, die sie ohnehin zeigt. - Der Übernahme-Fortschritt klappt zu, sobald sie durch ist. Fünfzehn abgehakte Schritte sind auf einem laufenden Host kein Dauerinhalt — aufklappbar über <details>, ohne JavaScript. - PlanVersion::requiredTemplateVmids() ersetzt die dritte Kopie derselben Fensterlogik. - BuildVmTemplate sagt nicht mehr "this takes 10–20 minutes". Das war eine Schätzung vor dem ersten Lauf; gemessen waren es unter zwei. Eine Konsole, die falsch vorhersagt, erzieht dazu, sie zu ignorieren. Geprüft: 2281 Tests grün, Pint sauber, Codex ohne Befund. Die Farbwahl gegen den Validator gerechnet (ΔE 28,3 protan / 39,2 normal; der Akzent liegt unter 3:1 gegen die Fläche, deshalb tragen beide Reihen sichtbare Beschriftung). Im Browser: null Konsolenfehler über einen vollen Poll-Zyklus, und die Kurve wandert auf dem echten Poll ohne Neuladen — mit eingespielten Messwerten belegt, weil die Testhosts in TEST-NET liegen und nie antworten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:24:21 +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	97ac6c04e8	Release v1.3.87 — VM.Monitor gibt es in Proxmox 9 nicht mehr ... Die Übernahme des ersten PVE-9-Hosts blieb in CreateAutomationToken stehen: `pveum role modify` lehnt die GANZE Privilegienliste ab, sobald ein einziger Name darin unbekannt ist — "invalid privilege 'VM.Monitor'". Die Liste stammt aus der PVE-8-Zeit. Ersatzlos gestrichen, nicht ersetzt: VM.Monitor gab Zugriff auf den QEMU-Monitor, und den benutzt CluPilot nirgends. Geprüft, nicht vermutet — die einzigen Treffer auf "monitor" im Provisioning betreffen Uptime Kuma. Auf PVE 8 fehlt damit ein Recht, das dort ohnehin niemand gebraucht hat; eine Liste passt weiterhin auf beide Fassungen. Dazu ein Test, der die angeforderten Namen gegen die gültigen hält — abgelesen aus der Administrator-Rolle eines echten PVE 9. Die Liste ist die Verabredung zwischen CluPilot und jedem Host, den es je übernimmt; sie hier zu prüfen ist billiger als der Abbruch auf einer Maschine, die schon halb eingerichtet ist. 2245 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 03:42:37 +02:00
nexxo	4f04d9d29d	Release v1.3.86 — der Grund von pveum, nicht nur die Feststellung ... „could not converge the Proxmox automation role privileges", fünfmal hintereinander. Die Meldung sagte, WAS scheiterte, und verschwieg das Einzige, was weiterhilft: was `pveum` dazu geschrieben hat. Der Betreiber musste sich auf den Host melden und den Befehl von Hand nachstellen, um eine Zeile zu lesen, die daneben schon dastand. Die Fehlerausgabe von `pveum role modify` steht jetzt in der Meldung — erste Zeile, gekürzt: `pveum` stellt den Grund voran und breitet danach seine Aufrufhilfe aus, und die wäre ein Bildschirm Text in einer Ereigniszeile. 2244 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 03:38:02 +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	200df30b9d	Hetzner-Cloud-DNS, Bereitschaftsseite aus sich heraus behebbar ... Die alte Hetzner-DNS-API ist abgeschaltet (301 auf die Weboberflaeche). Jede Bereitstellung starb in ConfigureDnsAndTls, nachdem der Kunde bezahlt hatte. HttpHetznerDnsClient und DnsTokenCheck sprechen jetzt die Cloud-API: Bearer statt Auth-API-Token, RRSets ueber {name}/{typ} statt Record-IDs, der Zonen-Lookup entfaellt. Gegen das Live-Konto gemessen, nicht geraten. Drei Fallen, die am Konto gemessen wurden: TXT-Werte muessen in Anfuehrungszeichen (sonst 422, was als read_only gemeldet worden waere), ein Name mit Zonensuffix wird STILL angenommen (201), und der Fake gab andere IDs aus als der echte Client -- zwoelf Tests waren gruen ueber einem Abbau, der im Betrieb geworfen haette. Bereitschaftspunkte, die nur eine Shell beheben konnte, sind jetzt bedienbar: SSH-Schluesselpaar erzeugen (Ed25519 ueber phpseclib, privater Teil direkt in den Tresor), Stripe-Katalog abgleichen (Warteschlange, Trockenlauf, Ausgabe wortgleich), Mailzustellung als Schalter statt MAIL_MAILER, Neustart der Arbeiterprozesse. Stripe hat jetzt alle drei Werte in der Konsole: Secret Key, Signatur-Secret (Tresor, je Modus getrennt) und Publishable Key (Klartext). Codex-Review (R15), zwei P1 behoben: der Signaturschluessel faellt nicht mehr vom Live- in den Testplatz, und eine Record-ID aus der alten API macht einen Host nicht mehr unloeschbar -- was adressierbar ist, wandelt eine Migration um, der Rest wird beim Loeschen laut uebergangen statt geworfen. 2109 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 19:50:01 +02:00
nexxo	1056dddc62	Take the address by field, fix the customer type, ask why they leave ... **The billing address was one textarea**, so what landed in it was whatever somebody typed: a postcode on the street line, a city with no postcode, no country at all. It is four fields now — street, postcode, town, country — in the customer's settings and in the console's customer editor, which had its own free-text copy of the same field and would have had an operator's correction silently reverted the next time the customer saved. `customers.billing_address` is neither dropped nor parsed: guessing which line of an existing block is the street would put a postcode where a street belongs on a document nobody can correct afterwards. It becomes the COMPOSED form, rewritten from the fields on every save, so IssueInvoice and everything else that reads it keep working, and a record nobody has re-saved keeps the block it always had. **The customer type is fixed once it is on record.** It decides the fourteen-day right of withdrawal, and a business able to set itself to "Privatperson" on this page is a business able to withdraw from a contract it may not withdraw from. Registration asks the question; this page reports the answer, and saveProfile refuses to answer it a second time — in the component, not by hiding a radio, because a form that hides a control has never stopped anybody who can post to /livewire/update. A record created before the question existed may still be given one, once. The panel is a fact rather than a form now, which is also what was odd about it, and the sentence about who has the right of withdrawal is gone. **Cancelling asks why.** A reason from a fixed list, required, with a note beside it that "Sonstiges" cannot go without — the one fact worth having about a departure, asked at the only moment the customer is looking at the question. It lands on the contract (`cancel_reason`, `cancel_reason_note`). And where the fourteen days are still running, the dialogue offers the WITHDRAWAL as a way out of itself rather than as one more reason inside it: withdrawing ends the service the same day and sends the whole amount back, cancelling keeps the term that was paid for, and somebody entitled to the first should not lose it by taking the second unasked. A business is never offered it — WithdrawalRight answers that, not the template. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 16:41:32 +02:00
nexxo	a84251260c	Read the mailbox password where it actually is, and let the console test it ... The inbox kept saying no mailbox was set up while the password sat right there on the settings page. isConfigured() read config('services.inbound_mail.password'), which is only ever the .env value: this project deliberately does not overlay stored secrets onto config at boot — SecretVault's own docblock says so, and HttpMonitoringClient reads its token at the point of use for exactly that reason. My docblock even asserted the opposite mechanism, which I never verified. It reads the vault now, and falls back to .env because SecretVault::get() already does. And a way to find out. "Verbindung prüfen" saves the form first — testing what is on screen while the server still holds the previous values would report on a mailbox nobody configured — then performs the same four verbs the real fetch performs: LOGIN, SELECT, SEARCH UNSEEN. A check that proves something easier than the actual job is worse than none. What it reports back is one of five fixed words, never the server's own prose: an IMAP error carries the command it failed on, and for LOGIN that command contains the password. Each word maps to a sentence an operator can act on — address and port, mailbox and password, the folder. The line saying when the mailbox was last reached is on both pages, and it is written by the SCHEDULED run as well as by the button. Otherwise "last checked" would mean "last time somebody pressed a button", which is the less interesting of the two: a mailbox that stopped answering at three in the morning is the one worth seeing, and nobody presses a button at three in the morning. It is also shown when the answer is "never" — an empty inbox and a mailbox that stopped answering look identical, and this line is the whole difference. A fetch against a mailbox that just refused the login now takes nothing in and records the refusal, rather than reporting "nothing new" — which was true and useless. Also: HostStepsTest asserted the literal clupilot.com for a host name. That was true until CLUPILOT_DNS_ZONE was set to clupilot.cloud on this installation, and then a correct configuration failed a test. The zone is pinned in the test now; what it is about is the shape of the name and which address it carries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 13:12:29 +02:00
nexxo	889b401faf	Fix nine defects in the provisioning pipelines ... The capacity park could not survive its own first poll. ReserveResources polls every 120 s and declared a maxDuration of 60, and RunRunner measures a step's budget from a started_at it deliberately does not reset on a poll — so every re-entry was ruled timed out before the body ran, a timeout consumes an attempt, and five of them failed a paid order in about six minutes. The fourteen-day promise, the console's capacity queue and the "go and buy a server" workflow were unreachable code. maxDuration is now the whole park plus one poll interval, and a test drives a park through the runner rather than calling execute() directly, which is why this was invisible. Every guest occ call ran as root. `docker compose exec` defaults to root and the Nextcloud image's console.php exits 1 unless the caller owns config/config.php, so all five call sites were failing on every instance. There is now one builder, App\Support\NextcloudOcc, and a test refuses a second: nothing in app/ may spell the invocation out by hand. deploy/ update.sh had learned this for our own container and nobody carried it across. RunAcceptanceChecks was terminal on the first no. certReachable() answers false for a connect timeout as readily as for a missing certificate, so one bad second ended a finished, certified Nextcloud as a failed order with the instance released. The probes retry now and the run still fails for good with the probe's own reason once the budget is spent; the two facts a retry cannot change stay terminal. The in-flight guard asked whether anything was running, not whether it would do the work. App\Provisioning\WorkInFlight asks the second question, reading the step lists the runner executes: a domain proven during a restart is routed, and a storage pack booked during an address run is delivered instead of charged monthly and forgotten. The address pipeline ran its steps in the wrong order for the direction it exists for. Nextcloud before the router in `address` and `plan-change`, as in `customer`, because a run that got the certificate and then failed left the customer's own domain serving an untrusted-domain error under a valid certificate while the portal called it live. Safe in both directions; the reasoning is written above the pipeline. A stale guest_ip could never be corrected. ConfigureDnsAndTls compared the hostnames but never the backend, and nothing re-read the address after the build. It now records and compares `routed_backend`, and ConfigureNetwork joins the `restart` pipeline — a cold boot is what moves a DHCP lease — and asks for the address to be re-applied when the guest has actually moved. Also: HetznerDnsClient::upsertRecord read only the first page of a zone that pages at 100, so past a hundred records it created a second A record for the same name and the cloud was up about half the time; the console's retry left a live customer's order in `provisioning` for ever for any maintenance pipeline; and a revived run's first pass burned an attempt on a timeout that had already happened, because the clause written for it used `??=`. Seven test sites wrote config('provisioning.plans.*'), a key that has not existed since the catalogue moved into the database. Every write was a no-op, so each test proved something other than its name: the missing template, the two snapshot regressions and the grandfathered-price scenario are now actually constructed, ValidateOrder's reasons are asserted rather than only its type, and the end-to-end run checks that the quota step delivered something. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 01:34:55 +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	8440266ed3	Stop charging for a service that has ended ... Nothing in this application could cancel a Stripe subscription — there was no such method on the client at all. So a customer who cancelled and a consumer who withdrew both stayed subscribed, the card went on being charged every month, and every one of those payments arrived as invoice.paid, drew a real number out of the gapless Austrian series and mailed the PDF, for a machine that had been switched off. Indefinitely. StripeClient::cancelSubscription() closes the first half, with the timing passed explicitly at the call site — CANCEL_AT_PERIOD_END for a cancellation, because the customer keeps the term they paid for, and CANCEL_IMMEDIATELY for a withdrawal, because that unwinds the contract and the whole amount has just gone back. The immediate form states prorate and invoice_now as false rather than inheriting them: a credit note of Stripe's beside our own Storno would be the same money twice. The second half is ApplyStripeBillingEvent::owesADocument(). Refusing every invoice on a cancelled contract would lose the legitimate final one — the cycle for a term the customer really did use, unpaid, dunned for three weeks and settled after the contract ended. So the question is not when the payment landed but what it is for: an invoice whose billed period STARTED before the contract ended is documented, one whose period begins at or after that moment is not. Neither is a contract marked cancelled with no date, nor an invoice with no period, because a number handed out in error can never be withdrawn while a missing document can still be issued. The register entry is written either way — the money moved, and that is where an operator finds what has to go back. A cancellation also took its date from the order date plus MONTHS, whatever the term said, so a yearly customer who cancelled in March lost the nine months they had already paid for. It reads current_period_end now, which Stripe keeps current for both terms; the month-walk survives only for a machine with no contract behind it, where nothing records a term at all. Stripe is asked first and our rows are written only if it agreed: a cancellation we could not make effective is the defect above wearing a "gekündigt" label on the settings page, and a cancellation has no deadline, so being asked to try again costs nobody anything. A withdrawal cancelled the OPENING invoice only, found by invoices.order_id — which a renewal and a module document leave null on purpose. A storage pack booked on day three and withdrawn from on day ten was therefore neither cancelled nor refunded. Every charge inside the window is covered now, one Storno per document and one refund per payment, each against the payment that actually took it: a single refund of the total against the opening PaymentIntent is what Stripe would have refused for exceeding it, and one idempotency key for the whole withdrawal would have had Stripe replay the first refund's answer for the second. StartCustomerProvisioning::resume() opened a missing contract and returned, and the only production call to IssueInvoice::forOrders() is after the order commits — so a worker killed in between cost that customer their invoice for good, silently, with nothing anywhere sweeping for it. resume() finishes that work too, guarded by the invoice already filed against the order and by invoices.sent_at, so however often Stripe redelivers it comes out as one invoice, one number, one mail. The order confirmation stays on the first pass alone: it has nothing to stamp. subscriptions.cancel_requested_at is new because the billing half of the application had no way to tell a cancelled contract from an untouched one. Deliberately not a status: until the term runs out this is a paying customer, which is the distinction EndInstanceService is built around, and `cancelled_at` beside it still means the day it genuinely ended. clupilot:verify-vat-ids is scheduled monthly on the first, and its docblock no longer points at a note in routes/console.php that never existed. Reverse charge rested on a one-off VIES answer, a withdrawn registration keeps earning rate 0 for ever, and the unpaid VAT on those invoices is the seller's — so the cadence is the width of that window, and the first of the month is the rhythm the return is filed on. Two tests that proved nothing are now about behaviour. SettingsTest asserted service_ends_at was not null, a column the code had just written and which the broken monthly arithmetic satisfied exactly as well as the right answer; it states the yearly date, the contract's own record and the order to Stripe. EndInstanceServiceTest travelled to whatever value the implementation had computed, so it recomputed the code instead of checking it, and never looked at billing at all; the boundary is a literal date now and the money stopping is asserted beside the address coming down. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 00:52:19 +02:00
nexxo	ec8675861e	Take the order, park it, and say when it will be delivered ... A paid order that no host has room for used to FAIL at the reservation step. The customer has paid by then, so that turned a sale into an incident and left somebody holding money against nothing. The estate is finite and booked thick, so "no host has room right now" is an ordinary Tuesday — it means a machine has to be bought, which takes days. So the order waits instead. poll(), not retry(): the wait is measured in days and must not eat the run's attempt budget. It only fails after PARK_DAYS (14) — long enough to buy, rack and onboard a server over a weekend, short enough that a forgotten order surfaces instead of waiting for ever. Then say so, in the same words on both sides of the payment: - The price sheet marks each package "wird sofort ausgeliefert" or "Bereitstellung in 2-3 Werktagen", read from free capacity rather than written into the page. - The customer's own overview says their cloud is being prepared while it is parked, instead of a stepper standing still for two days under "wird eingerichtet" — which reads as broken. - The console front page shows the same per-package answer, so an operator can see what visitors are being promised. And a capacity page for the decision that follows: who is waiting, what the roomiest host still has, what the queue needs ("3x Start, 1x Business" - the LARGEST parked package sets the minimum machine, because an instance lives on one host), and what such a machine costs today from the provider's live list. It orders nothing: buying a server is a contract, and a bug in a capacity calculation must not sign one. The operator can also say where each parked order goes. A pin is honoured or it waits — never quietly redirected — because placing it elsewhere answers a different question than the one they answered, and they would find out from the finished instance. Two things this shook out: - `current_step` is an INDEX into the pipeline, not the step's key, and it is cast to integer. `where('current_step', 'reserve_resources')` reads as correct and matches step 0 of EVERY pipeline instead. Both lookups go through HostCapacity::parkedRuns() now, which resolves the index and filters by pipeline. - The auction feed sends `hdd_hr` as a list, not a string. Casting it printed "Array" into the console and raised a warning that took the page down with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 18:50:46 +02:00
nexxo	d76de5ada3	Restart a machine, enforce the quota that was sold, end a route that ended ... Three places where the product said one thing and did another. **Nothing could restart a virtual machine.** ProxmoxClient had startVm and no way to stop anything, so `restart_required_since` — set by every plan change that grows a running guest — could only ever be cleared by a resize step that happened to find the machine stopped, which nothing in the product could arrange. A paid upgrade's cores and RAM could stay unreached for the life of the contract, and the cloud page's "Neu starten" was a toast. There is now a `restart` pipeline: shutdown, start, wait for the agent, confirm. A shutdown and a start rather than a reboot, because only a cold boot makes qemu read the VM definition again — a reset would take the machine round and bring it back exactly as small as it was. The shutdown is a REQUEST, bounded at ten minutes, and there is no escalation: ProxmoxClient deliberately does not expose Proxmox's forceStop, because the guest is a Nextcloud and cutting power to a database mid-write to apply a CPU change trades an inconvenience for a restore from backup. A guest that ignores ACPI for ten minutes fails the run instead, and a person decides what happens to it. `restart_required_since` is cleared by the last step, from what the RUNNING guest reports (`cpus`/`maxmem`) — not by the button, and not by the run merely finishing. A machine that comes back smaller than it was sold fails the run. Started by App\Actions\RestartInstance, which re-checks authorisation itself rather than trusting a hidden button: an operator holding the new `instances.restart` may restart anything, a portal user their own machine and nothing else. Refused while another run is in flight against the same order. Confirmed in a modal on both sides (R23), addressed by uuid (R11). **Existing instances had no storage quota.** ApplyStorageQuota reaches new and changed machines; everything built before it kept the whole disk whatever it had paid for, and nothing recorded which was which. `instances.quota_applied_gb` is now what the guest was actually told, written by the step only after the occ call succeeds — so "sold" and "enforced" are separate facts and can be compared. `clupilot:apply-quotas` sweeps the estate: one `quota` run per instance through the same step the pipelines use, skipping what it should and saying why, a no-op once an allowance is enforced, and inert under --dry-run. Deliberately NOT scheduled — a nightly sweep would quietly cover for the pipeline step the day it stopped working, which is how the original hole survived this long. **A Traefik router was never torn down.** TraefikWriter::remove() had no caller anywhere. What was missing was the moment: ConfirmCancelPackage wrote a date into `service_ends_at` and nothing ever went back to it, so every route this platform ever wrote was written for good — pointing at a guest address the host is free to reassign. `clupilot:end-due-services` (hourly) keeps that appointment through App\Actions\EndInstanceService. "Ended" means cancellation_scheduled AND `service_ends_at` passed, never the day a cancellation is scheduled: that customer has paid to the end of the term and is working in it. The DNS record goes with the route — it is in our zone, pointing at a host that serves other people, which is the shape of every subdomain takeover there has ever been. The customer's own domain is in their zone and is not ours to touch; the virtual machine is left alone, because the cancellation flow promises a data export first and destroying disks is not this change's decision. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 18:28:28 +02:00
nexxo	34874adec3	Apply a bought plan change instead of only pricing it ... PlanChange could say what a move would cost and whether it was allowed, and that was all it could do. Billing::purchase() wrote an upgrade order and nothing ever consumed it: same snapshot, same machine, same quota. A customer could pay for a bigger package and receive nothing. ApplyPlanChange is now the single place a change lands — it moves the contract onto the target's current version, writes one register row, settles the custom domain, and starts a run that resizes the machine. Applying the same order twice is a no-op, enforced by a unique event key rather than by a check two callers could both pass. Two things a plan change must not do, and now does not. A disk is never shrunk — Proxmox cannot, so the QUOTA shrinks instead, which is what was sold anyway. And a live machine is never rebooted as a side effect: cores and RAM are written, and where they need a restart the instance says so where an operator and the customer can both see it. The storage allowance also joins the build pipeline. ApplyStorageQuota was written for plan changes and ran only there, so a brand-new customer still got no quota at all — quota_gb reached the instance row and stopped, and every package delivered the whole disk. The test guarding that pipeline only counted its steps, which is how a list missing the one step that makes a package's storage real stayed green for its whole life. It now names the step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 17:18:55 +02:00
nexxo	712803edd6	Serve the custom domain, not just announce it ... A verified custom domain was reported as the customer's address by Instance::address(), by the portal and by the credentials mail while nothing on the platform routed it: the Traefik router's rule was hard-coded to {subdomain}.{zone}. The address a customer was handed answered nothing, and a withdrawn domain stayed in Nextcloud's trusted_domains forever, because the only thing that ever wrote either was the initial provisioning run. - TraefikWriter::write() takes a LIST of hostnames under one stable router name — the platform address always, the verified domain as well when there is one. One file per instance, so a withdrawal is a rewrite rather than a second thing somebody has to remember. - ConfigureDnsAndTls records the custom domain's certificate instead of waiting on it: it depends on an A record in the customer's own zone, which may never appear, and must never fail a run. The platform address keeps its 840s deadline. instances.domain_cert_ok tells "proven" apart from "answering", and the portal now says which. - ConfigureNextcloud deletes trusted_domains 2 when there is no verified domain, so a withdrawn one stops being trusted. - New `address` pipeline (those two steps) plus ReapplyInstanceAddress, which starts one against the order and refuses to start a second while any run is in flight. The route is rewritten when the hostname list differs from what the router carries — not on route_written, which would short-circuit exactly the case a re-apply exists for. - Triggered where the address changes: verification flipping either way in clupilot:verify-domains, the customer's own domain page, and CustomDomainAccess::deactivate() on a package downgrade. - A maintenance run no longer condemns its subject: an address run that failed used to mark the order failed and release the live instance with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 16:44:52 +02:00
nexxo	864126ec7f	Add the SSH identity to the vault, and give deployment config a console page ... The SSH private key CluPilot deploys to every host is now stored through SecretVault (ssh.private_key), preferred over CLUPILOT_SSH_PRIVATE_KEY(_PATH) at all three real consumers — SshTraefikWriter and HostStep::keyLogin. kuma.password/kuma.totp stay in .env: they authenticate a separate Python container at boot, and nothing in this app reads them, so the vault would have nothing to wire them to. A new /admin/infrastructure page, backed by App\Support\ProvisioningSettings, makes the non-secret deployment settings that used to force a shell — DNS zone, WireGuard hub endpoint and public key, Traefik's dynamic-config path, the SSH public key, and the monitoring bridge URL — visible and editable from the console, each wired to every real consumer. WG subnet/hub IP and Kuma's own connection details stay in .env: the compose file and a separate container read those before this application ever does.	2026-07-29 00:52:44 +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	2b1989f53d	Move host DNS names off the public zone into vpn-dns's internal hostsdir	2026-07-28 23:44:31 +02:00
nexxo	75b4a47768	Stop mailing the initial admin password, hold it in the panel until noted ... The password no longer travels through third-party mail servers or sits forever in an inbox: it moves onto the instance (encrypted, same as nc_admin_ref) and shows on the dashboard until the customer clicks "Notiert", which deletes it for good.	2026-07-28 23:19:20 +02:00
nexxo	20329b176b	Refuse a portal login for an address that already belongs to an operator ... Customer::ensureUser() enforced uniqueness only within users, so a customer provisioned (or registering publicly) with an operator's email got a second, colliding identity for the same address — the exact thing R21 exists to prevent. Checks Operator by address now, not by session (the deleted assertNotAdmin() checked who was signed in, which could never be the right question). Public registration gets the same guard via a plain unique() validation rule, reusing Laravel's stock "already taken" message rather than a dedicated one — naming the collision specifically would tell a public visitor an address belongs to staff, a worse leak than the generic refusal every other collision here already gives them. Impersonation answers 409 instead of crashing into it. The Stripe webhook keeps recording the paid order (same principle as openContract()'s own comment: the order is proof money changed hands) and withholds only the colliding login, logged for an operator to resolve by hand. Verified the reverse direction Codex flagged as already covered: two Admin\Settings actions and the clupilot:create-operator command all already refuse an operator email that collides with a customer's, and that check is sound today because every users row is created in lockstep with a customers row of the same email (CreateNewUser and ensureUser are the only two creation sites, both confirmed by grep) and nothing in this app can change a user's email afterwards (Fortify's updateProfileInformation feature is disabled, and no other code calls that action).	2026-07-28 14:42:16 +02:00
nexxo	5e22e16291	Send a guest bounced off the console to the console's own sign-in ... ApplicationBuilder::withMiddleware() defaults redirectGuestsTo() to fn () => route('login') before bootstrap/app.php's own callback ever runs — always the portal's Fortify page, regardless of which side of the site turned the guest away. In non-exclusive (shared, this VM's own mode) that sends a guest bounced off /admin to a sign-in form whose table holds no operators: no 404 any more, but a sign-in that can never succeed. Exclusive mode happened to self-correct only because RestrictAdminHost 404s the wrong host before this ever ran. Fixed for both modes at once rather than depending on which one a given deployment runs: ask AdminArea, the one place routes/web.php's own registration and RestrictAdminHost already agree is the source of truth for "is this the console".	2026-07-28 13:32:05 +02:00
nexxo	87c49de6e5	Move the console's identity out of the customer table	2026-07-28 10:31:43 +02:00
nexxo	0560ae743d	feat(billing): Stripe owns the billing cycle, we own capability ... A Product per plan family and a Price per priced row of a published version, plus the four subscribed webhook events that were arriving and being ignored. `stripe:sync-catalogue` mirrors the catalogue. Idempotent twice over: a stored id is skipped, and each call carries an idempotency key derived from our own row, so a crash between Stripe creating a Price and us recording its id gives back the same object rather than a second one. That matters more here than usual — a Stripe Price cannot be edited or deleted, so a duplicate is permanent. Drafts are not synced at all: a version that has promised nothing has no business in a price list. --dry-run shows what would be created. The webhook now handles invoice.paid, invoice.payment_failed, customer.subscription.updated and customer.subscription.deleted. It never re-derives an amount: the invoice is the authority for what was charged, and recomputing it from our catalogue would produce a second, disagreeing answer. A failed payment is recorded and nothing else — Stripe runs the dunning schedule, and cutting a customer off on the first failure would punish an expired card as though it were a refusal to pay. Only a cycle renewal moves the term on. Stripe also sends paid invoices for prorations and manual charges, and the checkout's own invoice — which is already in the register as the purchase, and would otherwise double every customer's first payment. Stripe does not guarantee delivery order, which is the source of most of the care here: - state changes are judged and written in one transaction with the row held, so two deliveries cannot both pass a check made on a stale copy; - an older event never overwrites a newer one, with a rank breaking ties between events sharing a second — their timestamps have one-second resolution, and a failed attempt and its successful retry routinely do; - a term is never shortened, and an ended contract is never revived; - an event for a contract that does not exist yet is HELD and replayed the moment it appears, rather than acknowledged and forgotten. A cancellation dropped that way would leave us serving someone who had already left. Held rows that never match are pruned after a week. Register entries are keyed by what they are about — the invoice, the attempt, the subscription — with a unique index doing the work, because a check two concurrent deliveries can both pass is not idempotency. PlanChange is now documented as the preview shown before someone confirms, not the invoice: Stripe's proration accounts for tax, existing credit and the exact second the change lands, and ours cannot. Not run against the live account — `stripe:sync-catalogue` creates objects that cannot be deleted, so that is the owner's call. The dry run lists 12. 457 tests green. Codex review clean after seven rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 13:36:28 +02:00
nexxo	6387c747d0	feat(billing): the plan catalogue becomes three tables, and config stops selling ... Plans lived in config/provisioning.php, where the owner cannot reach them and where a plan has no history. They now live in plan_families / plan_versions / plan_prices — a name that never moves, what the plan WAS at a point in time, and a price per version and term with its own Stripe Price id. - Availability is computed on every read (available_from <= now < until, half-open, UTC) plus a per-family sales kill switch. Nothing schedules a plan into or out of sale: a job that fails to run is a plan that silently misbehaves. - Overlaps crash rather than resolve. currentVersion() uses sole(), and scheduling takes a lock on the family and rejects an overlapping window — two versions on sale at once would decide a customer's price by row order. - A version is frozen from publication, not from first sale, and so is its price: a checkout is not instant, and an amount edited between the session opening and the webhook landing would contract someone at a price they were never quoted. Repricing publishes a new version, as Stripe requires anyway. - Neither a published version, its price, nor a family with customers can be deleted, and a family key cannot be renamed. All of those would null the provenance off existing contracts. - Subscriptions and orders record plan_version_id. A historical reference resolved by plan NAME hands back today's terms, which is the split-brain one level up. A checkout that carried its version is honoured even after the window closes — they paid for what they were shown. Switched atomically and failing closed: config('provisioning.plans') and plan_features are gone, and nothing falls back to them. A fallback would resurrect a plan the owner had just switched off. The seed lives in the migration, and PlanCatalogueTest pins what the config catalogue sold as the shadow comparison. `php artisan plans:check` reports overlaps, gaps and missing prices before a customer finds them. Contract-backed displays, which were reading the live catalogue: seat limits, the cloud card, the plan card, and admin MRR — the last three now divide a yearly contract down via Subscription::monthlyPriceCents(), since all three label the figure per month. Two recovery gaps closed along the way: the order now commits before the contract is opened (so a contract failure can never erase the record of a payment), a Stripe retry repairs a missing contract and restarts a run stranded with no_subscription, and TickProvisioning sweeps runs left pending by a crash rather than only running/waiting ones. 402 tests green. Codex review clean after thirteen rounds. Verified in the browser: portal, billing and console render unchanged off the new catalogue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:05:56 +02:00
nexxo	52b41bb0d5	fix(billing): a paid order opens a contract, and provisioning obeys it ... The pipeline re-resolved config('provisioning.plans') by order.plan, so the subscription snapshot protected a customer's price but not their machine: shrinking a plan resized an existing customer's VM on its next run. Nothing created a subscription either, so closing this meant opening the contract at purchase and pointing provisioning at it. - OpenSubscription freezes the catalogue onto a subscription when a checkout is paid; StartCustomerProvisioning calls it inside the order transaction. - CustomerStep::plan() reads the frozen snapshot. ValidateOrder and ReserveResources fail closed with no_subscription rather than falling back to the catalogue, which is the bug itself. - template_vmid joins the snapshot so a re-clone cannot pick up a blueprint published after the sale. Deliberately outside FROZEN: it is how we build the machine, not a term the customer is owed, and a dead template must be replaceable without cancelling a contract. - TrafficMeter reads the allowance off the contract too — cutting a plan's traffic was otherwise enough to start throttling someone who bought more. - The migration backfills contracts for orders that already bought something, reconstructed from what was actually delivered where an instance exists, and adopts an existing order-less contract instead of opening a second. Orders paid in a currency the catalogue cannot price get none, matching the checkout path. price_cents stays the catalogue's NET price, which is what PlanChange prorates against — not Order::amount_cents, which holds Stripe's GROSS total. Reconciling the two belongs to the proof register and Stripe (phases 4/5). Also pins STRIPE_WEBHOOK_SECRET blank in phpunit.xml: the operator's real secret was reaching the suite from .env and rejecting every unsigned test payload, which is why 7 webhook tests failed before any of this. Verified in the browser: with team traffic cut from 3000 to 500 GB in the catalogue, the customer's portal still shows 3 TB. 373 tests green. Codex review clean after three rounds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 11:10:00 +02:00
nexxo	3fad319053	fix(hosts): re-read the host before deciding there is no DNS record ... A registration finishing while the purge waited on the run locks wrote dns_record_id after the purge had already loaded the host, so it skipped the deletion and then deleted the row holding the only id. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 00:02:18 +02:00
nexxo	7b57ab21cb	fix(hosts): retry a failed DNS registration before advancing without a name ... The failure may be a lost response to a request that did create the record. Advancing straight away stored no id, so PurgeHost could never remove it and the host's management address stayed published. The upsert is idempotent, so a retry recovers the id; only after the attempts run out does the onboarding continue without a name. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-26 00:01:16 +02:00
nexxo	952e8e5d2f	fix(hosts): number DNS names by the normalised label, not the raw code ... Two legacy codes can normalise to the same label (eu_west and eu-west), and separate counters then handed both of them eu-west-01 — a unique-constraint failure inside the reservation, which blocks onboarding rather than being a DNS problem the step can shrug off. Lock, counter and the in-use check all key off the label now. (The helper was also called label(), which HostStep already declares as the step's display name — renamed.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 23:59:58 +02:00
nexxo	e96f4c1c1a	fix(datacenters): a code becomes a DNS label, so validate it as one ... alpha_dash accepted eu_west, -edge and edge-, none of which are valid DNS labels — every host in such a datacenter would have failed registration and, because DNS is non-fatal, silently ended up without a name. The console now requires a proper label, and the step normalises anything created before that rule so existing rows still get a usable name. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 23:56:50 +02:00
nexxo	69043f9ffc	fix(dns): deleting a record that is already gone is success ... A lost response, or a retry after a later step failed, made every further attempt a 404 — and the host impossible to purge. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 23:54:45 +02:00
nexxo	9f8659da32	fix(hosts): a failed DNS deletion must not orphan the record ... Swallowing it and carrying on deleted the row that held the only reference to that record, publishing the machine's management address for good. The purge now fails instead — and is retried, since it re-reads the host and its other steps are idempotent — so a broken DNS provider becomes a visible failed job rather than a silent leak. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 23:53:14 +02:00
nexxo	edf24257b5	fix(hosts): reserve the DNS name under the lock, never reuse it, clean it up ... Codex was right that my never-reuse claim did not hold: - The lock was released with only a candidate in hand, so two concurrent onboardings in one datacenter could pick the same name and overwrite each other's record. The name is now persisted on the host while still locked. - The number was derived from the hosts that happen to exist, so removing the highest one handed that number straight back out — a cached name would then resolve to a different machine. The counter is stored per datacenter, floored by what is actually in use so a wiped settings store cannot reissue live names. - PurgeHost deleted the row that carried the record id, leaving the machine's management address published with nothing left to clean it up. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 23:51:25 +02:00
nexxo	5db2f7fda7	feat(hosts): give each host a DNS name under the public zone ... fsn-01.node.clupilot.com, numbered per datacenter and never reused — removing a host must not renumber its neighbours onto its name, so the number is stored rather than derived. The record points at the host's WireGuard address, not its public IP: the name exists so an operator can reach a host by name over the VPN, and publishing a Proxmox host's public address would hand every scanner a target, which is the one thing this network design avoids. DNS is convenience, not a prerequisite: a failure logs an event and lets the onboarding finish rather than stranding a host that is otherwise ready. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 23:49:18 +02:00
nexxo	71ca0e1394	feat(admin): VPN access management with live peer state ... The console can now create, block and remove VPN accesses, and shows who is actually connected — traffic counters, source endpoint and last handshake. Design notes: - The web container has no wg0, so the page never talks to WireGuard. Live state is copied in by SyncVpnPeers on the provisioning queue (the only worker whose container owns the interface); the page polls the database and merely nudges that job, throttled so many open tabs cannot flood the queue. - enabled (operator intent) and present (observed on the hub) are stored separately, so a sync can never quietly undo a block and drift stays visible as "wird angewendet". - The sync adopts peers the host pipeline registered, naming them after their host — otherwise "who is on the VPN" would have blind spots. - Keypairs are generated in PHP via libsodium rather than shelling out to wg genkey (no interface in this container, and it keeps generation testable). The private key is shown once and never stored. - allocateIp() now also considers vpn_peers, which would otherwise be handed a tunnel address a host already holds. - vpn.manage is a new capability held by Owner/Admin only, and it hides the nav entry too — a VPN access reaches the management network. Verified end to end against the real hub, not just mocks: created an access in the browser, connected with the generated config, watched the console flip to "Verbunden" with real counters, then blocked it and confirmed the peer was gone from wg0 and the client could no longer handshake. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 21:38:12 +02:00
nexxo	46d821a047	fix(monitoring): cap monitoring retries at the run budget; dependency-free liveness probe ... - MONITORING_ATTEMPTS is capped by the run's max_attempts, so a large value can no longer burn the retry budget and fail the very provisioning the degradation exists to protect (covered by a new test at the budget boundary) - /health is now dependency-free (200 in ~2ms with Kuma absent, verified: the container healthcheck stays healthy); Kuma state is exclusively in /ready Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 20:19:32 +02:00
nexxo	82916167cf	fix(monitoring): MONITORING_ATTEMPTS is now exact (off-by-one); accept int or dict monitor id ... - attempt is 0-based, so compare one-based: ATTEMPTS=2 really means two tries - bridge accepts add_monitor returning {monitorID}|{id}|int (v1.2.1 returns a dict — re-verified: first create on a fresh Kuma is HTTP 200 with the id) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 20:08:07 +02:00
nexxo	5301ce4309	feat(monitoring): Uptime Kuma support via a REST bridge + resilient monitoring policy ... Kuma has no write REST API (monitor CRUD is Socket.IO only), so docker/kuma-bridge translates the exact generic REST contract HttpMonitoringClient already speaks — no PHP client change needed. Opt-in compose profile 'monitoring'. Verified end-to-end against a real Uptime Kuma 1.x: create -> id, create again -> same id (idempotent), list, status, delete and PHP MonitoringClient -> bridge -> Kuma round-trip. The e2e run caught a real bug: add_monitor takes 'maxretries', not 'retries'. Monitoring is now observability, not a delivery gate: - RegisterMonitoring retries MONITORING_ATTEMPTS times on an outage, then continues degraded with a visible 'info' event - RunAcceptanceChecks no longer fails when monitoring isn't green (a fresh Kuma monitor legitimately reports 'pending' — confirmed in the e2e run); it records the gap instead. MONITORING_REQUIRED=true restores strict gating. - docs/monitoring-uptime-kuma.md documents setup, failure behaviour, alternatives Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 20:04:58 +02:00