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>
71 lines
2.8 KiB
PHP
71 lines
2.8 KiB
PHP
<?php
|
||
/**
|
||
* Deploymentcenter Configuration – VORLAGE
|
||
*
|
||
* Diese Datei nach config/config.php kopieren und ausfüllen.
|
||
* config/config.php ist per .gitignore vom Repository ausgeschlossen.
|
||
*
|
||
* Jeder Wert kann alternativ über eine Umgebungsvariable gesetzt werden
|
||
* (siehe dc_env() unten). Die Umgebungsvariable hat immer Vorrang.
|
||
*/
|
||
|
||
if (!function_exists('dc_env')) {
|
||
/**
|
||
* Liest eine Umgebungsvariable, fällt sonst auf den Standardwert zurück.
|
||
*/
|
||
function dc_env(string $key, $default = null)
|
||
{
|
||
$val = getenv($key);
|
||
if ($val === false || $val === '') {
|
||
return $default;
|
||
}
|
||
return $val;
|
||
}
|
||
}
|
||
|
||
return [
|
||
'app' => [
|
||
'name' => 'Deploymentcenter',
|
||
'version' => '2.0.0',
|
||
'url' => dc_env('DC_APP_URL', 'https://dc.example.com'),
|
||
'timezone' => 'Europe/Berlin',
|
||
// Bei true werden Exception-Texte in API-Antworten ausgegeben.
|
||
// Auf Produktivsystemen zwingend false lassen.
|
||
'debug' => (bool)dc_env('DC_DEBUG', false),
|
||
],
|
||
'db' => [
|
||
'host' => dc_env('DC_DB_HOST', 'localhost'),
|
||
'dbname' => dc_env('DC_DB_NAME', 'deploymentcenter'),
|
||
'username' => dc_env('DC_DB_USER', 'root'),
|
||
'password' => dc_env('DC_DB_PASS', ''),
|
||
'charset' => 'utf8mb4',
|
||
],
|
||
'security' => [
|
||
// Master-Key für Server-zu-Server-Aufrufe (Evaluator-Cron, Deactivate, Migration).
|
||
// Mit `openssl rand -hex 32` erzeugen.
|
||
'shared_key' => dc_env('DC_SHARED_KEY', ''),
|
||
'session_name' => 'DC_SESSION_ID',
|
||
// Signaturschlüssel für ausgehende Webhooks (HMAC-SHA256).
|
||
'webhook_key' => dc_env('DC_WEBHOOK_KEY', ''),
|
||
// Signaturschlüssel für Offline-Lizenzdateien (.lic).
|
||
'license_key' => dc_env('DC_LICENSE_SIGNING_KEY', ''),
|
||
// Privater RSA-Schlüssel, mit dem Releases signiert werden. Entweder
|
||
// das PEM selbst oder ein Pfad zur Schlüsseldatei.
|
||
// openssl genrsa -out /etc/dc/release-signing.pem 2048
|
||
// chmod 600 /etc/dc/release-signing.pem
|
||
// Leer lassen schaltet das Signieren ab; Releases bleiben dann
|
||
// installierbar, der Agent weist aber bei jedem Update darauf hin.
|
||
// Bewusst asymmetrisch: geprüft wird auf fremden Systemen, dort darf
|
||
// der Signierschlüssel nicht liegen.
|
||
'release_private_key' => dc_env('DC_RELEASE_SIGNING_KEY', ''),
|
||
],
|
||
'bugtracker' => [
|
||
// Projekt-Slug, unter dem das Deploymentcenter eigene Fehler meldet.
|
||
'self_project' => 'deploymentcenter',
|
||
// Reports pro IP und Minute am öffentlichen Ingest-Endpunkt.
|
||
'report_rate' => 60,
|
||
// Wie lange ein Agent ein Item exklusiv beansprucht (Minuten).
|
||
'lease_minutes' => 30,
|
||
],
|
||
];
|