- 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 <abbrtitle="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: <abbrtitle="_GRand Unified Bootloader ">GRUB</abbr> est tout à fait capable de démarrer sur
le premier disque. Le fichier de configuration de <abbrtitle="_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 <abbrtitle="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 <abbrtitle="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'<abbrtitle="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 <abbrtitle="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
