fix(guard): Zugangsschutz je Produkt abschaltbar, Dienst-Betrieb, Buildzeiten
Sieben Rueckmeldungen aus einer laufenden Integration. Der schwerwiegendste Punkt ist ein Fehler von mir. D2 - Predictalytics ist ausgesperrt. Bestaetigt: /releases/predictalytics/ antwortet mit 401, waehrend die API weiter "Update verfuegbar" meldet. Jede ausgelieferte Installation laeuft damit in die Wand. Ursache ist nicht der Schutz an sich, sondern dass ich ihn scharfgeschaltet habe, ohne zu pruefen, ob die Verbraucher nachgezogen sind - genau der Fall, vor dem UPGRADE §16.1 warnt. Behoben wird die Klasse des Problems, nicht nur dieser Fall: Produkte lassen sich unter UpdateService -> Zugangsschutz einzeln ausnehmen. Damit ist der gestaffelte Rollout moeglich, der bisher fehlte: ausnehmen, Build mit Schluessel ausliefern, wieder einschalten. Ausgenommene Produkte sind in der Uebersicht deutlich als AUSGENOMMEN markiert und faerben den Selbsttest nicht gruen. D5 - BuildInfo.targets verhinderte inkrementelle Builds. BuildDateUtc trug die volle Uhrzeit, aenderte sich also bei jedem Build; WriteOnlyWhenDifferent griff nie, und jedes einbindende Projekt wurde jedes Mal neu uebersetzt. Jetzt tagesgenau. Das Commit-Datum waere stabiler, laesst sich aber nicht verlaesslich holen - die Formatangabe von git log ueberlebt MSBuild und cmd.exe nicht, wie ein Fehlversuch gezeigt hat. D4 - LicenseConfig war uneinheitlich und fuer Dienste unbrauchbar. SetStorageDirectory benutzte den Pfad roh, waehrend der Weg ueber die Umgebungsvariable <slug>/license anhaengte: zwei Produkte im selben Prozess schrieben in dieselbe state.dat. Und ohne $HOME - systemd User= ohne Heimatverzeichnis - landete der Rueckfall im Installationsverzeichnis, unter /opt nicht beschreibbar. Neu: einheitliches Anhaengen und ein Rueckfall auf /var/lib/<slug>, der vorher prueft, ob dort ueberhaupt geschrieben werden kann. D1 - Woher die Anwendung den Lizenzschluessel fuer den Update-Zugang nimmt, stand nirgends zusammenhaengend. Jetzt ein Beispiel in UPDATESERVICE §5A, das TryGetCachedKey und CheckForUpdateAsync verbindet. D3 - Fuer einen laufenden systemd-Dienst gab es keinen Update-Weg. Neu: SETUP §4A mit einer oneshot-Unit, die stoppt, aktualisiert und wieder startet - ohne --restart, weil der Agent sonst an systemd vorbei einen zweiten Prozess startet. Inklusive EnvironmentFile fuer den Schluessel und dem Hinweis auf die Dateirechte nach einem Lauf als root. D6 - Die Empfehlung Environment.Exit(1) passt fuer handelnde Systeme nicht. Ein neuer Abschnitt im Lizenz-Leitfaden beschreibt den Sperrbetrieb: abschalten, was neue Verpflichtungen eingeht; weiterlaufen lassen, was bestehende abwickelt. D7 - Die Drosselungsgrenzen aller Endpunkte stehen jetzt in docs/README.md. /api/errors/v1/report erlaubt 300 pro Minute, nicht 60; die Einstellung bugtracker.error_rate fehlte in der Beispielkonfiguration. Der zweite Teil des Befunds war veraltet: docs/README.md fuehrt die Release-Anleitung bereits. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Deploymentcenter Bot
co-authored by
Claude Opus 5
Claude Opus 5
parent
a8b9f6f7c9
commit
f8771c8d1b
@@ -136,7 +136,7 @@ Reagiere auf `code`, nicht auf den Text:
|
||||
Fassung in dieser Datei ein, direkt hier:
|
||||
|
||||
```
|
||||
Deploymentcenter-Anbindung: SDK 2.5.0, integriert am 2026-08-14
|
||||
Deploymentcenter-Anbindung: SDK 2.5.1, integriert am 2026-08-14
|
||||
```
|
||||
|
||||
Der Wert steht in `DeploymentcenterSdk.Version`. Ohne ihn muss beim nächsten
|
||||
@@ -145,7 +145,7 @@ Mal die gesamte Historie gelesen werden.
|
||||
**Bevor du die Anbindung anfasst,** frag zuerst, was sich seitdem geändert hat:
|
||||
|
||||
```
|
||||
GET /api/updateservice/v1/changelog?since=2.5.0
|
||||
GET /api/updateservice/v1/changelog?since=2.5.1
|
||||
```
|
||||
|
||||
Die Antwort nennt nur die neueren Fassungen, dazu `action_items` (Punkte mit
|
||||
@@ -155,7 +155,7 @@ zu tun.
|
||||
|
||||
Kommt `"count": 0` zurück, bist du auf Stand und musst gar nichts lesen.
|
||||
|
||||
Zum Nachschlagen für Menschen: `https://dc.mhdf.de/docs/changelog.php?since=2.5.0`
|
||||
Zum Nachschlagen für Menschen: `https://dc.mhdf.de/docs/changelog.php?since=2.5.1`
|
||||
|
||||
**Nach getaner Arbeit die Zeile oben auf die neue Fassung setzen.**
|
||||
```
|
||||
@@ -171,8 +171,8 @@ description, error_message, stack_trace, severity, file_path, line_no,
|
||||
client_ref). Vor der Arbeit an einem Item: POST .../manage?action=next zum
|
||||
Übernehmen. Danach ?action=resolve mit resolved_in_build.
|
||||
|
||||
Deploymentcenter-Anbindung: SDK 2.5.0
|
||||
Bevor du sie anfasst: GET /api/updateservice/v1/changelog?since=2.5.0 —
|
||||
Deploymentcenter-Anbindung: SDK 2.5.1
|
||||
Bevor du sie anfasst: GET /api/updateservice/v1/changelog?since=2.5.1 —
|
||||
zeigt nur, was seitdem dazukam. Danach die Zeile hochsetzen.
|
||||
|
||||
Vollständige Beschreibung: https://dc.mhdf.de/api/openapi.json
|
||||
|
||||
@@ -387,6 +387,47 @@ else
|
||||
}
|
||||
```
|
||||
|
||||
### Wenn Beenden die gefährlichere Option ist
|
||||
|
||||
`Environment.Exit(1)` ist die richtige Antwort für ein Werkzeug, das man
|
||||
einfach nicht mehr benutzen darf. Für ein System, das **offene Verpflichtungen
|
||||
verwaltet**, ist es die falsche: Ein Handelssystem mit offenen Positionen, eine
|
||||
Maschinensteuerung im Zyklus, ein Dienst mitten in einer Transaktion — die
|
||||
dürfen bei einer abgelaufenen Lizenz nicht einfach aufhören. Der Schaden aus
|
||||
dem abrupten Ende wäre größer als der aus dem Weiterlaufen.
|
||||
|
||||
Die brauchbare Antwort ist **Sperrbetrieb statt Abbruch**: Was neue
|
||||
Verpflichtungen eingeht, wird abgeschaltet; was bestehende abwickelt, läuft
|
||||
weiter.
|
||||
|
||||
```csharp
|
||||
if (!res.IsValid && !res.IsTransient)
|
||||
{
|
||||
logger.Error("Lizenz ungültig: {0}. Wechsle in den Sperrbetrieb.", res.Message);
|
||||
|
||||
// Was neue Verpflichtungen eingeht: aus.
|
||||
strategyEngine.StopOpeningPositions();
|
||||
scheduler.PauseNewJobs();
|
||||
|
||||
// Was bestehende abwickelt: bleibt an.
|
||||
// - Risikoüberwachung
|
||||
// - Schließen offener Positionen
|
||||
// - Ordnungsgemäßes Herunterfahren, wenn nichts mehr offen ist
|
||||
riskManager.KeepRunning();
|
||||
|
||||
notifier.Alert("Lizenz abgelaufen - Sperrbetrieb. Keine neuen Positionen.");
|
||||
}
|
||||
```
|
||||
|
||||
Wer diesen Weg geht, sollte zwei Dinge festhalten: **wann** aus dem
|
||||
Sperrbetrieb ein Ende wird (etwa sobald keine Position mehr offen ist), und
|
||||
**dass der Zustand sichtbar ist** — ein Sperrbetrieb, den niemand bemerkt, ist
|
||||
ein stiller Ausfall.
|
||||
|
||||
Der Offline-Cache federt das übrigens schon ab: Eine kurzzeitig nicht
|
||||
erreichbare Prüfung führt gar nicht erst hierher, dafür ist `IsTransient` da.
|
||||
Hier geht es um das echte Urteil.
|
||||
|
||||
| Status | `IsTransient` | Bedeutung |
|
||||
|---|---|---|
|
||||
| `valid` | – | Vom Server bestätigt |
|
||||
|
||||
@@ -50,6 +50,23 @@ hinterlegte Textblock entfällt damit.
|
||||
|
||||
---
|
||||
|
||||
## Drosselung
|
||||
|
||||
Je IP und Minute. Wird die Grenze überschritten, antwortet der Endpunkt mit
|
||||
`429 rate_limited` — dann das Intervall verdoppeln und später erneut versuchen,
|
||||
nicht sofort wiederholen.
|
||||
|
||||
| Endpunkt | Grenze | Einstellbar über |
|
||||
|---|---|---|
|
||||
| `/api/errors/v1/report` | **300** | `bugtracker.error_rate` |
|
||||
| `/api/bugtracker/v1/report` | 60 | `bugtracker.report_rate` |
|
||||
| `/api/license/v1/*` | 120 | fest |
|
||||
| `/api/updateservice/v1/*` | 240 | fest |
|
||||
| `/api/setup/v1/login` | 10 | fest — dort werden Passwörter geprüft |
|
||||
| `/api/tokens/v1/provision` | 20 | fest |
|
||||
|
||||
---
|
||||
|
||||
## Antwortformat
|
||||
|
||||
Alle JSON-Endpunkte antworten einheitlich:
|
||||
|
||||
@@ -324,6 +324,64 @@ der Installer schreibt die abgefragten Werte hinein. Siehe
|
||||
|
||||
---
|
||||
|
||||
## 4A. Einen laufenden systemd-Dienst aktualisieren
|
||||
|
||||
Der `update-agent` schreibt nach `--target-dir` — unter `/opt/<app>` hat der
|
||||
Dienstbenutzer dort keinen Schreibzugriff. Als `root` gestartet würde er zwar
|
||||
schreiben können, dann aber über `--restart` **an systemd vorbei** einen
|
||||
zweiten Prozess starten.
|
||||
|
||||
Die Abfolge lautet deshalb: anhalten, aktualisieren, starten — und der Agent
|
||||
startet **nichts** selbst.
|
||||
|
||||
```ini
|
||||
# /etc/systemd/system/myapp-update.service
|
||||
[Unit]
|
||||
Description=Update für myapp einspielen
|
||||
After=network-online.target
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
# Der Agent braucht Schreibrecht in /opt/myapp.
|
||||
User=root
|
||||
|
||||
# Der Lizenzschlüssel gehört nicht in die Kommandozeile - "ps" zeigt sie
|
||||
# jedem Benutzer der Maschine. EnvironmentFile mit 0600 und root:root.
|
||||
EnvironmentFile=/etc/myapp/update.env
|
||||
|
||||
ExecStartPre=/usr/bin/systemctl stop myapp.service
|
||||
ExecStart=/opt/myapp/update-agent \
|
||||
--action update --project myapp --channel prod \
|
||||
--target-dir /opt/myapp --version latest
|
||||
ExecStartPost=/usr/bin/systemctl start myapp.service
|
||||
```
|
||||
|
||||
```bash
|
||||
# /etc/myapp/update.env chmod 600, chown root:root
|
||||
DC_LICENSE_KEY=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
|
||||
```
|
||||
|
||||
Auslösen von Hand oder über einen Timer:
|
||||
|
||||
```bash
|
||||
systemctl start myapp-update.service
|
||||
```
|
||||
|
||||
**Kein `--restart` und kein `--wait-for-pid`.** Den Neustart übernimmt
|
||||
`ExecStartPost`, das Anhalten `ExecStartPre` — der Dienst ist beim Anwenden
|
||||
bereits beendet, es gibt keinen Prozess, auf den zu warten wäre.
|
||||
|
||||
Wird der Update-Weg dagegen **aus der Anwendung heraus** angestoßen, gilt
|
||||
`restartPath: ""` und `exitCurrentApp: false`: Die Anwendung fährt sich selbst
|
||||
geordnet herunter, systemd startet sie über `Restart=on-success` neu.
|
||||
|
||||
> **Dateirechte nach dem Update.** Der Agent läuft als `root` und legt die
|
||||
> Dateien entsprechend an. Gehört der Dienst einem anderen Benutzer, gehört
|
||||
> ein `ExecStartPost=/usr/bin/chown -R myapp:myapp /opt/myapp` davor — sonst
|
||||
> startet der Dienst danach nicht mehr.
|
||||
|
||||
---
|
||||
|
||||
## 5. Nachträglich einrichten
|
||||
|
||||
```bash
|
||||
|
||||
@@ -173,7 +173,7 @@ Version, UTC-Build-Datum und Git-Commit entstehen automatisch zur
|
||||
</PropertyGroup>
|
||||
|
||||
<ItemGroup>
|
||||
<PackageReference Include="Deploymentcenter.Client" Version="2.5.0" />
|
||||
<PackageReference Include="Deploymentcenter.Client" Version="2.5.1" />
|
||||
</ItemGroup>
|
||||
```
|
||||
|
||||
@@ -685,6 +685,47 @@ Hash wird unverändert aus `dc_users` übernommen: PHPs `password_hash()` erzeug
|
||||
bcrypt im Format `$2y$`, und genau das versteht Apache. Ein Klartextpasswort
|
||||
wird nirgends gebraucht.
|
||||
|
||||
### Woher die Anwendung den Schlüssel nimmt
|
||||
|
||||
Die häufigste Rückfrage bei der Integration: Der Schlüssel steht **im
|
||||
Lizenz-Cache**, den das Lizenzmodul ohnehin führt. Es muss nichts zusätzlich
|
||||
gespeichert werden.
|
||||
|
||||
```csharp
|
||||
// Beim Start einmal: Lizenz prüfen (legt den Schlüssel im Cache ab)
|
||||
var license = await new LicenseClient().EnsureLicensedAsync(
|
||||
productSlug: "myapp",
|
||||
serverBaseUrl: "https://dc.mhdf.de",
|
||||
allowPrompt: false); // im Dienst: nicht nach einer Eingabe warten
|
||||
|
||||
if (!license.IsValid) { /* Sperrbetrieb, siehe Lizenz-Leitfaden §6 */ }
|
||||
|
||||
// Danach jederzeit für den Update-Weg:
|
||||
string? key = LicenseClient.TryGetCachedKey("myapp");
|
||||
|
||||
var check = await new UpdateClient().CheckForUpdateAsync(
|
||||
baseUrl: "https://dc.mhdf.de",
|
||||
projectId: "myapp",
|
||||
currentVersion: BuildInfo.Version,
|
||||
channel: "prod",
|
||||
credentials: ReleaseCredentials.FromLicenseKey(key));
|
||||
|
||||
if (check.Unauthorized)
|
||||
{
|
||||
// Kein Netzwerkfehler: Die Lizenz trägt nicht mehr.
|
||||
log.Warn(check.Message);
|
||||
}
|
||||
```
|
||||
|
||||
`TryGetCachedKey` ist statisch und liest den verschlüsselten Cache aus
|
||||
`LicenseConfig.GetStorageDirectory(slug)`. Liefert er `null`, wurde noch nie
|
||||
erfolgreich validiert — dann gibt es auch keinen Update-Zugang.
|
||||
|
||||
> **Im Dienst ohne Heimatverzeichnis** (systemd `User=` ohne `$HOME`) fällt der
|
||||
> Cache auf `/var/lib/<slug>/license` zurück. Ist auch das nicht beschreibbar,
|
||||
> gibt es keinen Offline-Cache — dann muss `DEPLOYMENTCENTER_STORAGE_DIR` auf
|
||||
> ein beschreibbares Verzeichnis zeigen.
|
||||
|
||||
### Was sich für Clients ändert
|
||||
|
||||
**Ohne Nachziehen bekommt keine bestehende Installation mehr Updates.**
|
||||
|
||||
Reference in New Issue
Block a user