Linux-Update-Server

Script beziehen

Um die benötigten Dateien auf dem Update-Server zu erhalten, stellen wir ein Bash-Skript bereit. Sie können es im Browser oder in einem Terminal herunterladen:

curl

curl -O https://repos.passwork.pro/repository/linux/scripts/get_desktops.sh

wget

wget -O get_desktops.sh https://repos.passwork.pro/repository/linux/scripts/get_desktops.sh

Vorteile

• Lädt nur die erforderliche Version aus unserem Repository herunter — die zu Ihrem Backend passt. Das Remote-Repository dient als Dateiquelle, nicht als Versionsquelle: Es hostet alle Desktop-Anwendungsversionen. Welche XXYY heruntergeladen wird, bestimmt das Skript über die API oder eine lokale Datei.
• Unterstützt Proxy (HTTP_PROXY / HTTPS_PROXY), wichtig in isolierten Netzwerken, die über einen Proxy auf das Internet zugreifen.
• Kann zeitgesteuert (cron / Task Scheduler) ausgeführt werden, damit der Update-Server mit Ihrem Backend synchron bleibt.

Woher die Version (welche XXYY herunterzuladen ist) kommt:

1. Backend-API — wenn PASSWORK_DOMAIN gesetzt ist, fordert das Skript die verfügbare Desktop-Version über die Passwork-Server-API an und lädt das entsprechende XXYY herunter.
2. Lokale Datei — die Datei LOCAL_VERSIONS_FILE enthält eine Zeile mit der Version.

Es werden keine anderen Versionsquellen verwendet: Das Dateirepository wird nur zum Herunterladen genutzt, nicht zur Versionsbestimmung.

Jeder Lauf lädt eine XXYY-Version herunter. Wechselt das Backend auf eine neue Version — holt das Skript beim nächsten Lauf das neue XXYY (von der API oder der aktualisierten Datei) und lädt die Update-Dateien herunter.

Variablen

Variable	Beschreibung
REPO_BASE_URL	URL des Repositorys mit den gebauten Desktop-Installern (Dateiquelle).
OUTPUT_DIR	Verzeichnis für gespeicherte Dateien (Update-Server-Stamm oder Kopie).
PASSWORK_DOMAIN	Backend-URL für Versionsanfrage per API (empfohlen, wenn erreichbar).
LOCAL_VERSIONS_FILE	Pfad zur Versionsdatei, wenn die API nicht genutzt wird.
HTTP_PROXY	Proxy für ausgehende Anfragen (z. B. http://proxy:3128).
LOG_FILE	Pfad zur Protokolldatei (optional).
STATUS_FILE	Pfad zur Statusdatei für die Überwachung (optional, siehe „Monitoring“).
KEEP_RELEASES	Wie viele alte XXYY-Verzeichnisse in OUTPUT_DIR behalten werden (Standard 2).
LOCK_FILE	Sperrdatei zur Vermeidung paralleler Läufe (cron); leere Zeichenkette zum Deaktivieren.

Dry run

shell

./get_desktops.sh --dry-run

Ausführung

shell

# Einmalig oder per cron
export PASSWORK_DOMAIN="https://your-backend.example.com"
export OUTPUT_DIR="/var/www/updates"
export HTTP_PROXY="http://proxy.example.com:3128"   # bei Bedarf
./get_desktops.sh

Das Skript prüft den Speicherplatz, legt bei Bedarf eine Sperre an, damit nicht zwei Instanzen gleichzeitig laufen (z. B. durch cron), vergleicht Manifeste mit bereits heruntergeladenen Dateien und lädt nur bei Änderungen herunter.

Monitoring

Um zu prüfen, ob die Synchronisation lief und der Inhalt aktuell ist:

1. Skript-Exitcode

   • 0 — Erfolg; keine Aktualisierung nötig oder Aktualisierung abgeschlossen, oder --dry-run.
   • 1 — Fehler (Netzwerk, Repository, Speicherplatz usw.).
     Überwachungssysteme (cron + Prüfskript, Zabbix, Prometheus usw.) können den Skript-Exitcode nutzen.

2. Statusdatei (STATUS_FILE)
   Ist STATUS_FILE gesetzt, überschreibt das Skript diese Datei nach jedem Lauf mit Zeilen im Format key=value:

   • status — ok oder error;
   • version — aktuelle XXYY-Version (oder leer bei Fehler vor Versionsbestimmung);
   • timestamp — Zeit in UTC (ISO);
   • message — kurze Meldung (z. B. „Update complete for version 0002“ oder „All latest YAML unchanged“).

   Beispielinhalt nach erfolgreichem Lauf:

shell

status=ok
version=0002
timestamp=2025-02-17T12:00:00Z
message=Update complete for version 0002

Bei Fehler (auch vor Versionsbestimmung) schreibt das Skript status=error und optional message=exit N. Zur Überwachung: STATUS_FILE lesen, status=ok prüfen und optional die Aktualität über timestamp oder das Vorhandensein von OUTPUT_DIR/<version>/latest.yml.

3. Protokoll (LOG_FILE)
   Ist LOG_FILE gesetzt, werden alle Skriptmeldungen dorthin geschrieben. Sie können das Protokoll auf Fehler oder Zeilen wie „Update complete“ / „Repository unreachable“ durchsuchen.

Beispielprüfung für Monitoring (Bash):

shell

STATUS_FILE="/var/www/updates/.sync_status"
export STATUS_FILE
./get_desktops.sh

# Nach dem Lauf prüfen (oder aus einem anderen geplanten Skript):
grep -q '^status=ok$' "$STATUS_FILE" && echo "Sync OK" || echo "Sync FAIL"

# oder nach Aktualität (z. B. nicht älter als 25 Stunden):
ts=$(grep '^timestamp=' "$STATUS_FILE" | cut -d= -f2)