Deploymentcenter BotandClaude Opus 5
56b1d2631a
Zwei Beobachtungen aus der laufenden Integration. 1. Der Installer schrieb Geheimnisse weltlesbar SetupWriter benutzte File.WriteAllText ohne Rechteanpassung - unter Linux also die Standardmaske und damit ueblicherweise 644. In genau dieser Datei stehen Lizenzschluessel und Anwendungstoken; jeder Benutzer des Systems konnte sie lesen. Der Lizenz-Cache in StateStore wird aus demselben Grund seit jeher auf 600 gesetzt - der Installer zog nicht nach. Enthaelt ein Ziel mindestens einen geheimen Wert, wird die Datei jetzt auf den eigenen Benutzer beschraenkt. Als geheim gilt type=secret UND source=provision: ein so geholtes Token traegt oft den Typ "string", ist aber genauso schutzbeduerftig. Unter Windows bleibt es beim Profil-ACL. 2. Zielnamen koennen plattformabhaengig unterschiedlich sein %APPDATA%\MeineAnwendung gegen $XDG_CONFIG_HOME/meineanwendung - eine setup.json kannte nur eine Schreibweise. Die kleingeschriebene Form allein traegt, weil NTFS die Schreibweise ignoriert, aber nur solange das Dateisystem tatsaechlich unempfindlich ist; auf APFS mit Beachtung der Schreibweise oder bei groesseren Unterschieden entstuende ein zweites, leeres Verzeichnis neben dem, aus dem die Anwendung liest. Ziele haben deshalb optional fileWindows, fileLinux und fileMacOS; ohne Angabe gilt weiterhin file. Die Dokumentation haelt ausserdem fest, dass der Installer bewusst Klartext schreibt und die Anwendung selbst entscheidet, ob und wie sie ihn danach schuetzt - und dass eine Entschluesselung, die Klartext durchreicht, deshalb kein Altlast-Zweig mehr ist, sondern ein aktiv genutzter Pfad. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deploymentcenter — Entwickler- und Agenten-Dokumentation
Zentrale Plattform für Lizenzverwaltung, Software-Updates, Infrastruktur- Monitoring und einen Bugtracker, den Coding-Agenten selbständig bedienen.
Zuerst lesen
| Dokument | Wofür |
|---|---|
| UPGRADE.md | Ablaufplan für die Umstellung auf 2.0. Enthält Pflichtschritte: Zugangsdaten wechseln, Migration, Evaluator-Cron. |
| Agent-Prompt-Vorlage | Textbaustein für CLAUDE.md / AGENTS.md eines Projekts |
| Agenten-Handbuch | Vollständige Beschreibung des Bugtracker-Workflows, öffentlich unter /docs/ |
Modul-Handbücher
- Lizenzsystem (Hardware-ID v2) — Hardware-Anbindung, Schlüsselvalidierung, Offline-Cache, CLI, Windows und Linux/Docker
- Watchdog (Heartbeat & Telemetrie) — Überwachung von Anwendungen, Diensten und Infrastruktur
- UpdateService — Release-Verteilung und Update-Prüfung
- Erstinstallation —
setup.json, Installationskonto,update-agent --action install - Bugtracker — Anbindung aus Anwendungen heraus
Modulübersicht
| Modul | Aufgabe | Endpunkte | Authentifizierung |
|---|---|---|---|
| Bugtracker | Fehler, Feature Requests und Ideen; Agenten-Workflow mit Claim/Lease | /api/bugtracker/v1/report/api/bugtracker/v1/projects/api/bugtracker/v1/manage |
Token mit bugtracker:* |
| UpdateService | Release-Verteilung, semantischer Versionsvergleich | /api/updateservice/v1/check/api/updateservice/v1/publish |
Lesen offen, Publish braucht updateservice:publish |
| Watchdog | Heartbeat-Monitoring, Zustandsbewertung, Alarmierung | /api/watchdog/v1/ping/api/watchdog/v1/evaluate |
Token mit watchdog:ping |
| Lizenzen | Lizenzprüfung, Hardware-ID v2, Offline-Cache | /api/license/v1/validate/api/license/v1/deactivate |
Validierung offen, Deaktivierung authentifiziert |
| Tokens | Selbst-Provisionierung von Sub-Tokens | /api/tokens/v1/provision |
Master-Token |
| Setup | Erstinstallation: Anmeldung, Katalog, Anwendungstoken | /api/setup/v1/login/api/setup/v1/catalog/api/setup/v1/token |
Login offen, Rest setup:* |
| System | Verfügbarkeit, Schema-Status, Schnittstellenbeschreibung | /api/health/api/openapi.json |
Health optional, OpenAPI offen |
Schnittstelle maschinenlesbar
GET https://dc.mhdf.de/api/openapi.json
Ein Agent kann sich daran selbst orientieren — der früher fest im WebUI hinterlegte Textblock entfällt damit.
Antwortformat
Alle JSON-Endpunkte antworten einheitlich:
{ "status": "success", "…": "…" }
{ "status": "error", "error": { "code": "already_claimed", "message": "…" } }
Der code ist stabil und für Programme gedacht; die message richtet sich an
Menschen und kann sich ändern.
Betrieb
| Aufgabe | Befehl |
|---|---|
| Deployment | python scripts/deploy.py |
| Migration | php public/install_db.php oder WebUI → System → DB-Migration |
| Evaluator (Cron, minütlich) | curl -fsS -H "Authorization: Bearer <SHARED_KEY>" https://dc.mhdf.de/api/watchdog/v1/evaluate |
| Zustand prüfen | curl https://dc.mhdf.de/api/health |
| Logs | var/log/dc-<datum>.log auf dem Server |
Aufbau
config/ Zugangsdaten (nicht versioniert), Vorlage in config.example.php
src/ Anwendungscode, PSR-4 unter dem Namensraum Deploymentcenter\
Core/ Bootstrap, Konfiguration, DB, Auth, CSRF, HTTP, Tokens, Migrator
Modules/ Bugtracker, License, UpdateService, Watchdog, Notify
public/ Webroot-Inhalte: WebUI, API-Endpunkte, öffentliche Dokumentation
sql/ Schema und Migrationen (fortlaufend nummeriert)
var/log/ Laufzeitprotokolle
scripts/ Deployment
Neue Klassen werden automatisch geladen, sobald sie dem Namensraum-Pfad
entsprechen — eine require-Zeile ist nicht mehr nötig.