Référence des librairies en bash – suite

La mise en place de la Référence des librairies en bash est fonctionnelle. La deuxième version de cette librairie est en ligne ici :

http://bachue.nebule.org/l/a3f3211a21174f7a4d719a8d0db08777dd8fb53742816440461a337ab5ea0b5d

Notamment, on voit bien apparaître en dernier les liens f et u. Extrait simplifié :

nebule/liens/version/1.1
4a778c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_5d5b09f6dcb2d53a_8e2adbda190535721
e6d529.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_5d55e03f2d47d270_0
44451c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_92127d432cc786d8_5312dedbae053266a
b98a1c.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_204159611b85c906_31e415a2fb3a47fd1
869b43.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_7931aa2a1bed8554_8b2520354f930f569
e37c40.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_c97550ce8213ef5c_9c3b5b12eb4e6aa7f
dafba8.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_0b8efa5a3bf10441_3dbea4b46d525a78d
d32916.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_535fa30d7e25dd8a_4ad634a7140931341
b8a946.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_9f14025af0065b30_3aa88d2c571cd17c3
8babc4.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_8527a891e2241369_9520b18653418ae08
aa975b.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_23d78c3b5451a304_b5a33ef345fb537a3
a0ac39.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_aa4e255307ea7ff2_940c75a60c14a24e5
bed805.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_89c4ec9f6b3f1086_fd7d447334feb3d03
d678fc.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_a8d605ad6b35649a_a5e056d51490d9b34
a7c90b.sha256_19762515dd804577f_2013-05-03T23:35:15_l_a3f3211a21174f7a_594d1ede91cf77b7_e207a4ac0f703d21d
2ae0ea.sha256_19762515dd804577f_2013-05-03T23:35:13_u_13664cda947381d6_a3f3211a21174f7a_0
032638.sha256_19762515dd804577f_2013-05-03T23:35:13_f_2d0468b3153a1a43_a3f3211a21174f7a_0

Référence des librairies en bash

L’entité bachue commence sont rôle de diffusion de logiciels signés.

Le tout premier est logiquement la librairie nebule en bash puisque c’est l’implémentation la plus avancée à ce jour.

Déploiement

Un objet dédié contenant « nebule/bachue/reference/bash », de hash 2d0468b3153a1a43861ada08cc0a209df138f581df61b8ebc4cf022ee3d83aef, permet de suivre l’évolution des version successives de la librairie. Pour cela, un lien de type f est fait entre cet objet et les objets successifs contenants les différentes versions de la librairie.
Un autre lien de type u est fait directement entre deux versions successives de la librairie.

Annulation

Si une version de la librairie doit être annulée, il y a plusieurs méthodes possibles qui aboutissent à ce résultat :

  1. La première méthode est de déployer une nouvelle version de la librairie et de faire un lien de type u entre la version à annuler et la nouvelle version. Normalement, toutes les entités devraient ainsi mettre à jour leur copie de la librairie avec la nouvelle version, ce depuis la version à annuler ou depuis une version antérieur.
  2. La seconde méthode est d’annuler le lien de mise à jour (type u) avec un lien de type x. Dans ce cas, toutes les entités avec la version de librairie à annuler devraient ainsi mettre à jour leur copie de la librairie vers la version précédente en attendant une nouvelle version. Les entités avec une version antérieur de la librairie s’arrêteront naturellement à la version précédent la version à annuler, en attendant aussi une nouvelle version.
  3. Une troisième solution pourrait être d’ajouter un lien de type u en sens inverse, c’est à dire entre la version de la librairie à annuler et la version précédente. Cependant, cela crée une boucle dans les liens de mises à jour d’un objet avec tous les risques de boucles infinies à gérer que cela entraîne. C’est une solution similaire à la deuxième solution.

dans tous les cas, par sécurité on peut demander la suppression de l’objet contenant la librairie à annuler avec un lien de type d.

La seconde méthode me paraît plus hasardeuse dans le sens où elle nécessite une régression dans la mise en application des versions de la librairie. Cependant elle à le mérite de pouvoir répondre immédiatement à un problème sans attendre la mise en place rapide d’une nouvelle version.

Attention, la version actuelle de la librairie ne tient pas encore compte des liens de type u, x et d. Ce développement devrait arriver assez rapidement pour couvrir ce besoin de gestion des références de logiciels.

