Neue Anfrageart rescue-tunnel im bestehenden Update-Postkasten (kein
zweiter Weg): UpdateChannel::requestRescueTunnel(), der Agent fuehrt
deploy/rescue-tunnel.sh mit Frist aus, die Konsole zeigt Ergebnis,
Waechter-Stand und Wirt-Helfer-Vertrag in der Update-Karte, Bestaetigung
im Modal (R23) nach dem Muster von ConfirmReleaseUpdateLock.
Zusatzfix in deploy/watchdog.sh: der wg0-Block meldete geheilt=true
schon, bevor geprueft war, ob wg-quick up wg0 wirklich gewirkt hat --
ein fehlgeschlagener Tunnelaufbau haette der Konsole "healed" vorgemacht.
geheilt wird jetzt erst nach der zweiten wg-show-Probe gesetzt, mit
Regressionstest in WatchdogVisibilityTest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seit Task 2 steht in update.sh HOST_STEP_NEEDS="$(release_host_step_needs)"
statt einer nackten Zahl. Str::between() zog daraufhin die
Kommandoersetzung selbst aus dem Text, (int) davon war 0 — der Test verglich
3 gegen 0 und war rot. Der vorgegebene Filter HostStepContract|... traf
HostStepTest.php nicht (falscher Teilstring), deshalb fiel das erst im
Review auf.
Die rechte Seite des Vergleichs ruft jetzt release_host_step_needs() aus
deploy/lib/release.sh tatsächlich per Shell auf (gleiches Muster wie
HostStepContractTest), statt sie aus update.sh herauszulesen. Damit kommen
beide verglichenen Zahlen aus zwei verschiedenen Dateien
(install-agent.sh CONTRACT vs. release.sh release_host_step_needs) und die
Kopplung ist wieder erzwungen — verifiziert, indem CONTRACT testweise auf 4
gesetzt wurde und der Test daraufhin rot wurde ("4 is identical to 3"), dann
zurückgesetzt.
Task 2 hat HOST_STEP_NEEDS=3 in update.sh durch release_host_step_needs()
ersetzt (deploy/lib/release.sh). Dieser Test prüfte bislang den nackten
literalen String und wäre sonst der einzige verbliebene Ort, der die alte
Verdopplung verlangt.
Der Waechter redete bisher nur ins Journal auf dem Wirt — die Konsole
im Container sieht ihn also nicht. Er schreibt jetzt zusaetzlich
storage/app/deploy/watchdog-last-run.json (atomar, .tmp + mv) mit
Ausgang (idle/healed/stood_down) und den say()-Meldungen des Laufs.
WatchdogLog::lastRun() liest das robust (fehlend/kaputt -> null,
stale-Erkennung nach 5 Minuten).
Die mitgelieferte Testvorlage hatte selbst einen Fehler: die
docker-Attrappe setzte ihren mehrzeiligen Vorgabewert ungequotet in
generierten Shell-Code ein, wodurch die "ps"-Antwort einen Dienst
verschluckte und der idle-Test faelschlich "healed" sah. Behoben
durch Anfuehrungszeichen um den eingesetzten Wert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Office (ONLYOFFICE über einen künftigen gemeinsamen Dokumentenserver) wurde
an drei Stellen beworben, ohne dass irgendwo im Repository ein Dokumentenserver
existiert: der Kachel "Office im Browser" auf der Preistafel, dem Paketmerkmal
`office` in Team und Business, und dem Zusatzmodul `collabora_pro` für
22,80 €/Monat. Alle drei sind jetzt stillgelegt, aber nicht gelöscht — ein
einziger dokumentierter Schalter (LandingController::OFFICE_ON_SALE) plus eine
neu veröffentlichte Planversion holen das Versprechen zurück, sobald der
Dokumentenserver steht.
Das Paketmerkmal wird über das im Katalog bereits etablierte Handover-Muster
entfernt (neue Migration, analog zu switch_to_new_plan_ladder): die laufende
Version von Team/Business wird geschlossen und durch eine identische ohne
`office` ersetzt. Bestehende Verträge bleiben auf ihrer alten, eingefrorenen
Version stehen und behalten das Merkmal unverändert.
Die dritte Planversion für Team/Business hat 24 Bestandstests berührt, die
eine feste Versionsnummer oder eine feste Preis-/Versionszahl annahmen —
repariert, überwiegend durch dynamisches Lesen der aktuellen Version statt
eines eingetippten Werts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bei zehn Servern liess sich eine Auslieferung nicht staffeln: entweder alle
nehmen die neueste Version oder niemand. Der einzige Griff, der eine bestimmte
setzt, war RELEASE=vX.Y.Z bash deploy/update.sh auf der Kommandozeile.
Der Kern ist eine geklemmte Variable. Der Agent uebergab in Zeile 669 ohnehin
schon RELEASE="$TARGET_RELEASE"; wird die an der Decke geklemmt, faellt
`behind` aus derselben Rechnung, und Knopf wie Wartungsfenster folgen von
selbst. Task 4 belegt genau das mit einem Test, der KEINEN Produktivcode
braucht: es gibt keinen zweiten Weg in eine Auslieferung.
Die Decke faellt zu, nicht auf. Unlesbar, formwidrig oder ins Leere zeigend
heisst: nichts wird angeboten. Ein Rueckfall auf "neueste Version"
installierte genau das, wovon weggenagelt wurde.
Nicht enthalten: Zurueckrollen. Das ist verboten (update.sh:222), und der
Datenbank-Schnappschuss, auf den die Fehlermeldung dort verweist, wird
nirgends genommen. Eigene Baustelle, ihr fehlendes Stueck ist der
Schnappschuss, nicht der Knopf.
Unterwegs gefunden und mitbehoben: zwei Stellen, an denen eine Zuweisung aus
einer Kommandoersetzung unter set -e + pipefail den Agenten toetete, BEVOR er
eine Statusdatei schreiben konnte (sync_vpn_certificate, release_manifest_
version) — dieselbe Ausfallart, die die Konsole eine nie endende Pruefung
zeigen laesst.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sechs Befunde aus dem Schlussreview, in einer Welle behoben:
- BEFUND 1 (Important): eine leere Auswahl im Festnageln-Feld liess
pinRelease() ueber `$this->ceilingChoice ?: null` in setCeiling(null)
laufen — die Gegenhandlung (Decke abnehmen) — und meldete dabei die
Erfolgsmeldung des Festnagelns. ConfirmPinRelease::confirm() schickt die
Version jetzt als Event-Nutzlast (wie ConfirmSaveSecret den Schluessel),
und pinRelease(string $version) weist eine leere Version ausdruecklich
ab, mit einer eigenen Meldung (release_pin_empty).
- BEFUND 2 (Minor, durch 1 miterledigt): Modal und Seite lasen bisher zwei
getrennte Eigenschaften ($version vs. $ceilingChoice). Der Fix oben
beseitigt die Trennung.
- BEFUND 3 (Important, Text only): der Kommentar bei release_tag_exists()
in deploy/lib/release.sh und der Fehlerbehandlungs-Abschnitt der Spec
behaupteten, ceiling_missing schuetze gegen einen vom Release-Prozess
geloeschten Tag. Tut es nicht: `git fetch --tags --force` (ohne
--prune-tags, bewusst) entfernt keine lokal bereits geholten Tags, die
drueben verschwunden sind. Beide Stellen beschreiben jetzt, wogegen die
Pruefung tatsaechlich schuetzt (ein nie geholter oder nie existierender
Tag) und wogegen nicht. Kein --prune-tags hinzugefuegt.
- BEFUND 4 (Minor): ConfirmPinRelease hatte keinen Test. Zwei neue Tests
nach dem Vorbild von ConfirmSaveSecret in IntegrationsPageTest.
- BEFUND 5 (Minor): ceilingChoice wurde nie aus dem gesetzten Zustand
vorbelegt. UpdateChannel::ceiling() ist jetzt public, Settings::mount()
belegt das Feld damit vor.
- BEFUND 6 (Minor): eine von Hand geleerte Deckendatei liest die Konsole
als "keine Decke" (ceiling() -> null), der Agent meldet dafuer aber
ceiling_error. Der "Decke abnehmen"-Knopf stand nur hinter
@if($update['ceiling']) und verschwand damit genau in dem Zustand, aus
dem er zurueckfuehren muesste. Bedingung erweitert auf
($update['ceiling'] || $update['ceiling_error']).
Jeder Befund traegt einen eigenen Test in ReleaseCeilingConsoleTest.php.
Volle Suite: 2973 passed (10389 assertions).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fuenf Befunde aus der abschliessenden Review, in einer Runde behoben:
- EnvFileEditor::backup() liess PHPs copy() die Umask entscheiden statt den
Modus der Quelle zu uebernehmen — .env stand mit deploy/install.sh auf 0600,
jede Sicherung landete trotzdem weltlesbar bei 0644, mit APP_KEY,
DB_PASSWORD, VPN_CONFIG_KEY und STRIPE_SECRET darin. Reproduziert (per
kurzzeitigem git stash des Fixes: 420 statt 384) und jetzt durch einen
expliziten chmod nach dem Kopieren sowie einen neuen Test verhindert.
- HostSeparationTest pruefte "jede Route hat einen Hostnamen" nur scheinbar
allgemein — deploy/install.sh schreibt ADMIN_HOST_EXCLUSIVE=false als
Vorgabe, und im nicht-exklusiven Fallback registriert routes/web.php jede
/admin/*-Route absichtlich ohne Domain. Der Test setzte zwar
ADMIN_HOST_EXCLUSIVE=true, sagte aber nirgends, dass genau das die
Voraussetzung der Pruefung ist. hostSeparationTable() gibt AdminArea::
isExclusive() jetzt als Out-Parameter zurueck, gelesen waehrend die zweite
Anwendung noch gebootet ist, und der Test besteht darauf.
- clupilot:bind-hosts existierte, aber nichts sagte einem Operator, dass es
ihn braucht. deploy/update.sh druckt jetzt einen eigenen Hinweis, wenn
APP_HOST in .env leer ist — mit der vollen docker-compose-Zeile statt der
internen in_app-Abkuerzung, weil der Operator sie in seiner eigenen Shell
eintippt.
- ask STATUS_DOMAIN und ask FILES_DOMAIN versprachen "blank to keep it auf
jedem Host", fuellten Enter aber ueber den dritten ask()-Parameter mit dem
Default. Fuer FILES_DOMAIN war das kein Schoenheitsfehler: der Default
verschiebt /bootstrap.tar.gz vom Portal weg, bevor DNS fuer den neuen Namen
existiert. Beide Defaults entfernt.
- ask WWW_DOMAIN erklaerte nicht, dass SITE_HOST mehrere kommagetrennte Namen
traegt (der erste kanonisch, der Rest leitet dauerhaft um) — ein Operator,
der die Apex-Domain zusaetzlich zu www. binden wollte, hatte keinen Weg,
das aus dem Prompt zu erfahren. Nur der Prompt-Text geaendert, kein neuer
Prompt, Default unveraendert.
Voller Testlauf: 2953 passed (Baseline 2952 + der neue Backup-Berechtigungs-
Test), 0 failed. routes/web.php, RestrictAdminHost, config/fortify.php und
PublicSiteGate unangetastet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
apply() ersetzte eine vorhandene Zeile per preg_replace($pattern, $line, ...)
- $line kommt von der Befehlszeile, und preg_replace deutet $1/\1/\\ im ERSATZ
als Rueckverweis, auch ohne Klammern im Muster. Ein Hostname mit solchen
Zeichen wuerde still verstuemmelt in die Datei geschrieben, die jedes
Geheimnis der Installation haelt - und EnvFileEditor::isValidLine() kann das
nicht fangen, das Ergebnis ist syntaktisch weiter KEY=value. apply() arbeitet
jetzt zeilenweise ohne jede Regex im Ersatzpfad.
Zusaetzlich: EnvFileEditor::write() wirft InvalidEnvContentException, wenn der
neue Inhalt nicht parst - das war ungefangen und zeigte dem Betreiber einen
Stapelabzug auf der Zugangsdatendatei statt eines Satzes wie jeder andere
Fehlerpfad in diesem Befehl.
Neuer Test deckt den Rueckverweis-Fall ab, ueber die bereits vorhandene
(leere) SITE_HOST-Zeile - der Pfad, den preg_replace tatsaechlich traf.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Task 5: Bedienoberfläche zum Festnageln einer Release-Version, in der
bestehenden Update-Handlungsleiste statt einer zweiten daneben.
Bestätigt im Modal (R23), Auswahlfeld selbst ohne Modal (R20).
Zwei Important-Befunde aus dem Code-Review zu Task 3:
- writeAtomic() ignorierte den Rueckgabewert von File::put()/File::move()
und meldete setCeiling() als "true", selbst wenn ein I/O-Fehler (volle
Platte, Rechteproblem) nichts geschrieben oder eine .tmp liegen gelassen
hatte. Beide Rueckgabewerte werden jetzt geprueft, eine liegen gebliebene
.tmp wird im Fehlerfall aufgeraeumt, und der Fehlschlag wird bis zu
setCeiling() durchgereicht (Rueckgabe false).
- ceiling() konnte state() doch werfen lassen: zwischen File::exists() und
File::get() liegt ein Zeitfenster, und File::get() wirft eine
FileNotFoundException, wenn die Datei dazwischen verschwindet. readJson()
und lastLog() kapseln genau dieses Muster schon in try/catch(Throwable);
ceiling() zieht jetzt nach.
Beide Befunde tragen einen eigenen Test: ein Verzeichnis an der Ceiling-
Datei-Stelle (exists() wahr, get() wirft) fuer den zweiten, eine echte
Rechteverweigerung (chmod 0500 als nicht-root Testbenutzer) fuer den
ersten -- kein Facade-Mock noetig.
Der Zähler lag auf der Rechenzentrums-ZEILE (next_host_number). Ein leeres
Rechenzentrum liess sich löschen - bewusst so entschieden, was nichts mehr
hält, soll entfernbar bleiben -, aber die Zeile nahm den Zähler mit. Wer
denselben Code neu anlegte, bekam eine frische Zeile mit dem Schema-Default
1, und der nächste Host hiess wieder <code>-01, obwohl dieser Name schon in
alten Protokollen, Sicherungen und DNS-Zwischenspeichern auf eine ANDERE
Maschine zeigt.
Der Zähler zieht deshalb in eine eigene Tabelle host_name_sequences um,
geführt über den rohen Code statt über die id der Rechenzentrums-Zeile.
ConfirmDeleteDatacenter bleibt unangetastet: das Löschen war nie das
Problem, nur was es mitriss. Die Migration überträgt den Bestand (fsn/hel)
vor dem Löschen der alten Spalte und ist gegen echtes MariaDB in beide
Richtungen geprüft (hoch, Werte kontrolliert, zurück, wieder hoch).
Neuer Test in HostNamingTest stellt den ganzen Bruch nach: Rechenzentrum
anlegen, Host vergeben, Host entfernen, über den echten Bestätigungsdialog
löschen, mit demselben Code neu anlegen - der nächste Name bleibt fortlaufend
statt wieder bei 01 zu beginnen. Gegen den unveränderten Code lief er rot
(HostName::preview lieferte nbg-01 statt nbg-02).
Registereintrag "Ein Zähler kann durch Löschen eines Rechenzentrums
zurückfallen" gestrichen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Registereintrag nannte den falschen Grund: das Deaktivieren startet sehr
wohl eine Provisionierung. CustomDomainAccess::deactivate() ruft seit Langem
ReapplyInstanceAddress, das legt einen Lauf der `address`-Pipeline an und
schickt AdvanceRunJob auf die provisioning-Warteschlange; ConfigureNextcloud
loescht dort trusted_domains 2 und ConfigureDnsAndTls schreibt den Router ohne
den Namen neu. Das ist gebaut und geprueft.
Der Schaden war trotzdem echt, nur eine Tuer weiter. Erreicht wurde deactivate()
allein ueber PlanChange::settleCustomDomain, also ueber den Paketwechsel. Der
zweite und haeufigere Weg, auf dem das Recht endet — der Kunde bucht das Modul
in der Abrechnung ab, clupilot:end-cancelled-addons haelt den Termin am Ende des
bezahlten Zeitraums — ging an dieser Stelle vorbei: BookAddon::cancel() lieferte
Speicher nach und sprach mit Stripe, fragte aber niemanden nach der Adresse. Die
Domain verschwand aus jeder Ansicht und blieb auf der Maschine stehen.
BookAddon::cancel() fragt jetzt CustomDomainAccess::enforce() — die ganze Regel,
nicht den Modulschluessel: wer von Team auf Business aufgestuft hat und sein
altes Modul loswird, behaelt die Domain, weil das Paket sie selbst traegt.
Und der Anstoss darf die Entscheidung nicht kippen. deactivate() faengt jetzt
einen Fehlschlag der Nachfuehrung ab und schreibt ihn als Fehler ins Log: die
Wahrheit steht in der Datenbank, die Maschine zieht nach, und eine Kuendigung
haengt nicht daran, ob ein fremder Host gerade antwortet.
Die Gegenrichtung brauchte nichts: der Entzug loescht die Domain-Spalte, also
traegt der Kunde sie nach der Neubuchung neu ein und weist sie neu nach — und
genau dort haengt seit jeher der Lauf, der sie wieder ausliefert. Ein Test haelt
das fest, damit es keine Einbahnstrasse wird.
Registereintrag gestrichen.
Rot gesehen: ohne den settleCustomDomain-Aufruf fallen drei der vier neuen
Tests; ohne das try/catch faellt der vierte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Update-Agent meldete dauerhaft "kommt nicht an die Arbeit", obwohl nichts
kaputt war. Wächter und Agent haben beide einen minütlichen Zeitgeber und nahmen
beide `.agent.lock` in ihren ersten Zeilen — bevor sie wussten, ob sie überhaupt
etwas tun würden. Der Wächter tut an fast jedem Tag nichts: seine vier Prüfungen
sind allesamt lesend. Er hielt die Sperre trotzdem, jede Minute; der Agent kam
leer aus und schrieb einen Übersprung-Vermerk. Weil der Agent der ist, der an die
Konsole berichtet, stand dort eine Dauerstörung, während beide Dienste genau das
taten, was sie sollten.
Der Wächter sieht jetzt ungesperrt nach und nimmt die Sperre erst, wenn wirklich
etwas zu richten ist — im gesunden Fall fasst er sie nie an. Wo er eingreift,
wird die Lage nach dem Nehmen der Sperre noch einmal geprüft: zwischen dem
ungesperrten Blick und der Sperre kann ein Update fertig geworden sein, und
`--force-recreate` auf gesunde Container reißt jede offene Verbindung ab.
Versetzte Zeitgeber wären nur seltener gewesen, nicht weg — zwei Takte derselben
Länge wandern gegeneinander, und systemd zieht sie über AccuracySec aktiv auf
gemeinsame Weckpunkte zusammen. Eine zweite Sperre wäre schlimmer als der Fehler
gewesen: dann liefe der Wächter mitten in ein Update hinein.
Dazu zwei Dinge, die derselbe Vorfall aufgedeckt hat:
- Vierzehn Aufrufe nach draußen standen im Wächter ohne Frist, alle unter der
Sperre. Der Agent hat `timeout -k` am 4. August gelernt, der Wächter nie — ein
`docker compose exec`, das auf den Daemon wartet, hätte die Sperre unbegrenzt
gehalten.
- Ein übersprungener Lauf sah im Journal aus wie ein erfolgreicher: der Agent
beendet sich sauber, systemd meldet Starting → Deactivated. Das hat die
Fehlersuche zweimal in die falsche Richtung geschickt. Er sagt es jetzt, mit
Halter und Zähler in der Zeile.
WatchdogLockContentionTest lässt beide echten Skripte gegeneinander laufen statt
die Sperrenlogik nachzurechnen — und prüft beide Richtungen: der Agent kommt an
die Arbeit, während der Wächter nur nachsieht, und der Wächter hält still,
während ein Update die Sperre hält.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
K1 — abgebaute Instanzen zaehlten weiter als belegend. `scopeOccupyingHost`
filtert jetzt `torn_down_at`: eine abgebaute Instanz behaelt `ended`, `vmid`
und `disk_gb` als Nachweis, `status != 'failed'` war fuer sie also wahr. Der
Knoten wurde physisch leer und die Buchhaltung blieb voll — die naechste
bezahlte Bestellung derselben Groesse waere geparkt und verworfen worden.
K2 — `deleteVm()` gibt die UPID zurueck, der Abbau wartet den qmdestroy-Auftrag
ab und schreibt `torn_down_at` erst danach. Ein 200 heisst nur, dass Proxmox
den Auftrag angenommen hat; scheitert die Zerstoerung danach, stand bisher eine
laufende Maschine mit einem Datensatz da, der "abgebaut" sagte — und niemand
sah sie je wieder an. Die Attrappe bildet die Asynchronitaet ab
(`destroyedVmids`, `destroyExitStatus`, `destroyHangs`). Die Fristen des
Auftrags wandern mit: Sichern 900 s, Zerstoeren 300 s, Summe unveraendert 1800 s
unter der Uhr des Arbeiters.
K3 — vor `shutdownVm()` steht derselbe `vmStatus()`-Riegel wie im
Nachbarschritt. Eine wegen offener Zahlung gesperrte Cloud und jeder
Wiederholungslauf nach einem Teilfehlschlag treffen einen gestoppten Gast; der
Wurf haette die Instanz unheilbar gemacht und den echten Grund am Datensatz
ueberschrieben. Die Attrappe weist eine Bitte gegen eine stehende Maschine
jetzt ab, und ein Test faehrt erstmals einen zweiten Lauf nach einem
Fehlschlag durch.
W2 — der rote Kasten "Abbau haengt" filtert `status = 'ended'`. Eine
wiederbelebte Instanz waere sonst fuer immer darin stehengeblieben.
Neun Pruefungen im Mahnwesen lassen ihre Cloud jetzt laufen, bevor sie gesperrt
wird — die geschaerfte Attrappe legt offen, dass `SuspendInstance` denselben
fehlenden Riegel hat (Folgepunkt im Bericht).
Zu jedem der vier Punkte eine Zusicherung, die ohne den Fix rot ist; die
Rotproben stehen im Bericht.
Gekuendigte Kundenmaschinen liefen bisher fuer immer weiter. Task 3 hat den
Abbau gebaut; hier kommen der Griff, der ihn faehrt, und der Ort, an dem man
sieht, was passiert ist.
Die Wartezeit-Frage, entschieden: ein Auftrag je Instanz auf der
provisioning-Warteschlange. Das ist keine Abwaegung — nur queue-provisioning
steht im Netz-Namensraum des vpn-hub, der scheduler-Container nicht. Ein
Befehl, der selbst mit Proxmox spraeche, haette gar keine Route zu einem Host.
Die Fristen stehen ausdruecklich ineinander: die Aktion bekommt 600+1200 =
1800 s, der Auftrag hat $timeout 2100 s, retry_after der Verbindung ist
2400 s. Nur die unterste Uhr hinterlaesst einen lesbaren Grund am Datensatz;
die mittlere toetet den Arbeiterprozess stumm, die oberste startet einen
ZWEITEN Abbau gegen eine Maschine mitten im vzdump. $tries=1, weil ein
sofortiger zweiter Versuch am Herunterfahren einer gesperrten VM scheitern und
den richtigen Grund ueberschreiben wuerde. Die Staffelung ist als Pruefung
festgenagelt. Der Preis — zwanzig statt sechzig Minuten fuers Sichern — steht
im Kopfkommentar ausgeschrieben.
Dazu zwei Entscheidungen, nach denen niemand gefragt hat: eine Obergrenze je
Lauf, weil ueber dieselbe serielle Warteschlange bezahlte Bestellungen laufen;
und eine Reihenfolge, die einen Dauerfall die uebrigen nicht aushungern laesst.
Zeitplan taeglich um 05:30 — der Abbau hat keinen Moment, auf den es ankommt,
aber er darf nicht ins naechtliche vzdump-Fenster um 02:00 fallen.
Sichtbarkeit: zwei Kaesten in der Konsole. „Abbau haengt" (rot, ganz oben) —
eine Instanz mit gefuelltem teardown_error steht unbegrenzt und belegt weiter
einen Platz. Und „Archiviert und abgebaut" (unter der Liste) mit archive_volid
im Klartext. Beide sortieren absteigend und beide haben ein Ende: der Fehler
raeumt sich beim naechsten erfolgreichen Lauf selbst ab, das Archiv faellt
nach zwoelf Monaten heraus. Der Folgepunkt vom Export-Kasten also nicht noch
einmal.
Suite 2929 gruen. 25 neue Pruefungen, vier Mutationsproben rot gesehen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Befunde aus der Pruefung.
Der schwerste: der Nachtrags-Zweig konnte eine LAUFENDE Kundenmaschine als
abgebaut verbuchen. vmExists() ist ->get(...)->successful() ohne ->throw(), und
Proxmox antwortet auf die Konfiguration einer nicht vorhandenen VM mit 500 —
demselben Code wie ein hakender Knoten. "Gibt es nicht" und "ich konnte nicht
fragen" sahen damit gleich aus, und der Zustand entsteht im Regelbetrieb: ein
Lauf sichert, scheitert am Loeschen, und der naechste findet archive_volid
gesetzt und einen Knoten, der nichts beantwortet. Die Ablagenpruefung steht
deshalb jetzt VOR dem Zweig: nodeStorage() ruft ->throw(), laeuft sie durch, hat
der Knoten geantwortet, und erst dann ist ein "nein" aus vmExists() ein Befund
statt einer Vermutung.
Drei Ausnahmen lagen ausserhalb des try und haetten im Zeitplan die uebrigen
Instanzen mitgerissen: das Anlegen der Sperre (im Betrieb Redis), das Vermerken
des Grundes im catch, und die Freigabe im finally — die sogar am Erfolgsfall
vorbei. Alle drei abgesichert.
Die Sperrfrist war mit backupWaitSeconds + 600 knapper als der laengste Lauf
(Herunterfahren UND Sichern) und konnte kurz vor dem Loeschen auslaufen. Jetzt
shutdownWaitSeconds + backupWaitSeconds + Puffer — und sie hat endlich eine
eigene Pruefung.
Ein einzelnes Archiv ohne Zeitpunkt bleibt gueltig, mehrere nicht: sie lassen
sich nicht ordnen, und vermerkt wuerde womoeglich die Sicherung von vorgestern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bei verborgener Website kam der Betreiber auf admin. und stand auf www., app.
und status. vor der Baustellenseite seines eigenen Portals — obwohl er im VPN
war und seine Adresse in der Konsole freigegeben hatte.
Zwei Tore hatten zwei Vorstellungen davon, wer "wir" sind:
RestrictConsoleNetwork VPN-Subnetz + die Freigabeliste aus der Konsole
PublicSiteGate nur admin_access.trusted_ranges
Wer seine Bueroadresse eintrug, oeffnete damit nur das eine Tor. Das andere
kannte die Liste nicht und liess ihn stehen — was wie ein kaputtes VPN aussah
und keines war.
Jetzt fragt das Seiten-Tor dieselbe Stelle wie das Konsolentor. Eine Liste, ein
Begriff davon, wer hereindarf: wer die Konsole sehen darf, darf die versteckte
Seite auch sehen. Das ist dieselbe Person.
2901 Tests gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gekuendigte Kundenmaschinen wurden nie abgebaut. EndInstanceService nimmt der
Instanz am Laufzeitende die Adresse weg und laesst die Maschine ausdruecklich
stehen; danach kam nichts mehr, und sie belegte fuer immer einen Platz auf dem
Host. ArchiveAndTearDown ist der Schritt danach: vierzehn Tage nach dem Ende
wird die Maschine archiviert und geloescht.
Die eine Regel: niemals loeschen, bevor das Archiv nachweislich existiert. Ein
vzdump kann mit einer Auftragskennung enden und trotzdem nichts hinterlassen —
volle Ablage, abgebrochener Lauf, ein Fehler im Gast. Deshalb steht zwischen
Sichern und Loeschen eine echte Nachschau auf der Ablage (backupsFor), und der
juengste Eintrag muss nach dem Beginn dieses Laufes entstanden sein: eine
naechtliche Sicherung von gestern ist kein Archiv, dem der letzte Tag fehlen
darf.
Beide Proxmox-Aufrufe liefern nur eine Kennung, keine Zusage, also wird auf den
Auftrag gewartet und danach nachgesehen — beim Herunterfahren, ob der Gast
wirklich steht, beim Sichern, ob die Datei liegt. Unmittelbar vor dem Loeschen
wird der Datensatz neu gelesen: eine Instanz, die in der Zwischenzeit
wiederbelebt wurde, wird nicht geloescht. Keine Ausnahme entkommt — ein
Fehlschlag ist false und ein Grund in teardown_error, weil dieser Ablauf spaeter
im Zeitplan ueber viele Instanzen laeuft.
Die Ablage kommt aus einer Einstellung (provisioning.proxmox.archive_storage,
Vorgabe local wie bei den naechtlichen Sicherungen) UND wird gegen die Ablagen
des Knotens geprueft. Fehlt sie oder nimmt sie keine Sicherungen auf, bricht der
Abbau ab, bevor eine Kundenmaschine dafuer heruntergefahren wurde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
archive_volid: speichert den Ort des Archivs, ohne den es nach 12 Monaten
nicht wiederzufinden ist.
archived_at: speichert den Zeitpunkt der Archivierung, daraus berechnet sich
die 12-Monats-Frist.
torn_down_at: speichert den Zeitpunkt der Maschinenlöschung, getrennt von
archived_at, damit der Zwischenstand sichtbar bleibt, wenn Archivierung
erfolgreich war aber Löschung noch nicht versucht oder gescheitert ist.
teardown_error: speichert die Fehlermeldung beim Löschen in Klartext, damit
ein Betreiber ohne Log-Suche reagieren kann.
Vier Tests zeigen, dass die Felder auf null stehen, in Carbon casten und
dass der Zwischenstand (archiviert, nicht abgebaut) ein gültiger Zustand ist.
Eine Mutation-Prüfung bestätigt, dass die Tests greifen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
backupNow() faehrt einen einmaligen vzdump (mode=stop, weil der Abbau die
Maschine vorher ohnehin herunterfaehrt) und liefert die Auftragskennung.
backupsFor() ist das eigentliche Fundament fuer den spaeteren Abbau: sie
fragt nach, was auf der Ablage wirklich liegt, statt der Auftragskennung zu
vertrauen — ein vzdump kann enden und trotzdem kein Archiv hinterlassen.
$storage ist an beiden Methoden ein Pflichtparameter, keine Einstellung: der
Client raet nicht, welche Ablage gemeint ist, und wiederholt damit nicht den
fest verdrahteten "local"-Namen aus createBackupJob().
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
v1.7.0 war getaggt, aber nie zusammengefuehrt. Der Update-Agent folgt Tags, die
Arbeit war also live — main kannte sie nicht, und main trug VERSION=1.6.6, also
UNTER dem existierenden Tag. Ein naechstes Release aus main haette 1.6.7
geheissen und waere nie ausgeliefert worden.
Drei Konflikte, alle so aufgeloest, dass beide Seiten ueberleben:
- VERSION auf 1.7.1, damit die Reihenfolge wieder steigt.
- deploy/install-agent.sh: main brachte install-server-terminal, der Zweig
release-update-lock. Zwei unabhaengige case-Arme an derselben Stelle — beide
bleiben, vier Schritte und vier sudoers-Zeilen.
- deploy/update.sh: nur ein Kommentar zu HOST_STEP_NEEDS=3.
Der timeout -k 10 aus 1.6.5 ist dabei erhalten geblieben. Ohne ihn haengt der
Agent unbegrenzt an docker compose exec, und genau das war der Ausfall, der
diese ganze Kette ausgeloest hat.
Dazu ein Merge-Artefakt: RbacMoveTest zaehlte 22 Berechtigungen. Beide Seiten
haben je eine ergaenzt — server.terminal und deployment.unblock — also sind es
23.
2868 Tests gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Nachwirkungen der ersten Fix-Welle (c9fef59).
1 — Die Regression, die sie selbst gesetzt hat. `endedAt()` fragte nur
„laeuft gerade nichts?" und nahm dann die juengste beendete Instanz. „Nichts
in Betrieb" ist aber nicht dasselbe wie „mit uns fertig": eine frisch
bestellte Instanz entsteht als `reserving` (ReserveResources) und bleibt das
den ganzen Bereitstellungslauf lang, `failed` (Order::markFailed) steht, bis
ein Betreiber wiederholt — beide fehlen in der Betriebs-Abfrage. Ein
wiederkehrender Kunde, der eben bezahlt hatte, las deshalb „Ihre Cloud ist
beendet." samt „Neues Paket buchen", direkt ueber dem Streifen, der seinen
laufenden Aufbau zeigte.
Jetzt muss die JUENGSTE Instanz des Kunden die beendete sein. Alle sechs
Instanzzustaende nachgeprueft (reserving, provisioning, active, failed,
cancellation_scheduled, ended; `suspended` ist seit 2026_07_31_160000 keiner
mehr, sondern eine eigene Marke) — jeder ausser `ended` ganz oben heisst: es
geschieht etwas Neueres.
Dazu eine zweite Bedingung, die die erste allein nicht traegt:
ReserveResources parkt eine bezahlte Bestellung ohne Platz und legt dabei GAR
KEINE Instanz an, bis zu vierzehn Tage. Die juengste Instanz ist in diesem
Fenster weiterhin die alte, beendete. Der Kasten bleibt deshalb weg, solange
fuer den Kunden ein Aufbau laeuft — dieselbe Bedingung, unter der
CustomerProvisioning den Fortschrittsstreifen zeigt. Zwei Bauteile auf einer
Seite duerfen einander nicht widersprechen.
2 — Das Versprechen stand noch dort, wo entschieden wird. Die erste Welle hat
drei von vier Stellen zurueckgenommen; die vierte war der Kuendigungsdialog
selbst. Der Kunde las dort einen Liefergegenstand („einen Link zum
Herunterladen", „erhalten Sie ... einen vollstaendigen Datenexport"), klickte
einmal auf Ja — und die Vertragsseite sagte danach nur noch „Ihr Wunsch ist
vermerkt, wir melden uns". Beide Saetze sind jetzt auf dasselbe Mass gebracht:
kein Liefergegenstand, keine Frist, kein Link, solange der Export nicht gebaut
ist. Der wahre Teil bleibt wortgleich stehen — ab dem Laufzeitende ist die
Cloud nicht mehr erreichbar, bis dahin selbst sichern.
lang/{de,en}/order.php bleibt absichtlich unveraendert: dieser Satz steht im
Verkauf und beschreibt, was das Produkt zusagt. Ihn zu streichen aendert das
Angebot und ist eine Entscheidung des Eigentuemers. Begruendung im Bericht.
Zu beiden Befunden wurde der Fix zurueckgedreht und die neue Zusicherung rot
gesehen (3 rot beim Waechter, 2 rot bei den Sprachdateien), dazu die
Gegenprobe mit einem zu breiten Waechter (1 rot). Ganze Suite: 2842 gruen,
0 rot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Am 4. August 2026 hielt ein einziger Aufruf — `timeout 45 docker compose
exec` ohne `--kill-after` — die Sperre stundenlang, und jeder folgende
Lauf wurde übersprungen. Behoben ist die Ursache in v1.6.5; was fehlte,
war der Griff für das nächste Mal. Er lag per SSH auf dem Wirt.
Die Konsole kann ihn nicht selbst führen: sie ist www-data in einem
Behälter, der Sperrenhalter ist ein Prozess auf dem WIRT. Also bittet
sie den Agenten, und der ruft den root-eigenen Helfer — dasselbe Muster
wie `apply-proxy-hosts`, mit eigener sudoers-Zeile.
Die Bitte liegt in einer EIGENEN Datei, und das ist keine
Geschmacksfrage: der Agent nimmt die Sperre in seinen ersten Zeilen,
lange bevor er den Postkasten ansieht. Ein blockierter Lauf steigt
vorher aus — eine Entsperr-Bitte im Postkasten erreichte ihn also genau
dann nie, wenn sie gebraucht wird. Dazu nimmt der Postkasten eine Bitte
zur Zeit an, und die dreißig Minuten, in denen dort eine wartende
Update-Anfrage liegt, sind die, in denen jemand entsperren will.
Der Dienstbenutzer sagt „gib die Sperre frei", nicht „töte 1234": welcher
Prozess das ist, sucht der Helfer selbst. Dürfte der Anrufer die Nummer
liefern, wäre die Freigabe das Recht, jeden beliebigen Prozess als root
zu beenden.
Beendet werden alle, die die Sperrdatei OFFEN halten — nicht nur der,
der das flock genommen hat. Ein flock hängt an der offenen
Dateibeschreibung, und die wird vererbt: stirbt der Agent, sein
hängendes `docker compose exec` aber nicht, bleibt die Sperre gehalten.
Genau das war der Vorfall. Verschont bleiben PID 1 und der Anrufer samt
Vorfahren — im Betrieb hält der blockierte Agent die Datei selbst offen
und ist zugleich der, der anruft.
Erst SIGTERM, fünf Sekunden, dann SIGKILL. Eine Frist ohne Nachdruck ist
keine Frist.
Bestätigt wird im Modal (R23), das VORHER nennt, was es beendet — PID,
Laufzeit und Kommandozeile aus dem Lebenszeichen. Eigene Berechtigung
`deployment.unblock`, nicht `site.manage`: wer aktualisieren darf, darf
damit nicht automatisch in einen laufenden Vorgang hineingreifen.
Der Helfer-Vertrag steigt auf 3, und update.sh verlangt ihn. Ohne das
wäre der Knopf auf einem Wirt, der install-agent.sh seither nicht mehr
gefahren hat, ein Knopf, der still nichts tut — und die Konsole sagt es
jetzt, statt den Betreiber dorthin zurückzuschicken, wo er ohne sie
schon war.
Geprüft wird ausgeführt, nicht begutachtet: der Helfer läuft im Test
gegen eine echte Sperrdatei mit echten Prozessen daran. Das hat gleich
einen Fehler gefunden — der Helfer erbt den Deskriptor und hielt seine
eigenen Kommandosubstitutionen für Halter, sodass die Runde nie zum Ende
gekommen wäre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eigene Faehigkeit, eigener Schluessel, eigene Tuer. Die Bruecke bleibt
unveraendert: sie kennt keine Hosts, nur Tickets.
Den Weg zum Wirt traegt die root-eigene Haelfte des Updaters — sie holt
sich die oeffentliche Haelfte selbst, prueft sie hart und schreibt die
Optionsliste, die das Dienstkonto nicht bestimmen darf. Kein sudo-Weg
dorthin: einen Root-Schluessel eintraegt ein Mensch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Befunde aus dem Gesamt-Review, und alle vier hatten dieselbe Wurzel:
`export_wish` fuehrt drei Zustaende, und jede Stelle, die den Kunden
ansprach, kannte nur zwei.
K1 — Der Streifen im Dashboard trug einen Schalter, und `(bool) null` ist
`false`. Wer vor dieser Ausrollung gekuendigt hat, las unter dem Streifen
„Kein Export gewuenscht" — als waere das seine eigene Antwort. Jetzt stehen
dort dieselben zwei Auswahlfelder wie im Kuendigungsdialog: gleiche Frage,
gleiche Form, und ein unbeantworteter Zustand markiert schlicht keines von
beiden. Der Satz daneben fragt dann, statt zu behaupten, und sagt, was
passiert, wenn die Frage offen bleibt.
K2 — Die Vertragsseite versprach jedem den Export, auch dem, den der Dialog
eine Sekunde vorher mit einem bewussten „Nein" genau dorthin umgeleitet
hatte. Drei Fassungen statt einer, an `export_wish` gebunden. Die Ja-Fassung
verspricht dabei nicht mehr den Export selbst, sondern dass der Wunsch
vermerkt ist und sich jemand meldet — den Export gibt es nicht, und ein
gebundenes, aber weiterhin unhaltbares Versprechen haette den Fehler nur
verschoben.
Dazu der Zustand danach: eine `ended`-Instanz holt Dashboard::render() nicht
mehr, und der Kunde fiel in denselben Zweig wie jemand, der noch nie etwas
bestellt hat — „Ihre Cloud wird eingerichtet." samt „Paket buchen", am Tag,
an dem ihm die Adresse eingezogen wurde. Der Fall hat jetzt seinen eigenen
Kasten, mit dem Datum, an dem das Paket endete.
W1 — Die Erinnerungsmail behauptete im Praesens, wir bereiteten bereits einen
Export vor. Der Satz sagt jetzt, was stimmt. Und die Antwort hatte in der
ganzen Konsole keinen einzigen Leser: ein „Ja" landete in einer Spalte, die
niemand je zu Gesicht bekam. Ueber der Instanzliste steht deshalb ein
Abschnitt „Datenexport bestellt" — wer, und bis wann. Nicht als Plakette in
der Zeile, weil die Liste geblaettert ist und ein alter Eintrag auf Seite acht
saesse; nicht auf der Uebersicht, weil ein Hinweis, den nichts je wieder
abraeumen kann, Moebel waere.
W3 — Die einzige Pruefung zur Anzeige der Antwort konnte nicht fehlschlagen:
`x-ui.switch` rendert beide Woerter und ueberlaesst dem CSS die Auswahl, also
war `assertSee('Kein Export gewuenscht')` bei true, bei false UND bei null
gruen. Nachgewiesen mit einer Wegwerf-Pruefung gegen den alten Streifen:
dreimal derselbe Satz, dreimal gruen. Jetzt drei Pruefungen, je eine pro
Zustand, am `checked`-Attribut der Auswahlfelder.
Zu jedem der vier Punkte wurde der Fix kurz zurueckgedreht und die neue
Zusicherung rot gesehen; die Ergebnisse stehen im Bericht.
Ganze Suite: 2819 gruen, 2 rot — beide fremd. ReadinessPageTest scheitert an
`server.private_key` aus der parallel laufenden Terminal-Arbeit im selben
Baum; HostStepTest ist auf main vorbestehend rot (install-agent.sh traegt
CONTRACT=3, update.sh HOST_STEP_NEEDS=2, beide unveraendert).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Konsole meldete „kommt seit HH:MM nicht an die Arbeit", sobald der
Agent EINMAL an der Sperre vorbeilief. Gemessen wurde das bei einem
Überholen von neun Sekunden: Zeitgeber und Wächter laufen beide
minütlich, einer nimmt die Sperre, der andere geht weg. Das ist Betrieb,
kein Fehler — und der Besitzer hat daraufhin eine Stunde lang eine
gesunde Anlage auseinandergenommen.
Der Kopfkommentar an der Stelle kannte den Unterschied längst („ließe
sich von einem gesunden Überholen zweier Läufe nicht unterscheiden").
Die Dauer wurde mitgeführt, nur gegen nichts verglichen.
Der Agent zählt die Serie jetzt mit (`skips` im Lebenszeichen), die
Konsole macht ab zwei Läufen eine Meldung daraus. Gezählt wird in
LÄUFEN, nicht in Minuten: wie oft der Zeitgeber wirklich auslöst, steht
in der systemd-Unit auf dem Wirt, die diese Anwendung nicht sehen kann.
Die Schwelle gilt für den ganzen Zustand, nicht nur für den Satz. Nur
die Meldung zu unterdrücken hätte den Fehlalarm gegen einen stilleren
getauscht: `blocked_since` blendet auch „N Aktualisierungen zurück" und
die Zielversion aus, und die wären beim ersten übersprungenen Lauf
verschwunden, ohne dass irgendwo stünde warum.
Geprüft wird der Zähler am echten Skript, nicht an einer Nachbildung
seiner Logik: der Zweig liegt vor allem Teuren, also läuft der Agent im
Test gegen eine gehaltene Sperre und steigt aus, bevor `git fetch` oder
`docker compose` in die Nähe kommen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eine Mail sieben Tage vorher kann im Postfach untergehen; die eigene Uebersicht
oeffnet der Kunde ohnehin. Der Streifen nennt das Datum, die Restzeit und was
danach geschieht — dass der Zugang zur Cloud endet, nicht dass irgendetwas
geloescht wird. Das ist die Frist, die ihn betrifft.
Und er traegt die Antwort zum Export: wer liest, dass die Zeit laeuft, will es
sich im selben Atemzug anders ueberlegen koennen (Aufgabe 4) — bis zum
Laufzeitende, danach nicht mehr, geprueft direkt an der Methode und nicht nur
am Schalter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
$instance->update(['export_reminded_at' => now()]) lag ausserhalb des
try/catch, das nur den Mailversand absicherte. Ein Fehlschlag dieses einen
Schreibzugriffs haette die Marke leer gelassen (morgen eine zweite Mail fuer
dieselbe Instanz) UND den ganzen Lauf abgebrochen, statt nur diese eine
Instanz zu ueberspringen. Jetzt beides in derselben Absicherung.
Dazu zwei Pruefungen, die der Rand "Ende schon vorbei" bislang nicht hatte:
keine Erinnerung mehr, wenn die Frist schon abgelaufen ist (kein akademischer
Fall - EndInstanceService laesst einen DNS-Fehler bewusst durch, eine
Instanz kann also real tagelang mit abgelaufener Frist stehenbleiben), und
die obere Einschlussgrenze bei genau sieben Tagen, damit beide Raender der
"hoechstens sieben Tage"-Regel durch je eine eigene Pruefung belegt sind.
Ausserdem: die Selbst-Herunterladen-Adresse selbst wird jetzt im Rendertest
geprueft, nicht nur Datum und Sprachschluessel.
Ab dem Laufzeitende zieht EndInstanceService die Adresse ein — der Kunde kommt
ab dem Moment nicht mehr an seine Nextcloud. Wer selbst etwas herunterladen
will, muss es VORHER tun, und das wusste bisher niemand.
Die Auswahl ist bewusst "hoechstens sieben Tage" und nicht "genau sieben Tage":
ein Gleichheitsvergleich verfehlt jede Instanz, die zwischen zwei Laeufen
durchrutscht, und der Preis dafuer waere, dass jemand ausgesperrt wird, ohne es
gewusst zu haben.
Zusaetzlich zum Zettel: lang/{de,en}/mail_pace.php bekommen einen Eintrag fuer
ServiceEndingSoonMail, weil MailPacePageTest fuer jede Klasse in MailLane::all()
einen Anzeigenamen verlangt — ohne ihn waere die Suite rot.
Befund 1: neuer deutscher Text (Kommentare, ein Testname) benutzte ae/oe/ue/ss
statt ä/ö/ü/ß — der Bestand schreibt mit echten Umlauten, das Original wird
hier nachgezogen. Betroffen: die drei Kommentare in ConfirmCancelPackage.php,
der Blade-Kommentar, sowie Kopfkommentare und ein Testname in
CancelAsksAboutExportTest.php. Der Funktionsname kuendbareInstanz() und die
Test-Fixtures (E-Mail/Subdomain "kuendigt") bleiben ASCII — ersterer ist
wörtlich aus dem Zettel übernommen, letztere sind technische Werte wie jede
andere Test-Subdomain im Bestand (acme, berger).
Befund 2 (Entscheidung des Betreibers): cancel_point_export versprach den
Datenexport unbedingt, direkt über einer Frage, die ihn an ein Ja knüpft. "auf
Wunsch" eingefügt, in beiden Sprachdateien — der Satz sagt jetzt, was der
Dialog tatsächlich tut, ohne sonst etwas am Text zu ändern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Angelpunkt des ganzen Vorhabens: wer keinen Export braucht, loest keine
Arbeit aus und wartet auf nichts. Zwei Auswahlfelder und keine Checkbox — eine
Checkbox kennt keinen dritten Zustand, und "nicht angekreuzt" waere von "nein"
nicht zu unterscheiden.
Die Frage ist nicht ueberspringbar (#[Validate('required|boolean')], vor Stripe
geprueft wie jede andere Vorbedingung hier). Das macht drei bestehende
Erfolgspfad-Pruefungen zu ConfirmCancelPackage neu pflichtig in einem Feld, das
sie vorher nicht kannten — PackageCancellationTest, SettingsTest und
EndInstanceServiceTest setzen deshalb jetzt zusaetzlich exportWish, ohne dass
sich an ihren eigentlichen Zusicherungen etwas aendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Zustaende, nicht zwei: `null` heisst "noch nicht gefragt". Jede Instanz,
die vor diesem Bau gekuendigt wurde, hat die Frage nie gesehen — ihr ein "nein"
zu unterstellen hiesse, still fuer Menschen zu antworten, die niemand gefragt
hat.
Achtundzwanzig Eintraege in sieben Gruppen, und „System" war der Platz fuer
alles, was sonst nirgends hinpasste: Mail-Einrichtung neben einem
Rechtsdokument, neben den persoenlichen Kontoeinstellungen, neben der
Mitarbeiterverwaltung — und ganz unten die Seite, die sagt, was liegt. Der
Betreiber hat es so beschrieben: „offene Punkte ist der letzte Punkt, dann
Rolle drueber und Einstellungen wieder drueber".
Zwei Regeln ordnen es jetzt.
Was man einmal einrichtet, verlaesst die Leiste: neun Seiten liegen als
Kacheln hinter EINEM Eintrag (admin.setup), gruppiert nach dem, was sie
einrichten. Keine dieser Seiten wurde angefasst — sie behalten Route,
Berechtigung und Inhalt, es aendert sich nur der Weg dorthin. Damit ist der
Umbau rueckholbar.
Und die drei Seiten, auf denen etwas WARTET, stehen ganz oben, mit einer Zahl
daneben: das ist die Frage, mit der man eine Konsole oeffnet. Stoerungen sind
aus „Betrieb" nach oben gezogen und Zahlungsprobleme aus „Geld" — umgezogen,
nicht verdoppelt. Bei null faellt die Plakette weg, der Eintrag bleibt: eine
Seite, die verschwindet, sobald nichts offen ist, ist genau dann nicht
erreichbar, wenn man nachsehen will, ob wirklich nichts offen ist.
Zwanzig Eintraege statt achtundzwanzig, jede Seite genau einmal.
Zwei Dinge, die beim Verschieben kaputtgegangen waeren:
* Die neun verschobenen Seiten standen nicht mehr in console(). Damit war auf
ihnen KEIN Eintrag markiert (Codex R15, P2) und currentLabel() lieferte
null — die Brotkrume haette dort nur noch „Konsole" gesagt. Zwei Stellen,
eine Wurzel: die Kachelliste ist nach Navigation::setup() gewandert, wo
beide sie lesen, und isCurrent() haelt die Tuer markiert, solange man
dahinter steht.
* Die Versionszeile im Fuss stand als toter Text da, waehrend die Seite mit
dem Aktualisierungsknopf in die Einrichtung gezogen war. Gemeldet vom
Betreiber: „man sieht es nicht, ohne genau hinzuklicken." Sie ist jetzt der
Weg dorthin — und sagt in der Akzentfarbe, wenn etwas wartet. Wartet
nichts, bleibt sie grau: eine Zeile, die immer ruft, ruft nie.
Die drei Zahlen liegen fuer eine Minute im Zwischenspeicher. Diese Leiste
rendert auf JEDER Konsolenseite; ohne das waeren es vier Abfragen je
Seitenaufruf — eine Abgabe, die man erst sucht, wenn die Konsole zaeh ist.
Achtzehn Zusicherungen, darunter die, auf die es ankommt: keine der
achtundzwanzig Seiten von vorher ist verlorengegangen. Die Liste steht im Test
ausgeschrieben und nicht aus der Repository-Geschichte gelesen — ein Test, der
sich seine Erwartung aus demselben Repository holt, das er prueft, prueft
nichts.
Entwurf: docs/superpowers/specs/2026-08-04-konsolen-seitenleiste-design.md
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Läuft der 72-Stunden-Link ab, gab es keinen Weg zurück ausser der Shell —
und die setzt dabei ungefragt auf Owner. Settings::resendInvitation() zieht
für ein noch nie benutztes Konto (last_login_at ist null) ein neues Token
und verschickt dieselbe Einladungsmail; der Broker macht das alte Token
dabei von selbst ungültig. inviteStaff() läuft jetzt in einer Transaktion,
damit eine Störung zwischen Kontoanlage und Mailversand keine für immer
blockierte Adresse mehr hinterlässt.
Dazu der Nachtrag am Testnachweis: die reflektierende Prüfung auf ein
verstecktes Passwort steigt jetzt in Arrays ab statt sie zu überspringen,
und prüft zusätzlich das gerenderte HTML statt nur die Komponenteneigen-
schaften. Drei Kleinigkeiten: ein falscher Kommentarhinweis auf eine
angeblich fehlende Übersetzungsdatei korrigiert, eine fehlende Zusicherung
gegen einen rohen Statusschlüssel ergänzt, und ein toter throttle-Wert aus
config/auth.php entfernt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher erzeugte Settings::inviteStaff() beim Einladen eines
Betreiber-Mitarbeiters ein Passwort und zeigte es dem Inhaber einmal auf dem
Bildschirm, damit er es "sicher weitergibt" -- fuer einen Zugang zur Konsole,
die die ganze Flotte verwaltet. Der Kommentar dort nannte sich selbst eine
Attrappe.
Jetzt geht eine Einladung ohne Passwort hinaus: der Eingeladene bekommt eine
Mail mit einem Link und vergibt sein Passwort selbst, ueber
App\Livewire\Auth\OperatorSetPassword. Niemand -- auch der Inhaber nicht --
kennt je ein fremdes Passwort.
Dafuer brauchte es einen eigenen Weg, den es fuer Betreiber noch nicht gab
(R21: Konsole und Portal teilen keine Identitaet). Ein eigener Broker mit
eigener Tabelle (operator_password_reset_tokens, config/auth.php), eine
eigene Route in der Gast-Gruppe der Konsole (admin.invitation), und
Operator::sendPasswordResetNotification() wirft jetzt, statt Laravels
Vorgabe zu nutzen, die auf die Portalseite verlinkt haette.
Der Einladungslink gilt 72 Stunden -- lang genug fuer ein Wochenende, kurz
genug, dass ein altes Postfach nicht auf Dauer einen Schluessel zur Konsole
haelt. Zwei-Faktor bleibt unberuehrt: die neue Seite meldet niemanden
automatisch an, der Eingeladene durchlaeuft danach die normale Anmeldung
samt ihrer bestehenden Zwei-Faktor-Pruefung. Die Route liegt hinter denselben
Netz- und Hostwaechtern wie der Rest der Konsole (RestrictAdminHost,
RestrictConsoleNetwork), ohne Sonderfall.
OperatorInvitationMail reiht sich in den Versandtakt ein (MailLane::LOCKED,
wie ResetPasswordMail und VerifyEmailMail -- ein Mensch wartet gerade) und
ist damit in der Vorschau- und Versandtakt-Uebersicht der Konsole sichtbar,
statt lautlos in die gedrosselte Spur zu fallen.
Zwei Mutationsproben gegen die tragende Zusicherung durchgefuehrt (Bericht:
.superpowers/sdd/betreiber-einladung-report.md): die erste (durch die
Vorgaengersitzung) hielt fest, dass drei Zusicherungen fallen wuerden, waere
das Konto sofort anmeldbar; die zweite -- das Passwort testweise wieder auf
die Seite gebracht -- faellt exakt an der dafuer gebauten reflektierenden
Pruefung ueber alle oeffentlichen Eigenschaften der Seite.
Suite: 2771 passed (9683 assertions).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemeldet: „seit 1.5.1 muss ich nach jedem Update install-agent.sh fahren,
sonst kommt kein Update mehr". Die Konsole meldete „Der Update-Dienst auf dem
Server laeuft nicht" und schickte genau dorthin.
Er lief. Das Journal zeigt zwei Tage lang lueckenlos 57-59 Laeufe je Stunde.
Aber ueber zweiundachtzig Minuten hinweg startete und endete jeder Lauf in
DERSELBEN Sekunde, waehrend ein arbeitender Lauf zwei braucht: sie stiegen
alle sofort wieder aus, an der Sperre eines anderen Vorgangs — `flock -n 9 ||
exit 0`. Lautlos. Kein Journal-Eintrag (systemd sieht einen sauberen Lauf),
keine Zeile in der Statusdatei, nichts in der Konsole.
Und die Statusdatei war die einzige Lebendmeldung, die es gab. Sie wird erst
nach rund 190 Zeilen geschrieben — nach dem `git fetch` und nach einem
`docker compose exec`, beide ohne Zeitgrenze und beide unter der Sperre. Ein
Lauf, der davor aussteigt, hinterlaesst nichts, und nach zwanzig Minuten
schliesst die Konsole daraus, der Dienst sei tot. Sie schloss falsch, und die
Handlungsanweisung dazu aendert an einer gehaltenen Sperre nichts.
Drei Aenderungen:
* Ein Lebenszeichen (agent-alive.json) als ERSTES bei jedem Lauf, vor allem,
was blockieren kann. Zwei Zustaende: `running` heisst "ich habe die Sperre
und arbeite", `blocked` heisst "ich bin ausgestiegen" — mit `since` (seit
wann ununterbrochen) und `held_by` (wer, per fuser und ps).
* Zeitgrenzen: 45 Sekunden um den docker-exec, 120 um den git fetch. Ohne
sie wartet ein Abruf gegen eine tote Verbindung, bis das Betriebssystem
ihn nach vielen Minuten aufgibt — und haelt dabei die Sperre.
* Die Konsole liest das Lebenszeichen statt der Statusdatei. Der Unterschied
ist der Punkt: Status heisst "zuletzt ERFOLGREICH nachgesehen",
Lebenszeichen heisst "zuletzt ueberhaupt gelaufen". Ein blockierter Agent
gilt als lebendig, aber seine Zahlen zaehlen nicht mehr als aktuell —
`behind` und `target_release` fallen auf "unbekannt", statt eine Stunde
alte Auskunft als frisch auszugeben.
Statt "laeuft nicht" steht dort jetzt "laeuft, kommt aber seit HH:MM nicht an
die Arbeit", mit dem Prozess darunter.
Ein Agent von VOR dieser Aenderung schreibt die Datei nicht — fuer den gilt
weiter die alte Regel. Ihn dafuer fuer tot zu erklaeren waere derselbe Fehler
mit umgekehrtem Vorzeichen; ein Test haelt das fest.
Widerlegt und damit ausgeschlossen: Besitzrechte (Wirt, .env und Behaelter
fuehren alle 1001), das Ausführbar-Bit (100755 im Repo), systemds
Startdrosselung (seit v1.1.0 abgeschaltet), ein zwischengespeicherter Zustand
im Panel (es liest bei jedem Aufruf frisch) und eine Luecke im Timer (keine).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei eigene Saetze statt einer geteilten Meldung an den drei
Inhaber-Wachen (sperren, Rolle aendern, entfernen) — jede nennt jetzt
den Grund: der Inhaber-Sitz ist der Zugang, mit dem der Kunde seine
eigene Cloud verwaltet.
Der Kommentar zum Auffangnetz in NextcloudUsers::applyRole() behauptete
einen engeren Schutz, als &&/|| linksassoziativ tatsaechlich bilden —
korrigiert statt geklammert, weil Klammern die gerade erst gebaute
|| true-Erkennung in FakeProxmoxClient gebrochen haetten, fuer einen in
der Praxis folgenlosen Fall.
Beide Fakes (FakeProxmoxClient, FakeRemoteShell) verweisen jetzt im
Kopfkommentar aufeinander: sie behandeln ein angehaengtes || true
unterschiedlich, und wer nur den einen kennt, soll das an der Klasse
lesen koennen.
Die Restnaht beim nachgeschickten Sperren (SyncSeatToNextcloud::invite())
bleibt Code wie er ist — Begruendung als Kommentar an der Stelle: die
Naht ist real, aber folgenlos (kein nc_synced_at, kein Wiederholen-Knopf,
Weg zurueck bleibt die Vordertuer).
Und ein kurzer Satz an der restore-Aktion in retry(), der die schon
vorhandene, aber weit oben stehende Begruendung buendelt: kein Feld fuer
ein faelliges enable, weil das die naechste Behauptung ueber eine Cloud
waere, in die das Portal nicht sehen kann.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
nexxo