Arborescence virtuelle

Dans nos systèmes d’information actuels, le rangement des fichiers dans une arborescence est non seulement classique mais fondamentale et souvent incontournable. L’autre forme de rangement est d’utiliser une base de données.

Il est possible avec nebule de simuler une arborescence mais virtuelle et uniquement constituée d’objets et de liens.
CF Wiki РR̩flexion Рanalyse des applications РSyst̬me de fichiers

Un arborescence commence par une racine, par exemple ‘/‘. Dans cette racine on va trouver des fichiers, des sous-dossiers et des fichiers dans les sous-dossiers.
Chaque fichier a nativement un nom ou au pire un identifiant unique. Les fichiers vont avoir en plus un ou des liens pour les positionner dans l’arborescence à un ou plusieurs endroits.
Chaque dossier est constitué de l’objet contenant son nom. Cet objet de nommage est lié au dossier parent par un lien, lui-même relié à son dossier parent… jusqu’à la racine.

Le nom des objets ne pose pas de problème, il risque juste de changer d’une entité à l’autre. Le nom d’un dossier peut par contre avoir deux formes, mais on ne doit en gérer qu’une seule.
Soit le nom d’un dossier ne contient que sont nom et pas l’ensemble de l’arborescence. Dans ce cason peut avoir n’importe quel nom, y compris des noms avec le caractère séparateur de dossiers ‘/’. Mais si on souhaite mettre deux dossiers avec le même nom dans deux branches différentes de l’arborescence, il y a conflit sur le nom et donc mélange des fichiers enfants.
Soit le nom d’un dossier contient l’ensemble de l’arborescence. On résoud les problèmes de conflit. Et on n’accepte pas des noms de dossiers avec le caractère séparateur de dossiers. C’est la meilleur solution.

Comme il est possible que plusieurs entités créent plusieurs arborescences différentes ou en reconnaîssent plusieurs, il faut un objet unique de référence de cette arborescence. L’objet contenant ‘/’ doit dans ce cas être lié à l’objet de référence, et il en est de même pour tous les objets de l’aborescence.
Ainsi, comme pour l’émulation de commentaires dans le blog, les objets on des liens entre eux avec comme contexte un objet de référence. Les mêmes liens peuvent tout à fait être reproduire intégralement ou partiellement avec un autre objet de référence et ne pas entrer en conflit.

On obtient, du fait même de la base nebulisée, des comportements spécifiques sur l’arborescence.
Par exemple dans une arborescence de fichiers d’une société, le chef pose un nouveau fichier dans un sous-dossier. Tout le monde dans la société va voir ce nouveau fichier. Un des employé ‘copie’ le fichier ailleurs dans l’arborescence, tout le monde voit le nouveau fichier. Si il le modifie, il crée un objet de mise à jour et les deux fichiers sont mis à jours. Cela est intéressant puisque tous les emplacements sont tenus à jours mais cela peut déjà poser problème puisque l’on ne voulait peut-être pas tout mettre à jour. Il faut donc bien distinguer la mise à jour et le dérivé.
Prenons un autre cas. Un des employé modifie le nom du fichier créé par le chef. tout le monde voit la modification. Le chef décide d’annuler le nouveau nom, de redonner le nom d’origine au fichier. Tout le monde va voir le fichier revenir à son nom d’origine… sauf peut-être celui qui avait renommé le fichier puisque la gestion sociale des liens va peut-être décider que personne ne peut annuler son opération, même si le chef est son supérieur hiérarchique dans la société.

Cette arborescence virtuelle sera ajoutée pour expérimentation à sylabe. Comme ce n’est pas quelque chose de vraiment natif dans la philosophie de nebule, l’implémentation se fera sous forme d’un module.

On peut ensuite, sur cette base, aller plus loin avec par exemple inotify. Pour un dossier spécifié et ses sous dossiers, tout changement sur un dossier ou un fichier serait immédiatement nébulisé et synchronisé vers un serveur local ou distant.

Avancement

La librairie nebule en bash évolue. Ça faisait longtemps…

Comme un nouveau fichier nebule.env est utilisé par la librairie nebule en php, en place de l’ancien env_nebule.php, il était naturel que ce fichier serve aussi à la librairie en bash. Ce fichier évolue pour intégrer des options spécifiques au bash. Certaines options sont spécifiques au php et d’autres, comme la crypto, sont communes.

Le gros changement ‘est surtout que les options ne sont plus des variables. Il est possible d’extraire directement une option de configuration au moment de l’utiliser, mais il est aussi possible d’en faire une variable, comme avant. C’est cette dernière solution qui est utilisée pour l’instant, par facilité.