Ralentissement des échanges à débit constant

Je commence à voir ressortir un problème que je ne pensais pas avoir à régler si tôt.

Le nombre d’objets augmente, et avec, les liens associés aussi. Or lorsqu’un robot par exemple synchronise les liens d’un objet pivot, que l’on peut plutôt appeler un nÅ“ud, il télécharge systématiquement l’intégralité des liens… et vérifie leurs signatures.
Tant qu’il n’y en avait pas beaucoup, ça ne se sentait pas trop sur le temps de synchronisation. Mais ça commence à se voir aujourd’hui sur certains objets.

Une des solutions serait de voir si le lien est déjà connu. Cela oblige à parcourir l’intégralité des liens d’un objet qui justement peut en contenir beaucoup. On va gagner à court terme sur le traitement des liens. Mais on continue à télécharger des liens inutilement.
Et que ce passera-t-il lorsque la recherche de la présence du lien sera plus longue que la vérification de sa signature?
Bref, cela ne fait que reporter le problème à plus tard…

Il faut résoudre ce problème de façon plus élégante. Cela peut être fait en demandant les liens après un lien particulier, le dernier que l’on connaît déjà.
Cela oblige à implémenter la fonction côté entité, mais aussi côté serveur. Or la façon dont les serveurs web délivrent les liens et objets ne se pas prête à ça. Il faut leur ajouter un peu plus d’intelligence.

D’un autre côté, la vérification si le lien est déjà présent est réalisée juste avant de l’ajouter à un objet… On aura aussi un problème à résoudre à cette étape là…

Hash et type des objets – suite

Suite à la décision de modifier deux objets de base niveau, hash function et mime-type, les premières répercussions ont été faites sur puppetmaster, cerberus et kronos.

De fait, les premiers liens de type x ont été générés. C’est à dire que ce sont les premiers liens qui permettent la suppression d’autres liens précédemment créés.

Cela se voit sur le graph de l’objet entité de puppetmaster :

C’est un peu fouillis parce que le précédent lien supprimé est remplacé par un nouveau lien dont l’objet meta est différent. Il faudra améliorer le tracé de ces liens…

Problèmes en cours

Deux problèmes apparaissent avec le chronographe :

1/ La gestion du suivi des événements dans le temps via l’objet "nebule/objet/entite/suivi" et dérivés n’est as optimale. La période de temps exponentielle donne satisfaction même si elle pourrait être remplacée par une fonction beaucoup plus linéaire que le calque sur le découpage humain du temps (seconde, minute, heure, jour, mois, année). Le problème vient surtout que les caractéristiques des objets "nebule/objet/entite/suivi" et dérivés sont elles-même déplacées d’un objet à l’autre et ne sont plus directement disponibles pour l’objet d’origine.

2/ Je songe à remplacer l’objet "mime-type" par "nebule/objet/type", et l’objet "hash function" par "nebule/objet/hash". Cela implique de corriger une grande partie des scripts déjà en places. A voir…

Premier lien entre deux entités

Pour les besoins de l’expérience 4, les deux entités suivantes ont été liées :
975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5
bca2c25e6564af173a65bf88b8bb1f91cb9c4f5e9ddaf96b8775206543be56c8

La première entité est gérée par un humain, la seconde par un robot. Ce robot à besoin de savoir à quel endroit il peut télécharger les objets et liens de l’autre entité.

Continuer la lecture de Premier lien entre deux entités

Implémentation de liens sécurisés

Une première implémentation en shell bash a été réalisée pour la lecture et l’écriture de lien sécurisés.

Ces liens sont dits sécurisés parce qu’ils sont signés par une entité, et donc leur intégrité et leur provenance peuvent être vérifiés. Si la signature est invalide, ils sont simplement ignorés.

Voir l’implémentation de référence en bash.

