--Présentation technique
	-C newpage(SCENE_WEBCAM);
	-T
	-B Le projet Bolixo a commencé en 2017.
	-B Publié fin 2018
	-B Développement depuis
	-B Accent sur la sécurité
	-B Architecture de Bolixo.
	-B Présentation des principales composantes

--Système distribué
	-C newpage(SCENE_WEBCAM);
	-T
	-B Ça évite les problèmes du système de nom unique
		-b Un serveur par organisation
		-b Serveurs privés et publics.
		-b Marie-mai@bolixo.adisq.ca vs Marie-mai@gmail.com
	-B inutile d'avoir des grappes complexes
		-b Relations limitées entre les serveurs
		-b Les lectures sont toujours locales.
		-b Plus simple à réaliser
	-B Annuaire central bolixo.org
		-b Pas requis pour les opérations
		-b Utile pour trouver des amis
	
--Les microservices
	-C newpage(SCENE_WEBCAM);
	-T
	Quel est l'intérêt des microservices ?
	-B Découpage des fonctionnalités
		-b Qui fait quoi
		-b Spécialisation du code
		-b Un service A ne touche pas à la BD
		-b Qui parle à qui
	-B Augmente la résilience
		-b Faile de sécurité
		-b Le système ne s'écroule pas comme des dominos
	-B Les composantes peuvent être installées où on veut
		-b Elles ne savent pas comment communiquer entre elles.
		-b Blackhole est un aiguilleur

--Les microservices
	-C newpage(SCENE_WEBCAM);
	-T
	-B Quand c'est au point
		-b On peut repartir n'importe quelle composante
		-b Les composantes sont petites
		-b Le cycle pour un développeur est très rapide
		-b Et c'est maintenant très robuste.
	-B Mais ça reste une complexité ... nécessaire
		-b Beaucoup de développeurs aimeraient mieux un seul gros programme

--Les microservices LXC0
	-C newpage(SCENE_WEBCAM);
	-T
	-B La plupart sont lourds
		-b Construits à partir de paquetages
		-b Contiennent beaucoup de choses inutiles
	-B Les LXC0 sont construits avec strace
		-b System call Trace
		-b On exécute le programme via strace
		-b On analyse le journal strace
		-b Uniquement les fichiers/librairies accédés par le programme
	-B Le microservice contient
		-b Le programme
		-b Les librairies
		-b Les fichiers de configuration
		-b Les données

--Les microservices LXC0, suite
	-C newpage(SCENE_WEBCAM);
	-T
	-B Ne contient pas
		-b bash
		-b utilitaires système aidant un attaquant
		-b /proc et /sys
	-B On a donc le minimum requis
	-B Tous les microservices Bolixo sont construits comme cela
		-b Ça inclut apache, mariadb et exim

--Les microservices LXC0, code de vie
	-C newpage(SCENE_WEBCAM);
	-T
	-B Connexion IP
		-b Les microservices ne peuvent pas communiquer entre eux
		-b Par défaut, ne peuvent aller sur Internet
	-B Unix domain socket
		-b En général
		-b Le système blackhole dépose des sockets Unix dans le service
		-b Le service utilise ces sockets pour se connecter au blackhole
	-B Blackhole
		-b On met les services où on veut
		-b Configuration centralisée
		-b 'load balancer' où c'est requis

--Les microservices, code de vie, suite
	-C newpage(SCENE_WEBCAM);
	-T
	-B Configuration du blackhole
		-b Le blackhole a des règles générées par bo-manager
		-b De Serveur1,service-web,/dev/bod.sock
		-b Vers Serveur2,service-bod,/dev/bod-1.sock
		-b Vers Serveur2,service-bod,/dev/bod-2.sock
		-b Vers Serveur3,service-bod,/dev/bod-1.sock
		-b On voit ici 3 alternatives pour une même source
		-b Blackhole réalise un égalisateur de charge
	-B On peut repartir les microservices sans impacter les autres
		-b Aide aux mises à jour
		-b On peut en faire en production n'importe quand

--Architecture
	-C newpage(SCENE_WEBCAM);
	-T
	-B les rectangles représente un microservice
	-B En général, ne contiennent qu'un seul programme.
	-B Quand un microservice en contient plusieurs
		-b on les présente dans une ellipse
	-B Les flèches indiquent qui initie la connexion

--Architecture
	-C newpage(SCENE_WEBCAM);
	-C printf ("(cd ~/projets/bolixo/trunk; DOCNAME='--docname /projects/jacques-A/public/anim.whi' make gen-bolixo-arch)\n");

--Comment ça peut scaler
	-C newpage(SCENE_WEBCAM);
	-T
	-B Le concept de serveurs distribués nous protège
	-B Mais ... si ... c'était requis
	-B Blackhole
		-b Seul à savoir où sont les microservices
		-b Égaliseur de charge entre n'importe quoi
	-B Seuls 3 services se font bombarder
		-b web, bod et la base de données de contenu
		-b web et bod n'ont pas d'état
		-b Ils n'écrivent rien.
		-b Facile de les mettre en grappe sur plusieurs serveurs
	-B Toutes les écritures faites par writed
		-b On peut avoir un serveur MariaDB en grappe pour le contenu
		-b Ou pas. writed pourrait réaliser les écritures séparément
		-b Pas besoin de temps réel.

