Informatique personnelle distribuée

J'ai parfois l'impression de faire des trucs bizarres avec mes ordinateurs. Ou plus exactement, j'ai envie de faire des trucs qui m'ont l'air logiques et naturels, et je suis toute surprise d'avoir l'impression d'être la première à prendre les choses sous cet angle. Alors je me dis que ce n'est pas possible que je sois la première à avoir cette idée, et je me demande sérieusement comment les Gens Normaux sont censés faire.

L'itération présente est sévèrement geek, et la partie de mon lectorat qui n'a aucune idée de ce qu'est un script shell peut sereinement s'arrêter ici, je ne ferai aucun effort pour que ça leur soit accessible. Je rattraperai ça une autre fois, promis.

Le cas de base

Pour faire simple, quand j'ai un ordinateur et que je veux lui faire faire des choses répétitives, j'ai tendance à partir en premier sur le script shell. Pour diverses raisons je fais du shell POSIX de base, mais peu importe, le principe est que pour mon utilisation courante, je programme volontiers des séquences de commandes.

Comme (j'imagine) à peu près n'importe quel administrateur système UNIX, sauf s'il déteste son boulot au point de ne rien vouloir en savoir dans sa vie personnelle.

Les séquences d'opérations à mon initiative, c'est fort pratique, mais il n'est pas si rare que je veille que d'autres choses déclenchent des séquences d'opérations que j'ai choisies. La composabilité qui découle naturellement de la « philosophie UNIX » se traduit par l'existence d'outils qui me permettent d'« accrocher » un script shell à un évènement donné.

L'exemple le plus simple est cron, pour faire quelque chose régulièrement dans le temps. Des outils comme at et anacron le complètent pour affiner les critères temporels. filewatcherd et inotify font quelque chose quand un fichier change.

Le cas distribué

Et puis au fil du temps, mes moyens informatiques croissent, et le nombre d'ordinateurs qui me sont soumis croit également. Il arrive donc naturellement, me semble-t-il, de vouloir qu'un ordinateur fasse quelque chose en réaction à quelque chose qui se passe sur un autre ordinateur.

L'exemple le plus simple est la sauvegarde automatique, où l'émission depuis un ordinateur et la réception sur un autre doivent bien être coordonnées d'une façon ou d'une autre.

Là encore, rien d'extraordinaire pour la boîte à outil UNIX, ssh permet facilement l'exécution d'un script sur un ordinateur à l'initiative d'un autre ordinateur.

Sauf que ssh est un outil un peu trop puissant pour mon goût, au point que j'ai des réticences à ouvrir l'accès de tous mes ordinateurs à tous mes ordinateurs. Il suffirait qu'un méchant trouve une seule brèche dans mon système informatique pour avoir le contrôle total sur tout, et je n'ai pas assez confiance dans mes compétences d'administratrice système pour supposer qu'il n'y a aura jamais de brèche chez moi.

Dans une certaine mesure, on peut s'en sortir avec des contorsions. Par exemple un serveur SSH peut forcer une commande pour une certaine clef, et comme ça la cĺef de Manabiya qui sert pour les sauvegardes de Rebma ne donne pas d'autre accès, et Rebma n'a aucun accès à Manabiya.

Et puis il arrive un moment où les contorsions ne suffisent plus. Pour moi ce moment c'était la propagation des sauvegardes de mon téléphone sur Manabiya vers Ravenholdt, sans que l'éventuelle indisponibilité de Ravenholdt puisse gêner la sauvegarde principale sur Manabiya.

Alors d'accord, j'aurais pu continuer les contorsions pour résoudre ça, mais c'est le point où j'ai voulu arrêter d'envoyer des ordres d'un ordinateur à un autre, mais seulement des messages.

La communication entre machines

Je regarde d'assez loin la domotique depuis que j'ai découvert le concept (je crois que c'était dans un Science et Vie micro des années 1990s), mais ça ne m'a jamais enthousiasmée au point de passer à l'acte. Je crois que j'ai surtout été rebutée par l'impression de n'y trouver que des gadgets flashy alors que j'aurais sauté sur outils simples et composables genre « philosophie UNIX » (genre les trucs que fait Shelly ces jours-ci).

C'est comme ça que j'ai appris l'existence de MQTT, qui a toute la simplicité compréhensible que j'attends des outils dont je m'entoure.

Et puis sur #gcu, semarie m'a branchée sur les pages des Jan-Piet Mens, et j'ai trouvé la solution très séduisante.

En résumé, c'est un protocole très simple, qui a sans doute besoin de couches de plus haut niveau pour être vraiment utile, et donne une sorte de multicast sans le mal de crâne d'ingénieur réseau.

Concrètement, les clients envoient des messages sur des topics, l'un et l'autre étant de simples tas d'octets, et le broker diffuse les messages à tous les clients qui ont souscrit au topic correspondant.

MqttAgent

Il manquait juste un peu de composabilité pour mon goût, alors je l'ai faite moi-même, en collant un interpréteur Lua sur un client MQTT.

Je regrette un peu le mot « agent » dans le climat actuel saturé d'« intelligence artificielle », mais je n'ai pas trouvé mieux avant de me retrouver avec ce nom un peu partout.

C'est un peu comme un mqttwarn, mais je n'avais aucune envie de mettre un interpréteur python dans une de mes sjails.

J'ai entendu des mots assez fleuris envers les langages Go et Lua.

Je trouve que le Go est une alternative intéressante au Python, dont le déploiement est beaucoup plus facile (et qui évite tous les pet peeves qui m'irritent dans ce langage).

Lua a aussi son lot de défauts, mais sur le créneau des scripts shell je le trouve très compétitif, et sa facilité d'intégration avec les primitives du langage hôte le rend très opportun pour cette application.

Applications

Comme je m'y attendais, ouvrir un canal de communication entre mes ordinateurs et les traiter avec la puissance d'un vrai langage de programmation (fût-il Lua) permet de faire beaucoup plus de choses que juste éviter des contorsions.

Mon utilisation personnelle est à l'origine de tous les exemples dans le README de mqttagent, donc je ne vais pas reproduire le code Lua dans ce billet.

Propagation de backups

J'ai un topic pour chaque jeu de données sur chaque ordinateur qui le réplique, par exemple backup/manabiya/rebma pour les données de Rebma qui sont sauvegardées sur Manabiya. J'y mets le temps de réplication et l'éventuelle étiquette (quand ce sont des snapshots ZFS qui sont répliqués), mais c'est juste pour l'humain qui regarde.

Quand Manabiya voit un message backup/ravenholdt/rebma, c'est une confirmation que Ravenholdt est opérationnel, et Manabiya lance le rsync qui pousse les données de mon téléphone vers Ravenholdt.

Et voilà le problème initial résolu en trois lignes, sans contorsion.

Surveillance de backups

Avec un message à la fin de chaque réplication, une variable globale dans l'interpréteur peut compter les réplications qui se sont bien passées, et un timer peut vérifier périodiquement cette variable et alerter s'il en manque.

Je n'avais pas vraiment de surveillance avant, parce que ce n'est pas facile de trouver quelque chose qui fonctionne quand on sait qu'il y a un problème. Par exemple, si l'accès internet de Ravenholdt est coupé, il ne va pas pouvoir faire les sauvegardes qui l'impliquent, mais il ne va pas pouvoir alerter non plus. Donc il faudrait une surveillance séparée, par l'extérieur.

Alors qu'avec le message à la fin d'une réplication qui fonctionne, j'ai facilement et directement une surveillance fonctionnelle des sauvegardes elles-mêmes.

Transmettre des alertes

Je ne l'ai pas encore mis en place, mais il est facile de fournir un client HTTP dans l'environnement Lua, ce qui fait un pont entre les surveillances ci-dessus ou des topics particuliers et des alertes à base de pushover ou d'équivalent, voire de SMS.

Graphique de prise connectée

J'ai une prise connectée qui transmet son statut par MQTT, en bon élément domotique.

Je ne sais pas quelles solutions logicielles sont traditionnellement utilisées dans la domotique, mais mes serveurs ont déjà un µMon que je consulte régulièrement, autant ranger les données dans une autre RRD que je peux voir en même temps.

L'interface

Les trucs automatiques, c'est bien, mais pouvoir garder un œil dessus et éventuellement ajuster des trucs à la main, c'est parfois indispensable.

J'ai pour ça un autre projet, mqttim, qui fait le pont entre mon irssi préféré et l'infrastructure MQTT. Je continue de vérifier tous les matins la liste des sauvegardes qui ont eu lieu pendant la nuit, et ça me dispense de système d'alerte pour l'instant.

Ça manque d'authentification, mais comme le serveur IRC est dans la même jail que mon client IRC, et sur la même machine que le pont, l'accès à ma machine personnelle est une protection qui m'a l'air suffisante.

Le futur

Je pensais que je trouverais plus d'applications pratique avant de parler publiquement de cette infrastructure, mais je continue de penser que la mise en place d'une communication efficace et facile d'utilisation sera rentabilisée assez rapidement en gains de confort.

La prochaine application la plus évidente est la domotique, et autant je ne me sens pas du tout capable de compter sur Home Assistant, autant je serais prête à entretenir un mosquitto qui coordonne des jouets de Shelly et Tasmota, avec de l'intelligence sortie de mon mqttagent.

Je n'ai juste pas encore trouvé de cas concret qui me donnerait envie de faire cet effort : les interfaces vocales m'horripilent au plus haut point, les lumières asservies à la luminosité ou aux capteurs de présence ne me donnent pas l'impression d'améliorer mon confort (et leur côté flashy ne m'intéresse pas du tout), et sorti de là je ne vois même pas quoi automatiser. S'il y a des domotistes qui arrivent sur ces lignes, j'écouterai avec attention et intérêt toutes les idées que j'aurais pu rater.

Une piste plus prometteuse est de partir sur l'owntracks que j'utilise déjà au quotidien pour faire du geofencing, c'est-à-dire déclencher des actions quand mon ordiphone entre ou sort d'une zone géographique (comme l'enregistrement de trace GPS fine, pointer des logs personnels, allumer un ordinateur, etc). Cependant je crois que ça oblige à utiliser l'interface MQTT au lieu de l'interface HTTP, et c'est embêtant parce que certains points d'accès WiFi que j'utilise régulièrement ne laissent pas passer MQTT.

Dans les communications entre ordinateurs, j'aurai aussi un jour la prochaine version de mon site, basé sur des pages statiques servies par un système différent de leur génération. Les changements, qu'ils viennent de commentateurs ou de moi, auront probablement à passer par plusieurs processus, et peut-être plusieurs ordinateurs, ce qui pourrait passer par MQTT (probablement pas pour le contenu lui-même, mais surtout pour les notifications qui font aller chercher les données).

J'aimerais beaucoup un ordinateur en forme de réveil, avec des gros chiffres rouges parce que c'est ce dont j'ai besoin pendant la nuit, et qui aurait des fonctions pratiques comme la désactivation à distance (pour quand on part en vacances trop précipitamment) et l'enregistrement en un appui de bouton de mes heures de coucher et de lever (pour mes statistiques personnelles), voire l'asservissement à un CalDAV pour déterminer quels jours et à quelle heure sonner. Je n'ai pas l'impression que ça existe, et ça a l'air un peu trop compliqué comme premier projet de DIY électronique…

Encore une fois, j'ai déployé l'infrastructure en suivant l'intuition que ça m'ouvrirait plein de possibilités ensuite, mais si vous avez des idées que j'aurais pu rater, vos suggestions seront bienvenues.

Si je me mets à utiliser sérieusement MQTT, au point d'en dépendre, ou au moins que mon confort en dépende, je vais me poser sérieusement la question du point de fragilité qu'est l'unique broker sur Rebma. Même sans compter la malveillance d'un ennemi ou d'une organisation, il suffit d'une mise à jour foireuse ou d'une erreur d'administration système pour tout faire tomber. Il me faudra de la redondance, et MQTT n'a pas l'air construit pour y répondre facilement.

Je suis tombée sur NATS, qui a l'air de généraliser les idées de MQTT avec une délocalisation de la fonction de broker, et qui prétend même être interopérable avec MQTT, pour une transition encore plus facile. Je creuserai ce côté-là, mais a priori ça ressemble exactement à ce dont je rêve (au point d'en être suspect).

Commentaires

Pas de commentaire pour le moment.

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.