diff --git a/doc/rapport.gpp.md b/doc/rapport.gpp.md
index 75ad000fad6cced3a4b6f1f24d1030c1a18b1e11..9323ab327e036d11ded48d2f4670c519d6de376d 100644
--- a/doc/rapport.gpp.md
+++ b/doc/rapport.gpp.md
@@ -119,9 +119,6 @@ On désire aussi que le système de déploiement permette de customiser
certains aspects de l’image choisie. Ce travail ce base sur une ébauche
d’un travail déjà existant.
-**TODO: Reformuler ce texte: c'est le descriptif de l'énoncé écrit par
-F. Gluck**
-
## Objectifs
- Etude du travail existant.
@@ -144,9 +141,6 @@ F. Gluck**
- Si le temps le permet: optimisation de la bande passante du réseau
dans le cas de nombreux téléchargements effectués en parallèle.
-**TODO: Reformuler les objectifs: ils sont tirés de l'énoncé écrit par
-F. Gluck**
-
## Méthodologie de travail
**TODO: Expliquer comment le travail a été planifié, les meetings
@@ -1094,11 +1088,178 @@ utilisées.
## Amélioration de l'OS de déploiement
-**TODO: expliquer pourquoi le passage d'une image buildroot chargée d'un
-coup en mémoire à Debian avec un système de fichiers racine sur NFS
-apporte plus de flexibilité pour des temps de boot similaires. Expliquer
-la problématique de la gestion des paquets et de leur mise à jour avec
-buildroot. Parler aussi de l'impact du passage à systemd avec debian.**
+### _Buildroot_: l'outil de construction de l'!!acronym{OS} de déploiement initial
+
+L'image du système d'exploitation _Linux_ servant à l'exécution des
+scripts de déploiement dans le système initial est construit avec
+_Buildroot_. Cet outil permet de générer compiler un noyau linux, de
+créer un système de fichier racine minimal et de générer un chargeur
+d'amorçage (_bootloader_). Cet outil est principalement utilisé pour
+générer des systèmes embarqués. Il avait été choisi dans le système
+initial car il permettait de créer une image d'!!acronym{OS} très petite
+qui peut être téléchargée très rapidement sur le réseau.
+
+### Problèmes avec_Buildroot_ pour construire l'!!acronym{OS} de déploiement
+
+Buildroot permet d'installer facilement les paquets de nombreuses
+applications dans le système de fichiers de l'image. Malheureusement,
+aucun paquet n'existe pour _Clonezilla_. L'idée de créer un paquet pour
+ce logiciel a été étudiée, mais n'a pas été retenue, car il nécessite de
+nombreuses dépendances, et bien que cela aurait été possible de le
+faire, le temps à investir dans cette tâche aurait été considérable, et
+le résultat n'aurait été testable qu'une fois cette tâche accomplie. De
+plus, pour chaque mise à jour de _Clonezilla_ que l'on souhaiterait
+utiliser, par exemple pour profiter de l'implémentation d'un nouveau
+système de fichier ou des résolutions de bugs, il faudrait remettre à
+jour ce paquet.
+
+### Choix de _Debian_ pour remplaçer _Buildroot_
+
+Pour simplifier l'utilisation de _Clonezilla_ et de nombreux autres
+outils, le passsage à une solution alternative à _Buildroot_ a été
+décidé. De nombreuses distributions Linux proposent des paquets pour
+_Clonezilla_. Les plus intéressantes sont _Debian_ et _Ubuntu_ car
+l'équipe de _Clonezilla_ les utilise pour la version _live-CD_ de
+l'outil. Ils développent et distribuent eux-mêmes des paquets au format
+`deb` pour ces deux distributions. Un travail a donc été entrepris pour
+remplacer l'!!acronym{OS} de déploiement basé sur _Buildroot_ par un
+!!acronym{OS} basé sur _Debian_. Ce choix permettra d'utiliser
+facilement les nombreux paquets disponibles pour cette distribution si
+il y en a besoin dans les versions futures du système de déploiement.
+
+Le problème avec l'utilisation d'une distribution telle que _Debian_ est
+que la taille du système de fichiers racine n'est pas aussi réduite que
+ce que l'on peut obtenir avec _Buildroot_. La stratégie d'exécution du
+système d'exploitation a donc été modifiée pour tenir compte de ce
+changement de taille. Le système initial chargeait à chaque fois une
+image entière du système de fichiers racine (environ 100MB) en mémoire.
+Sur le nouveau système, seul le noyau linux est téléchargé, ainsi que
+l'image _initrd_. Le sytème de fichier racine est monté à partir d'un
+partage !!acronym{NFS}. Cela permet d'avoir un système de fichiers
+racine contenant beaucoup plus de données, mais de ne télécharger à
+travers le réseau que ceux qui sont utilisés, au moment où ils sont
+utilisés.
+
+### Création du système de fichiers racine _Debian_ avec _multistrap_
+
+Le système de fichiers racine accessible via un partage !!acronym{NFS}
+est créé en utilisant l'outil _multistrap_ fourni par Debian. Cet outil
+permet de générer un système de fichiers racine pour une architecture
+donnée, et d'y installer une liste de paquets choisie. Une fois le
+sytème de fichiers racine créé, certains fichiers de configurations
+doivent sont créés manuellement:
+
+- `/etc/hostname`: le nom d'hôte de la machine. Dans notre cas, la
+ valeur `bootiful-deployer` a été entrée.
+- `/etc/hosts`: la liste des hôtes connus. Dans notre cas, une seule
+ entrée est nécessaire: `127.0.0.1 localhost`
+- `/etc/fstab`: la liste de systèmes de fichiers à monter au démarrage.
+ Pour palier au fait que le système de fichiers racine sera en lecture
+ seule, plusieurs dossiers ont été montés en `tmpfs` (système de
+ fichier temporaire chargé en mémoire) afin de permettre aux processus
+ du système d'y écrire des fichiers: `/tmp`, `/dev`, `/var/run`,
+ `/var/lock`, `/var/tmp`, `/var/log`, `/var/lib/clonezilla`,
+ `/bootiful`
+- `/etc/mtab`: ce fichier contient la liste des volumes actuellement
+ montés. Au début, il n'avait pas été créé et cela causait une erreur
+ fatale dans _Partclone_, qui n'arrivait pas à détecter si une
+ partition était montée ou non. Cela a été résolu en créant ce fichier
+ comme un lien symbolique vers le fichier `/proc/mounts` qui est un
+ faux fichier généré en mémoire par le noyau _Linux_ et qui contient la
+ liste des points des volumes actuellement montés.
+
+Quelques autres fichiers sont rajoutés/remplacés dans le système de
+fichiers racine:
+
+- `/etc/initramfs.conf`: configuration pour générer une image
+ _initramfs_ qui va initialiser montage du système de fichiers racine
+ depuis un partage NFS
+- `/etc/systemd/system/bootiful-deploy-log.service`: configuration
+ d'unité _Systemd_ qui permet de lancer le script d'initialisation du
+ déploiement d'images au démarrage
+- `/usr/bin/bootiful-deploy-init`: script d'initialisation du
+ déploiement d'images. Lance le script de déploiement d'images et
+ affiche permet de choisir quelle action effectuer si le déploiement ne
+ se termine pas avec succès.
+- `/usr/bin/bootiful-common`: script contenant des fonctions communes
+ aux différents script de déploiement `bootiful-*`. Il n'est pas conçu
+ pour être exécuté directement, mais à être chargé par les autres
+ scripts avec la commande `source`.
+- `/usr/bin/bootiful-deploy`: script permettant le choix de l'image, des
+ configurations (si applicable), et d'effectuer le déploiement de
+ l'image choisie.
+- `/usr/bin/bootiful-save-image`: script utilitaire permettant de
+ construire une image avec _dd_. Il a été utilisé pour construire les
+ images des benchmarks, mais il vaut mieux utiliser le live-cd
+ _Clonezilla_ pour la création d'une nouvelle image.
+- `/usr/bin/bootiful-reset-cache`: script utilitaire permettant de
+ réinitialiser le cache des images. Il a été utilisé pour pouvoir
+ facilement réinitialiser le cache lors des benchmarks.
+
+Ensuite, la commande `chroot` est utilisée pour remplacer temporairement
+le système de fichier racine actuel de la machine (celle qui a lancé
+_multistrap_) par celui qui vient d'être créé. Plusieurs commandes sont
+lancées dans cet environnement pour initialiser le système:
+
+1. `dpkg --configure -a`: lance la configuration post-installation de
+ tous les paquets _Debian_.
+2. `apt-get autoremove --purge && apt-get clean`: désinstalle les
+ dépendances inutiles et vide le cache des paquets.
+3. `update-initramfs -u`: regénère une image _initramfs_ qui va
+ initialiser montage du système de fichiers racine depuis un partage
+ NFS en utilisant la configuration rajoutée précédemment dans
+ `/etc/initramfs.conf`.
+4. `systemctl enable bootiful-deploy-log.service`: active l'unité
+ _Systemd_ de lancement automatique du script de déploiement décrite
+ dans le fichier `/etc/systemd/system/bootiful-deploy-log.service`
+ ajouté précédemment.
+
+### Automatisation de la création du système de déploiement avec _Docker_
+
+Pour utiliser l'outil _multistrap_ afin de créer un système de fichier
+racine _Debian_, il faut que le programme `multistrap` soit lancé depuis
+un système d'exploitation _Debian_. Pour rendre la création de ce
+système de fichiers possible depuis d'autres distributions Linux, un
+conteneur _Docker_ a été créé.
+
+Le processus de création du système décrit dans la section précédente a
+été automatisé et est décrit dans un fichier `Dockerfile`. La nouvelle
+fonctionnalité de Docker de construction en plusieurs "étages"
+(_multi-stage build_) a été utilisée. Trois "étages" sont définis:
+
+- `build-stage`: depuis une image `debian:bullseye` construit une image
+ de système de fichier racine _Debian_ et le configure comme décrit
+ dans la section précédente. Le dossier `/boot/` est sorti du dossier
+ du système de fichiers racine nouvellement créé et déplacé dans
+ `/multistrap/boot`. Le reste du système de fichier racine (tout sauf
+ `/boot/` est compressé dans une archive `/multistrap/nfsroot.tar.gz`.
+ Cette étape est un pré-requis des étapes suivantes et n'est
+ normalement pas exécutée directement.
+- `nfs-export-stage`: dans une image vide (`FROM scratch`), copie le
+ fichier `/multistrap/nfsroot.tar.gz` depuis l'étape `build-stage`.
+ L'image de cette étape contient donc uniquement un fichier à sa
+ racine, `nfsroot.tar.gz`, qui pourra être exporté et extrait dans le
+ serveur !!acronym{NFS} pour être partagé.
+- `tftp-export-stage`: dans une image vide (`FROM scratch`), copie le
+ contenu du dossier `/multistrap/boot` depuis l'étape `build-stage`.
+ L'image de cette étape contient donc uniquement le contenu de la du
+ dossier `/boot/` de la partition racine, c'est à dire les fichiers
+ `initrd.img` (image _initrd_ initialisant le système de fichier racine
+ depuis !!acronym{NFS}) et `vmlinuz` (le noyau _Linux_). Le contenu de
+ cette image pourra être exporté dans le dossier partagé du serveur
+ !!acronym{TFTP}, afin d'être téléchargé depuis le logiciel d'amorçage
+ !!acronym{GRUB} pour lancer le système de déploiement.
+
+Le fichier `Makefile` à la racine du projet définit des cibles et des
+recettes pour exécuter `docker build` exporter les données des deux
+derniers étages dans leurs dossiers respectifs:
+- le contenu de l'étage `nfs-export-stage`, c'est à dire l'archive
+ `nfsroot.tar.gz`, est exportée dans le dossier `nfs/`. Elle sera
+ extraite dans le serveur !!acronym{NFS}.
+- le contenu de l'étage `tftp-export-stage`, c'est à dire `initrd.img`
+ et `vmlinuz` sont exportés dans le dossier
+ `tftp/tftpboot/boot/deployer` qui contient le système de déploiement
+ d'image servi par le serveur !!acronym{TFTP}.
## Réduction du temps de déploiement total
diff --git a/doc/rapport.md b/doc/rapport.md
index 613fe99aec535b4b3941264217cdfcc9bce74632..cc8f8903da80be927f997ba6a9d8233cf777f7f3 100644
--- a/doc/rapport.md
+++ b/doc/rapport.md
@@ -83,9 +83,6 @@ On désire aussi que le système de déploiement permette de customiser
certains aspects de l’image choisie. Ce travail ce base sur une ébauche
d’un travail déjà existant.
-**TODO: Reformuler ce texte: c'est le descriptif de l'énoncé écrit par
-F. Gluck**
-
## Objectifs
- Etude du travail existant.
@@ -108,9 +105,6 @@ F. Gluck**
- Si le temps le permet: optimisation de la bande passante du réseau
dans le cas de nombreux téléchargements effectués en parallèle.
-**TODO: Reformuler les objectifs: ils sont tirés de l'énoncé écrit par
-F. Gluck**
-
## Méthodologie de travail
**TODO: Expliquer comment le travail a été planifié, les meetings
@@ -1151,11 +1145,178 @@ utilisées.
## Amélioration de l'OS de déploiement
-**TODO: expliquer pourquoi le passage d'une image buildroot chargée d'un
-coup en mémoire à Debian avec un système de fichiers racine sur NFS
-apporte plus de flexibilité pour des temps de boot similaires. Expliquer
-la problématique de la gestion des paquets et de leur mise à jour avec
-buildroot. Parler aussi de l'impact du passage à systemd avec debian.**
+### _Buildroot_: l'outil de construction de l'<abbr title="Operating System: système d’exploitation ">OS</abbr> de déploiement initial
+
+L'image du système d'exploitation _Linux_ servant à l'exécution des
+scripts de déploiement dans le système initial est construit avec
+_Buildroot_. Cet outil permet de générer compiler un noyau linux, de
+créer un système de fichier racine minimal et de générer un chargeur
+d'amorçage (_bootloader_). Cet outil est principalement utilisé pour
+générer des systèmes embarqués. Il avait été choisi dans le système
+initial car il permettait de créer une image d'<abbr title="Operating System: système d’exploitation ">OS</abbr> très petite
+qui peut être téléchargée très rapidement sur le réseau.
+
+### Problèmes avec_Buildroot_ pour construire l'<abbr title="Operating System: système d’exploitation ">OS</abbr> de déploiement
+
+Buildroot permet d'installer facilement les paquets de nombreuses
+applications dans le système de fichiers de l'image. Malheureusement,
+aucun paquet n'existe pour _Clonezilla_. L'idée de créer un paquet pour
+ce logiciel a été étudiée, mais n'a pas été retenue, car il nécessite de
+nombreuses dépendances, et bien que cela aurait été possible de le
+faire, le temps à investir dans cette tâche aurait été considérable, et
+le résultat n'aurait été testable qu'une fois cette tâche accomplie. De
+plus, pour chaque mise à jour de _Clonezilla_ que l'on souhaiterait
+utiliser, par exemple pour profiter de l'implémentation d'un nouveau
+système de fichier ou des résolutions de bugs, il faudrait remettre à
+jour ce paquet.
+
+### Choix de _Debian_ pour remplaçer _Buildroot_
+
+Pour simplifier l'utilisation de _Clonezilla_ et de nombreux autres
+outils, le passsage à une solution alternative à _Buildroot_ a été
+décidé. De nombreuses distributions Linux proposent des paquets pour
+_Clonezilla_. Les plus intéressantes sont _Debian_ et _Ubuntu_ car
+l'équipe de _Clonezilla_ les utilise pour la version _live-CD_ de
+l'outil. Ils développent et distribuent eux-mêmes des paquets au format
+`deb` pour ces deux distributions. Un travail a donc été entrepris pour
+remplacer l'<abbr title="Operating System: système d’exploitation ">OS</abbr> de déploiement basé sur _Buildroot_ par un
+<abbr title="Operating System: système d’exploitation ">OS</abbr> basé sur _Debian_. Ce choix permettra d'utiliser
+facilement les nombreux paquets disponibles pour cette distribution si
+il y en a besoin dans les versions futures du système de déploiement.
+
+Le problème avec l'utilisation d'une distribution telle que _Debian_ est
+que la taille du système de fichiers racine n'est pas aussi réduite que
+ce que l'on peut obtenir avec _Buildroot_. La stratégie d'exécution du
+système d'exploitation a donc été modifiée pour tenir compte de ce
+changement de taille. Le système initial chargeait à chaque fois une
+image entière du système de fichiers racine (environ 100MB) en mémoire.
+Sur le nouveau système, seul le noyau linux est téléchargé, ainsi que
+l'image _initrd_. Le sytème de fichier racine est monté à partir d'un
+partage <abbr title="Network File System: système de fichiers en réseau ">NFS</abbr>. Cela permet d'avoir un système de fichiers
+racine contenant beaucoup plus de données, mais de ne télécharger à
+travers le réseau que ceux qui sont utilisés, au moment où ils sont
+utilisés.
+
+### Création du système de fichiers racine _Debian_ avec _multistrap_
+
+Le système de fichiers racine accessible via un partage <abbr title="Network File System: système de fichiers en réseau ">NFS</abbr>
+est créé en utilisant l'outil _multistrap_ fourni par Debian. Cet outil
+permet de générer un système de fichiers racine pour une architecture
+donnée, et d'y installer une liste de paquets choisie. Une fois le
+sytème de fichiers racine créé, certains fichiers de configurations
+doivent sont créés manuellement:
+
+- `/etc/hostname`: le nom d'hôte de la machine. Dans notre cas, la
+ valeur `bootiful-deployer` a été entrée.
+- `/etc/hosts`: la liste des hôtes connus. Dans notre cas, une seule
+ entrée est nécessaire: `127.0.0.1 localhost`
+- `/etc/fstab`: la liste de systèmes de fichiers à monter au démarrage.
+ Pour palier au fait que le système de fichiers racine sera en lecture
+ seule, plusieurs dossiers ont été montés en `tmpfs` (système de
+ fichier temporaire chargé en mémoire) afin de permettre aux processus
+ du système d'y écrire des fichiers: `/tmp`, `/dev`, `/var/run`,
+ `/var/lock`, `/var/tmp`, `/var/log`, `/var/lib/clonezilla`,
+ `/bootiful`
+- `/etc/mtab`: ce fichier contient la liste des volumes actuellement
+ montés. Au début, il n'avait pas été créé et cela causait une erreur
+ fatale dans _Partclone_, qui n'arrivait pas à détecter si une
+ partition était montée ou non. Cela a été résolu en créant ce fichier
+ comme un lien symbolique vers le fichier `/proc/mounts` qui est un
+ faux fichier généré en mémoire par le noyau _Linux_ et qui contient la
+ liste des points des volumes actuellement montés.
+
+Quelques autres fichiers sont rajoutés/remplacés dans le système de
+fichiers racine:
+
+- `/etc/initramfs.conf`: configuration pour générer une image
+ _initramfs_ qui va initialiser montage du système de fichiers racine
+ depuis un partage NFS
+- `/etc/systemd/system/bootiful-deploy-log.service`: configuration
+ d'unité _Systemd_ qui permet de lancer le script d'initialisation du
+ déploiement d'images au démarrage
+- `/usr/bin/bootiful-deploy-init`: script d'initialisation du
+ déploiement d'images. Lance le script de déploiement d'images et
+ affiche permet de choisir quelle action effectuer si le déploiement ne
+ se termine pas avec succès.
+- `/usr/bin/bootiful-common`: script contenant des fonctions communes
+ aux différents script de déploiement `bootiful-*`. Il n'est pas conçu
+ pour être exécuté directement, mais à être chargé par les autres
+ scripts avec la commande `source`.
+- `/usr/bin/bootiful-deploy`: script permettant le choix de l'image, des
+ configurations (si applicable), et d'effectuer le déploiement de
+ l'image choisie.
+- `/usr/bin/bootiful-save-image`: script utilitaire permettant de
+ construire une image avec _dd_. Il a été utilisé pour construire les
+ images des benchmarks, mais il vaut mieux utiliser le live-cd
+ _Clonezilla_ pour la création d'une nouvelle image.
+- `/usr/bin/bootiful-reset-cache`: script utilitaire permettant de
+ réinitialiser le cache des images. Il a été utilisé pour pouvoir
+ facilement réinitialiser le cache lors des benchmarks.
+
+Ensuite, la commande `chroot` est utilisée pour remplacer temporairement
+le système de fichier racine actuel de la machine (celle qui a lancé
+_multistrap_) par celui qui vient d'être créé. Plusieurs commandes sont
+lancées dans cet environnement pour initialiser le système:
+
+1. `dpkg --configure -a`: lance la configuration post-installation de
+ tous les paquets _Debian_.
+2. `apt-get autoremove --purge && apt-get clean`: désinstalle les
+ dépendances inutiles et vide le cache des paquets.
+3. `update-initramfs -u`: regénère une image _initramfs_ qui va
+ initialiser montage du système de fichiers racine depuis un partage
+ NFS en utilisant la configuration rajoutée précédemment dans
+ `/etc/initramfs.conf`.
+4. `systemctl enable bootiful-deploy-log.service`: active l'unité
+ _Systemd_ de lancement automatique du script de déploiement décrite
+ dans le fichier `/etc/systemd/system/bootiful-deploy-log.service`
+ ajouté précédemment.
+
+### Automatisation de la création du système de déploiement avec _Docker_
+
+Pour utiliser l'outil _multistrap_ afin de créer un système de fichier
+racine _Debian_, il faut que le programme `multistrap` soit lancé depuis
+un système d'exploitation _Debian_. Pour rendre la création de ce
+système de fichiers possible depuis d'autres distributions Linux, un
+conteneur _Docker_ a été créé.
+
+Le processus de création du système décrit dans la section précédente a
+été automatisé et est décrit dans un fichier `Dockerfile`. La nouvelle
+fonctionnalité de Docker de construction en plusieurs "étages"
+(_multi-stage build_) a été utilisée. Trois "étages" sont définis:
+
+- `build-stage`: depuis une image `debian:bullseye` construit une image
+ de système de fichier racine _Debian_ et le configure comme décrit
+ dans la section précédente. Le dossier `/boot/` est sorti du dossier
+ du système de fichiers racine nouvellement créé et déplacé dans
+ `/multistrap/boot`. Le reste du système de fichier racine (tout sauf
+ `/boot/` est compressé dans une archive `/multistrap/nfsroot.tar.gz`.
+ Cette étape est un pré-requis des étapes suivantes et n'est
+ normalement pas exécutée directement.
+- `nfs-export-stage`: dans une image vide (`FROM scratch`), copie le
+ fichier `/multistrap/nfsroot.tar.gz` depuis l'étape `build-stage`.
+ L'image de cette étape contient donc uniquement un fichier à sa
+ racine, `nfsroot.tar.gz`, qui pourra être exporté et extrait dans le
+ serveur <abbr title="Network File System: système de fichiers en réseau ">NFS</abbr> pour être partagé.
+- `tftp-export-stage`: dans une image vide (`FROM scratch`), copie le
+ contenu du dossier `/multistrap/boot` depuis l'étape `build-stage`.
+ L'image de cette étape contient donc uniquement le contenu de la du
+ dossier `/boot/` de la partition racine, c'est à dire les fichiers
+ `initrd.img` (image _initrd_ initialisant le système de fichier racine
+ depuis <abbr title="Network File System: système de fichiers en réseau ">NFS</abbr>) et `vmlinuz` (le noyau _Linux_). Le contenu de
+ cette image pourra être exporté dans le dossier partagé du serveur
+ <abbr title="Trivial File Transfer Protocol: protocole simplifié de transfert de fichiers ">TFTP</abbr>, afin d'être téléchargé depuis le logiciel d'amorçage
+ <abbr title="GRand Unified Bootloader ">GRUB</abbr> pour lancer le système de déploiement.
+
+Le fichier `Makefile` à la racine du projet définit des cibles et des
+recettes pour exécuter `docker build` exporter les données des deux
+derniers étages dans leurs dossiers respectifs:
+- le contenu de l'étage `nfs-export-stage`, c'est à dire l'archive
+ `nfsroot.tar.gz`, est exportée dans le dossier `nfs/`. Elle sera
+ extraite dans le serveur <abbr title="Network File System: système de fichiers en réseau ">NFS</abbr>.
+- le contenu de l'étage `tftp-export-stage`, c'est à dire `initrd.img`
+ et `vmlinuz` sont exportés dans le dossier
+ `tftp/tftpboot/boot/deployer` qui contient le système de déploiement
+ d'image servi par le serveur <abbr title="Trivial File Transfer Protocol: protocole simplifié de transfert de fichiers ">TFTP</abbr>.
## Réduction du temps de déploiement total
diff --git a/doc/rapport.pdf b/doc/rapport.pdf
index 505b8f93c3744065248e94e3252497fbdd635700..7683dcab65d32b3ecb7c75be0d85b3a75fb59225 100644
Binary files a/doc/rapport.pdf and b/doc/rapport.pdf differ