Deploymentcenter BotandClaude Opus 5
2388b5abe1
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>
56 lines
2.8 KiB
SQL
56 lines
2.8 KiB
SQL
-- Migration 009: Plattform-Dimension im UpdateService
|
|
--
|
|
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
|
|
|
|
-- ---------------------------------------------------------------------------
|
|
-- Fuer welche Plattform gilt dieses Release?
|
|
-- ---------------------------------------------------------------------------
|
|
-- Der UpdateService kannte Produkt, Kanal und Version - aber keine Plattform.
|
|
-- Seit fuer mehrere Laufzeitkennungen gebaut wird (win-x64, linux-x64, ...)
|
|
-- landeten beide Pakete im selben Kanal unter derselben Version und
|
|
-- ueberschrieben sich gegenseitig; ein Linux-System zog sich das
|
|
-- Windows-Paket. Behelfe waren getrennte Produkt-Slugs oder zweckentfremdete
|
|
-- Kanaele - beides trug nicht weit.
|
|
--
|
|
-- 'any' ist der Wert fuer plattformunabhaengige Releases und zugleich der
|
|
-- Bestandsschutz: alles, was vor dieser Migration veroeffentlicht wurde, gilt
|
|
-- weiterhin fuer jeden Client, der keine Plattform mitschickt.
|
|
ALTER TABLE updateservice_releases
|
|
ADD COLUMN platform VARCHAR(32) NOT NULL DEFAULT 'any' AFTER channel;
|
|
|
|
-- Die Eindeutigkeit muss die Plattform einschliessen, sonst verdraengt das
|
|
-- zuletzt veroeffentlichte Paket einer Version alle anderen Plattformen
|
|
-- derselben Version (ON DUPLICATE KEY UPDATE greift auf dem alten Schluessel).
|
|
ALTER TABLE updateservice_releases
|
|
DROP INDEX uq_prod_ver_chan;
|
|
|
|
ALTER TABLE updateservice_releases
|
|
ADD UNIQUE KEY uq_prod_ver_chan_plat (product_slug, version, channel, platform);
|
|
|
|
-- Die Abfrage lautet immer "Produkt + Kanal + passende Plattform".
|
|
ALTER TABLE updateservice_releases
|
|
ADD KEY ix_us_lookup (product_slug, channel, platform);
|
|
|
|
-- ---------------------------------------------------------------------------
|
|
-- Signatur des Releases
|
|
-- ---------------------------------------------------------------------------
|
|
-- Der SHA256 eines Pakets stammt aus derselben Quelle wie das Paket selbst.
|
|
-- Das schuetzt gegen Uebertragungsfehler, nicht gegen einen manipulierten
|
|
-- Webroot oder gestohlene FTP-Zugangsdaten - ausgerechnet auf dem Pfad, der
|
|
-- fremden Code ausfuehrt.
|
|
--
|
|
-- Bewusst KEIN HMAC: Bei einem HMAC braucht der Pruefende denselben
|
|
-- geheimen Schluessel wie der Signierende. Der Agent laeuft auf fremden
|
|
-- Systemen; ein dort hinterlegter Schluessel koennte gestohlen und zum
|
|
-- Signieren beliebiger Pakete benutzt werden - die Signatur waere wertlos.
|
|
-- Beim Lizenzmodul geht HMAC auf, weil dort der Server prueft.
|
|
--
|
|
-- Stattdessen RSA-SHA256: der Server signiert mit dem privaten Schluessel
|
|
-- (security.release_private_key), der Agent prueft mit dem oeffentlichen aus
|
|
-- /api/updateservice/v1/pubkey. Base64 einer 2048-bit-Signatur sind 344
|
|
-- Zeichen, daher TEXT und nicht VARCHAR(64).
|
|
--
|
|
-- Optional: Releases ohne Signatur bleiben installierbar, der Agent warnt.
|
|
ALTER TABLE updateservice_releases
|
|
ADD COLUMN manifest_signature TEXT NULL AFTER manifest_json;
|