Le site arthur.bebou.netlib.re - retour accueil
git clone git://bebou.netlib.re/arthur.bebou
Log | Files | Refs |
commit 77d1f5ea32d4b7b559895df9645b3ee2e4fe43ab parent d55d9088db2aca7bd3f2902184477745f8cae3b0 Auterice: Arthur Pons <arthur.pons@unistra.fr> Date: Mon, 10 Jun 2024 14:52:35 +0200 Avancées article des services Diffstat:
| M | contents/services-sobres/index.sh | | | 147 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------- |
1 file changed, 134 insertions(+), 13 deletions(-)
diff --git a/contents/services-sobres/index.sh b/contents/services-sobres/index.sh @@ -51,10 +51,10 @@ différentes de services mais j'ai le sentiment que dans l'ensemble quelques caractéristiques restent assez constantes. Premièrement le cadre technique dans lesquels ils s'inscrivent est, en 2024 et ce depuis des années, presque toujours le web. Deuxièmement ils semblent vouloir, parfois volontairement, tenir au -maximum à distances les personnes utilisateur·ices du fonctionnement interne du -service. La première pose des questions de soutenabilité pour des raisons mille -fois évoquées sur ce blog bien que l'on puisse déjà drastiquement optimiser -cette variable en faisant du web "sobre" et pour peu que l'on y évolue avec un +à distance les personnes utilisateur·ices du fonctionnement interne du service. +La première pose des questions de soutenabilité pour des raisons mille fois +évoquées sur ce blog bien que l'on puisse déjà drastiquement optimiser cette +variable en faisant du web "sobre" et pour peu que l'on y évolue avec un outillage radicalement différent de celui majoritaire. La seconde va à l'encontre de l'utopie technique rêvée à Katzele dans laquelle la ligne de démarcation entre celleux qui détiennent et savent manipuler les outils et @@ -67,14 +67,21 @@ sérieusement entrepris d'interfacer mes outils via du web. Je privilégiais le fait de faire des ateliers, des formations, des démos et des articles associés pour distribuer le code localement sur les machines des personnes intéressées, propager les idées et inciter les personnes à faire leurs propres versions quand -elles le peuvent. Évidemment la viabilité de cette stratégie est certainement -corrélée à la complexité des idées et du code en question. Plus l'outil est -complexe plus il sera simple et intéressant temporellement pour moi d'investir -une fois du temps dans une interface web et dire aux personnes "va simplement -sur telle url" plutôt que de dupliquer l'outil ou ses variantes n fois sur n -machines de n copaines. - -### Mais l'idée fera son bout de chemin +elles le peuvent. + +Évidemment la viabilité de cette stratégie est certainement corrélée à la +complexité des idées et du code en question. Plus l'outil est complexe plus il +sera intéressant pour moi d'investir une unique fois du temps +dans une interface web et dire aux personnes "va simplement sur telle url" +plutôt que de dupliquer l'outil ou ses variantes n fois sur n machines de n +copaines. De la même manière, la pertinence de la critique est corrélée à +l'écart qu'il existe entre la simplicité du service rendu et la complexité de +son implémentation technique. C'est pour cela que les services implémentés +jusque là sont simples et requiert peu d'interactions avec l'utilisateur·ice. +C'est aussi parce que je n'ai pas l'envie ni le temps de faire des choses +compliquées. + +### Mais l'idée fera tout de même son bout de chemin Et pourtant, pour de multiples raisons que je n'ai pas audité en profondeur, les personnes sont généralement bien plus enthousiasmées par l'idée d'avoir un @@ -97,7 +104,121 @@ l'outil en ligne de commande en local. ## Quelle forme pour ces services ? +L'objectif est de minimiser au moins : + + * La dépendance à une connection internet + * nombre de dépendances + * l'instabilité de ces dépendances + * nombre de lignes de codes de l'outil et des dépendances + * nombre de personnes dans les projets de ces dépendances[^4] + +En permettant : + + * l'interopérabilité de l'outil avec des interfaces textuelles et cli + +### Communiquer sur internet + +Sur internet les machines communiquent entre elles via des socket. +Un moyen simple de créer des sockets est d'utiliser un outil fait pour qui +pourra les ouvrir ou écouter dessus. `netcat-openbsd` en est un exemple. +Il a l'avantage d'être relativement simple, ne faisant "que" 2340 lignes de C, +dont le fichier principal a été édité par une vingtaine de personne depuis +25 ans. Sans faire de revue plus détaillée[^5] j'en conclu que c'est un logiciel +suffisamment stable fonctionnement et techniquement pour assurer une bonne +soutenabilité. La documentation est raisonnable et présente même quelques +exemples[^6]. Par exemple, pour communiquer à un serveur web, nc permet de faire +passer tel quel un header HTTP et de recevoir la réponse : + + $ nc bebou.netlib.re 80 + GET / HTTP/1.1 + Host: arthur.bebou.netlib.re + + HTTP/1.1 200 OK + Server: nginx/1.22.1 + Date: Mon, 10 Jun 2024 12:15:14 GMT + Content-Type: text/html + Content-Length: 5940 + Last-Modified: Wed, 05 Jun 2024 17:41:29 GMT + Connection: keep-alive + ETag: "6660a349-1734" + Accept-Ranges: bytes + + <!DOCTYPE html> + <html lang="fr"> + <head> + <title>Unix et environnement ?</title> + <link rel=stylesheet href="/style.css" /> + <meta charset="utf-8"> + <meta name="viewport" content="width=device-width,initial-scale=1.0"> + <meta name="description" content="Un blog au sujet de la culture Unix redirigée vers la diminution de l'impact environnementale du numérique" /> + <meta name="author" content="Arthur Pons" /> + <link rel="icon" href="/favicon.png" /> + [...] + +Au passage on voit que c'est côté serveur web qu'est géré la partie +"virtual-hosting" qui, sur la base de la valeur du `Host` renverra tel site +plutôt qu'un autre. + +Cet exemple qui paraîtra trivial pour les personnes ayant commencé à faire de +l'informatique il y a plus de vingt an et un peu magique pour la plupart des +autres[^7] met quelque chose en lumière : Il n'y a rien de magique dans la façon +dont les machines parlent entre elles via des protocoles. D'ailleurs n'importe +quoi peut s'échanger entre deux sockets. Le manuel nous enseigne que (traduit de +l'anglais) : + +> Il est assez aisé de construire un modèle client/serveur très simple +> avec nc. Dans une console écoutez sur un port donné. Par exemple : +> +> $ nc -l 1234 +> +> nc attend une connection sur le port 1234. Dans une seconde console (ou une +> seconde machine) connectez vous à la machine et le port correspondant : +> +> $ nc -N 127.0.0.1 1234 +> +> Il devrait dorénavant y avoir une connection établie entre les deux ports. +> Ce qui est tapé dans la seconde console sera concaténé à la première et +> vice-versa. + +Admettons que l'on souhaite que ce que l'on tape dans la première console soit +traité d'une manière ou d'une autre et nous revienne. Plusieurs versions de +netcat proposent une option `-e` qui passe les données reçues à un script tier +pour traitement. Ce n'est pas le cas de netcat-openbsd, il faudra donc trouver +un subterfuge. Ca tombe bien, il nous est donné dans le manuel : + +> Il n'existe pas d'option `-c` ou `-e` dans ce netcat mais vous pouvez toujours +> exécuter une commande après qu'une connection ait été établie en redirigeant +> des descripteurs de fichiers. Attention, ouvrir un port et laisser n'importe +> qui exécuter des commandes arbitraires sur votre serveur est DANGEREUX. Si vous +> avez réellement besoin de le faire voici un exemple : +> +> Côté serveur : +> +> $ rm -f /tmp/f; mkfifo /tmp/f +> $ cat /tmp/f | /bin/sh -i 2>&1 | nc -l 127.0.0.1 1234 > /tmp/f +> +> Côté client : +> +> $ nc host.example.com 1234 +> $ (shell prompt from host.example.com) + +L'example donne carrément un shell interactif à toute personne qui se connecte. +C'est effectivement très dangeureux mais en plus ce n'est pas ce que l'on +cherche à faire. + +### Exécuter des commandes à distance + +Le serveur est déjà équipé des commandes `conjuguer`, `synonyme` etc. On +cherche, en se basant sur ce que l'on a appris précédemment, à implémenter le +minimum nécessaire sur le serveur pour rendre ces commandes disponibles à +distance de manière non authentifiée et sécurisée. L'idée est que la +construction de services sous cette forme ne nécessite presque rien de plus que +de faire fonctionner les commandes associées en local. Contrairement + [^1]: sur debian faire `sudo apt install netcat-openbsd` si vous ne l'avez pas déjà. En réalité tout outil permettant de se connecter à un port sur une machine distante. `socat` fonctionne, `telnet` aussi etc. [^2]: article plus très à jour par rapport à ce que je fais aujourd'hui mais passons [^3]: surtout quand on parle de sobriété dans le numérique, lol. - +[^4]: en écrivant ces lignes je me rends compte qu'ils n'ont rien d'évident. Notamment celle-ci. L'intuition première est que peu de personne = projet simple et facile à maintenir, pleins de personnes = projet complexe et difficile à maintenir. Je pense que cette intuition n'est pas totalement fausse mais il faut envisager d'autres paramètres. Une personne peut, si elle est très productive, construire des logiciels qui ne sont raisonnablement maintenu par la suite que par une équipe de personne (eg Fabrice Bellard avec qemu et ffmpeg). Il est également possible qu'un outil soit créé et maintenu par une seule personne sans être pour autant documenté ou partagée. A moins que cet outil soit très simple sa maintenance posera problème. D'une certaine manière l'existence d'une équipe, et donc de plus de monde, autour d'un outil peut offrir de la résilience en cas de perte d'une personne. Ça n'est probablement qu'en combinant les variables du nombre de personnes actives pour maintenir l'outil, le nombre de personnes connaissant bien son fonctionnement et la documentation associée que l'on parviendrait à dégager un avis pertinent sur le rapport entre personnes impliquées et soutenabilité. Il faudrait également y inclure des variables économiques telles que la pérennité des financements du projet s'ils existent, la popularité des technologies utilisées etc. Bref c'est bien plus compliqué que ce que ces cinq critères de base laissent penser. +[^5]: un jour peut-être +[^6]: oui oui, si vous avez l'habitude des manuels des outils GNU ça paraît fou. +[^7]: je dois avouer que je n'étais pas très bon élève lors de mes études mais je n'ai pas souvenir que l'on m'ait enseigné des protocoles aussi fondamentaux qu'HTTP et SMTP on me faisant expérimenter de la sorte. Tout conservait un aura un peu mystérieuse. On m'a pourtant enseigné TCP dans les détails.