Cette nouvelle version de la librairie nebule en bash sera prochainement diffusée par bachue

Avancement

La remise en place des fonctions de la librairie nebule en php orienté objet ainsi que la ré-écriture du bootstrap pour en profiter reprend pleinement.

La résolution du graphe des mises à jours des objets, c’est à dire le suivi des liens de mises à jours, est fonctionnelle. On peut donc maintenant rechercher la dernière version de la librairie ainsi que la dernière version du programme à charger par défaut.
La librairie ayant le minimum fonctionnel pour le bootstrap, elle y a été intégralement copiée. Plus tard, elle sera allégée des fonctions non utilisées. La librairie étant plus modulable, les modules non nécessaires au bootstrap ne seront simplement pas intégrés.

La cible : faire charger la librairie par le bootstrap et le programme par défaut.

Le programme sylabe est fonctionnel sur la librairie actuelle moyennant la conservation des fonctions procédurales. Ces anciennes fonctions seront progressivement transformées pour utiliser les nouvelles fonctions en programmation orienté objet… et/ou supprimées dès que sylabe aura été mis lui aussi à jour. En attendant, il intègre en bas de page les nouveaux compteurs du nouveau bootstrap.

nebule_bootstrap_-_Experimental_-_2014-11-16_10.21.26

Localisation des objets

La possibilité de localiser un objet ou juste une entité me travaille depuis un moment. Même si cela n’a pas d’application aujourd’hui, il est plus logique de faire remonter la possibilité de localisation au niveau de l’objet. Ainsi, si il sera toujours possible de localiser une entité, on peut imaginer soit localiser un objet soit aussi s’en servir pour demander à un robot d’héberger cet objet.

Ainsi, l’objet méta contenant la propriété ‘nebule/objet/entite/localisation‘ est doublé de ‘nebule/objet/localisation‘ pour l’instant et disparaîtra à terme. CF wiki.nebule.org – Documentation – nebule v1.2 – Objets à usage réservé

Les propriétés ‘nebule/objet/entite/webaccess‘ et ‘nebule/objet/entite/webaccess/firstofall‘ sont périmées et dès maintenant supprimées.

Les différentes propriétés ‘nebule/objet/entite/suivi/...‘ sont en sursit.

Changement d’identifiant d’entité

On avait déjà vu qu’une entité pouvait être amenée à changer d’identifiant, donc en fait de clé publique et de clé privée. On avait vu que renouveler son entité n’est pas un problème facile à résoudre de façon satisfaisante, c’est à dire vraiment sécurisée et facile pour l’utilisateur.

Du point de vue interface, la nouvelle entité change aussi de couleur propre. Donc on ne peut pas demander à l’utilisateur par ailleurs de se fier à cette couleur propre des objets puisqu’elle va changer complètement à chaque mise à jour de ceux-ci. C’est ici que se fait sentir le besoin d’une référence d’objet stable dans le temps quelque soit les mises à jours, mais cette référence est par nature source de conflit d’une entité à l’autre et surtout elle est impossible à sécuriser.

Le problème est plus simple si l’entité est dépendante d’une autre entité, d’une entité maitresse. A condition que cette entité maitresse soit publiquement déclarée, comme le puppetmaster, il est possible de vérifier de façon sûr qu’une entité à changé de clé privée. CF Entités multiples, gestion, relations et anonymat

Par contre, une entité autonome ou assimilée ne peut pas se reposer sur une entité supérieure. Il faut prévoir un mécanisme qui permette à l’utilisateur d’une entité lambda de valider automatiquement ou manuellement la mise à jour d’une autre entité. Cela ne veut pas dire que l’autre entité ne changera pas d’identifiant, mais que cet identifiant ne sera pas reconnu tant que l’entité lambda n’aura pas validé (pour elle) son changement.

Pour le changement d’une entité qui potentiellement remet gravement en question la sureté de fonctionnement, une acceptation inconditionnelle de la mise à jour serait catastrophique. Il peut être utile dans ce cas particulier de générer un lien d’annulation de l’opération, mais un lien qui n’est pas actif, c’est à dire qui n’est pas diffusé. Ce lien de type x, serait affiché à l’utilisateur et serait donc valide mais pas pris en compte parce que non diffusé avec les autre liens.

