• Correction des modules : Création d'un serveur Debian sur une machine virtuelle VirtualBox avec LVM,Connexion à un serveur SSH, Déploiement d'un serveur web sur un serveur Linux
• Module PostgreSQL 1 : Gérer les connexions et les droits utilisateurs sous PostgreSQL
• Module PostgreSQL 2 : Sauvegarde et restauration d'une base de données sous PostgreSQL
• Module Domain Name System
• Modules Linux journey : Diagrammes UML et le document XSL permettant de transformer le XML qu’on a obtenu à partir des documents du repo Git de Linuxjourney. Vous pouvez trouver ces documents ainsi que les codes sources d’Alexis sur ce repo.

Nous n’avons pas axé les modules sur des thématiques spécifiques. Il s’agissait surtout d’aborder des points d’administration système importants et méconnus, particulièrement à l’UTC.

Pour les modules que j’ai réalisé, j’ai choisi de faire toujours un exercice ou un quiz bilan à la fin de chaque partie. On essayait aussi de proposer autant que possible des manipulations qui sont très efficaces pour faire comprendre des concepts. Dans cette optique, le module DNS a été articulé autour d’une commande. Cela permet de construire petit à petit des connaissances autour de cette commande. L’apprenant est ainsi un peu plus impliqué dans son apprentissage car on l’incite très fortement à manipuler

Les modules Linux Journey sont un peu particuliers car notre travail était de récupérer le contenu des cours du site Linux Journey. Il faut savoir que le contenu de Linux Journey (très riche et intéressant) est libre mais le support ne l’est pas donc nous avons préféré ne pas contribuer directement sur leur support. On finit donc en récupérant le contenu et en le transposant sur Scenari (notre support). Ce travail appelle à une suite qui consistera à créer des exos et des TP pour faire mieux comprendre le contenu de Linux Journey, contenu manquant de pratique.

Vous vous rendez sur ce repo dans lequel tous les fichiers du repo Git officiel de Linux journey sont présents.

Sur le repo officiel de Linux Journey, vous trouverez les grains de cours du site dans des fichiers .md (écrits en pseudo markdown).

Pour obtenir un cours Scenari après cela vous avez simplement à suivre les 3 étapes suivantes:

Ce parseur va :

1. Transformer le fichier en xhtml grâce à une bibliothèque
2. Transformer le xhtml dans un xml particulier

Vous utilisez donc ce parseur pour transformer un fichier markdown en fichier xml.

Vous obtenez donc un premier ficheir xml que vous ne pouvez pas utiliser dans Scenari.

Si vous ne connaissez pas XSLT, je vous invite à lire la page wikipédia traitant du sujet.

Il vous suffit de prendre le fichier xml parsé et de la transformer soit grâce à Oxygen XML Editor soit avec le site suivant : https://www.freeformatter.com/xsl-transformer.html.

Après cette étape, vous avez un nouveau fichier XML utilisable dans Scenari.

Je n’ai pas eu le temps d’intégrer la transformation au parseur. Il serait donc préférable d’intégrer cette transformation à parser.py grâce à la librairie lxml.

Vous n’avez plus qu’à glisser et déposer le fichier xmlToScenari.xsl dans Scenari.

NB: le XML formera une activité d’apprentissage dans Scenari. On a choisi de faire une activité d’apprentissage pour pouvoir intégrer les petits quiz qu’on trouve dans chaque leçon de Linux Journey. Il ne reste qu’à écrire des TPs pour compléter ce contenu Linux Journey.

Voici un petit schéma illustrant la transformation depuis fichier source de Linux journey jusqu’à l’obtention d’un fichier déposable et utilisable dans Scenari:

Dans ce document, j’ai fait le choix de stocker le titre de chaque cours dans une variable. Ceci était nécessaire car pour que les partie contenu et exercice d’une activité d’apprentissage soient valides, elles nécessitent un titre.

Si par la suite, d’autres problèmes d’absence de titre apparaissent, vous n’aurez qu’à insérer la valeur de cette variable.

Il faut bien avoir en tête qu’une modification sur le parsage du fichier Linux Journey entraînera une nécessaire modification du XSL. En effet, le XSL prend en compte le XML parsé sous sa forme actuelle. Si vous modifiez certaines balises, il sera nécessaire de faire un nombre de changements plus ou moins grand sur le XSL. Si vous ajoutez des balises, il suffira d’ajouter quelques lignes et la transformation se fera sans encombre. On peut également envisager d’ajouter des attributs.

Pour illustrer ceci, prenons l’exemple des listes. Notre modèle XML n’incorpore pas les listes dans les paragraphes, les listes ont des balises à part entière. Il y a donc eu le choix de créer un paragraphe à part entière dans Scenari pour chaque liste dans l’activité d’apprentissage finale. On note, grâce aux captures ci-dessous, que cela n’a aucune incidence sur le rendu visuel du cours:

Si un jour, le parsage incluait les listes dans les balises paragraphe, il y aurait des changements importants à faire sur le XSL, particulièrement dans les templates traitant du corps de la leçon, du paragraphe et des listes.

On constate que si un jour vous souhaitiez améliorer le parsage des listes, il faudrait favoriser les ajouts pour éviter de devoir réécrire une grande partie du XSL.