--Comment ça peut scaler, suite
	-C newpage(SCENE_WEBCAM);
	-T
	-B Il y a deux types de comptes sur un serveur Bolixo
		-b locaux
		-b distants
	-B Les comptes distants
		-b Ils sont créés à la volée
		-b jacques sur serveur1 devient jacques@serveur1 sur serveur2
		-b jacques sur serveur2 n'est pas jacques@serveur1
		-b Un compte distant peut faire la même chose qu'un compte local
		-b Connexion sur serveur2 au compte jacques@serveur1, uniquement de serveur1
	-B Comment les comptes distants s'authentifient
		-b serveur1 fait un appel remotelogin sur serveur2 pour jacques@serveur1
		-b serveur2 répond par une question
		-b serveur1 signe la question avec la clé privée de jacques
		-b serveur2 utilise la clé publique de jacques@serveur1 pour valider

--Comment ça peut scaler, suite, suite
	-C newpage(SCENE_WEBCAM);
	-T
	-B Utilisation restreinte des comptes distants
		-b Un utilisateur ne peut pas s'y connecter
		-b Le serveur de l'utilisateur fait des connexions distantes
		-b L'utilisateur n'a pas accès à sa clé privée
	-B Activité sur un serveur
		-b La majorité de l'activité sur un serveur est locale
		-b Les serveurs contiennent des copies du contenu distant.
	-B Le service publishd
		-b Il fonctionne en arrière plan
		-b Lorsqu'un message est créé (écriture locale)
		-b publishd vérifie si d'autres serveurs sont concernés
		-b Il utilise alors les comptes distants de l'auteur
		-b Et copie vers chaque serveur concerné

--Comment ça peut scaler, un exemple complexe
	-C newpage(SCENE_WEBCAM);
	-T
	-B Jacques sur serveur1, Pierre sur serveur2
		-b Jacques a créé le groupe de discussion hockey
		-b Jacques a invité Pierre (pierre@serveur2)
	-B Pour Pierre sur serveur2
		-b Le groupe hockey de jacques@serveur1 apparaît
		-b Pierre sélectionne le groupe et écrit un message.
		-b Le groupe est sur serveur1
		-b Le compte distant de Pierre sur serveur1 est utilisé
		-b Le message est transmis (sur serveur1)
		-b publishd voit que ce message concerne des utilisateurs distants
		-b Il fait la distribution: serveur2, serveur4, ...
	-B Tous les membres du groupe hockey voit le message 'localement'

--Comment ça peut scaler, un exemple complexe
	-C newpage(SCENE_WEBCAM);
	-T
	-B Pour les messages publics
		-b Jacques peut avoir 1,000,000 d'abonnés
		-b Peu d'impact sur le serveur
		-b Le message sera copié une fois par serveur
	-B Si jacques a une page publique
		-b et que Jacques est très populaire
		-b alors le serveur devra être construit en conséquence
		-b Les pages publiques sont visibles pour tous

--WEBAPI
	-C newpage(SCENE_WEBCAM);
	-T
	-B Programme fonctionnant dans le service WEB
	-B Il réalise le procole REST
	-B C'est un simple proxy
	-B Il se connecte au service BOD
		-b Utilise le protocole interne
	-B Offre tous les services pour faire un front-end
	-B Sert à la communication interserveur
		-b Sert aussi à bofs, outils ligne de commande

--Bases de données
	-C newpage(SCENE_WEBCAM);
	-T
	-B 3 microservices MariaDB
		-b Drole de nom
	-B Les documents volumineux sont stockés dans le système de fichier
	-B Pourquoi 3 bases de données
		-b Une pour Bolixo.org, aucun rapport avec le reste du système
		-b Un serveur, plusieurs bases de données
		-b Résilience
		-b Flexibilité (en fonction de la charge)
	-B Un serveur pour les informations privés
		-b Mot de passe
		-b Clé privés
	-B Un serveur pour le contenu


--Mises à jour
	-C newpage(SCENE_WEBCAM);
	-T
	-B Comment mettre à jour un réseau social
		-b Ça fonctionne 24 sur 24
		-b Surtout la fin de semaine
	-B C'est très simple
		-b On installe le nouveau paquetage bolixo
		-b Installer un nouveau paquetage n'a aucun effet
		-b bo restart most
		-b Voilà
		-b On peut faire cela n'importe quand

--Mises à jour, suite
	-C newpage(SCENE_WEBCAM);
	-T
	-B Comment ça fonctionne
		-b Dans le service web, il y un gardien
		-b Chaque requête reçue doit être authorisée par le gardien.
		-b On peut demander au gardien de tout bloquer
		-b Toutes les nouvelles requêtes vont bloquer.
		-b Le gardien attend que les requêtes déjà autorisées terminent.
		-b On peut alors redémarrer tous les microservices internes
		-b Repartir un microservice le reconstruit (avec la nouvelle version)
		-b Même les bases de données
		-b On débloque le gardien

--Mises à jour, le service web
	-C newpage(SCENE_WEBCAM);
	-T
	-B Stratégie complètement différente
		-b On veut repartir le service web et webssl
	-B Il y a deux autres services: web-fait et webssl-fail
		-b Blackhole les utilise en mode bascule (fail over)
		-b web-fail et webssl-fait ont une priorité 0
		-b Donc aucune activité
	-B Voici la séquence
		-b On met à jour web-fail et webssl-fail
		-b On bascule la priorité sur web-fail et webssl-fail
		-b On attend que toutes les connexions terminent sur web et webssl
		-b On bascule la priorité sur web et webssl
		-b On attend (pour être sure) la fin des connexions sur web-fail et webssl-fail
	-B On peut faire cela n'importe quand
		-b bo restart most
		-b redémarre les services internes et web

--Structure du code
	-C newpage(SCENE_WEBCAM);
	-T
	-B Séparation claire
		-b qui fait du HTML
		-b Exception pour documentd pour supporter OLE
		-/ -C printf ("./techno-sup.sh imbed-chess\n");

--Dépendances
	-C newpage(SCENE_WEBCAM);
	-T
	-B MariaDB
	-B openssl
	-B exim