florian.wilde/proxdeploy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
00712dc6ce37c5e8f6d6d8111b958b096f29227f
proxdeploy/CHANGELOG.md
T
florian.wildeandClaude Opus 5.5 00712dc6ce feat(templates): Profile ins Template einbacken 
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>
2026-10-12 14:20:32 +02:00

4.8 KiB
Raw Blame History

Changelog

Alle nennenswerten Änderungen an ProxDeploy werden in dieser Datei dokumentiert.

Das Format basiert auf Keep a Changelog, und dieses Projekt folgt Semantic Versioning.

[Unveröffentlicht]

Hinzugefügt

  • Templates mit eingebackenen Profilen: beim Template-Bau Profile wählen; Ausrollen nimmt das passende Template und überspringt, was schon drin ist (#022)
  • Profil-Editor: eigene Profile als YAML mit Live-Prüfung und Skriptvorschau, Katalogprofile als Kopie bearbeiten (#011)
  • Vorlagen (Presets): im Assistenten wählen und speichern, Vorlagenseite, vorlage in der API; Beispiel „Docker-Host klein“ (#012)
  • Ubuntu 22.04/24.04/26.04 als VM und LXC; Fortschritt beim Klonen aus dem Task-Log (#010)
  • LXC-Container ausrollen: Container-Template prüfen und laden, anlegen (unprivilegiert, nesting für docker), Netz, Provisionierung per pct exec über Node-SSH oder per SSH in den Container mit einem Bereitstellungsschlüssel (#009)
  • Profile kennen die festen Bedingungen if: vm und if: lxc (#009)

Geändert

Behoben

  • chrony wird in Containern nicht mehr installiert – ohne CAP_SYS_TIME scheiterte dort das Profil base (#009)
  • SSH-Härtung auf Ubuntu 24.04 scheiterte an fehlendem /run/sshd (#009)

Entfernt

Sicherheit

[0.2.0] – 2026-10-12

Hinzugefügt

  • Katalog als Daten: Debian 12/13 und Ubuntu 22.04/24.04/26.04 sowie die Profile base, docker und zabbix-agent als YAML unter catalog/, beim Start in die Datenbank abgeglichen (#004)
  • Katalogseite mit Aktiv-Schaltern für Distributionen und Profile; GET /api/v1/distributionen?typ=vm|lxc, GET /api/v1/profile (#004)
  • README mit Stand, Fähigkeiten und Entwicklungsumgebung (#018)
  • Provisionierungs-Adapter debian und Profil-Engine: Profile werden zu einem idempotenten Skript; geprüft mit shellcheck und echt in Containern für alle fünf Distributionen (pnpm test:container) (#005)
  • docs/katalog.md: neue Distribution, neuer Adapter, eigenes Profil (#005)
  • Aufträge im worker (pg-boss) mit Phasen, Detail-Log und Live-Fortschritt per Server-Sent Events; Live-Ansicht im Aufbau der CLI-Ausgabe, Verlaufsseite (#006)
  • Template-Bau: Cloud-Image mit Prüfsumme laden, VM mit q35/UEFI anlegen, Disk importieren, Guest-Agent einbauen, als Template markieren; Templates-Seite (#007)
  • VM ausrollen: Klonen, Hardware, cloud-init, Start, Guest-Agent, Provisionierung der Profile über den Guest-Agent – ohne SSH (#008)
  • Deploy-Assistent mit 9 Schritten, Dry-Run mit allen geplanten Proxmox-Aufrufen und passendem CLI-Befehl (#008)

Behoben

  • Provisionierungsskripte mit Umlauten scheiterten an Proxmox' file-write; sie werden jetzt base64-kodiert übertragen (#008)

Sicherheit

  • Profil-Variablen werden in Shell-Befehlen immer gequotet; Zeitzone, Locale und Tastatur gegen strenge Muster geprüft (#005)
  • VMIDs werden unter einer Sperre je Server vergeben – parallele Aufträge bekommen nie dieselbe ID (#006)

[0.1.0] – 2026-10-12

Hinzugefügt

  • Architektur- und Umsetzungsplan (docs/architektur.md) mit Prüfung der Proxmox-API 8.x/9.x und der Image-Quellen (#001)
  • Issues #001–#020 für die sechs Etappen und den Feldtest (#001)
  • Grundgerüst: Next.js 16, Prisma 7, Tailwind 4 mit den ProxDeploy-Farben als Tokens, dunkles und helles Theme (#001)
  • Anmeldung mit lokalem Benutzer; der erste Administrator entsteht aus ADMIN_BENUTZER/ADMIN_PASSWORT (#001)
  • Seitenleiste mit Wortmarke, auf dem Handy als Schublade; Übersichtsseite (#001)
  • /api/v1/gesundheit und /api/v1/ich (#001)
  • Server-Verwaltung: Proxmox-Server anlegen, bearbeiten, löschen; Zertifikat ansehen und Fingerprint pinnen; Verbindung vor dem Speichern prüfen (#002)
  • Optionales SSH-Schlüsselpaar je Server mit Einzeiler zum Hinterlegen auf den Nodes (#002)
  • Server-Umschalter in der Seitenleiste, Serverliste auf der Übersicht (#002)
  • Verbindungstest: Version, Cluster, Nodes, Storages, Bridges, VNets und die Rechte des Tokens; je Vorgang, ob er per API, per SSH oder gar nicht geht (#003)
  • SSH zu den Nodes mit Host-Key-Pinning nach Bestätigung (#003)
  • docs/proxmox-rechte.md: Rolle ProxDeploy für PVE 8 und 9 mit fertigen pveum-Befehlen (#003)
  • Proxmox-Client mit verständlichen Fehlern (Ursache + Hinweis, fehlendes Recht samt Pfad) und Warten auf Proxmox-Tasks (#002)

Sicherheit

  • Geheimnisse werden mit AES-256-GCM verschlüsselt, Schlüssel aus PROXDEPLOY_SCHLUESSEL (#001)
  • Passwörter mit argon2id; Sperre nach zehn Fehlversuchen in 15 Minuten; Content-Security-Policy mit Nonce (#001)
  • Das Audit-Log ist per Datenbank-Trigger nur anhängbar (#001)
  • Proxmox-Token-Secret und SSH-Privatschlüssel liegen nur verschlüsselt vor und verlassen den Server nie; TLS ohne Prüfung oder Pin ist ausgeschlossen (#002)
Reference in New Issue View Git Blame Copy Permalink