Les listes sont un exemple parmi tant d’autres. A chaque amélioration, il faudra avoir cette idée d’ajout en tête.

J’ai personnellement remarqué deux points que ne sont pas encore pris en compte dans le parsage:

• les sous-titres
• les liens

Pour effectuer ces améliorations, il sera donc préférable de prendre en compte les paragraphes précédents traitant des choix.

EDIT : ces améliorations ont été intégrées au parseur en fin de semestre. Il est désormais nécessaire de mettre à jour la transformation XSL.

Il faut également intégrer la transformation XSL au parseur comme dit précédemment.

• Correction des modules : Création d'un serveur Debian sur une machine virtuelle VirtualBox avec LVM,Connexion à un serveur SSH, Déploiement d'un serveur web sur un serveur Linux
• Modules Docker Basics I et Docker Basics II.
  * Fork du projet linuxjourney afin d’intégrer le contenu (open source) des cours/exercices du site dans SCENARI. Création de scripts pour la création d’un schéma xml, la génération et finalement la validation des fichiers xml correspondant aux différents cours.

Docker Basics a été le premier module que j’ai effectué. Les deux seules choses que je connaissais de Docker avant cette TX étaient son nom, et sa réputation. La première phase a donc été une phase de documentation. L’étude de Docker, la compréhension des notions clés qui y sont liées pour enfin passer sur la pratique sur Docker ont été les étapes préalable à l’élaboration du module. Une fois ces notions intégrées (et il faut avouer que cela m’a pris du temps), je me suis attaché à la synthétisation des éléments qui me semblaient les plus pertinents afin de comprendre le fonctionnement mais également la puissance de Docker. Plusieurs exercices d’application me sont venus en tête afin de remplir la fonction principale des modules : faire pratiquer. Docker Basics s’articule en 3 parties principales :

• Philosophie des conteneurs
• Utilisation de Docker
• Dockerfile : une procédure légère et efficace

Pour les deux dernière parties (qui relèvent plus de la pratique que de la théorie), au moins deux exercices complets ont été proposés, basé sur des indices afin que la résolution des questions successives soit guidée et segmentée.

Ce module est donc la prémice du module que j’ai effectué durant l’été suivant la TX: Docker Basics II.

Initialement appelé Docker Advanced, je me suis vite rendu compte qu’il était un peu prétentieux d’appeler ce module “avancé”. Docker présentant des possibilités si vastes, qu’il fallait au moins un autre module Basics pour aborder les notions principales : docker-compose, le networking et les Volumes Docker.

Avant de pouvoir commencer à élaborer ce module, il m’a fallu une bonne phase de documentation et d’expérimentation. Beaucoup de notions nouvelles m’ont souvent contraint à ouvrir une cinquantaine d’onglet sur la même fenêtre, témoin de mon apprentissage intensif.

Ce module est construit de sorte à acquérir une aisance de manipulation de Docker au fur et à mesure de son avancée. On y découvre les principes fondamentaux des notions abordées en pratiquant lors des exercices guidés.

Il serait bon que ce module soit testé par une audience et, j’en suis convaincu, ajusté en conséquence.

Comme dit précédemment, le but de ce travail est d’automatiser l’intégration d’un contenu open source, disponible sur un dépôt git directement dans un format Scenari-compliant. Ce travail a été effectué avec le language de programmation python.

Il s’est décomposé en 3 phrases.

• Un fork a été effectué, puis un script a été créé afin de pouvoir parcourir l’arborescence et découvrir de manière logique chaque fichier le composant

• Une fois les fichiers accessibles un à un, il a fallu en dégager une structure commune. Ce travail a été commencé en UML par Marc, et je l’ai formalisé dans un schéma Relax NG, language de description de fichier XML.

• Dans cette partie a eu lieu le véritable parsing de l’information. Le but étant d’à partir d’une fichier écrit en markdown (.md), arriver à un fichier .xml bien formé, mais surtout valide au schéma que l’on modélisé à l’étape précédente. Pour ce faire, le fichier markdown a été transformé en fichier HTML. Grâce à la librairie lxml et XSLT, il a été ensuite possible de transformer ce HTML en XML suivant le schéma RelaxNG modélisé. Marc a donc pu s’en servir comme base, pour continuer le travail et intégrer les contenus dans SCENARI.
• Suite à une non conformité de la méthode utilisée, le script python a du être revu et réécrit afin de switcher de technologie. Désormais le parseur utilise le XSLT, et xpath. Ce choix est logique notamment dans le sens de la maintenance : Marc utilisant cette technologie, une personne maîtrisant XSLT (avec un soupçon de python), pourra maintenir à jour les scripts facilement.

Quelques fichiers sources n’étant originellement pas bien formés, il a parfois été impossible de procéder à leur validation. Changer notre schéma pour le rendre flexible et compatible avec ces fichiers mal formés n’est pas une option envisageable, car remettrait en cause le principe même d’avoir un schéma.

Sur les cours disponibles en anglais, nous avons un taux de 183/185 leçons validées. En français, ce taux est de 29/30.

Tous les fichiers sources se trouvent sur le repo du GitLab de l’UTC : https://gitlab.utc.fr/renardal/linuxjourney-xml. Le dépôt est tagué au commit de fin de la TX, mais l’archive reflétant ce travail réalisé est également disponible ici.