Selbstaktualisierung

CLI und eigenständiger Agent können ihre eigene Programmdatei von der Veröffentlichungsseite aktualisieren – unter Windows x64/arm64, Linux x64/arm64 (glibc- und statische musl-Builds), macOS Apple Silicon sowie FreeBSD/NetBSD x64/arm64:

remote-cli update self --check
remote-cli update self
remote-agent update self --check
remote-agent update self

Der Updater behält die C-Laufzeit der laufenden Programmdatei bei: Ein musl-Build installiert nur das musl-Archiv, ein glibc-Build nur das glibc-Archiv. OpenWrt bleibt auch auf x64/arm64 bei opkg/apk: Seine Pakete enthalten keinen Archiv-Updater, und ein musl-Archiv auf einem Host mit /etc/openwrt_release verweigert das Selbstupdate. Eine Plattform wird nur aktualisiert, wenn ihr Archiv im Manifest steht; Installationen, die vor der Unterstützung dieser Plattform gebaut wurden, müssen einmal manuell ersetzt werden.

Kontenanmeldung oder Gerätekonfiguration sind nicht erforderlich.

Für die Erstinstallation des Agent selbst (Programm, private Konfiguration und Betriebssystem-Autostart) empfiehlt sich unter Linux, macOS und Windows remote-agent install / remote-agent uninstall; siehe platforms.md. Dieser Befehl benötigt keinen Netzwerkzugriff; Kopplung bleibt ein eigener Schritt. Sobald eine Version mit install auf dem Rechner liegt, können spätere Aktualisierungen update self oder auf unterstützten Plattformen die automatische Aktualisierung verwenden.

--check vergleicht die SHA-256-Metadaten der Programme aus dem Manifest ohne Archivdownload. Fehlen diese Metadaten, wird das Archiv heruntergeladen und geprüft. Hashes unterscheiden Entwicklungsbuilds gleicher Version; die Prüfung verändert nichts. Die Installation verhindert Downgrades und prüft Version, Größe und Hash des Programms.

Die Standardquelle ist https://r2.ivjn.us (die öffentliche R2-Domain für downloads/). --source https://your-mirror.example/releases wählt einen vertrauenswürdigen Spiegel mit derselben Struktur für downloads/manifest.json und Archive. GitHub Releases (mbcc2006/remote-control releases) veröffentlichen dieselbe Klasse von Desktoparchiven als zusätzlichen Downloadkanal. Sie ersetzen nicht das Websiteformat; die Selbstaktualisierung verwendet weiter r2.ivjn.us, sofern --source nicht auf einen Spiegel mit downloads/manifest.json zeigt. Ausschließlich HTTPS wird akzeptiert, Weiterleitungen werden abgelehnt und Kontotokens werden nicht gesendet. Der Archivname wird anhand von Betriebssystem und Architektur gewählt; Größe und SHA-256 werden gegen das HTTPS-Manifest geprüft und nur der exakt passende Programmeintrag extrahiert. Desktopclients prüfen zuerst downloads/manifest.json.sig mit eingebauten öffentlichen Ed25519-Schlüsseln. Fehlende Signaturen, veränderte Bytes oder unbekannte Schlüssel führen zur Ablehnung. Spiegel müssen Manifest und Signatur unverändert ausliefern; die Signatur muss vor der Einführung von Clients mit Signaturpflicht veröffentlicht werden.

Vor Installation muss das neue Programm eine zeitlich begrenzte --version-Prüfung bestehen. Eine benachbarte .update.lock-Datei serialisiert Aktualisierungen; das aktuelle Programm wird erneut geprüft, um gleichzeitigen Austausch zu erkennen. Nur das Programm und seine Aktualisierungs-/Sicherungsdateien werden verändert. Geräte-IDs, Zugangsdaten und Konfiguration bleiben erhalten.

Unter macOS muss das heruntergeladene Programm vor der Versionsprüfung zusätzlich codesign --verify --strict bestehen. Veröffentlichte Signatur und Bytes bleiben beim Austausch erhalten, damit spätere Hashvergleiche stabil sind.

Das bisherige Programm bleibt als <executable>.previous erhalten. Stoppen Sie bei Bedarf den Agent und stellen Sie diese Datei am ursprünglichen Programmpfad wieder her. Unter Windows wird das geladene Programm vor der Installation des Ersatzes zur Sicherung umbenannt; bei Installationsfehler wird der ursprüngliche Name wiederhergestellt.