Exemple de résultats (empreintes tronquées à 16 caractères) :
sha256:03e7785a6-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-970bdb5df1e79592-93d4a5f3ef1fc5c8
sha256:2ec7df2b9
-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-7c512aaa1c5e3837-a6b4edb371e864e4
sha256:86d8d0f2f
-975571a8a470a6d9-20120914182240-F-6a4b7f1100b87044-975571a8a470a6d9
sha256:2c7911d50
-975571a8a470a6d9-20120914182240-L-975571a8a470a6d9-37d22e047bd0173f-703c4a9a2573f76a
sha256:90952b31d
-975571a8a470a6d9-20120914182241-L-975571a8a470a6d9-69eb5187e4469dfd-93d4a5f3ef1fc5c8
sha256:3ed5b8f4c
-975571a8a470a6d9-20120914182242-L-975571a8a470a6d9-6bf6ae23819cd0d1-0e87632cd46bd490
sha256:0626480c2
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4b9a7f50c0bb198c-911f9ec89c20f340
sha256:51b955e0b
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-3514acf61732f662-5ef523ac47dae4aa
sha256:01bcc6d09
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-8527a891e2241369-b5977b836b445eaf
sha256:58a62c5ab
-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4ec9599fc203d176-dc80905e9df6dac2
sha256:bf51f9067
-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-785f3ec7eb32f30b-28cdd20eaf134a05
sha256:553af0cc7
-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-aea92132c4cbeb26-9d64d711a2a1123e
sha256:162bfc0c5
-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-caa1aedb2a6ce96b-c0f059214d078968

Début de l’expérience 3

L’expérience 3 est lancée.

Introduction

Cette nouvelle expérience doit permettre de gérer des objets privés, c’est à dire chiffrés.

Aujourd’hui, il est difficile d’exploiter des fichiers chiffrés sans devoir au préalable les déchiffrer. La messagerie est mieux logée puisque avec des certificats ou des clés PGP il est possible de lire mais aussi d’écrire nativement des messages.

En attendant de pouvoir nativement lire et écrire des objets chiffrés, il faut exploiter plusieurs capacités des liens. Il faut commencer par gérer la création d’un objet non chiffré (L), le mettre à jours vers sa version chiffrée (U) et supprimer le fichier en clair (D).

La suppression de l’objet en clair ne signifie pas la suppression de ses liens. Ainsi, si celui-ci est récupéré ailleurs, étant déjà marqué d’un lien de suppression, il sera automatiquement supprimé de nouveau. Les liens étant publics, la suppression va se propager entre entités de confiance.

Fin de l’expérience 2

L’expérience 2 est terminé. Elle restera néanmoins comme base d’objets et de liens pour la suite.

Conclusions de l’expérience :

Premier constat, déjà vu avec la première expérience, le nombre de fichiers tient bien dans un répertoire sans provoquer de ralentissement notoire. L’affichage est plus lent parce que le résultat passe par le réseau, mais la consultation d’un fichier particulier n’est pas visiblement plus lente. Par contre, difficile de traiter dans un shell bash une boucle avec autant de fichiers. La commande rm * ne marche plus avec une erreur disant qu’il y a trop d’arguments. Il faut la relancé avec moins de fichiers, par exemple rm a* .

La représentation sous forme de texte des liens est le minimum. Ca fait un peu un effet Matrix avec tous ces chiffres. Mais si on peut naviguer d’un objet à un autre, ce n’est pas très lisible et il faut la pratiquer pour s’y retrouver. Difficile de savoir du premier coup d’œil où on est ou quel est le type d’objet.

Certains objets ont une très grande quantité de liens. C’est impossible à afficher. Est-ce vraiment utile d’avoir un affichage complet de ceux-ci justement? N’est-il pas préférable dans certains cas de n’afficher que les derniers? Voir de n’afficher par défaut que sur certains critères? Ceci oblige à mettre en place une consultation des objets plus fine.
Dans cette expérience, tous les objets ont été liés sur une courte période de temps, de l’ordre de quelques heures. Mais en fait, les objets manipulés ont été créés sur plusieurs années. Ne faut-il pas donner par défaut les liens sur une période de temps défini, et de permettre de récupérer des liens sur des périodes de temps plus grandes moyennant une plus grande latence?

Quel valeur donner à un objet?
Peut-on se baser sur le nombre de liens, auquel cas des objets, comme 77d626eb24d2bae8391953237c40f058 qui contient « mime-type », deviennent des super stars? Or cet objet par exemple est (presque) toujours un objet méta et n’est donc jamais source d’un lien.

Et le plus important : ça marche !