Initiateur bootstrap

En cours de ré-écriture !

Le bootstrap est un fichier PHP unique qui fonctionne comme un initiateur des applications. Il a plusieurs rôles lors du chargement initiale d’une page web liée à nebule ou un des programmes annexes :

• Prépare au besoin l’environnement lors de l’installation sur un nouveau serveur ;
• Réalise des tests indispensables au bon fonctionnement des applications ;
• Gère ou charge les applications.

Dans le détail :

1. Lors du tout premier lancement, il vérifie l’environnement et crée au besoin ou télécharge ce qui manque. Il vérifie notamment la présence des dossiers ‘o’ et ‘l’, et si il peut écrire dedans. Il vérifie aussi qu’une entité instance du serveur existe, et la crée au besoin.
2. A chaque page chargée, il fait préalablement une série de tests rapides afin de détecter tout problème qui auraient un impact sur le bon fonctionnement des applications. Il vérifie que les dossiers ‘o’ et ‘l’ sont utilisables. Il vérifie la cryptographie lors d’une série de chiffrement/déchiffrement et prise d’empreinte avec des réponses attendues positives et négatives.
3. Il recherche et charge la dernière version de la librairie nebule.
4. Lorsque tout se passe bien, il permet à l’utilisateur de sélectionner une application disponible ou appelle l’application par défaut. Lorsqu’une application a été sélectionnée par l’utilisateur, il retient le choix et appelle ensuite automatiquement cette application. Il recherche toujours la dernière version de l’application disponible avant chargement.
5. A tout moment, l’utilisateur peut faire appel au bootstrap pour changer d’application.
6. A tout moment, l’utilisateur peut activer le mode de récupération.

Toute application est un objet à part entière de nebule, et donc elle est non seulement complètement verrouillée et vérifiable mais sont usage est aussi complètement sous contrôle.

Comme l’organisation interne de la librairie et des programmes peut changer avec le temps, le bootstrap mémorise lors du premier lancement les identifiants des objets de la librairie et de l’application utilisés. Il mémorise aussi dans un état dit ‘sérialisé’ les instances de la librairie et de l’application afin de réduire les temps de chargements ultérieurs. Ce fonctionnement permet de garder une complète cohérence entre les objets et les instances des classes utilisées mais aussi de pouvoir demander des mises à jours des objets sans risquer de casser l’existant. La mise en application des mises à jours peut être demandé explicitement ou se faire naturellement lors de l’expiration de la session PHP.

Le bootstrap utilise des constantes pour définir son comportement générique ou le nom de certaines options. Tant que la bibliothèque en PHP orienté objet (LIB POO) n’est pas chargée, le code fait référence aux constantes définies dans la phase d’initialisation du bootstrap ou dans la bibliothèque en PHP procédural (LIB PP).

Mise en place

Voir la page Installation et ses pages annexes par système d’exploitation.

Arguments en ligne et accès directs

Les arguments permettent de contrôler en partie le comportement du bootstrap mais depuis le poste utilisateur. Potentiellement, tout le monde ayant accès au serveur via un navigateur, la liste est volontairement très réduite et très limitée dans la portée des actions permises.

Pour modifier plus profondément le comportement du bootstrap, il faut passer par les options. Mais les options ne sont pas librement modifiable par tout le monde.

Tous les arguments purement du ressort de nebule sont codées sur un seul caractère.

La liste des arguments pour la partie purement du ressort de nebule :

• o : le contenu de l’objet. Opérateur dont la valeur désigne l’objet attendu.
• l : le contenu des liens de l’objet. Opérateur dont la valeur désigne l’objet.
• e : l’entité instance du serveur. Fichier contenant l’ID de l’entité.
• a : l’ID de référence de l’application à utiliser. Opérateur dont la valeur désigne l’objet de référence.
• b : arrêt du bootstrap. Commutateur.
• f : nettoyage complet de la session enregistrée. Commutateur.
• i : affichage réduit pour insertion à l’intérieur d’une autre page. Commutateur.
• r : mode de récupération. Commutateur.
• u : demande de chargement de la dernière version de la bibliothèque et de l’application. Commutateur.

Un opérateur désigne une chaîne de texte de type clé=valeur. Un fichier désigne un fichier accessible directement sur le serveur sous ce nom. Un commutateur désigne une valeur présente comme argument d’une URL et qui suffit à activer un comportement défini.

Par exemple :

• http://server.nebule.org/?o=6501352a9da77110e52e31338fd4801a
• http://server.nebule.org/?l=6501352a9da77110e52e31338fd4801a
• http://server.nebule.org/?b
• http://server.nebule.org/?a=0
• http://server.nebule.org/?f&r

Ce qui peut être récupéré via les arguments o, l et e le sont aussi directement via l’URL sans utiliser les arguments. Dans ce cas aucun pré-traitement n’est appliqué et applicable.