Nach erfolgreichem remote-agent update self (ohne --check) versucht der Updater, den laufenden Agent neu zu starten, damit die neue Programmdatei geladen wird: Unter Linux (glibc und musl) führt er systemctl restart remote-agent, dann systemctl --user restart remote-agent und, falls /etc/init.d/remote-agent existiert, rc-service remote-agent restart (OpenRC) aus; ist nichts davon verfügbar, startet er andere remote-agent-Daemons per SIGTERM mit ihren bisherigen Argumenten neu. Unter Windows (x64 und arm64) startet er die geplante Aufgabe RemoteAgent neu, mit Rückfall auf Prozessebene. Unter FreeBSD/NetBSD führt er das von remote-agent install --system installierte rc.d-Skript remote_agent restart aus und meldet sonst, dass ein manueller Neustart nötig ist. Ist der aktualisierende Prozess selbst der Daemon (Argumente nicht update self), ersetzt er sich unter Unix per exec (PID bleibt für Supervisoren erhalten) bzw. startet unter Windows einen losgelösten Ersatzprozess. remote-cli update self startet nie einen Agent neu. Statuszeilen melden, ob der Neustart über systemd, OpenRC, rc.d, eine geplante Aufgabe oder einen neuen Prozess erfolgte oder nicht möglich war (das Update selbst ist trotzdem erfolgreich). Mit den Rechten des Installationseigentümers ausführen; der Updater erhöht keine Rechte. Beim Neustart protokollierte Befehlszeilen schwärzen --token-Werte. Läuft noch ein früherer Windows-Agent aus der Sicherung, diesen vor dem nächsten Update neu starten.

Automatische Aktualisierung des Desktop-Agent-Daemons

Der laufende Agent-Daemon (kein einmaliges update self) prüft regelmäßig dasselbe Website-Manifest und aktualisiert sich, wenn sich das veröffentlichte remote-agent-Programm im Hash unterscheidet. Standardverhalten:

• Standardmäßig aktiviert auf unterstützten Desktopbuilds (Windows x64/arm64 / Linux x64/arm64 glibc und musl / macOS arm64 / FreeBSD und NetBSD x64/arm64).
• Deaktivierung über REMOTE_AUTO_UPDATE=0 (auch false / no / off), JSON-Konfiguration "auto_update": false oder CLI --auto-update false.
• Erste Prüfung etwa 90 Sekunden nach Start, danach ungefähr alle 12 Stunden, nicht bei jedem Heartbeat.
• Fortschritt wird deutlich protokolliert; Gerätetokens gelangen niemals an das Update-CDN.
• OpenWrt (auch ein musl-Archiv auf einem OpenWrt-Host) überspringt Desktop-Auto-Updates; Android nutzt seinen eigenen OTA-Weg. Nicht zugeordnete Architekturen wie Intel-Mac oder 32-Bit-ARM liefern einen Fehler „kein Release-Archiv“ und können nicht automatisch aktualisieren.

Ferngesteuerte Aktualisierung (Operator → Gerät)

Operatoren mit gewöhnlicher Gerätesitzung (dieselben ACLs wie OpenExec) können ein Onlinegerät zur Prüfung oder Installation einer Aktualisierung auffordern:

Protokoll (WebSocket-JSON):

• OperatorUp::update_device { session_id, device_id, check_only, source? }
• Exchange → DeviceDown::update_req
• Gerät → Fortschrittsmeldungen DeviceUp::update_status / OperatorDown::update_status mit phase: checking | downloading | applying | up_to_date | available | applied | error

Konsole: in den Gerätedetails Nach Updates suchen / Update ausrollen.

CLI, entsprechend anderen Gerätesitzungsoperationen:

remote-cli device update <device_id> --check
remote-cli device update <device_id>
remote-cli device update <device_id> --source https://r2.ivjn.us

Bei aktiviertem LAN bildet die LAN-Steuerung update_device genauso ab wie andere open-*-Nachrichten von OperatorUp.

OpenWrt und andere nicht unterstützte Agents liefern eine eindeutige Phase error, statt ein falsches Artefakt zu installieren. Windows arm64, Linux musl, macOS Apple Silicon und FreeBSD/NetBSD nutzen denselben Desktop-Archivpfad wie Windows x64 und Linux glibc.

Android-Agent-OTA

Die Android-Agent-APK (remote-agent-android.apk auf der Website) kann sich über dasselbe HTTPS-Manifest aktualisieren:

