Richard/Deploymentcenter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
34 Commits 1 Branch 0 Tags
9d0261306c142a9abaa93b53395bb62f67cb7f6d
Commit Graph
2 Commits
Author SHA1 Message Date
Deploymentcenter BotandClaude Opus 5 e01a608c08 feat(release): Veroeffentlichungsvorlage fuer fremde Projekte 
Die Anleitung benutzte pack-and-deploy, als laege es im PATH - beziehbar war
es nirgends. Ein Projekt, das den UpdateService einbindet, konnte also nicht
veroeffentlichen, ohne dieses Repository auszuchecken und selbst zu
uebersetzen. Das Werkzeug existierte, nur kam niemand daran.

- build_installer.ps1 baut pack-and-deploy fuer dieselben Laufzeitkennungen
  mit und fuehrt es in installer.json unter "tools". Damit steht es neben dem
  Agenten unter /installer/ bereit.
- Neue Vorlage unter public/docs/release-template/: release.ps1, release.sh
  und release.config.example.json. Kopieren, Konfiguration ausfuellen, fertig -
  die Skripte selbst bleiben unveraendert und lassen sich bei einer neuen
  Fassung einfach ersetzen.
- Sie orchestrieren nur: je Laufzeitkennung einmal dotnet publish, dann
  pack-and-deploy. Pruefsummen, Dateimanifest, latest.json und die Anmeldung
  bleiben im Werkzeug - ein zweiter Ort fuer dieselbe Logik waere ein zweiter
  Ort fuer dieselben Fehler.
- Das Werkzeug wird beim ersten Lauf selbst geholt, gegen die .sha256 geprueft
  und unter .dc-tools/ abgelegt. Die Vorlage ist damit wirklich eine Datei.
- setup.json wird ins Publish-Verzeichnis kopiert, sonst faende der Installer
  sie nicht.
- Rueckgabewert 1 (Konfigurations- oder Versionsfehler) bricht sofort ab; die
  weiteren Plattformen wuerden genauso scheitern. Bei 2 laeuft es weiter und
  meldet am Ende, welche betroffen sind.

Anleitung: public/docs/release.md, oeffentlich unter /docs/release.md - dort,
wo auch das Bugtracker-Handbuch liegt. Das Entwickler-docs/ wird nicht
ausgeliefert; ein erster Anlauf legte die Vorlage dort ab und war deshalb
nicht abrufbar.

Beim Erproben in einem leeren Projekt aufgefallen und behoben:
- Die Vorlage verlangte jq. Das ist auf den wenigsten Systemen vorinstalliert;
  sie kommt jetzt auch mit Python aus.
- Windows legt unter WindowsApps einen python3-Platzhalter ab, der gefunden
  wird, beim Aufruf aber nur auf den Store verweist. Die Erkennung erprobt den
  Interpreter deshalb, statt nur seine Existenz zu pruefen.
- Der Ternary-Operator in release.ps1 gibt es erst ab PowerShell 7; die
  Vorlage laeuft jetzt auch mit dem mitgelieferten 5.1.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-14 13:23:38 +02:00
Deploymentcenter BotandClaude Opus 5 c8f3e78635 feat(setup): Erstinstallation ueber den Update-Agent, Installationskonto, Downloads 
Bisher gab es nur den Update-Weg: eine Anwendung musste bereits installiert und
eingerichtet sein, damit sich etwas aktualisieren liess. Die Erstinstallation
auf einem neuen System war Handarbeit - Paket kopieren, Konfiguration
abtippen, Token besorgen.

Setup-API (neu)
- POST /api/setup/v1/login tauscht Benutzername und Passwort gegen ein Token
  mit 30 Minuten Gueltigkeit und ausschliesslich setup:install. Es wird nicht
  mitgeschrieben und lebt im Installer nur im Speicher.
- GET /api/setup/v1/catalog zeigt nur, was zur Laufzeitkennung des anfragenden
  Systems passt. Ein Projekt mit ausschliesslich Windows-Paket taucht auf einem
  Linux-Rechner gar nicht erst auf.
