rapport: write about rembo

doc/rapport.gpp.md

@@ -61,12 +61,14 @@ abstract: |
 !!defacronym{DHCP}{_Dynamic Host Configuration Protocol_: protocole de configuration dynamique des hôtes }
 !!defacronym{EFI}{_Extensible Firmware Interface_: interface micrologicielle extensible unifiée}
 !!defacronym{ESP}{_EFI System Partition_: partition système EFI}
+!!defacronym{FOG}{_Free Open-source Ghost_}
 !!defacronym{FTP}{_File Transfer Protocol_: protocole de transfert de fichier}
 !!defacronym{GPT}{_GUID Partition Table_: table de partitionnement GUID}
 !!defacronym{GRUB}{_GRand Unified Bootloader_}
 !!defacronym{HEPIA}{Haute école du paysage, d'ingénierie et d'architecture de Genève}
 !!defacronym{HTTPS}{_HyperText Transfer Protocol Secure_: protocole de transfert hypertexte sécurisé}
 !!defacronym{HTTP}{_HyperText Transfer Protocol_:  protocole de transfert hypertexte}
+!!defacronym{IBM}{_International Business Machines corporation_}
 !!defacronym{IPFS}{_InterPlanetary File System_: système de fichier inter-planétaire}
 !!defacronym{IP}{_Internet Protocol_: protocole internet}
 !!defacronym{LDAP}{_Lightweight Directory Access Protocol_: protocole léger d'accès à un annuaire}
@@ -144,13 +146,6 @@ distance dans un contexte "cours du soir"**
 
 # Cas d'utilisation
 
-**TODO: décrire les cas d'utilisation du projet à l'aide d'un diagramme
-de use cases qui montre les inter-actions possibles entre les
-différentes entités du sytème que sont les utilsateurs, administrateurs,
-les postes clients, le serveur, les images, les configurations. Le
-diagramme doit décrire les aspects fonctionnels du système (quoi) sans
-détailler les aspects techniques (comment).**
-
 L'aspect fonctionnel du système à réaliser est décrit avec un diagramme
 de cas d'utilisations dans la figure !!ref{diagram_usecases}.
 
@@ -166,15 +161,34 @@ Les sous-sections qui suivent décrivent quelques-uns de ces systèmes,
 leurs points forts et points faibles et pourquoi ils ne sont pas adaptés
 tels-quel pour ce projet.
 
-## IBM Tivoli / Rembo
+## BpBatch / Rembo / !!acronym{IBM} Tivoli
+
+Ce système est l'inspiration directe de ce projet. Son développement a
+commencé en 1996 au département informatique de l'université de Genève
+par Marc Vuilleumier Stückelberg et David Clerc.
+
+Les fonctionnalités de ce projet sont similaires à celles visée par le
+projet _Bootiful_. Il permet aux postes clients de lancer un mini
+système d'exploitation via !!acronym{PXE} au démarrage de la machine. Ce
+mini-système permet de télécharger et déployer des images de système
+d'exploitation sur la machine, tout en créant une copie en cache à la
+fin du disque pour éviter de la télécharger plusieurs fois.
+
+La première version, nommée _BpBatch_ fut distribuée gratuitement sur
+internet. Une entreprise nommée _Rembo Technology Sàrl_ a ensuite été
+fondée en 1999 pour continuer un développement commercial de ce projet
+sous le nom de _Rembo_. En 2006, la société a été rachetée par IBM et le
+projet a été intégré à leur solution _Tivoli Provisionning Manager_.
+
+Bien que ce système réponde aux besoins, sa licence couteuse et sa
+complexité sont problématiques pour une utilisation à !!acronym{HEPIA}.
 
-**TODO: expliquer que ce projet se rapproche le plus des objectifs du
-projet, qu'il a été développé initialement à l'université de Genève et a
-été utilisé à HEPIA par le passé avec succès. Expliquer le rachat par
-IBM et la problématique de la licence couteuse. Introduire l'intérêt
-d'une solution open source pour ne pas retomber dans le meme schéma.**
+Le développement d'une solution alternative _open-source_ plus simple et
+se basant sur des briques logicielles existantes a donc tout son
+intérêt.
+
+## !!acronym{FOG} project
 
-## Fog
 
 **TODO: expliquer le fonctionnement et les cas d'utilisation de fog,
 l'utilisation actuelle de ce système dans l'école, de ses limitations et
@@ -1514,7 +1528,6 @@ compte le temps passé à attendre un choix de l'utilisateur.
 
 ### Amélioration des logs
 
-
 Plusieurs améliorations ont été apportées au mécanisme de logging. Dans
 le système initial, les flux `stdin` et `stdout` du script de
 déploiement étaient redirigés vers un fichier de log sur le serveur.
@@ -1675,12 +1688,6 @@ un environnement de production.**
 **TODO: expliquer exactement comment sont structurées les données des
 images (raw et clonezilla).**
 
-## Système de personnalisation des images
-
-**TODO: expliquer en détails comment fonctionne le système de
-personnalisation des images, ce qui est nécéssaire sur le client et ce
-qui est nécessaire sur le serveur**
-
 # Utilisation du système déployé
 
 ## Déployer une image sur un poste