Öffnen Sie im Agent Einstellungen → Nach Updates suchen, um manuell zu prüfen. Die Prüfung lädt und verifiziert die APK; bei verfügbarem Update ist eine separate Bestätigung erforderlich, bevor der Android-Installer geöffnet wird.

• APK herunterladen, Bytes + SHA-256 prüfen und versionCode sowie Paketname mit der installierten App vergleichen. Neu gebaute Versionen mit gleicher Versionsnummer, aber anderem Hash können ebenfalls installierbar sein.
• Installation über PackageInstaller. Die App deklariert REQUEST_INSTALL_PACKAGES. Beim ersten OTA muss der Benutzer möglicherweise „Unbekannte Apps installieren“ für Remote Agent in den Systemeinstellungen erlauben und anschließend den angezeigten Systeminstaller bestätigen.
• Ein Installationsstart liefert available mit einer Meldung über die ausstehende Installation, nicht applied. Der private Installer-Callback öffnet die Systembestätigung. Wiederholte Anfragen für dieselbe ausstehende APK verwenden dieselbe Sitzung; fehlgeschlagene und veraltete Selbstaktualisierungssitzungen werden verworfen. Prüfen Sie installierte Version und Hash nach Wiederverbindung des Agent.
• Während AgentService läuft, erfolgen automatische Prüfungen in einem ähnlichen Intervall.
• Remote-update_req wird vom nativen Agent verarbeitet, der die APK-Steuerbrücke aufruft (action: ota_update).
• Appprivater Speicher (Geräte-ID / Token) bleibt beim Paketaustausch erhalten; MY_PACKAGE_REPLACED startet die Verbindung bei aktivierter Funktion weiterhin neu.

Rust Agent/CLI/Exchange, Browser-Erweiterung, Android-Apps und Web-Konsole verwenden gemeinsam Version 0.1.27. Versionen künftig zusammen erhöhen; Android versionCode ist 30. Vor dem Paketbau python scripts/check-release-versions.py ausführen.

Aktualisierung der Android-Konsole

Die native Konsole besitzt eine eigene Schaltfläche Einstellungen → Nach Updates suchen, die vor und nach Anmeldung verfügbar ist. Sie liest das öffentliche Website-Manifest ohne Kontozugangsdaten und vergleicht den installierten Build mit dem veröffentlichten versionCode. Fehlen Build-Metadaten im Manifest und stimmen Marketingversionen überein, bietet sie einen Download an, ohne zu behaupten, die installierte App sei aktuell.

Installationspaket herunterladen öffnet die Website-APK im Browser; schließen Sie die Installation über Androids Bestätigungsbildschirm ab. Damit wird die Konsole auf dem aktuellen Telefon aktualisiert. Update-Steuerelemente einer Gerätedetailseite betreffen weiterhin jenes entfernte Gerät.

„Nach Updates suchen“ in der Konsole (gemeinsamer Ablauf)

Die Gerätedetails bieten nur noch eine Aktion „Nach Updates suchen“. Zunächst wird update_device { check_only: true } gesendet:

• up_to_date → „Bereits aktuelle Version x.y.z“ anzeigen.
• available → „Aktuell → Neu (Größe)“ anzeigen. Der Benutzer wählt „Update ausrollen / Später“. Nach Bestätigung wird check_only: false gesendet und Fortschritt und Ergebnis werden angezeigt.
• Meldet Android nach dem Ausrollen „Installation pending …“, wird auf die nötige Systembestätigung am Gerät hingewiesen.
• Bei Offlinegeräten und Browsergeräten wird der Grund direkt angezeigt; bei nicht unterstützter Plattform „Dieses Gerät unterstützt keine Fernaktualisierung“.

Ergebnisnachrichten enthalten current <版本> und size <字节> bytes.

Siehe außerdem docs/watchdog.md im Repository für den optionalen Verfügbarkeits-Watchdog (--watchdog, REMOTE_WATCHDOG=1).

Die Android-Diagnose zeigt das letzte automatische Update mit Zeitstempel auch ohne READ_LOGS. Feste Meldungen unterscheiden HTTP-Status, DNS, Zeitüberschreitung, TLS, Manifest, APK-Größe/Hash und Installationsberechtigung. Dieselbe sichere Meldung erscheint mit dem Tag RemoteAgentOTA in logcat; vollständige Gerätelogs benötigen weiterhin READ_LOGS. URLs, Pfade und Zugangsdaten aus Ausnahmen werden nicht übernommen.