3 choses à savoir sur la planification des mises à jour OTA dans votre homelab

Les mises à jour d’un système étaient relativement simples. Lorsqu’un développeur avait besoin de réviser quelque chose qu’il avait déjà distribué au public, une mise à jour était publiée pour que les gens puissent l’exécuter. Les utilisateurs exécuteraient le programme de mise à jour, permettant aux anciens fichiers d’être remplacés par de nouveaux fichiers et de nouveaux fichiers à ajouter. Même avec ces mises à jour “relativement simples”, il y avait un hic. Que se passe-t-il lorsque l’installation d’un utilisateur est dans un état inattendu ? Que se passe-t-il lorsqu’une mise à niveau est interrompue ? Ces questions sont tout aussi pertinentes maintenant que toutes sortes d’appareils sont en ligne et ont parfois besoin d’importantes mises à jour de sécurité. Aujourd’hui, de nombreuses mises à jour sont fournies sans fil, en direct (OTA), et le potentiel de mauvaises connexions, de perte soudaine de signal ou de perte de puissance peut potentiellement être désastreux pour ce qui devrait être une mise à jour mineure. Ce sont les trois principales stratégies à prendre en compte lors de la planification de la diffusion de mises à jour en direct.

1. Vérification

Le protocole TCP comporte de nombreuses vérifications intégrées, il est donc généralement vrai que lorsque vous envoyer des paquets à un appareil, vous pouvez être sûr que chaque paquet a été reçu intact. Cependant, TCP ne peut pas signaler d’erreurs sur quelque chose qu’il ne connaît pas, c’est donc à vous de vérifier des choses comme :

• Avez-vous envoyé tous les fichiers nécessaires à la mise à jour ? Un appareil ne peut pas recevoir ce qui n’a pas été envoyé en premier lieu.

• Les fichiers reçus sont-ils les mêmes que les fichiers que vous avez envoyés ? À tout le moins, vérifiez les sommes SHA pour vérifier l’intégrité des fichiers.

• Lorsque cela est possible, utilisez signature numérique pour s’assurer qu’un fichier provient d’une source fiable.

• Vous devez vérifier que l’appareil est capable d’appliquer une mise à jour avant d’autoriser le démarrage de la mise à jour. Vérifiez les autorisations et l’état de la batterie avant de vous engager dans une mise à jour et assurez-vous que votre processus de mise à jour annule tout événement utilisateur inattendu, comme un redémarrage programmé ou une mise en veille prolongée.

• Enfin, vous devez vérifier qu’une mise à jour qui prétend s’être terminée avec succès s’est réellement terminée. Vérifiez les emplacements et l’intégrité des fichiers sur le périphérique cible avant d’autoriser la mise à jour à être officiellement marquée comme résolue par le système.

2. Repli et états d’échec

Le pire scénario pour une mise à jour est qu’un appareil reste dans un état défectueux, de sorte qu’il ne peut même pas être utilisé pour continuer une mise à jour interrompue. Dans ce scénario, les fichiers de mise à jour existent sur le périphérique cible, mais le processus a été interrompu. Cela peut laisser un appareil dans un état inconnu, où certains fichiers ont été remplacés par des versions mises à jour, tandis que d’autres n’ont pas été touchés. Dans le pire des cas, les fichiers qui ont été mis à jour sont incompatibles avec les fichiers qui n’ont pas encore été mis à jour, et l’appareil ne peut donc pas fonctionner comme prévu.

Il existe quelques stratégies pour gérer cela. L’étape de mise à jour initiale peut consister à installer une image de démarrage spéciale ou un environnement dédié à la réalisation de la mise à jour et à définir un “indicateur” sur le système pour établir qu’une mise à jour est en cours. Cela garantit que même lorsqu’un appareil perd soudainement de l’alimentation au milieu d’une mise à jour, le processus de mise à jour est redémarré lors du prochain démarrage. Le drapeau signalant une mise à jour réussie n’est supprimé qu’une fois la mise à jour vérifiée.

Une image de démarrage spéciale peut ne pas être possible ou nécessaire, selon la politique de sécurité du périphérique cible et ce que vous mettez à jour. Le principe reste cependant le même. Une fois lancée, une mise à jour doit établir un environnement dans lequel la mise à jour en attente est la seule voie à suivre jusqu’à ce qu’elle soit résolue.

Jusqu’à ce qu’une mise à jour ait reçu l’autorisation de démarrer, un utilisateur (le cas échéant) devrait avoir la possibilité de retarder ou d’ignorer la mise à jour.

3. Additif

Dans de nombreux appareils périphériques et IoT, la base de l’appareil cible est immuable. Les mises à jour ne font qu’ajouter à un état connu d’un système. Des projets comme Fedora Silverblue démontrent que ce modèle peut fonctionner sur de nombreux marchés, de sorte que le luxe pourrait devenir monnaie courante. Jusque-là, cependant, une partie de l’application réussie d’une mise à jour consiste à comprendre l’environnement que vous êtes sur le point d’affecter.

Cependant, vous n’avez pas besoin d’un noyau immuable pour appliquer des mises à jour additives. Vous pourrez peut-être concevoir un système pour utiliser le même concept, en utilisant la mise à jour comme moyen d’ajouter des bibliothèques ou des packages sans réviser les anciennes versions. En tant qu’étape finale d’une telle mise à jour, l’exécutable avec les chemins mis à jour est la seule révision réelle que vous effectuez.

Mises à jour OTA

Le monde est de plus en plus sans fil. Pour les téléphones mobiles, les appareils IoT et informatique de pointe, les mises à jour en direct sont souvent la seule option. La mise en œuvre d’une politique de mise à jour OTA nécessite une planification minutieuse et une prise en compte minutieuse des scénarios improbables. C’est vous qui connaissez le mieux vos appareils cibles, donc planifiez votre schéma de mise à jour bien avant de commencer à coder afin que votre architecture initiale soit conçue pour un OTA robuste et sûr.