diff --git a/doc/rapport.gpp.md b/doc/rapport.gpp.md
index b703da83a5b4922475013c70dd2023cea562b1e9..3bcc609e66d544387b9a7ef1025056f613afbed7 100644
--- a/doc/rapport.gpp.md
+++ b/doc/rapport.gpp.md
@@ -307,9 +307,11 @@ Le composant central du système est un *serveur* linux qui inter-agit
avec les postes clients pour leur permettre d'effectuer plusieurs
actions:
-1. Recevoir une configuration IP et un chargeur d'amorcage à exécuter
- pour démarrer sur le réseau en utilisant le standard PXE.
-2. Analyser la signature présente sur le disque dur.
+1. Recevoir une configuration IP et un chargeur d'amorcage
+ !!acronym{GRUB} à exécuter pour démarrer sur le réseau en utilisant
+ le standard PXE.
+2. Analyser la signature présente sur le disque dur depuis le chargeur
+ d'amorçage chargeur d'amorcage !!acronym{GRUB}.
- Si elle n'est pas présente, amorcer un système d'exploitation
minimaliste servant à effectuer le choix d'une image et
d'automatiser son déploiement et sa mise en cache.
@@ -446,10 +448,10 @@ déployée ne fonctionnait pas. Pour des raisons non documentées,
le serveur !!acronym{TFTP}, qui lui même initie le démarrage depuis le
premier disque. Ce système ne fonctionnait pas: `ipxe` ne se lançait
même pas à cause d'un chemin invalide. De plus ce système rajoutait une
-étape inutile: !acronym{GRUB} est tout à fait capable de démarrer sur le
-premier disque. Le fichier de configuration de !acronym{GRUB} a donc été
-modifié pour directement démarrer sur le disque quand la signature est
-détectée à la fin du disque. Enfin, le système était fonctionnel.
+étape inutile: !!acronym{GRUB} est tout à fait capable de démarrer sur
+le premier disque. Le fichier de configuration de !!acronym{GRUB} a donc
+été modifié pour directement démarrer sur le disque quand la signature
+est détectée à la fin du disque. Enfin, le système était fonctionnel.
Pour faciliter l'utilisation et le développement du système dans le
futur, il a été décidé d'automatiser la création d'une machine virtuelle
@@ -463,19 +465,47 @@ fois ce fichier de configuration créé, une seule commande est nécessaire
pour créer, configurer et lancer un serveur fonctionnel dans une machine
virtuelle: `vagrant up`.
-!!svg{Logo du logiciel _Vagrant_}{images/vagrant_logo}
+!!svg{Logo du logiciel _Vagrant_ utilisé pour automatiser la création du serveur du système initial.}{images/vagrant_logo}
La distribution _Linux_ _Debian_ a été choisie comme !!acronym{OS} de
base de cette machine virtuelle, car elle est _open-source_, populaire,
stable et dispose de nombreux paquets. Elle est utilisée dans la version
_Buster_, qui est la version stable au moment de ce travail.
-!!svg{Logo de la distribution _Linux_ _Debian_}{images/debian_logo}
-
-## Limitations
-
-**TODO: énumérer les limitations de ce projet et des améliorations
-souhaitées**
+!!svg{Logo de la distribution _Linux_ _Debian_ utilisée comme base du serveur.}{images/debian_logo}
+
+## Limitations du projet initial
+
+Bien que le système du projet initial ait pu être mis en fonctionnement,
+il comporte de nombreuses limitations auxquelles il faudrait palier:
+
+- Les systèmes EFI ne sont pas supportés.
+- Les images prennent beaucoup de place et sont longues à transférer.
+- Les grosses images prennent beaucoup de temps à être déployées.
+- La création d'images nécessite plusieurs opérations en ligne de
+ commande, ce n'est pas très facile à utiliser.
+- Les scripts de déploiement sont fragiles et gèrent mal les erreurs.
+- Il n'y a pas de système de personnalisation d'image. Si on veut faire
+ $n$ personnalisation partant sur la base du même !!acronym{OS}, il
+ faut faire $n$ images: une pour chaque personnalisation.
+- L'installation de nouveaux outils sur le système d'exploitation de
+ l'!!acronym{OS} de déploiement créé avec _Buildroot_ peut être
+ compliqué si l'outil a beaucoup de dépendances.
+- Les dépendances du projet sont difficile à reproduire: il faut
+ disposer des bonnes dépendances et du bon environnement.
+- Les scripts de déploiement ne fonctionnent que si le client utilise
+ une interface réseau nommée `eth0`.
+- Les logs sauvés sur le serveur ne sont pas très complets et il est
+ difficile de diagnostiquer les erreurs et les timings des différentes
+ étapes à partir de ceux-ci.
+- Le système de déploiement doit sauver et restaurer un !!acronym{MBR}
+ sur le serveur pour utiliser sa partition cachée de cache des images.
+ Cela implique des lectures/écritures sur le disque et sur le partage
+ NFS du serveur qui prennent du temps et rajoutent de la complexité.
+ Étant donné que la position du cache est fixe (elle est calculée à
+ partir de la taille du disque, qui ne devrait pas changer), le client
+ devrait être capable de détecter et monter la partition sans dépendre
+ du serveur.
# Recherche et développement
diff --git a/doc/rapport.md b/doc/rapport.md
index 6350e9c0cf3cbc997821992d2ba935ed995f6d5b..7e736c85b87a16d0fed29a69e02f05f602cff9d0 100644
--- a/doc/rapport.md
+++ b/doc/rapport.md
@@ -272,9 +272,11 @@ Le composant central du système est un *serveur* linux qui inter-agit
avec les postes clients pour leur permettre d'effectuer plusieurs
actions:
-1. Recevoir une configuration IP et un chargeur d'amorcage à exécuter
- pour démarrer sur le réseau en utilisant le standard PXE.
-2. Analyser la signature présente sur le disque dur.
+1. Recevoir une configuration IP et un chargeur d'amorcage
+ <abbr title="_GRand Unified Bootloader ">GRUB</abbr> à exécuter pour démarrer sur le réseau en utilisant
+ le standard PXE.
+2. Analyser la signature présente sur le disque dur depuis le chargeur
+ d'amorçage chargeur d'amorcage <abbr title="_GRand Unified Bootloader ">GRUB</abbr>.
- Si elle n'est pas présente, amorcer un système d'exploitation
minimaliste servant à effectuer le choix d'une image et
d'automatiser son déploiement et sa mise en cache.
@@ -429,10 +431,10 @@ déployée ne fonctionnait pas. Pour des raisons non documentées,
le serveur <abbr title="Trivial File Transfer Protocol: protocole simplifié de transfert de fichiers ">TFTP</abbr>, qui lui même initie le démarrage depuis le
premier disque. Ce système ne fonctionnait pas: `ipxe` ne se lançait
même pas à cause d'un chemin invalide. De plus ce système rajoutait une
-étape inutile: !acronym{GRUB} est tout à fait capable de démarrer sur le
-premier disque. Le fichier de configuration de !acronym{GRUB} a donc été
-modifié pour directement démarrer sur le disque quand la signature est
-détectée à la fin du disque. Enfin, le système était fonctionnel.
+étape inutile: <abbr title="_GRand Unified Bootloader ">GRUB</abbr> est tout à fait capable de démarrer sur
+le premier disque. Le fichier de configuration de <abbr title="_GRand Unified Bootloader ">GRUB</abbr> a donc
+été modifié pour directement démarrer sur le disque quand la signature
+est détectée à la fin du disque. Enfin, le système était fonctionnel.
Pour faciliter l'utilisation et le développement du système dans le
futur, il a été décidé d'automatiser la création d'une machine virtuelle
@@ -446,19 +448,47 @@ fois ce fichier de configuration créé, une seule commande est nécessaire
pour créer, configurer et lancer un serveur fonctionnel dans une machine
virtuelle: `vagrant up`.
-
+
La distribution _Linux_ _Debian_ a été choisie comme <abbr title="Operating System: système d’exploitation ">OS</abbr> de
base de cette machine virtuelle, car elle est _open-source_, populaire,
stable et dispose de nombreux paquets. Elle est utilisée dans la version
_Buster_, qui est la version stable au moment de ce travail.
-
-
-## Limitations
-
-**TODO: énumérer les limitations de ce projet et des améliorations
-souhaitées**
+
+
+## Limitations du projet initial
+
+Bien que le système du projet initial ait pu être mis en fonctionnement,
+il comporte de nombreuses limitations auxquelles il faudrait palier:
+
+- Les systèmes EFI ne sont pas supportés.
+- Les images prennent beaucoup de place et sont longues à transférer.
+- Les grosses images prennent beaucoup de temps à être déployées.
+- La création d'images nécessite plusieurs opérations en ligne de
+ commande, ce n'est pas très facile à utiliser.
+- Les scripts de déploiement sont fragiles et gèrent mal les erreurs.
+- Il n'y a pas de système de personnalisation d'image. Si on veut faire
+ $n$ personnalisation partant sur la base du même <abbr title="Operating System: système d’exploitation ">OS</abbr>, il
+ faut faire $n$ images: une pour chaque personnalisation.
+- L'installation de nouveaux outils sur le système d'exploitation de
+ l'<abbr title="Operating System: système d’exploitation ">OS</abbr> de déploiement créé avec _Buildroot_ peut être
+ compliqué si l'outil a beaucoup de dépendances.
+- Les dépendances du projet sont difficile à reproduire: il faut
+ disposer des bonnes dépendances et du bon environnement.
+- Les scripts de déploiement ne fonctionnent que si le client utilise
+ une interface réseau nommée `eth0`.
+- Les logs sauvés sur le serveur ne sont pas très complets et il est
+ difficile de diagnostiquer les erreurs et les timings des différentes
+ étapes à partir de ceux-ci.
+- Le système de déploiement doit sauver et restaurer un <abbr title="Master Boot Record: enregistrement d’amorcage maître ">MBR</abbr>
+ sur le serveur pour utiliser sa partition cachée de cache des images.
+ Cela implique des lectures/écritures sur le disque et sur le partage
+ NFS du serveur qui prennent du temps et rajoutent de la complexité.
+ Étant donné que la position du cache est fixe (elle est calculée à
+ partir de la taille du disque, qui ne devrait pas changer), le client
+ devrait être capable de détecter et monter la partition sans dépendre
+ du serveur.
# Recherche et développement
diff --git a/doc/rapport.pdf b/doc/rapport.pdf
index 6528d8032d9feb8f2fb7f7526d19605f295e4b0a..77337a17e2b50b7c3daacdcdeb9e514b7ee36997 100644
Binary files a/doc/rapport.pdf and b/doc/rapport.pdf differ