Par exemple :

• http://server.nebule.org/o/6501352a9da77110e52e31338fd4801a
• http://server.nebule.org/l/6501352a9da77110e52e31338fd4801a
• http://server.nebule.org/e

Via un opérateur, la demande se fait dans une session http avec potentiellement une entité déverrouillée. Via un argument, la demande se fait aussi dans une session http mais une éventuelle entité déverrouillée n’est pas utilisée. Cela veut dire notamment que via un argument le contenu en clair d’un objet protégé ne peut être récupéré par cette méthode. De même, le nom d’un objet n’est pas transmis lors du téléchargement parce qu’on transfert un objet dont le nom est son identifiant.

Les quatre faces visibles

Face erreurs

En temps normal on ne voit pas le bootstrap parce qu’il ne se manifeste pas et appelle rapidement une application. Mais il peut se manifester en cas d’erreur grave, c’est sa première face.
Dans ce cas, il tourne avec une version très réduite de la librairie nebule. Hormis lors de l’initialisation d’une entité instance du serveur, il ne fait aucune modification. C’est avant tout un affichage pour signaler une erreur.

Interruption par l’utilisateur.

Cette page peut être appelée en ajoutant à l’URL du serveur /?b . On obtient une interruption de l’utilisateur du bootstrap comme dans l’illustration ci-dessus. Par exemple lien.

Face applications

Il peut être appelé aussi par l’utilisateur pour changer d’application, c’est sa deuxième face.
Dans ce cas, il utilise la dernière version de la librairie nebule disponible. La présentation est sobre et présente à l’utilisateur toutes les applications qu’il peut appeler. C’est l’application ‘0’ (zéro).

Choix des applications.

Cette page peut être appelée en ajoutant à l’URL du serveur /?a=0 . On obtient l’affichage des applications disponibles comme dans l’illustration ci-dessus. Par exemple lien.

Face pré-chargement d’applications

…

Pré-chargement d’une application.

…

Face premier chargement

…

Les tests au chargement

.

Le mode de récupération

L’activation de ce mode de récupération empêche simplement l’entité instance du serveur et l’entité par défaut de devenir autorités locales. C’est à dire que les options qui leur permettent de devenir autorités locales ne sont plus pris en compte.
Le fait d’être autorité locale permet de générer des liens, qui seront réellement reconnus, pour faire des mises à jours de la librairie et des applications au même titre que le maître du code bachue. C’est comme cela que l’on peut travailler le code signé sans avoir recours en permanence au maître du code. Et c’est aussi comme cela que l’on peut mettre en place sa propre application sans qu’elle soit signée du maître du code.

L’activation peut se faire via les arguments de l’URL en ajoutant /?r dans l’URL si l’option permitOnlineRescue est à true. Par exemple lien.
En cas de besoin, option modeRescue permet à true d’activer et de forcer le mode de récupération sans tenir compte de l’option permitOnlineRescue.

Déclarer une application

C’est un acte technique qui consiste, après avoir préparer l’application, à créer le lien de déclaration.

Voir la page des applications pour plus de détail sur la création et la déclaration des applications. Les modules ne sont pas gérés par le bootstrap.

La déclaration tourne autour du mot réservé nebule/objet/interface/web/php/applications définissant un objet de référence des applications. Chaque application a en plus sont propre objet de référence mais utilisé dans le contexte de l’objet de référence des applications.

Les liens doivent être signés par le maître du code. Si l’option permitInstanceEntityAsAuthority=true, les liens de l’entité instance du serveur (définit dans le fichier e) sont aussi pris en compte. Si l’option permitDefaultEntityAsAuthority=true, les liens de l’entité par défaut (définit par l’option defaultCurrentEntity) sont aussi pris en compte. Les autres liens ne sont pas pris en compte.

Pour l’instant, toutes les applications disponibles sont utilisables mais il sera possible à terme de faire sélectionner par l’entité instance du serveur les applications utilisables. Les autres applications ne seront pas utilisables mais resteront disponibles soit pour les activer soit pour les relayer à d’autres serveurs.

Déroulement du code du bootstrap

Le code du bootstrap est découpé en plusieurs parties de codes afin de remplir les rôles qui lui sont dévolus (cf tout en haut).

Partie 0header : entête

Cette partie contient un en-tête générique et l’initialisation de la journalisation au nom du bootstrap.

Le buffer d’affichage est bloqué pour que rien ne s’affiche tant que ce ne sera pas prévu.

Un identifiant de session $bootstrapLogSession est généré afin d’assurer la cohérence du suivi des journaux. Puis les journaux sont initialisés et un marqueur de démarrage ' --- start bootstrap' est envoyé. Ce marqueur est présent à chaque démarrage du bootstrap, que ce soit pour le chargement d’une page principale ou de ces sous-parties.

