Deployment

Lokale Installation (systemd)

./scripts/install.sh fuehrt folgende Schritte aus:

legt Service-User/Group an
kopiert das Projekt nach /opt/sk
erstellt/aktualisiert .venv
erstellt /etc/skd/env aus env.example
schreibt eine systemd-Unit nach /etc/systemd/system/skd.service

Beispiel:

sudo ./scripts/install.sh
sudo systemctl status skd.service

Manuelles Starten

./scripts/run.sh

Remote-Deploy (SSH)

./scripts/deploy.sh packt das Repo und deployt es auf einen Zielhost. Konfiguration in deploy_hosts.yml.

Beispiel:

./scripts/deploy.sh kid-laptop

Deployment via ZIP

Im Repo liegt sk_deploy.zip. Dieses Archiv kann auf den Zielhost kopiert und nach /opt/sk entpackt werden. Anschliessend Abhaengigkeiten installieren und Service neu starten:

sudo -u skd /opt/sk/.venv/bin/pip install -r /opt/sk/backend/requirements.txt
sudo systemctl restart skd.service

Update des Services

./scripts/update.sh zieht den Branch neu und fuehrt einen harten Reset aus.

Wichtig: Das Script nutzt git reset --hard origin/main.

sudo ./scripts/update.sh

Update-Client (Remote Update Service)

Die Update-API startet scripts/update_client.sh bzw. scripts/rollback_client.sh. Wichtige ENV-Variablen:

SKD_UPDATE_SERVICE_URL
SKD_UPDATE_PROJECT_ID
SKD_UPDATE_TOKEN oder SKD_UPDATE_TOKEN_FILE Voraussetzungen auf dem Host:
curl, tar, sha256sum, python3, systemctl

Enrollment-Tools:

scripts/manual_enroll.py: Enrollment direkt gegen den Update-Service, schreibt Token in SKD_UPDATE_TOKEN_FILE.
scripts/enroll_local.py: Enrollment ueber die lokale API (/update/enroll), benoetigt Admin-Session; --token setzen (Default-Token ist nur Prototyp-Altlast).

Lokale Status/Logs:

SKD_UPDATE_STATUS_FILE (default /var/lib/skd/update_status.json)
SKD_UPDATE_LOG_FILE (default /var/lib/skd/update_logs.jsonl)

Backup/Restore

Bei Apply wird /opt/sk nach /opt/sk_backup_1.2.3_1700000000 verschoben (Beispiel).
Rollback nutzt das letzte Backup (/opt/sk_backup_*).

2.1 KiB Raw Blame History