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.

Cerberus et la mise en quarantaine d’objets

Une nouvelle entité est mise en ligne.

Cette entité à pour mission de lister les objets à bannir. Ce peut être par exemple du code malveillant.
Il faut bien sûr faire confiance à cette nouvelle entité… et supprimer automatiquement les objets référencés via cet objet particulier :

126520cc2d5453c68d070e80a38bea3c501cb2ef6284ec1edddc34b717739b8d
cerberus/danger‘.

L’entité est en ligne ici : http://cerberus.nebule.org/

Les scripts actuels de nebule ne le gère pas encore, mais ça viendra…

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…

Fin de l’expérience 4

L’expérience 4 est terminé. L’expérience 3 est encore en cours.

Conclusions de l’expérience :

L’entité du robot à été capable de retrouver un emplacement des objets de son entité maître, de synchroniser les liens et de télécharger les objets que l’entité maître lui avait attribué (liens).

L’entité maître ayant ajouté comme localisation le nouvel emplacement généré par le robot, on obtient donc bien un relais.

De plus, s’agissant d’objets en double sur plusieurs emplacement, nous obtenons la base du fonctionnement du P2P, c’est à dire répartition des données à télécharger sur plusieurs serveurs. Il restera cependant à ajouter une fragmentation d’objets pour véritablement permettre le téléchargement d’un objet simultanément sur plusieurs serveurs.

Continuer la lecture de Fin de l’expérience 4

Gestion de programmes

Lors des expériences, il est apparut qu’il était assez facile de diffuser des programmes, dans notre cas des pages web en php, comme des objets à part entière.

Il faut deux choses.

La première c’est qu’il faut une page web de bootstrap (marche pied). C’est cette page qui va déterminer si il existe une page à afficher dans les objets, et la lancer. La page en question doit être un dérivé (lien F) de l’objet « nebule/objet/entite/webaccess/firstofall », et être de mime-type « application/x-php ».

Et il faut que le programme en question puisse se mettre à jour. Ce peut être fait en suivant les liens de mise à jour d’objet (lien U) du programme en question. On peut aussi suivre les nouveaux liens de l’objet « nebule/objet/entite/webaccess/firstofall » d’une autre entité. Ne reste plus qu’à téléchager le nouvel objet et mettre à jour sont propre objet « nebule/objet/entite/webaccess/firstofall ».

Continuer la lecture de Gestion de programmes

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 !

Expérience sur les objets

Je lance une petite expérience de :
– génération d’objets à partir de fichiers existants ;
– génération de metas pour les objets en fonction de leur environnement ;
– manipulation d’objets en fonction de leurs metas par une application.

La description complète de l’expérience se passe ici :
Wiki – Galerie_photo_publique
Cette description évoluera au fil de l’expérience. Celle-ci sera terminé lorsque la conclusion sera rédigée.

Cette expérience n’intègre pas de partie cryptographique.