Une constante, à false par défaut en production, active la journalisation poussée des activités du bootstrap à des fins de dépannage de code. Cette journalisation ne peut pas être activée sauf à modifier la valeur de la constante dans le code.

Partie 1init : initialisation

Cette partie met en place des constantes pour définir l’environnement. On initialise les constantes définissant les commandes communes de nebule comme le téléchargement des objets et de leurs liens. Ces commandes sont réservées à nebule et font une taille de 1 caractère. Par défaut, les commandes réservées et utilisées par le bootstrap sont a, b, e, f, i, r et u.

Quatre constantes de dépannage du code sont initialisées. Ces constantes ne peuvent pas être modifiées sauf à modifier leurs valeurs dans le code. Les actions des constantes :

• Arrêt forcé, doit être à false. Cette constante force un arrêt du bootstrap, càd l’affichage de l’écran d’erreur avec le message Internal interrupt.
• Rechargement d’une application lorsqu’elle vient d’être préchargée, doit être à true. Cette constante permet de dépanner le pré-chargement des applications.
• Ne suivre que les liens des autorités, doit être à true. C’est utilisé lors de la recherche de la bibliothèque et des applications, permet de prendre en compte des liens d’entités n’ayant pas autorité sur le code.
• Une entité de développement, doit être une chaîne vide. L’identifiant de l’entité est ajouté de force à la liste des autorités du code. Cela permet de forcer une entité de développement et contourner certains problèmes délicats de dépannage du code de gestion des autorités.

Désactive la journalisation pour la bibliothèque procédurale.

…

Ensuite on vérifie si l’utilisateur n’a pas demandé une interruption du démarrage du bootstrap.

On vérifie aussi si le fichier qui déclare l’entité instance du serveur est présent. Si ce n’est pas le cas alors on demande l’interruption du chargement et on active la demande de première synchronisation.

Enfin, on force quelques variables et notamment des variables pour la librairie en PHP procédural afin déviter une attaque par des variables passées en argument de l’URL.

Partie 2libpp : librairie en PHP procédural

Cette partie contient sans modification la librairie en PHP procédural. La constante MODE_BOOTSTRAP est à true pour désactiver certaines fonctions.

La librairie est automatiquement initialisée au cours du chargement. Sont extraits les différentes entités et notamment le puppetmaster ainsi que ses entités rattachées.

Partie 3session : session PHP

On commence par vérifier si un nettoyage de la session PHP n’a pas été demandé. Si c’est le cas on le fait immédiatement.

On vérifie ensuite si il est demandé forcer la mise à jour de la librairie et de l’application, et si il est demandé de changer d’application.

A partir de là on recherche les id de la librairie et de l’application à utiliser depuis la session PHP. On vérifie que les instances ‘sérialisées’ de ceux-ci existent. Si ce n’est pas le cas on ignore l’id correspondant pour recharger quelque chose de propre. Si une application est bonne mais pas la librairie, on recharge complètement la librairie.

Dans la session, avec l’application, on recherche aussi les instances ‘sérialisées’ des classes d’affichage, d’action et de traduction de l’application à utiliser.

Si pas d’application on lit l’application à utiliser par défaut. A défaut on utilise l’application 0 de séection d’application.

Si pas de librairie on recharge complètement la librairie.

Partie 4libpoo : librairie en PHP orienté objet

La librairie en PHP orienté objet ayant normalement déjà été trouvé, on se contente de charger l’objet correspondant et de ‘déserialiser’ ou d’instancier la classe de la librairie.

Partie 5break : application de rupture

Cette partie déclare une fonction dédiée à l’affichage lorsqu’il est demandé l’interruption du chargement du bootstrap. Il est notamment affiché ce qui a provoqué l’interruption du chargement et l’état des librairies.

…

Partie 6preload : application de pré-chargement des applications

Cette partie déclare une fonction qui va pré-charger le code de la bibliothèque puis le code de l’application.

Cette partie pré-chargement peut être un peu long sur un serveur peu performant ou très occupé. Pendant le chargement, l’utilisateur n’a pas un écran vide et peut patienter plus facilement.

Partie 7first : application de premier chargement

Cette partie contient une fonction de premier lancement sur un nouveau serveur. Cela se déroule en plusieurs étapes incontournables.

…

Partie 8app0 : application 0

Cette partie déclare l’application 0 dédiée à la gestion par l’utilisateur du changement d’application.

Partie 9router : chargement des applications

Si tout se passe bien on charge l’objet correspondant à l’application et on ‘déserialise’ ou on instancie la classe de l’application. En fin d’application, on mémorise les id de la librairie et de l’application utilisés ainsi que leurs instances ‘sérialisées’ vers la session PHP. On mémorise aussi les instances ‘sérialisées’ des classes d’affichage, d’action et de traduction de l’application.

Sinon on appelle l’application de rupture pour afficher le problème ou la fonction de premier chargement au besoin.