Add latest tutorial revision

tutorial/ansible/Makefile

@@ -1,15 +1,18 @@
 include ../pandoc-opts.mk
 
 SOURCES_2	= tutorial-2.md setup.md maatma.md what.md netfilter.md anssi.md vitrine.md nameserver.md nameserver-anssi.md nameserver-troubleshooting.md
-SOURCES_ANSIBLE	= tutorial.md ansible.md deploiement-svc.md rendu.md
+SOURCES_ANSIBLE	= tutorial.md ansible.md rendu.md
+PROJECT		= project.md
 
 
-all: tutorial-2.pdf tutorial-ansible.pdf
+all: tutorial-2.pdf tutorial-ansible.pdf project.pdf
 
 tutorial-2.pdf: ${SOURCES_2}
 	pandoc ${PANDOCOPTS} -o $@ $+
 tutorial-ansible.pdf: ${SOURCES_ANSIBLE}
 	pandoc ${PANDOCOPTS} -o $@ $+
+project.pdf: ${PROJECT}
+	pandoc ${PANDOCOPTS} -o $@ $+
 
 clean::
-	rm tutorial-2.pdf tutorial-ansible.pdf
+	rm tutorial-2.pdf tutorial-ansible.pdf project.pdf

tutorial/ansible/ansible-advanced.md

