Mise à jour automatique

Le CLI et l'Agent autonome peuvent mettre à jour leur propre exécutable depuis le site de publication sous Windows x64/arm64, Linux x64/arm64 (versions glibc et musl statiques), macOS Apple Silicon et FreeBSD/NetBSD x64/arm64 :

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

L'outil conserve la bibliothèque C de l'exécutable en cours : une version musl n'installe que l'archive musl et une version glibc que l'archive glibc. OpenWrt reste sur opkg/apk même en x64/arm64 : ses paquets ne contiennent pas l'outil de mise à jour par archive, et une archive musl exécutée sur un hôte doté de /etc/openwrt_release refuse la mise à jour automatique. Une plateforme n'est mise à jour que si son archive figure dans le manifeste ; les installations construites avant la prise en charge de cette plateforme doivent être remplacées manuellement une fois.

Aucun compte connecté ni aucune configuration d'appareil n'est nécessaire.

Pour une première installation de l'Agent (exécutable, configuration privée et démarrage automatique système), privilégiez remote-agent install / remote-agent uninstall sous Linux, macOS et Windows ; voir platforms.md. Cette commande ne nécessite pas d'accès réseau ; l'appairage reste distinct. Une fois l'exécutable contenant install installé sur la machine, les mises à niveau suivantes peuvent utiliser update self ou la mise à jour automatique si elle est prise en charge.

--check compare le SHA-256 des exécutables dans le manifeste sans télécharger l’archive. En l’absence de ces métadonnées, l’archive est téléchargée et vérifiée. Les hachages distinguent les compilations de même version ; la vérification ne modifie rien. L’installation refuse les versions antérieures et vérifie version, taille et hachage de l’exécutable.

La source par défaut est https://r2.ivjn.us (domaine public R2 hébergeant downloads/ par défaut). --source https://your-mirror.example/releases sélectionne un miroir de confiance avec la même disposition downloads/manifest.json et les mêmes archives. Les GitHub Releases (versions mbcc2006/remote-control) publient le même type d'archives de bureau comme canal de téléchargement supplémentaire ; elles ne remplacent pas la disposition du site, et la mise à jour continue d'utiliser r2.ivjn.us, sauf si --source désigne un miroir servant downloads/manifest.json. Seul HTTPS est accepté, les redirections sont refusées et aucun jeton de compte n'est envoyé. L'archive est choisie selon le système et l'architecture actuels ; sa taille et son SHA-256 sont vérifiés contre le manifeste HTTPS, et seule l'entrée exacte de l'exécutable est extraite. Avant de faire confiance au manifeste, les clients de bureau vérifient downloads/manifest.json.sig avec les clés publiques Ed25519 intégrées. Une signature absente, des octets modifiés ou une clé inconnue entraînent le refus de la mise à jour. Les miroirs doivent servir le manifeste signé et sa signature sans modification ; publiez la signature avant de distribuer les clients qui l'exigent.

Avant installation, le nouvel exécutable doit réussir une vérification --version à durée limitée. Un fichier voisin .update.lock sérialise les mises à jour, et l'exécutable actuel est revérifié pour détecter un remplacement concurrent. Seuls l'exécutable et ses fichiers de mise à jour/sauvegarde sont modifiés ; identifiants d'appareil, identifiants d'accès et configurations sont préservés.

Sous macOS, l'exécutable téléchargé doit aussi réussir codesign --verify --strict avant la vérification de version. Sa signature et ses octets publiés sont conservés lors du remplacement afin de stabiliser les comparaisons de hachage suivantes.

L'exécutable précédent est conservé sous <executable>.previous. Si nécessaire, arrêtez l'Agent et restaurez ce fichier au chemin d'origine. Sous Windows, un exécutable chargé est renommé en sauvegarde avant l'installation de son remplaçant ; un échec d'installation restaure le nom d'origine.

