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>
Behebt eine Reihe zusammenhaengender Fehler im Update-Weg, die zusammen
verhindert haben, fuer mehr als eine Plattform auszuliefern - und die im
Fehlerfall halb aktualisierte Installationen hinterliessen.
Server
- Migration 009: Spalte platform samt neuem Unique-Key. Zuvor verdraengte das
zuletzt veroeffentlichte Paket alle anderen Plattformen derselben Version,
weil ON DUPLICATE KEY auf (slug, version, channel) griff. Ein Linux-System
zog sich damit das Windows-Paket.
- Aufloesungsregel: je Version das plattformgenaue Paket, sonst das
plattformunabhaengige. Ein Client ohne Plattformangabe sieht ausschliesslich
'any' - lieber kein Update als das falsche.
- manifest_json wird endlich befuellt; die Spalte blieb bisher immer leer,
wodurch die API nie der Rueckfall sein konnte, als der sie gedacht war.
- Releases werden serverseitig mit RSA-SHA256 signiert, neuer Endpunkt
/api/updateservice/v1/pubkey. Bewusst kein HMAC: der Pruefende laeuft auf
fremden Systemen und darf den Signierschluessel nicht besitzen.
Packager
- Bricht ab, statt die Versionshistorie zu verlieren. Schlug das Lesen der
bestehenden latest.json fehl, ersetzte ein leeres catch die komplette
Historie durch einen einzigen Eintrag - ohne jede Meldung.
- Echte Glob-Muster. Zuvor trafen "logs/**" und "scratch/**" aus der
mitgelieferten Beispielkonfiguration nie zu.
- preservePatterns: Konfigurationsvorlagen werden ausgeliefert, ersetzen am
Ziel aber keine vorhandene Datei. Eine settings.json mit Zugangsdaten
ueberschrieb bisher beim Update die Konfiguration jedes Zielsystems.
- Warnt vor Dateien, die nach Zugangsdaten aussehen und auf keiner Liste stehen.
- Prueft --version gegen die Hauptassembly. Eine Abweichung fuehrte zu einer
Endlosschleife: Clients aktualisieren, melden weiter die alte Version,
halten das Release erneut fuer neu.
- --platform mit Ableitung aus dem Publish-Pfad.
Agent
- Anwenden mit Plan, Backup und vollstaendigem Rollback. Die Stelle war als
"Atomic Replace with Backup" kommentiert und war eine Kopierschleife.
- Verwaiste Dateien werden entfernt, aber nur solche aus dem Manifest der
Vorversion. Was nicht aus einem Release stammt, bleibt liegen.
- Das laufende Agent-Binary wird zur Seite gelegt statt ueberschrieben.
- API-Rueckfall in FetchManifestAsync; bisher nur im SDK vorhanden, weshalb
die Anwendung "Update verfuegbar" und der Agent "kein Release" sagen konnte.
- Installierte Version aus --current-version oder manifest.json statt des
Textes "Unbekannt", der als 0 gelesen wurde und jede Version neuer erscheinen
liess. Reparatur funktioniert damit auch ohne manifest.json.
- Setzt das Ausfuehrungsbit fuer Linux-Pakete, die unter Windows gebaut wurden.
SDK
- ResolveAgentPath() liefert den plattformrichtigen Namen; ein fest verdrahtetes
"update-agent.exe" wird unter Linux nie gefunden.
- LaunchUpdateAgent uebergibt jetzt --restart (wurde nie uebergeben, die
Anwendung blieb nach dem Update zu), --wait-for-pid (kein Wettlauf mehr mit
dem Herunterfahren) und --platform.
Enthaelt ausserdem die bislang nicht committete Arbeit an Watchdog, Lizenz-
Client und cli/tick.php samt Migration 008; die betroffenen Dateien liessen
sich nicht getrennt stagen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