- POST /api/setup/v1/token stellt das Dauertoken der Anwendung aus. Welche
  Rechte vergeben werden, entscheidet der Server; die Anfrage kann nur
  einschraenken. Sonst waere der Umweg ueber ein kurzlebiges Token wirkungslos.

Rollentrennung (Migration 012)
- dc_users bekommt role, disabled und last_login_at. Die Rolle "installer"
  darf sich ueber den Setup-Weg anmelden und nicht am WebUI. Die Zugangsdaten
  werden auf jedem Zielsystem eingetippt; mit einem Administratorkonto
  verteilte man damit den Zugang zu Tokens, Lizenzen und Monitoren auf jeden
  Rechner, auf dem je etwas installiert wurde.
- Auth::verifyCredentials() prueft sessionfrei, damit Setup- und WebUI-Login
  nicht zwei verschiedene Haertungsgrade haben (Drosselung, Timing-Angleichung,
  Rehash gelten fuer beide).
- Konten mit hinterlegtem TOTP-Geheimnis werden am Setup-Weg mit 501
  abgewiesen. Eine TOTP-Pruefung gibt es im Deploymentcenter noch nicht; sie
  stillschweigend zu uebergehen waere ein Rueckschritt.
- Benutzerverwaltung im WebUI - es gab bisher gar keine, nur den einen von
  install_db.php angelegten Admin. Das letzte aktive Administratorkonto laesst
  sich weder deaktivieren noch loeschen.

Installer
- update-agent --action install fuehrt durch Anmeldung, Auswahl,
  Zielverzeichnis, Installation und Einrichtung. Die Dateien kommen ueber
  denselben Pfad wie ein Update - mit Pruefsumme, Signatur, Staging und
  Rollback. Ein zweiter Download-Weg waere ein zweiter Ort fuer dieselben
  Fehler.
- --action configure holt die Einrichtung nachtraeglich.
- setup.json im Paket beschreibt die benoetigten Werte. Bewusst im Paket und
  nicht zentral: so ist sie mit der Anwendung versioniert.
- Gefragt wird nur, was uebrig bleibt: bereits gesetzt -> detect:... ->
  provision -> fragen. Platzhalter wie changeme oder <dein-wert> gelten dabei
  nicht als eingerichtet, sonst liefe die Anwendung mit der Vorlage los.
- SetupWriter erhaelt vorhandene Inhalte. Eine appsettings.json fuehrt neben
  den abgefragten Werten meist Logging und anderes; sie neu zu erzeugen waere
  bequemer und verloere das - bei einer Neuinstallation ohne Backup.
  int und bool landen als JSON-Typ, nicht als Zeichenkette.

Downloads
- scripts/build_installer.ps1 baut selbstenthaltende Einzeldateien fuer
  win-x64, linux-x64 und linux-arm64 (rund 34 MB, .NET-Laufzeit inbegriffen).
  Ohne NativeAOT und ohne Trimming: Spectre.Console loest ueber Reflexion auf
  und braeche sonst erst beim Anwender.
- scripts/upload_installer.py laedt sie nach /installer/. Getrennt von
  deploy.py, das client-dotnet bewusst ausklammert.
- Bereich "Installer" auf der UpdateService-Seite mit Groessen, Pruefsummen
  und den wget-Befehlen; die Angaben stammen aus installer.json statt aus fest
  eingetragenem Text.
- install.sh und install.ps1 laden, pruefen die Pruefsumme und legen ab -
  sie richten bewusst nichts selbst ein. Das Manifest wird BOM-frei
  geschrieben, sonst scheitert json_decode() daran.

Enthaelt ausserdem die bislang nicht committete Arbeit an den
RocketChat-Benachrichtigungen (Migrationen 010 und 011) sowie die Loesch- und
Editierfunktion des UpdateService; die betroffenen Dateien liessen sich nicht
getrennt stagen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-13 10:33:26 +02:00