@@ -0,0 +1,32 @@
+\newpage
+
+Mieux utiliser Ansible
+======================
+
+Nous savons maintenant utiliser `ansible` et tirer parti des *playbooks* pour automatiser l'installation et la configuration de nos machines.
+
+Nous avons vu toute la puissance des *playbooks* : en automatisant les tâches d'administration de nos machines, on réduit les risques d'erreurs humaines, tout en écartant les tâches répétitives de mise à jour, ... Néanmoins, nos *playbooks* peuvent devenir rapidement redondant (peut-être avez-vous géré l'ouverture des ports du pare-feu dans chaque *playbooks* : 80 et 443 dans le playbook `vitrine.yml` et 53 dans le *playbook* `nameserver.yml` ?).
+
+Nous allons maintenant voir les roles Ansible qui résolvent ce problème en proposant un moyen standardisé et organisé de décomposer les tâches en composants plus petits et réutilisables.
+
+
+Apprivoiser les rôles
+---------------------
+
+Les rôles Ansible sont un concept clef d'Ansible, conçus pour rationaliser et organiser nos configurations. Il s'agit d'avoir une approche modulaire : de la même manière que l'on essaie de factoriser les parties redondantes lorsque l'on programme une fonction, les rôles vont nous permettre de réutiliser des briques de configuration entre plusieurs *playbooks*.
+
+Concrètement, les rôles Ansible regroupent un ensemble de tâches, *handlers*, variables, fichiers/modèles. En les concevant correctement, on peut aisément les partager entre différents projets.
+
+
+
+### Structure d'un rôle
+
+
+### Utilisation d'un rôle
+
+
+###
+
+
+Bonnes pratiques
+================

tutorial/ansible/ansible.md

@@ -4,11 +4,12 @@ Automatiser la configuration de son SI
 =======================================
 
 Comme tout bon ~~paresseux~~ sys. admin qui se respecte, sans plus attendre,
-vous allez vouloir automatiser toutes ces actions rébarbatives (configurer des
+nous allons vouloir automatiser toutes les actions rébarbatives que nous avons
-services). Comme de très nombreuses personnes sont passées par là avant vous,
+faites jusque là. Comme de très nombreuses personnes sont passées par là avant
-il existe un grand nombre de solutions pour gérer les configurations d'un parc
+nous, il existe un grand nombre de solutions pour gérer les configurations d'un
-de machines. Parmi les plus connues, citons : [Puppet](https://puppet.com/),
+parc de machines. Parmi les plus connues, citons :
-[Chef](http://www.chef.io/), [SaltStack](https://saltstack.com/) ou encore
+[Puppet](https://puppet.com/), [Chef](https://www.chef.io/),
+[SaltStack](https://saltstack.com/) ou encore
 [Ansible](https://www.ansible.com/).
 
 
@@ -17,40 +18,49 @@ Introduction à Ansible
 
 Ansible est une solution de gestion de configuration. Basé sur
 [Python](https://www.python.org/) et
-[YAML](http://www.yaml.org/spec/1.2/spec.html), sa principale particularité est
+[YAML](https://www.yaml.org/spec/1.2/spec.html), sa principale particularité est
 de ne pas nécessiter de daemon sur les machines qu'il va gérer : tout se fait
 exclusivement via SSH, à partir de la machine d'un administrateur, possédant
 Ansible (ou bien d'un système de gestion de configuration tel qu'[Ansible
-Tower](https://www.ansible.com/products/tower) ou
+Tower](https://www.ansible.com/products/tower),
-[AWX](https://github.com/ansible/awx)).
+[AWX](https://github.com/ansible/awx) ou [Semaphore](https://github.com/ansible-semaphore/semaphore/)).
 
 Son installation est très simple, car les dépendances sont minimes et l'outil
 n'a pas besoin de base de données pour fonctionner : tout va se faire à partir
 d'une arborescence de fichiers, qui sera gérée par Git.
 
-Commencez par installer Ansible, sur une machine distincte de la machine
+Commençons par installer Ansible, sur une machine distincte de la machine
-virtuelle démarrée : la machine hôte sera parfaitement adaptée à cette tâche,
+virtuelle démarrée : la machine hôte sera parfaitement adaptée à cette
-d'autant plus que l'installation de la plate-forme est propre et légère : vous
+tâche. Mais vous pouvez aussi choisir de l'installer dans une seconde machine
-ne risquez pas de vous retrouver avec une usine à gaz impossible à retirer.
+virtuelle.
 
-[Consultez la procédure d'installation pour votre distribution ici](http://docs.ansible.com/ansible/latest/intro_installation.html).
+[Consultez la procédure d'installation pour votre distribution ici](https://docs.ansible.com/ansible/latest/intro_installation.html).
 
 
 Résultat attendu
 ----------------
 
-À la fin de cette partie, vous devez être en mesure de déployer une nouvelle
+À la fin de ce TP, vous devez être en mesure de déployer une nouvelle
-machine, identique à celle que vous venez de configurer, à partir d'une ISO et
+machine, identique à celle que vous avez configurée, à partir d'une ISO et
 d'un nouveau disque.
 
-Le fichier à rendre est un *playbook* `login-x-TP2/basis.yml`, accompagné de
+Vous devrez pour cela réaliser des *playbooks* :
-toutes ses dépendances : celui-ci doit faire les configurations basiques du
+  - `basis.yml`, accompagné de toutes ses dépendances : celui-ci doit faire les
-système et des utilisateurs.
+    configurations **minimales** du système et des utilisateurs (le seul
+    *playbook* qui se connecte à l'utilisateur `root` directement, retirez le
+    maximum de chose de ce *playbook* qui pourraient aller dans le suivant).
 
-Un deuxième playbook est à rendre : `login-x-TP2/vitrine.yml`, celui-ci doit
+  - `securing.yml`, accompagné de toutes ses dépendances : ce *playbook* doit
-permettre de déployer, une page vitrine typique d'une entreprise (cf. la 4e
+    s'occuper de toute l'installation de la machine pour qu'elle soit aussi
-question de cours ;)). Cette page doit être accessible depuis votre domaine
+    sécurisée que possible.
-<https://login-x.adlin2024.example.tld/>.\
+
+  - `vitrine.yml` et ses dépendances : celui-ci
+    doit permettre de déployer une page vitrine typique d'une entreprise. Cette
+    page doit être accessible depuis votre domaine
+    <https://login-x.adlin2024.example.tld/>.
+
+  - `name-server.yml` et ses dépendances : celui-ci doit mettre en place le
+    serveur DNS faisant autorité sur le domaine qui vous est concédé.
 
 ::::: {.warning}
 
@@ -96,14 +106,15 @@ Plus tard, c'est dans ce fichier que vous pourrez créer des groupes de machines
 (pour, par exemple, regrouper les serveurs web, les bases de données, etc.) ou
 donner des caractéristiques spécifiques à vos machines.
 
+[Plus d'infos sur le fichier d'inventaire par ici.](https://docs.ansible.com/ansible/latest/inventory_guide/index.html)
 
 ### `ping`
 
-Lancez ensuite la commande suivante :
+Lançons maintenant la commande suivante :
 
 <div lang="en-US">
 ```
-42sh$ ansible --inventory-file hosts all --module-name ping --user root
+42sh$ ansible --inventory-file hosts all --user root --module-name ping
 192.168.0.106 | SUCCESS => {
     "changed": false,
 	"ping": "pong"
@@ -111,9 +122,11 @@ Lancez ensuite la commande suivante :
 ```
 </div>
 
+Nous demandons avec cette commande, qu'`ansible` utilise le fichier d'inventaire `hosts` ; `all` est un filtre qui nous permet d'indiquer les machines auxquelles on souhaite se restreindre (`all`, on va lancer le module sur toutes les machines de l'inventaire). L'option `--user` précise le nom de l'utilisateur que l'on veut utiliser pour la connexion SSH. Enfin nous avons les options du modules, et cela commence par le nom du module lui-même.
+
 Vous devriez avoir un retour similaire à celui-ci, indiquant simplement que la
-connexion a bien été effectuée et que le nécessaire est bien installé sur la
+connexion a bien été effectuée et que le nécessaire pour utiliser Ansible est
-machine distance.\
+bien installé sur la machine distance.\
 
 ::::: {.question}
 
@@ -123,26 +136,114 @@ compte, sinon vous obtiendrez une erreur plutôt incompréhensible.
 
 :::::
 
+En ajoutant une seconde machine dans notre inventaire, nous aurions quelque chose comme cela :
+
+<div lang="en-US">
+```
+42sh$ ansible --inventory-file hosts all --user root --module-name ping
+192.168.0.106 | SUCCESS => {
+    "changed": false,
+	"ping": "pong"
+}
+192.168.0.142 | SUCCESS => {
+    "changed": false,
+	"ping": "pong"
+}
+```
+</div>
+
+
 ### Confort
 
-Une des premières choses que nous devrions faire, est d'installer notre clef
+Une des premières choses que nous devrions faire, est de nous créer un
-SSH sur les machines, pour éviter d'avoir à taper le mot de passe à chaque
+utilisateur puis d'installer notre clef SSH sur les machines, pour éviter
-test.
+d'avoir à taper le mot de passe à chaque test.
 
-Si vous avez bien suivi jusqu'ici, vous savez qu'il ne faut pas utiliser le
+Pour créer notre utilisateur, nous pouvons utiliser le [module `user`](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html) :
-compte `root` directement ! Pas d'inquiétude, tout est prévu dans Ansible :
-retirer l'option `--user root` si votre nom d'utilisateur local est identique
-que celui dans la machine virtuelle, ou adaptez l'option en conséquence.
 
-Et ajoutez les options `--become` et `--ask-become-pass` (utilisez `--sudo` et
+<div lang="en-US">
+```
+42sh$ ansible --inventory-file hosts all --user root --module-name user --args "name=login_x uid=1042"
+192.168.0.106 | CHANGED => {
+    "ansible_facts": {
+        "discovered_interpreter_python": "/usr/bin/python3"
+    },
+    "append": false,
+    "changed": true,
+    "comment": "",
+    "group": 1001,
+    "home": "/home/login_x",
+    "move_home": false,
+    "name": "login_x",
+    "shell": "/bin/sh",
+    "state": "present",
+    "uid": 1042
+}
+```
+</div>
+
+On voit que le retour de notre commande est bien différent (ne serait-ce que la
+couleur du texte !). En particulier, on peut constater sur la première ligne de
+sortie standard `CHANGED` au lieu de `SUCCESS` précédemment.
+
+En fait notre utilisateur vient d'être créé, Ansible rapporte qu'il a apporté
+une modification au système cible. Si l'on renvoie exactement la même commande :
+
+<div lang="en-US">
+```
+42sh$ ansible --inventory-file hosts all --user root --module-name user --args "name=login_x uid=1042"
+192.168.0.106 | SUCCESS => {
+[...]
+```
+</div>
+
+Aucun changement, l'utilisateur est déjà créé et possède ces attributs, Ansible
+rapporte qu'il n'y a pas eu d'altération.\
+
+
+Maintenant que notre utilisateur est créé, nous pouvons lui ajouter notre clef SSH. Pour cela, on utilisera le [module `authorized_key`](https://docs.ansible.com/ansible/latest/collections/ansible/posix/authorized_key_module.html) :
+
+<div lang="en-US">
+```
+ansible --inventory-file hosts all --module-name authorized_key --args "user=login_x key='ssh-ed25519 AAAAC3NzaC1lZD...FD'"
+```
+</div>
+
+Notez que j'ai maintenant arrêté d'utilisé l'option `--user root`, puisque je peux me connecter avec l'utilisateur que j'ai créé. Sans préciser, le nom d'utilisateur de votre compte est utilisé pour établir les connexions.
+
+::::: {.exercice}
+
+Pour continuer, il va nous falloir installer `sudo` (en `root`), ajouter notre utilisateur au groupe `sudo` et éventuellement configurer le fichier `sudoers` pour accepter que l'on puisse lancer des commandes sans utiliser de mot de passe.
+Vous pourrez faire tout cela avec les modules :
+
+  - [`apt`](https://docs.ansible.com/ansible/2.10/collections/ansible/builtin/apt_module.html)
+  - [`user`](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html)
+  - [`lineinfile`](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/lineinfile_module.html)
+
+:::::
+
+
+## Utiliser `sudo`
+
+Après avoir installé et configuré `sudo`, voyons comment l'utiliser avec Ansible.
+
+Ansible peut utiliser différents programme pour élever ses privilèges (pas seulement `sudo`) ; il va détecter de lui-même quel programme utiliser.
+
+Il faudra cependant lui indiquer que l'on souhaite qu'il élève ses privilège
+juste après la connexion en tant que simple utilisateur. On ajoute pour cela
+les options `--become` et `--ask-become-pass` (utilisez `--sudo` et
 `--ask-sudo-pass` pour les vieilles versions) :
 
 <div lang="en-US">
 ```bash
-ansible --inventory-file hosts all -m ping -u bruce --become --ask-become-pass
+ansible --inventory-file hosts all -m ping -u login_x --become --ask-become-pass
 ```
 </div>
 
+L'option `--ask-become-pass` vous demandera systématiquement le mot de passe *sudoer*, avant d'établir la connexion.
+
+Maintenant que l'on sait se connecter proprement, essayons d'en apprendre un peu plus sur les modules.
+
 
 ### Les modules
 
@@ -164,7 +265,7 @@ exister. À l'application de cette nouvelle recette, si un tel utilisateur est
 trouvé, il sera donc supprimé.
 
 
-### Collecte ~~du lundi~~ d'informations
+### Collecte d'informations
 
 Parmi les modules de base, le module `setup` permet de récupérer un grand
 nombre de caractéristiques de la machine distance, voyez plutôt :
@@ -178,8 +279,8 @@ ansible -i hosts all -m setup
 Les informations récupérées (quel que soit le module), sont ensuite accessibles
 dans des variables afin de permettre de compléter des modèles ou pour faire de
 l'exécution conditionnelle d'état (par exemple on pourra utiliser la variable
-`ansible_facts.ansible_distribution` pour distinguer les gestionnaires de
+`ansible_distribution` pour distinguer les gestionnaires de paquets à utiliser
-paquets).
+selon la distribution de la machine).
 
 
 Ma première recette
@@ -219,7 +320,7 @@ décrit les tâches.
 
 Le guide de référence pour connaître toutes les syntaxes possibles est
 disponible dans [la documentation
-d'Ansible](http://docs.ansible.com/ansible/latest/playbooks.html).
+d'Ansible](https://docs.ansible.com/ansible/latest/playbooks.html).
 
 
 ### Exécution d'un *Playbook*
@@ -247,7 +348,7 @@ Voici à quoi ressemblerait votre premier playbook créant l'utilisateur
 
   tasks:
   - name: ensure adeline as an account
-    user:
+    ansible.builtin.user:
 	  name: adeline
 	  state: present
 	  shell: /bin/fish
@@ -256,8 +357,7 @@ Voici à quoi ressemblerait votre premier playbook créant l'utilisateur
 ```
 </div>
 
-La création de l'utilisateur se fait à l'aide du module
+::::: {.exercice}
-[`user`](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html).
 
 À vous maintenant, à l'aide [des collections de modules à votre
 disposition](https://docs.ansible.com/ansible/latest/collections/index.html)
@@ -265,6 +365,8 @@ de copier vos fichiers de configuration à leur place et avec les bons droits
 (`authorized_keys`, `.bashrc`, ...). Installez également les paquets que vous
 aviez installés à la main (client DHCP, `htop`, ...).
 
+:::::
+
 
 Les notifications
 -----------------
@@ -303,16 +405,23 @@ Voir [la
 documentation](https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html)
 pour davantage de détails et d'exemples.
 
+
+::::: {.exercice}
+
 La configuration de votre serveur SSH laisse à désirer. Corriger les problèmes
-énoncés par ces deux articles :
+énoncés par ces guides et articles :
 
 - <https://linuxhandbook.com/ssh-hardening-tips/> ;
 - <https://www.ssi.gouv.fr/guide/recommandations-pour-un-usage-securise-dopenssh/> ;
 - <https://stribika.github.io/2015/01/04/secure-secure-shell.html>.
 
-Mettez en place un *handler* pour relancer votre serveur SSH en cas de
+Pour modifier un fichier de configuration, on utilise généralement le module [`ansible.builtin.lineinfile`](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/lineinfile_module.html).
+
+Puis, mettez en place un *handler* pour relancer votre serveur SSH en cas de
 modification de sa configuration.
 
+:::::
+
 
 Les variables
 -------------
@@ -363,7 +472,7 @@ Ces variables peuvent être placées dans un fichier, pour plus de lisibilité
 ```yaml
 - hosts: webservers
   vars_files:
-    - /vars/webservers_common.yml
+    - vars/webservers_common.yml
 ```
 </div>
 
@@ -382,7 +491,7 @@ https_port: 443
 #### Modèles
 
 Ces variables peuvent être utilisées pour remplir un emplacement de texte dans
-un modèle. Ansible utilise [Jinja2](http://jinja.pocoo.org/) comme moteur de
+un modèle. Ansible utilise [Jinja2](https://jinja.pocoo.org/) comme moteur de
 template, un format très courant dans le milieu du développement Python.
 
 <div lang="en-US">
@@ -424,8 +533,8 @@ Jinja2 :
 ```yaml
 - hosts: webservers
   vars_files:
-    - /vars/webservers_common.yml
+    - vars/webservers_common.yml
-    - /vars/webservers_{{ ansible_os_family }}.yml
+    - vars/webservers_{{ ansible_os_family }}.yml
 ```
 </div>
 
@@ -451,4 +560,4 @@ tasks:
 </div>
 
 Vous trouverez bien d'autres cas d'utilisation dans [la
-documentation](http://docs.ansible.com/ansible/latest/playbooks_conditionals.html).
+documentation](https://docs.ansible.com/ansible/latest/playbooks_conditionals.html).

tutorial/ansible/project.md

@@ -0,0 +1,70 @@
+---
+title: Administration Linux avancée -- Projet
+author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
+institute: EPITA
+date: Jeudi 13 avril 2023
+abstract: |
+  Nous allons maintenant développer nos savoirs et connaissances
+  d'Ansible en faisant le tour de quelques bonnes pratiques et en les
+  appliquant à nos actuels playbooks.
+
+  \vspace{1em}
+
+  Ce projet est à rendre pour le
+  **dimanche 30 avril 2023 à 23 h 42**.
+...
+
+\
+
+En prenant appui sur la base des *playbooks* que vous avez commencés durant les précédents TP, vous devez fiabiliser votre travail et appliquer un certain nombre de [bonnes pratiques courantes](https://docs.ansible.com/ansible/2.8/user_guide/playbooks_best_practices.html).\
+
+
+Éléments supplémentaires
+========================
+
+Par rapport au sujet précédent, vous devez :
+
+* Faire usage des [rôles Ansible](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html) autant que possible : que ce soit les votres dans un dossier `roles` ou la [communauté](https://galaxy.ansible.com/). À ce stade, sont au moins attendu sous forme de rôle : le pare-feu, l'installation et la configuration des serveurs installés, la gestion des certificat (idéalement vos *playbook* ne devraient qu'appeler des rôles, avec les bonnes variables).\
+
+* Le *playbook* `name-server.yml` doit également installer et configurer [happyDomain](https://www.happydomain.org/fr/) au moyen de la [collection Ansible mise à disposition par le projet](https://galaxy.ansible.com/happydns/happydomain) (sans Docker, en écoute sur tous les ports 8081, selon la configuration par défaut, pensez à ouvrir le port du pare-feu).\
+
+* Le contenu de votre clef SSH publique doit se trouver dans la variable `ssh_key`. Cette variable doit avoir une précédence lui permettant de pouvoir être écrasée par une surcharge sur la ligne de commande (`ansible-playbook -e ssh_key="ssh-ed25519 ABCDEF..."`). Votre clef DOIT bien être présente dans une variable et être utilisée si la variable n'est pas précisée sur la ligne de commande.\
+
+* De même, une variable `acme_directory` doit pouvoir vous permettre de passer facilement de l'infrastructure de production (par défaut), à [l'environnement `staging`](https://letsencrypt.org/docs/staging-environment/) de votre fournisseur de certificats. (Vous devez impérativement utiliser l'environnement `staging` durant vos tests.) Le contenu par défaut est : `https://acme-v02.api.letsencrypt.org/directory`\
+
+* Utiliser le secret `4dL1n!` pour chiffrer le contenu de vos [`ansible-vault`](https://docs.ansible.com/ansible/latest/cli/ansible-vault.html).\
+
+* [KICS](https://docs.kics.io/latest/getting-started/) ne doit pas trouver de problème significatif.\
+
+* En bonus, utilisez `happyDomain` (au travers des modules disponibles) pour créer le sous-domaine de votre vitrine.\
+
+* N'oubliez pas de relire les guides de l'ANSSI pour vérifier que votre *playbook* `securing.yml` prend en compte un maximum de remarques pertinentes.\
+
+
+Arborescence attendue
+========
+
+Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
+Git privé, que vous partagerez avec [votre
+professeur](https://gitlab.cri.epita.fr/nemunaire/).
+
+Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
+cela dépendra de votre avancée dans le projet) :
+
+<div lang="en-US">
+```
+./basis.yml
+./securing.yml
+./vitrine.yml
+./name-server.yml
+./collections/requirements.yml
+./roles/requirements.yml
+...
+```
+</div>
+
+Votre rendu sera pris en compte en faisant un [tag **signé par votre clef
+PGP**](https://lessons.nemunai.re/keys) ou SSH. Consultez les détails du rendu
+(nom du tag, ...) sur la page dédiée au projet sur la plateforme de rendu.
+
+Les fichiers `requirements.yml` sont standardisés : [pour les collections](https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#install-multiple-collections-with-a-requirements-file) et [pour les rôles](https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a-file), placez-y toutes vos dépendances.

tutorial/ansible/rendu-5.md

@@ -0,0 +1,42 @@
+\newpage
+
+Rendu
+=====
+
+Arborescence attendue
+-------
+
+Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
+Git privé, que vous partagerez avec [votre
+professeur](https://gitlab.cri.epita.fr/nemunaire/).
+
+Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
+cela dépendra de votre avancée dans le projet) :
+
+<div lang="en-US">
+```
+./basis.yml
+./securing.yml
+./vitrine.yml
+./name-server.yml
+...
+```
+</div>
+
+Votre rendu sera pris en compte en faisant un [tag **signé par votre clef
+PGP**](https://lessons.nemunai.re/keys) ou SSH. Consultez les détails du rendu
+(nom du tag, ...) sur la page dédiée au projet sur la plateforme de rendu.
+
+
+Quelques précisions importantes
+-----
+
+* Le contenu de votre clef SSH publique doit se trouver dans la variable `ssh_key`. Cette variable doit avoir une précédence lui permettant de pouvoir être écrasée par une surcharge sur la ligne de commande (`ansible-playbook -e ssh_key="ssh-ed25519 ABCDEF..."`). Votre clef DOIT bien être présente dans une variable et être utilisée si la variable n'est pas précisée sur la ligne de commande.
+
+* Utiliser le secret `4dL1n!` pour chiffrer le contenu de vos `ansible-vault`.
+
+* Le fichier `hosts` avec votre inventaire sera écrasé. Vous pouvez le rendre ou non.
+
+* Tous les `playbooks` doivent pouvoir être exécutés plusieurs fois. **Exécuté deux fois de suite, un même playbook ne doit pas trouver de changement.**
+
+* Pour simplifier les choses, le *playbook* `basis.yml` sera systématiquement appelé avant tous les autres et le *playbook* `name-server.yml` sera toujours appelé avant `vitrine.yml`. Les autres doivent pouvoir s'exécuter dans un ordre indéfini.

tutorial/ansible/rendu.md

@@ -3,115 +3,36 @@
 Rendu
 =====
 
-## Modalité de rendu
+Arborescence attendue
+-------
 
-Un service automatique s'occupe de réceptionner vos rendus, de faire des
+Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
-vérifications élémentaires et de vous envoyer un accusé de réception (ou de
+Git privé, que vous partagerez avec [votre
-rejet).
+professeur](https://gitlab.cri.epita.fr/nemunaire/).
-
-Ce service écoute sur l'adresse <adlin@nemunai.re>, c'est donc à cette adresse
-et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
-envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
-sera pas pris en compte.
-
-
-## Tarball
-
-Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
-placer dans une tarball (pas d'archive ZIP, RAR, ...).
 
 Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
-en fonction de votre organisation ou de vos choix) :
+cela dépendra de votre avancée dans le projet) :
 
 <div lang="en-US">
 ```
-login_x-TP2/basis.yml
+./basis.yml
-login_x-TP2/vitrine.yml
+./securing.yml
-login_x-TP2/name-server.yml
+./vitrine.yml
-login_x-TP2/matrix.yml
+./name-server.yml
 ...
 ```
 </div>
 
-
+Votre rendu sera pris en compte en faisant un [tag **signé par votre clef
-## Signature du rendu
+PGP**](https://lessons.nemunai.re/keys). Consultez les détails du rendu (nom du
-
+tag, ...) sur la page dédiée au projet sur la plateforme de rendu.
-Deux méthodes sont utilisables pour signer votre rendu :
-
-* signature du courriel ;
-* signature de la tarball.
-
-Dans les deux cas, si vous n'en avez pas déjà une, vous devrez créer une clef
-PGP à **votre nom et prénom**.
-
-Pour valider la signature, il est nécessaire d'avoir reçu la clef publique
-**séparément**. Vous avez le choix de l'uploader sur un serveur de clefs, soit
-de me fournir votre clef en main propre, soit de l'envoyer dans un courriel
-distinct.
-
-### Signature du courriel
-
-Une version récente de [Thunderbird](https://www.thunderbird.net/fr/) vous
-permettra d'envoyer des courriels signés. Si vous n'avez qu'une version
-ancienne, l'extension [Enigmail](https://enigmail.net) est très bien réputée
-pour signer ses mails depuis Thunderbird. Bien entendu, de nombreuses autres
-solutions sont disponibles.
-
-Utilisez le service automatique <signcheck@nemunai.re> pour savoir si votre
-courriel est correctement signé et que je suis en mesure de vérifier la
-signature.
 
 
-### Astuces
+Quelques conseils
+-----
 
-#### No public key
+* Le fichier `hosts` avec votre inventaire sera écrasé. Vous pouvez le rendre ou non.
 
-Si vous recevez un rapport avec l'erreur suivante :
+* Tous les `playbooks` doivent pouvoir être exécutés plusieurs fois. Exécuté deux fois de suite, un même playbook ne doit pas trouver de changement.
 
-<div lang="en-US">
+* Pour simplifier les choses, le *playbook* `basis.yml` sera systématiquement appelé avant tous les autres et le *playbook* `name-server.yml` sera toujours appelé avant `vitrine.yml`. Les autres doivent pouvoir s'exécuter dans un ordre indéfini.
-```
-[FAIL] Bad signature. Here is the gnupg output:
-
-gpg: Signature made Tue Jan 01 16:42:23 2014 CET
-gpg:                using RSA key 842807A84573CC96
-gpg: requesting key E2CCD99DD37BD32E from hkp server keys.openpgp.org
-gpg: Can't check signature: No public key
-```
-</div>
-
-C'est que votre clef publique n'est pas dans mon trousseau et que les
-méthodes de récupération automatique n'ont pas permis de la
-trouver. Uploadez votre clef sur [un serveur de
-clefs](https://keys.openpgp.org/) ou envoyez un courriel au service
-avec votre clef publique en pièce jointe, avant de retenter votre
-rendu.
-
-
-#### Not explicit username
-
-Si vous recevez un rapport avec l'erreur suivante :
-
-<div lang="en-US">
-```
-[FAIL] The username of your key is not explicit, I can't find you.
-```
-</div>
-
-Votre clef ne contient sans doute pas vos noms et prénoms ou l'adresse
-électronique associée à la clef n'est pas celle que j'ai dans ma base de
-données.
-
-
-#### I've decided to skip your e-mail
-
-Si vous recevez un rapport concluant ainsi :
-
-<div lang="en-US">
-```
-After analyzing your e-mail, I've decided to SKIP it.
-```
-</div>
-
-Cela signifie que la lecture de votre courriel qui a été préférée n'est pas
-celle d'un rendu. Vérifiez que vous n'envoyez pas votre clef publique avec
-votre rendu.

tutorial/ansible/tutorial-5.md

@@ -0,0 +1,16 @@
+---
+title: Administration Linux avancée -- TP n^o^ 5
+subtitle: Bonnes pratiques d'Ansible
+author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
+institute: EPITA
+date: Jeudi 13 avril 2023
+abstract: |
+  Durant ce cinquième TP, nous allons développer nos savoirs et connaissances
+  d'Ansible en faisant le tour de quelques bonnes pratiques et en les
+  appliquant à nos actuels playbooks.
+
+  \vspace{1em}
+
+  Ce TP est le projet final du cours qui sera à rendre pour le
+  **dimanche 30 avril 2023 à 23 h 42**.
+...

tutorial/ansible/tutorial.md

@@ -1,24 +1,15 @@
 ---
-title: Administration Linux avancée -- TP n^o^ 2
+title: Administration Linux avancée -- TP n^o^ 4
-subtitle: "Maatma : l'hébergeur DIY"
+subtitle: Automatiser la gestion de configuration avec Ansible
 author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
 institute: EPITA
-date: Jeudi 16 mars 2023
+date: Jeudi 30 mars 2023
 abstract: |
-  Durant ce troisième TP, nous allons apprendre à déployer des services sur un
+  Durant ce quatrième TP, nous allons apprendre à déployer des services sur un
   serveur, de manière industrielle !
 
   \vspace{1em}
 
-  La partie 5 de ce TP est un projet à rendre à <adlin@nemunai.re> au plus tard
+  Ce TP contient un projet à rendre pour le **mercredi 12 avril à
-  le **jeudi 31 mars 2022 à 23 h 42**. Consultez la dernière
+  23 h 42**. Consultez la dernière partie pour plus d'informations.
-  section de chaque partie pour plus d'information sur les éléments à
-  rendre. Et n'oubliez pas de répondre aux [questions de
-  cours](https://adlin.nemunai.re/quiz/20).
-
-  En tant que personnes sensibilisées à la sécurité des échanges électroniques,
-  vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
-  [me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
-  faire signer votre clef et n'hésitez pas à [faire signer votre
-  clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
 ...