Une nouvelle page vient d’être créé dans la ligne directe de l’article Création d’une nouvelle entité, c’est la page Installation visible sur la partie gauche du blog.
Elle est encore en cours de rédaction!
Cette page décrit la mise en place d’une nouvelle instance de sylabe sur un serveur. C’est typiquement l’installation d’un serveur personnel à la maison.
Pour l’instant, c’est une documentation restreinte à Debian 7.0 et Apache 2.2.
L’implémentation de référence de nebule en bash utilise cette arborescence pour son fonctionnement :
pub
olpriv
oltmpOn trouve notamment dans pub et priv un fichier e contenant l’identifiant de l’objet entité, la clé publique pour le premier et la clé secrète pour le seconde.
Dans pub, on peut encore trouver sur certaines machines gnav.php et un répertoire g. C’est la page de tracé du graphe d’un objet. Cette page php est vouée à disparaître sous cette forme.
Le contenu du répertoire pub avait été volontairement séparé, c’est à dire les répertoires o et l en dessous, des scripts et autres fichiers bash, clés RSA, etc… Est apparu avec le temps les dossiers priv et tmp pour manipuler les objets soit qui ne devaient pas être diffusés soit les fichiers temporaires. Et le répertoire pub à rapidement servit à stocker aussi de nouvelles pages web en php comme gnav.php et webcli.php . Ce répertoire devenait donc directement public, ce pour quoi il est fait dès le début en fait…
Lors de la mise en place de sylabe, j’ai conservé cette arborescence par défaut. Mais elle pose problème.
Les objets et liens sont téléchargés sur des url du type http://site.net/o/ ou http://site.net/l/ . Or le serveur web utilise par défaut le dossier parent pour l’affichage des pages. Cela nécessite de faire le lien entre le pseudo dossier o et son réel emplacement en pub/o . En fonction du système d’exploitation et du logiciel serveur web, la manière de contourner ce problème est différente. Ce n’est pas vraiment optimal.
Il faut cependant pouvoir faire cohabiter simultanément les scripts bash et les pages php, voir peut-être d’autres choses par la suite.
Il y a une solution, remettre le dossier pub comme répertoire par défaut dans le serveur web, c’est à dire l’arborescence racine. Les scripts bash peuvent rester dans le répertoire parent sans entrer en conflit avec les pages php dans pub, tout en exploitant la même base d’objets et de liens. En bash, les objets sont dans pub/o alors que en php ils sont dans o tout simplement.
Et comment dans sylabe va-t-on gérer les fichiers temporaires et fichiers à ne pas partager ?
Cela peut être fait de deux façons. Soit on crée un sous dossier avec des restrictions via un fichier .htaccess. Cette méthode à inconvénient de se restreindre à un seul type de serveur web. Et plus grave, tous les objets privés de toutes les entités connectées sont ainsi mélangés… Soit on fait du déchiffrement à la volée et du stockage de petits objets dans la session php.
Les fichiers temporaires peuvent eux être mélangés tant qu’ils ne sont pas écrasés ou réutilisés entre deux sessions différentes. Dans ce cas il faut peut-être prévoir un sous dossier tmp.
Cette fois-ci, la vérification de la signature des liens marche enfin !
C’est une étape importante, la première en fait, puisque c’est ce qui permet de vérifier la validité des échanges, c’est à dire les liens.
Suite à ça, on peut maintenant espérer permettre la génération de nouveaux liens, mais aussi la réception de liens déjà signés. Cette réception marche d’ailleurs, pas la génération, mais si les liens existants sont bien vérifiés, il y a encore un petit bugg qui empêche la vérification d’un lien importé. Ça progresse…
Il y a aussi des variables permettant de désactiver la synchronisation d’objet ou de liens depuis le serveur, mais aussi le transfert d’objet ou de lien vers le serveur. CF upl sur zulu :
D’un autre côté, il y a des problèmes avec certaines fonctions dans php.
La fonction hex2bin n’est pas reconnu avant la v5.4.0 alors que la fonction inverse bin2hex était déjà présente dans la v4. Il faut à la place utiliser la fonction pack (v4).
La fonction openssl_verify est bien présente depuis la v4.0.4, mais sha256 n’est pas reconnu dans les fonctions de hashage supportées avant la v5.4.8 . Il faut à la place utiliser des fonctions plus basiques comme hash (v5.1.2) et openssl_public_decrypt (v4.0.6). Les anciennes versions stables de Debian et Ubuntu incluaient déjà php en v5.3, je pense que c’est maintenant suffisamment ancien pour ne pas risquer la perte de fonctionnalité.
Donc soit on est compatible uniquement avec des versions très récentes de php, et donc adieux les versions pré-packagées pour serveur (Debian ou Ubuntu par exemple). Bienvenue à la compilation à la demande et tous les problèmes de maintenances inhérents. Soit on utilise d’autres fonctions au prix peut-être de performances moindres, c’est donc le cas pour l’instant, et ça marche :
