4 Commits (1f32a2d5b3f8a60dcde2abf9ce979c8ef5607d61)

Author	SHA1	Message	Date
nexxo	5aedef2b35	Release v1.3.90 — nach dem Paket fragen, nicht nach dem Pfad ... Der zweite Bau auf echter Hardware brach ab mit "qemu-guest-agent ist NICHT im Abbild". Es war im Abbild. Die Prüfung suchte /usr/bin/qemu-ga, Debian legt den Gastagenten nach /usr/sbin/qemu-ga. Dass das Paket eingebaut war, stand im selben Protokoll: customise_cloud_image ruft --install und danach --run-command 'systemctl enable qemu-guest-agent'. Ein fehlgeschlagenes --run-command lässt virt-customize abbrechen, und systemctl kann keine Unit aktivieren, die es nicht gibt. Der Lauf ging durch — also war das Paket da. Das ist zum zweiten Mal derselbe Fehler in dieser Datei: eine Eigenschaft über einen NAMEN behauptet statt über die Sache. Erst die Partitionsnummer statt der Lage auf der Platte (v1.3.89), jetzt ein Pfad statt der Verpackung. Ein Pfad ist eine Vermutung darüber, wie ein Paket seine Dateien verteilt. Gefragt wird jetzt /var/lib/dpkg/info/<paket>.list — die Aussage des Pakets über sich selbst, und genau die Frage, die hier gestellt gehört: hat apt es still übergangen? Ein einziges Verzeichnis-Listing für alle vier Pakete, weil jeder virt-ls-Aufruf eine eigene Appliance startet. Geprüft werden damit qemu-guest-agent (Falle 3), cloud-guest-utils für growpart (Falle 4), docker-compose-plugin und docker-ce. Der Vergleich ist grep -qx: ein vorhandenes docker-ce-cli.list darf nicht als docker-ce durchgehen — durchgespielt, zusammen mit einem vollständigen und einem lückenhaften Listing. Falle 1 bleibt eine Inhaltsprüfung, weil sie eine ist: user: www-data steht in einer Datei, die wir selbst hineinkopieren, nicht in einem Paket. Und die Meldung nennt jetzt die fehlenden Pakete beim Namen statt nur die Falle. Bestätigt aus demselben Lauf: Falle 2 besteht seit v1.3.89 ("Wurzel auf /dev/sda1 und nichts dahinter"), und der Umbau selbst — Docker, Compose, Gastagent — lief in 38 Sekunden durch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 09:32:18 +02:00
nexxo	88dadf759a	Release v1.3.89 — Falle 2 lehnte das einzige Abbild ab, für das sie gedacht war ... Der erste echte Vorlagenbau brach ab mit: Die Root-Partition (/dev/sda1) ist nicht die letzte auf der Platte (/dev/sda15). Das Abbild war in Ordnung, die Prüfung nicht. Sie verglich Partitions-NAMEN und hielt für die letzte, was `sort -V` nach hinten sortiert. Debians Cloud-Abbild legt die BIOS-Boot- und die EFI-Partition aber an den ANFANG der Platte und nummeriert sie als 14 und 15; die Wurzel ist Nummer 1 und liegt physisch dahinter. Gemessen: sda15 beginnt bei 4 MB, sda1 bei 128 MB. Das ist kein Zufall dieses Abbilds, sondern genau die Eigenschaft, die Falle 2 verlangt — nur so kann growpart die Wurzel über den freien Rest ausdehnen. Die Prüfung verweigerte also ein Abbild, weil es ihre Bedingung erfüllte. Jetzt wird nach dem ANFANG auf der Platte gefragt statt nach der Nummer, über `guestfish part-list`, das Offsets in Bytes liefert. "Nichts liegt dahinter" ist eine Aussage über die Platte, nicht über die Benennung. Die Auswertung steht in zwei eigenen Funktionen (last_partition_number, partition_start), damit sie sich ohne Proxmox und ohne libguestfs gegen aufgezeichnete part-list-Ausgaben durchspielen lässt — gemacht, in beide Richtungen: Debians Anordnung besteht, eine Platte mit etwas hinter der Wurzel fällt durch. Genau diese Gegenprobe fehlte, weshalb der Fehler bis auf echte Hardware durchkam. Und die Fehlermeldung trägt jetzt die Byte-Offsets beider Partitionen mit. Scheitert das je wieder, steht die Platte im Protokoll statt einer Vermutung. Nebenbei bestätigt: der VPN-Aussetzer vor dem Bau hat zweimal "could not ask Proxmox about the VM templates" gemeldet und wiederholt, statt einen Neubau auszulösen — der Codex-P1-Fix aus v1.3.88 hat am ersten Tag verhindert, dass ein Netzausfall qm destroy --purge auslöst. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 09:21:54 +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	5d25018cc6	Build the golden template so nobody has to remember how ... All three Block A traps are CHECKED here rather than assumed, because each one has already cost a paid order and none of them shows a symptom until it is too late. Trap 2 is checked before anything is built: virt-filesystems is asked whether the image uses LVM and whether root is the last partition, and the section refuses if either is wrong. Debian's cloud image satisfies both by construction, which is exactly why it is the base — but "satisfies it by construction" is a claim about an artefact somebody else builds, and it gets verified rather than trusted. Traps 1 and 3 are checked AFTER the image is customised, because virt-customize reports success even when apt quietly did not install something. qemu-guest-agent has to be in /usr/bin or every provisioning run hangs in WaitForGuestAgent until it times out, and the compose file inside the image has to carry `user: www-data` or every occ call fails — including the acceptance check that decides whether a customer's instance is usable. The template is verified by its ATTRIBUTE, not its existence. VerifyVmTemplate checks only that 9000 is there, which a VM that merely happens to be numbered 9000 also passes; `template: 1` is passed only by a template. Docker comes from Docker's own repository, not Debian's. docker.io ships no compose plugin and Debian's docker-compose is the old Python one, which does not read this file at all. The compose file is deliberately customer-independent: no password, no name, no domain. Everything variable arrives in /opt/nextcloud/.env, written into the guest by cloud-init at clone time. Baking a password into an image copies it onto every host and into every instance, and leaves it there long after the customer has changed it. OVERWRITEPROTOCOL, OVERWRITEHOST and TRUSTED_PROXIES are set because TLS ends at Traefik on the host. Without them Nextcloud builds its own URLs with http://, the login loops, and WebDAV clients get handed an address that does not exist. Storage is discovered rather than named: local-zfs is what the PVE installer creates on ZFS, local-lvm on ext4, and `local` frequently cannot hold disks at all — an importdisk there fails only after the copy. Verified without hardware: dash-clean; the compose file parses, carries `user: www-data` on the app service, publishes 80, and every credential is a ${...} reference rather than a literal. Step 2 unticked, and it is the one the plan is most insistent about: the template must actually be cloned, started, and asked `occ status` as www-data. Without that clone it is not proven. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 20:16:50 +02:00