Après un remote-agent update self réussi (sans --check), l'outil tente de redémarrer l'Agent en cours afin de charger le nouvel exécutable : sous Linux (glibc et musl), il exécute systemctl restart remote-agent, puis systemctl --user restart remote-agent, puis rc-service remote-agent restart lorsque /etc/init.d/remote-agent existe (OpenRC) ; à défaut, il redémarre par SIGTERM les autres démons remote-agent avec leurs arguments précédents. Sous Windows (x64 et arm64), il redémarre la tâche planifiée RemoteAgent, avec un repli au niveau des processus. Sous FreeBSD/NetBSD, il exécute le script rc.d remote_agent restart installé par remote-agent install --system, et indique sinon qu'un redémarrage manuel est nécessaire. Si le processus qui se met à jour est lui-même le démon (arguments autres que update self), il exécute exec vers le nouvel exécutable sous Unix (en conservant le PID pour les superviseurs) ou lance un remplaçant détaché sous Windows. remote-cli update self ne redémarre jamais d'Agent. Les lignes d'état indiquent si le redémarrage a utilisé systemd, OpenRC, rc.d, une tâche planifiée, un nouveau processus, ou s'il a échoué (la mise à jour elle-même reste réussie). Exécutez-le avec les droits du propriétaire de l'installation ; l'outil n'élève pas les privilèges. Les lignes de commande journalisées lors du redémarrage masquent les valeurs de --token. Si un ancien Agent Windows tourne encore depuis la sauvegarde, redémarrez-le avant une nouvelle mise à jour.

Mise à jour automatique du démon Agent de bureau

Lorsque le démon Agent est actif (hors commande ponctuelle update self), il vérifie périodiquement le même manifeste du site et applique une mise à jour si le binaire remote-agent publié diffère, par comparaison de hachage. Par défaut :

• Activée par défaut sur les versions de bureau compatibles (Windows x64/arm64 / Linux x64/arm64 glibc et musl / macOS arm64 / FreeBSD et NetBSD x64/arm64).
• Désactivation avec l'environnement REMOTE_AUTO_UPDATE=0 (ou false / no / off), la configuration JSON "auto_update": false, ou --auto-update false.
• Première vérification environ 90 secondes après démarrage, puis environ toutes les 12 heures, sans vérification à chaque battement de cœur.
• Progression clairement journalisée ; le jeton d'appareil n'est jamais envoyé au CDN de mise à jour.
• OpenWrt (y compris une archive musl sur un hôte OpenWrt) ignore la mise à jour automatique de bureau ; Android utilise sa propre voie OTA. Les architectures non associées, comme les Mac Intel ou l'ARM 32 bits, renvoient une erreur d'archive absente et ne peuvent pas se mettre à jour automatiquement.

Mise à jour poussée à distance (opérateur → appareil)

