Feldtest auf PVE 9.2 vollständig (VM/LXC × Debian 12/13, Ubuntu 22.04/24.04/26.04, mit und ohne SSH zum Node); 8.x nicht im Einsatz und nicht geprüft. Dazu Standardwerte je Server und die Fehler aus dem Feldtest.
Closes#020Closes#023
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brach das Warten auf Klonen oder Anlegen ab, legte Proxmox den Gast trotzdem fertig an – und „Aufräumen“ wusste nichts von ihm (CT 114 im Feldtest).
Refs #020
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Im Feldtest wurde ein LXC fertig angelegt, während ProxDeploy nach drei gescheiterten Statusabfragen aufgab (Verbindungsaufbau > 10 s bei 76 % I/O-Last). Statusabfragen werden jetzt bis zum Task-Zeitlimit wiederholt, der Verbindungsaufbau darf 30 s dauern. nesting ist für Container standardmäßig an wie in der Proxmox-Oberfläche – Proxmox warnt sonst bei systemd 249/252.
Refs #020
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ubuntu 22.04 bringt eine Gruppe „admin“ mit; heißt der Gast-Benutzer so, brach useradd mit Code 9 ab (gefunden im Feldtest auf pve-demo). Der Container-Test legt jetzt diese Lage nach und lief seit pnpm 12 nicht mehr (pnpm -s gibt es dort nicht).
Refs #020
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Feldtest auf einem ausgelasteten pve-demo scheiterte an Verbindungswacklern, nicht an Proxmox: pveproxy meldete „Broken pipe“ (Backend weg), schloss Keep-Alive-Verbindungen, Storage-Abfragen dauerten 15 s. GET wird bis zu dreimal wiederholt, Schreibendes nur bei sicher nicht angekommener Anfrage; Schreibaufrufe dürfen 120 s dauern, Keep-Alive 2 s.
Refs #020
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Next.js bis 16.4.0 hat zwei kritische Lücken (RCE in der Bildoptimierung mit SVG und in use cache) und eine hohe (DoS über Server Actions). Prisma 7.10.1 hebt mysql2 und deepmerge-ts über bekannte Lücken. Volle Prüfung grün; dazu der Vorlagen-Ablauf mit mehr Zeit, weil sein Dry-Run wirklich gegen den Testhost plant.
Refs #020
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lange Zeilen unter „Letzte Deployments“ sprengten die Gitterspalte; der mobile Browser zoomte heraus, die Navigationsschublade verdeckte dann „Abmelden“. keinQuerscrollen misst jetzt gegen die eingestellte Breite – gegen innerWidth gemessen fiel das Herauszoomen nicht auf.
Refs #023
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Server kannte die Standards schon für kurze CLI-Befehle, aber nichts setzte sie. Jetzt im Server-Formular (Auswahl aus dem Verbindungstest) und als Vorbelegung im Assistenten.
Closes#023
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
q35 hängt IDE an den SATA-Controller; der Cloud-Kernel von Debian 12 kennt ihn nicht, cloud-init fand keine Datenquelle. Gefunden bei der Abnahme von #021 auf pve-demo: Template-Bau über die Bau-Adresse und eine Debian-12-VM daraus, beides ohne SSH zum Node.
Closes#021
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Etappe 6: Marken-Dateien, README mit Screenshots, Docker Compose und LXC-Installer.
Refs #017, #018, #019
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Screenshots per scripts/screenshots.ts aus dem gebauten Stand. Dabei gefunden und gefüllt: die Übersicht zeigte nur einen Platzhalter statt der letzten Deployments.
Closes#018
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ein Laufzeit-Paket (scripts/paket-bauen.sh) für beide Wege: Next standalone, worker als Bundle mit nur den nötigen Paketen, Migrationen ohne Prisma-CLI. Compose lokal komplett hochgefahren; der Installer auf pve-demo in einem echten Debian-13-LXC durchgelaufen.
Closes#019
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Alle Varianten aus dem Symbol der Vorgabe per Skript (pnpm marke); Texte als Pfade, damit Wortmarke und Banner ohne installierte Schrift gleich aussehen.
Closes#017
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Authorization Code mit PKCE, State und Nonce über openid-client 6.8.8; die Rolle kommt bei jeder Anmeldung aus dem Gruppen-Claim. Lokale Konten werden nie über den Namen übernommen, verknüpfen geht nur angemeldet. Getestet gegen einen Mock-IdP inklusive gefälschtem State, falscher Nonce und fremder Audience.
Closes#016
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Admins verwalten Benutzer (anlegen, Rolle, sperren, Passwort setzen); jeder ändert sein Passwort; das Audit-Log ist filterbar einsehbar. Sperre und Passwortwechsel beenden ältere Sitzungen über Benutzer.sitzungenAb. Der letzte Admin und das eigene Konto sind geschützt.
Closes#015
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Verlauf filterbar (URL, API, proxdeploy history); Wiederholen füllt den Assistenten aus einem alten Auftrag; Aufräumen löscht nach Fehlschlag oder Abbruch den halb angelegten Gast – nur, wenn dessen Beschreibung auf den Auftrag verweist. Deshalb setzt das Klonen die Beschreibung jetzt sofort. Auf pve-demo geprüft (CT 109).
Closes#014
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ssh2.utils.generateKeyPairSync liefert in etwa 4 von 1000 Fällen einen privaten Schlüssel, an dem der eigene Parser scheitert. Ein so erzeugter Server-Schlüssel wäre dauerhaft unbrauchbar gewesen; in den Tests war es die Ursache des gelegentlich roten SSH-Tests.
Refs #014
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Etappe 4: CLI proxdeploy in Go, API-Tokens, kurze Anfragen, OpenAPI. Abnahme auf pve-demo per batch (VM 107, CT 108).
Closes#013
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Befehle login, servers, distros, profiles, presets, vm, lxc, template list|build, batch, status, logs --follow, cancel. Renderer im Aufbau der Vorgabe (zeichengenau per Golden-File), 24-bit/256/ohne Farbe, --ascii, --quiet, --json, --dry-run; live im Terminal, zeilenweise ohne. SSE mit Wiederverbinden und Polling als Rückfall. Typen aus openapi.json per oapi-codegen; Release-Builds per cli/bauen.sh.
Refs #013
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- ApiToken (nur SHA-256), Bearer-Anmeldung, POST /auth/token für proxdeploy login, Verwaltung in den Einstellungen
- anfrageErgaenzen: Storage, Bridge, Node, Benutzer und Schlüssel aus Server-Standards, Verbindungstest und Anmeldung – auch beim Template-Bau
- Abschlussbox serverseitig (abschluss), Web und CLI zeigen dieselben Zeilen
- Antwortschemas als zod, daraus /api/v1/openapi.json und cli/api/openapi.json (pnpm openapi)
Refs #013
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Etappe 3: LXC, Ubuntu, Profil-Editor, Vorlagen, Profile im Template, SSH-Schlüssel, Template-Bau ohne SSH.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ohne SSH zum Node kommt der Guest-Agent jetzt über eine feste
Bau-Adresse ins Template: cloud-init setzt Adresse und den
Bereitstellungsschlüssel für den Standardbenutzer, ProxDeploy meldet
sich per SSH in der VM an, installiert den Agent und entfernt danach
Schlüssel, Adresse und cloud-init-Angaben.
Dabei korrigiert: der Verbindungstest meldete „Template-Bau per API“
auch ohne Weg, den Agent einzubauen. Im Protokoll erscheinen
unveränderte JSON-Felder nicht mehr als geändert.
Refs #021
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Benutzer hinterlegen ihre öffentlichen Schlüssel einmal, Admins
zusätzlich Team-Schlüssel. Sie kommen in jeden Gast: im Assistenten
vorausgewählt und abwählbar, per API und CLI automatisch, wenn die
Anfrage keine nennt. Die Schlüssel kommen über die Schnittstelle
SchluesselQuelle – dort lässt sich später eine externe Verwaltung
anbinden.
Vorgezogen aus #015 auf die Frage, ob Schlüssel ins Template gehören:
nein, in die Verwaltung.
Refs #015
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Beim Template-Bau lassen sich Profile wählen (nur solche ohne
Pflichtvariablen). Nach dem Vorbereitungsstart laufen sie über den
Guest-Agent; danach werden Maschinen-ID, SSH-Host-Keys, Docker-Engine-ID
und apt-Cache entfernt. Ausrollen nimmt das Template mit den meisten
passenden Profilen und überspringt, was schon eingebacken ist.
Auf pve-demo: Provisionierung mit base+docker 141 s ohne, ~30 s mit
Template. Dabei gefunden: docker nimmt den Benutzer per guest.user in
die Gruppe auf – Profile mit guest.* laufen deshalb beim Deploy noch
einmal (idempotent, schnell).
Closes#022
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ubuntu 24.04 auf pve-demo als VM (Template im selben Auftrag gebaut)
und als Container ausgerollt; 22.04 und 26.04 laufen im Containertest.
Der Voll-Klon brauchte auf dem Testhost neun Minuten – die Phase zeigt
jetzt den Fortschritt aus dem Task-Log.
Closes#010
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Gespeicherte Kombinationen aus Distribution, Ressourcen und Profilen.
Im Assistenten mit einem Klick vorbelegt oder dort gespeichert; die API
nimmt „vorlage“ entgegen (Grundlage für --preset der CLI). Eine Vorlage
liegt unter der Anfrage – was die Anfrage selbst sagt, gewinnt.
Beim ersten Start wird das Beispiel „Docker-Host klein“ aus der Vorgabe
angelegt, einmalig.
Closes#012
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Admins legen eigene Profile als YAML an; geprüft wird beim Tippen gegen
dasselbe Schema wie der Katalog, dazu eine Vorschau des erzeugten
Skripts. Katalogprofile bleiben schreibgeschützt und lassen sich als
Kopie bearbeiten. Ein Profil, das ein anderes voraussetzt, lässt sich
nicht löschen.
Closes#011
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Container aus dem Proxmox-Template (neueste passende Version aus
aplinfo), unprivilegiert, nesting automatisch für docker. Weil Proxmox
keine Exec-API für Container hat, läuft die Provisionierung per SSH:
bevorzugt pct exec über den Node, sonst direkt in den Container mit
einem Bereitstellungsschlüssel, der am Ende wieder entfernt wird.
Auf pve-demo beide Wege geprüft: Debian 13 mit docker per pct exec
(hello-world läuft mit nesting allein) und Ubuntu 24.04 per SSH in den
Container. Dabei gefunden: chrony scheitert ohne CAP_SYS_TIME (jetzt
if: vm), sshd -t auf Ubuntu 24.04 ohne /run/sshd.
Closes#009
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Eine VM aus dem ProxDeploy-Template ausrollen, vollständig per API:
Klonen, Hardware, cloud-init, Start, Guest-Agent und Provisionierung der
Profile über den Agent – ohne SSH. Der Fortschritt kommt aus der
Logdatei im Gast, je Profil eine Marke.
Der Dry-Run läuft durch dieselben Phasen mit einem Trocken-Client und
zeigt jeden geplanten Proxmox-Aufruf und den passenden CLI-Befehl. Der
Assistent hat 9 Schritte, den Zustand in der URL und bietet an, ein
fehlendes Template im selben Auftrag zu bauen.
Auf pve-demo abgenommen: pd-test01 (base, docker) per API, pd-test02
(base, zabbix-agent) über den Assistenten, beide per SSH geprüft. Dabei
gefunden: file-write scheitert an Umlauten – Skripte gehen jetzt
base64-kodiert hinüber.
Closes#008
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cloud-Image laden (download-url mit Prüfsumme, ab PVE 8.4 per API, davor
per SSH), VM mit q35/UEFI/virtio-scsi-single anlegen, Disk per
import-from importieren, Guest-Agent mit einem einmaligen
Vorbereitungsstart einbauen und als Template markieren.
Auf pve-demo (PVE 9.2.2) gebaut: Template 9000 aus Debian 13 in
5 min 26 s, Snippet und cicustom danach entfernt. Der Weg ohne SSH über
eine Bau-Adresse ist als #021 ausgegliedert.
Templates-Seite mit Liste (Proxmox ist maßgeblich, Tag
proxdeploy-template) und Formular; Abfrageschleifen erscheinen im
Detail-Log nur noch bei Fehlern.
Closes#007
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Aufträge laufen als pg-boss-Jobs im worker. Der Phasen-Runner der Engine
kennt weder Proxmox noch Datenbank; eine Senke schreibt Phasen und Log
in die DB und meldet per NOTIFY, die app streamt per SSE an Web und CLI
(Last-Event-ID, Herzschlag, Polling-Fallback im Browser).
VMIDs vergibt eine Advisory-Sperre je Server zusammen mit einer
Reservierungstabelle; zehn parallele Reservierungen im Test bekommen
zehn verschiedene IDs. Der Proxmox-Client hat einen Trockenmodus für
den Dry-Run: Lesendes echt, Schreibendes nur aufgezeichnet.
Live-Ansicht im Aufbau der CLI-Ausgabe. Im echten Betrieb aufgefallen:
ssh2 und pg sind CommonJS und brauchen im worker Default-Importe.
Closes#006
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Profile sind deklarative Schritte je Distributionsfamilie; der Adapter
übersetzt sie in ein idempotentes Shell-Skript. Ein neuer Adapter (rhel,
alpine) ist eine Datei und ein Eintrag in der Registry.
Variablen werden typisiert geprüft, in run-Schritten jeder Wert für die
Shell gequotet. SSH-Härtung läuft zuletzt, damit sich eine Provisionierung
per SSH nicht selbst aussperrt.
Geprüft mit shellcheck und echt in Containern (Debian 12/13, Ubuntu
22.04/24.04/26.04) inklusive zweitem Lauf. Dabei aufgefallen: frische
Images haben keine Paketlisten – der Vorspann macht jetzt apt-get update.
Closes#005
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Fünf Distributionen (Debian 12/13, Ubuntu 22.04/24.04/26.04) und drei
Profile liegen unter catalog/ und werden beim Start abgeglichen. Die
Datei ist maßgeblich für den Inhalt, die Datenbank nur für „aktiv“;
verschwundene Einträge werden markiert, nicht gelöscht.
Unbekannte Schlüssel sind Fehler, damit Tippfehler nicht still
verschwinden; eine kaputte Datei wird mit Pfad gemeldet und
übersprungen, statt den Start zu verhindern. Prüfsummen-Parser kennt
das Debian-, Ubuntu- und BSD-Format; bei mehreren LXC-Templates gewinnt
die höchste Version.
Closes#004
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ein Zwischenstand bis zum vollständigen README mit Banner und
Screenshots in Etappe 6 (#018).
Refs #018
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Etappe 1 abgeschlossen und auf dem Testhost pve-demo (PVE 9.2.2)
abgenommen: Rolle und Token nach docs/proxmox-rechte.md angelegt,
Fingerprint und SSH-Host-Key gegen den Node verglichen, Verbindungstest
mit und ohne SSH.
Der Fingerprint-Hinweis nennt jetzt ausdrücklich pve-ssl.pem bzw.
pveproxy-ssl.pem – pvenode cert info listet zuerst die Root-CA.
Closes#003
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Hinweis zeigt seit dem vorigen Commit auf docs/proxmox-rechte.md;
der Test erwartete noch das README.
Refs #003
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Test liest Version, Cluster, Nodes, Storages, Bridges, VNets und die
effektiven Rechte des Tokens und leitet daraus ab, welcher Vorgang per
API, per SSH oder gar nicht geht – je PVE-Version: Template-Bau per API
erst ab 8.4 mit import-Storage, Snippets und LXC-Exec nur per SSH.
Fehlende Rechte erscheinen einzeln mit Pfad und Zweck; die Rollenliste
in docs/proxmox-rechte.md prüft ein Test gegen den Code. SSH-Host-Keys
werden wie Zertifikate erst nach Bestätigung genutzt, und bestätigt
werden kann nur ein Schlüssel, den der letzte Test gesehen hat.
Statussymbole in der GUI sind jetzt gezeichnet: ◐ und ○ fehlen im
Web-Subset von JetBrains Mono.
Refs #003
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Server lassen sich anlegen, prüfen, bearbeiten und löschen. Proxmox
liefert ab Werk ein selbst signiertes Zertifikat; der Admin sieht es
vor dem Speichern und bestätigt den SHA-256-Fingerprint.
Der Pin wird in einem eigenen undici-Connector geprüft, sodass eine
fremde Gegenstelle das Token nie zu sehen bekommt. Weder Prüfung noch
Pin ist im Schema, im Client und per CHECK ausgeschlossen.
Fehler von Proxmox werden zu Ursache und Hinweis; bei 403 nennt der
Hinweis das fehlende Recht samt Pfad. Getestet gegen einen HTTPS-Mock
und im gebauten Stand auf Desktop und 390 px.
Closes#002
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Next.js 16, Prisma 7, Tailwind 4 und Vitest/Playwright, Konfiguration aus
Laufzettel übernommen, weil dort derselbe Stack erprobt ist.
Die Farben der Branding-Vorgabe stehen als Tokens in globals.css, das
helle Theme setzt dieselben Namen neu. Amber und Rot sind dort
abgedunkelt, sonst reicht der Kontrast nicht – ein Test prüft beide
Themes gegen 4,5:1.
Anmeldung mit lokalem Benutzer, Rolle je Anfrage aus der Datenbank,
Audit-Log per Trigger nur anhängbar. Geprüft im gebauten Stand auf
1440 px und 390 px.
Closes#001
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ubuntu 26.04 kommt mit, Templates booten UEFI, Template-VMIDs werden
als nächste freie ID im Template-Bereich des Servers vergeben.
Refs #001
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Plan für ProxDeploy zur Freigabe: Architektur (app, worker, Postgres),
Prisma-Entwurf, REST-API, Dateistruktur und sechs Etappen.
Die Proxmox-API wurde gegen das Schema von PVE 9.2 und die Quellen der
8er-Zweige geprüft. Daraus folgt die Fähigkeitserkennung pro Server:
Template-Bau per API erst ab 8.4, Snippets und LXC-Exec nur per SSH.
Refs #001
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
