Une démonstration ne commence jamais à l’heure, mais un petit écran qui
permet d’attendre le début et qui permet à l’auditeur de se mettre en
situation n’est jamais de refus.
On ajoute aussi une petite dashboard qui résume la situation du système.
Quand le code appelle named-checkzone pour le contrôle de syntaxe DNS,
les messages renvoyés par cet utilitaire de contrôle sont lus et
interprétés, puis remontés à l’utilisateur.
Ce n’est pas parfait et ça donne une espèce de franglais, mais ça
suffira pour la démo et tant qu’on ne laisse pas les élèves manipuler
directement les fichiers de zone. Dans le cas contraire, il faudra
améliorer cela.
On met tout derrière un proxy inversé, ce qui permet d’avoir un seul
point de connexion depuis lequel on a accès à la console Web du
démonstrateur. La webmail est intégrée via une iframe.
Intégrer un petit éditeur de texte dans l’éditeur de zone DNS, pour améliorer
l’expérience utilisateur.
Par défaut, cet éditeur ne fournit pas de règles de coloration
syntaxique pour les fichiers de zones DNS. Il faut donc un build custom
qui l’ajoute.
On refait complètement la page de l’éditeur de zones pour que ce soit un
peu plus joli, et on active la coloration syntaxique pour le DNS.
Faire un sorte que le script puisse fonctionner en mode non interactif :
dans ce cas, sa sortie sur la console est du JSON. Cela permet ensuite à
une éventuelle API REST de facilement se pluguer dessus.
On peut générer des clefs DKIM mais on ne peut pas encore choisir quel
sélecteur utiliser pour signer les mails sortants.
Une fois DKIM activé pour un domaine, on ne peut pas non plus le
désactiver.