Les opérateurs disposant d'une session ordinaire sur l'appareil (mêmes ACL qu'OpenExec) peuvent demander à un appareil en ligne de vérifier ou d'appliquer une mise à jour.

Protocole (JSON WebSocket) :

• OperatorUp::update_device { session_id, device_id, check_only, source? }
• Exchange → DeviceDown::update_req
• Appareil → progression DeviceUp::update_status / OperatorDown::update_status, avec phase : checking | downloading | applying | up_to_date | available | applied | error

Console : dans les détails de l'appareil, Vérifier les mises à jour / Envoyer la mise à jour.

CLI, selon le même modèle que les autres opérations de session :

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

Lorsque le LAN est activé, son contrôle associe update_device de la même façon que les autres messages d'ouverture OperatorUp.

Les Agents OpenWrt et autres plateformes non compatibles renvoient une phase error explicite au lieu d'installer un mauvais artefact. Windows arm64, Linux musl, macOS Apple Silicon et FreeBSD/NetBSD utilisent le même chemin d'archive de bureau que Windows x64 et Linux glibc.

Mise à jour OTA de l'Agent Android

L'APK Agent Android (remote-agent-android.apk sur le site) peut se mettre à jour depuis le même manifeste HTTPS.

Ouvrez Paramètres → Vérifier les mises à jour dans l'Agent pour vérifier manuellement. La vérification télécharge et contrôle l'APK ; une mise à jour disponible exige une confirmation distincte avant d'ouvrir l'installateur Android.

• Téléchargement de l'APK, vérification des octets + sha256, comparaison du versionCode et du nom de paquet avec l'application installée (une recompilation de même version avec un hachage différent peut encore s'installer).
• Installation par PackageInstaller. L'application déclare REQUEST_INSTALL_PACKAGES ; à la première OTA, l'utilisateur peut devoir autoriser « installer des applications inconnues » pour Remote Agent dans les paramètres système, puis confirmer dans l'installateur système.
• Le lancement d'une installation renvoie available avec un message d'installation en attente, et non applied. Le rappel privé de l'installateur ouvre l'écran de confirmation système. Les requêtes répétées pour le même APK en attente réutilisent la session ; les sessions échouées ou périmées sont abandonnées. Confirmez la version et le hachage installés après reconnexion de l'Agent.
• La vérification automatique suit un intervalle similaire pendant l'exécution d'AgentService.
• Le update_req distant est traité par l'Agent natif, qui appelle le pont de contrôle APK (action: ota_update).
• Le stockage privé de l'application (identifiant d'appareil / jeton) est conservé lors du remplacement du paquet ; MY_PACKAGE_REPLACED relance toujours la connexion lorsqu'elle est activée.

Rust Agent/CLI/Exchange, extension de navigateur, applications Android et console Web partagent la version 0.1.27. Incrémentez les versions ensemble ; Android versionCode vaut 30. Exécutez python scripts/check-release-versions.py avant de créer les paquets.

Mises à jour de la console Android

La console native possède son propre bouton Paramètres → Vérifier les mises à jour, accessible avant ou après connexion. Elle lit le manifeste public du site sans identifiants de compte et compare la compilation installée au versionCode publié. Si le manifeste ne contient pas de métadonnées de compilation et que les versions commerciales correspondent, elle propose un téléchargement sans affirmer que l'application installée est à jour.

Télécharger le paquet d’installation ouvre l'APK du site dans le navigateur ; terminez l'installation dans la confirmation Android. Cela met à jour la console du téléphone actuel. Les commandes de mise à jour des détails d'un appareil ciblent toujours cet appareil distant.

« Vérifier les mises à jour » dans la console (parcours unifié)

Les détails de l'appareil conservent une seule action « Vérifier les mises à jour » : elle envoie d'abord update_device { check_only: true }.

• up_to_date → affiche « Version x.y.z déjà à jour ».
• available → affiche « actuelle → dernière (taille) », puis propose « Envoyer la mise à jour / Plus tard ». Après confirmation, envoie check_only: false et affiche progression et résultat.
• Si Android renvoie « Installation pending … » après l'envoi, invite à confirmer l'installation système sur l'appareil.
• Pour un appareil hors ligne ou un appareil navigateur, affiche directement la raison ; pour une plateforme incompatible, affiche « Cet appareil ne prend pas en charge la mise à jour distante ».

Les messages de résultat incluent current <版本> et size <字节> bytes.

Voir aussi docs/watchdog.md dans le dépôt pour le watchdog facultatif de disponibilité (--watchdog, REMOTE_WATCHDOG=1).

Le diagnostic Android affiche le dernier résultat de mise à jour automatique avec sa date, même sans READ_LOGS. Des messages fixes distinguent statut HTTP, DNS, délai, TLS, manifeste, taille/empreinte APK et autorisation d’installation. Le même message sûr est écrit dans logcat sous RemoteAgentOTA ; les journaux complets exigent toujours READ_LOGS. Les URL, chemins et identifiants des exceptions ne sont jamais recopiés.