Files
kiddo/docs/update-client.md

50 lines
1.5 KiB
Markdown

ID: DOC_000004 | Version: 0.1.0 | Status: Draft
By: Codex (GPT-5)
# Client Update Flow (Kiddo)
## Purpose
Definiert den Client-seitigen Ablauf fuer das Pull-Update vom Update-Service.
## Manifest Format (JSON)
Beispiel:
```json
{
"version": "0.1.2",
"artifact_url": "https://update.wlkns.org/kiddo/kiddo-0.1.2.tar.gz",
"sha256": "<hex>",
"sig_url": "https://update.wlkns.org/kiddo/kiddo-0.1.2.sig"
}
```
## Flow (High Level)
1. Manifest abrufen (auth optional via Bearer Token).
2. `artifact_url` herunterladen.
3. SHA256 pruefen (Signatur optional).
4. In Staging-Verzeichnis entpacken.
5. Service stoppen.
6. Atomic swap: aktuelles Verzeichnis sichern, Staging nach `/opt/sk` verschieben.
7. Service starten.
8. Bei Fehlern Rollback auf Backup.
## Prototype Script
- `scripts/update_client.sh` implementiert den Flow als CLI-Prototyp.
- Erfordert `curl`, `tar`, `sha256sum`, `python3` und `systemctl`.
## Rollback
- Wenn Start fehlschlaegt: Backup nach `/opt/sk` zurueck, Service neu starten.
- Backup-Verzeichnis benoetigt genuegend Speicher.
## Security Notes
- Artefakte muessen checksum-verifiziert sein.
- Token-Handling ueber `SKD_UPDATE_TOKEN`.
## Constraints
- Update-Service ist extern (update.wlkns.org).
- Service muss als root stoppen/starten koennen.
## Status Reporting
- Status wird per HTTP POST an `https://update.wlkns.org/status` gemeldet.
- Schema siehe `docs/update-status.md`.
- Lokaler Status/Logs liegen unter `/var/lib/skd` (konfigurierbar via ENV).