Si on prend le cas spécifique de puppetmaster, cette entité valide des entités esclaves ayant des rôles près-définis. On retrouve notamment l’entité bachue qui diffuse les mises à jours logiciels liées au projet nebule. La compromission d’une telle entité poserait de graves problèmes de sécurité pour toutes les entités. Sa mise à jour vers une nouvelle entité serait dans ce cas obligatoire.
Mais ce problème pourrait être plus restreint dans la mesure où une fausse entité bachue serait générée et diffusée à des entités tierces. Si, par un autre moyen, on arrive à convaincre les entités tierces à l’utiliser en place de la vraie entité bachue, ces entités seront à considérer comme compromises. Le lien d’annulation serait alors le seul moyen pour ces entités de pouvoir revenir en arrière, faisant immédiatement un bond en arrière en terme de versions de logiciels, revenant à une version validée par l’entité bachue légitime.
Sauf que cela ne marche que si l’on peut enregistrer le lien de suppression hors du système nébulisé ou hors d’atteinte. Ce qui sera une vraie difficulté sur des systèmes entièrement nébulisés. Aujourd’hui, avec les systèmes d’informations actuels, on s’en sort en régénérant une nouvelle identité à l’utilisateur ou en nettoyant son compte. Peut-être faudra-t-il dans un premier temps garder ce fonctionnement avant d’aller vers quelque chose de plus ouvert…

Affichage de la couleur d’un objet

Une des orientations actuelles dans les interfaces graphiques centrées sur nebule, c’est de représenter les objets par leurs identifiants et pour chacun par des carrés de couleur spécifiques. Chaque objet a sa couleur propre calculée par rapport aux 6 premiers digits de son identifiant.

2014.11.11 21h03 ecran

Mais du point de vue de l’interface visuelle, si la représentation de l’identifiant équivoque d’un objet est indispensable, sa place encombrante n’est ni ergonomique ni pratique ni vraiment sécurisante à elle seule. Garder systématiquement la place pour un nombre hexadécimal de 128 caractères au minimum, fut-il l’objet en cours de consultation, c’est encombrant. L’ergonomie en prend un coups puisque l’on doit grader un grand espace variable pour une information certes importante mais peu pertinante pour l’utilisateur la plupart du temps. Enfin, puisqu’il est illusoire de penser pouvoir mémoriser l’intégralité des identifiants que l’on utilise pour les vérifier, à part quelques cas spécifiques l’affichage des identifiants des objets n’amène pas directement de sécurité pour l’utilisateur. Le problème de mémorisation est le même que pour les mots de passes multiples, passé un certain nombre, très restreint, cela affaiblie la sécurité de l’ensemble.

Il est tentant de remplacer purement et simplement l’affichage de l’identifiant d’un objet juste par son carré de couleur propre. Cela entraînerait l’impossibilité de vérifier immédiatement si l’objet que l’on visualise est le bon. On peut savoir avec la couleur si l’objet est celui que l’on attend. Mais la représentation des couleurs ne dépasse pas 24 bits d’information. C’est à dire qu’en ajouter plus que les 24 bits n’est pas perceptible par l’oeil humain. Ainsi, la couleur est un moyen de tri rapide mais pas un moyen de sécurité.

Le problème de ne pas pouvoir vérifier immédiatement et de façon sûr un objet est déjà un problème en soit mais peut être comblé par l’usage des liens. Par contre, la gestion des entités et notamment la reconnaissances de nouvelles entités uniquement sur leurs couleurs propres est un vrai problème de sécurité. Il est facile de générer une nouvelle entité ayant la même couleur propre. Avec 24 bits à respecter, cela ne présente pas une grande difficulté. L’identification d’une nouvelle entité doit dans tout les cas être parfaitement sécurisée, donc elle doit être basée sur l’intégralité des identifiants.

Il faut donc soit conserver l’affichage de l’identifiant des objets, même partiel(tant qu’il est suffisamment grand). Soit il faut trouver une méthode alternative de représentation simple des objets tout en conservant un espace de valeur correct.

Au moins deux méthodes peuvent être envisagées, liste non exhaustive.

On peut utiliser un petit pictograme de plusieurs couleurs successives calculées à partir de l’identifiant d’un objet. Le prictograme peut disposer d’un espace de valeurs suffisamment grand tout en étant facilement mémorisable.

On peut imaginer qu’une entité spécifique utiliser certaines valeurs choisies au hasard parmi tous les digits des identifiants pour calculer les couleurs propres des objets. Comme il faut 6 digits hexadécimaux pour constituer une couleur, ceux-ci sont choisis non pas au début des identifiants mais à l’intérieur. ce choix doit être aléatoire, secret pour l’entité et non recalculable par une entité tierce. Dans ce cas, la couleur affichée pour un même objet serait différente pour chaque entité qui consulte cet objet.