diff --git a/tutorial/ansible/Makefile b/tutorial/ansible/Makefile index 8e3c633..679a215 100644 --- a/tutorial/ansible/Makefile +++ b/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 diff --git a/tutorial/ansible/ansible-advanced.md b/tutorial/ansible/ansible-advanced.md new file mode 100644 index 0000000..6599789 --- /dev/null +++ b/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 +================ diff --git a/tutorial/ansible/ansible-inventory.png b/tutorial/ansible/ansible-inventory.png new file mode 100644 index 0000000..66cea09 Binary files /dev/null and b/tutorial/ansible/ansible-inventory.png differ diff --git a/tutorial/ansible/ansible.md b/tutorial/ansible/ansible.md index 107e12c..45e4e97 100644 --- a/tutorial/ansible/ansible.md +++ b/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 -services). Comme de très nombreuses personnes sont passées par là avant vous, -il existe un grand nombre de solutions pour gérer les configurations d'un parc -de machines. Parmi les plus connues, citons : [Puppet](https://puppet.com/), -[Chef](http://www.chef.io/), [SaltStack](https://saltstack.com/) ou encore +nous allons vouloir automatiser toutes les actions rébarbatives que nous avons +faites jusque là. Comme de très nombreuses personnes sont passées par là avant +nous, il existe un grand nombre de solutions pour gérer les configurations d'un +parc de machines. Parmi les plus connues, citons : +[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 -[AWX](https://github.com/ansible/awx)). +Tower](https://www.ansible.com/products/tower), +[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 -virtuelle démarrée : la machine hôte sera parfaitement adaptée à cette tâche, -d'autant plus que l'installation de la plate-forme est propre et légère : vous -ne risquez pas de vous retrouver avec une usine à gaz impossible à retirer. +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. Mais vous pouvez aussi choisir de l'installer dans une seconde machine +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 -machine, identique à celle que vous venez de configurer, à partir d'une ISO et +À la fin de ce TP, vous devez être en mesure de déployer une nouvelle +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 -toutes ses dépendances : celui-ci doit faire les configurations basiques du -système et des utilisateurs. +Vous devrez pour cela réaliser des *playbooks* : + - `basis.yml`, accompagné de toutes ses dépendances : celui-ci doit faire les + 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 -permettre de déployer, une page vitrine typique d'une entreprise (cf. la 4e -question de cours ;)). Cette page doit être accessible depuis votre domaine -.\ + - `securing.yml`, accompagné de toutes ses dépendances : ce *playbook* doit + s'occuper de toute l'installation de la machine pour qu'elle soit aussi + sécurisée que possible. + + - `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 + . + + - `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 :
``` -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 : ```
+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 -machine distance.\ +connexion a bien été effectuée et que le nécessaire pour utiliser Ansible est +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 : + +
+``` +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" +} +``` +
+ + ### Confort -Une des premières choses que nous devrions faire, est d'installer notre clef -SSH sur les machines, pour éviter d'avoir à taper le mot de passe à chaque -test. +Une des premières choses que nous devrions faire, est de nous créer un +utilisateur puis d'installer notre clef SSH sur les machines, pour éviter +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 -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. +Pour créer notre utilisateur, nous pouvons utiliser le [module `user`](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html) : -Et ajoutez les options `--become` et `--ask-become-pass` (utilisez `--sudo` et +
+``` +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 +} +``` +
+ +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 : + +
+``` +42sh$ ansible --inventory-file hosts all --user root --module-name user --args "name=login_x uid=1042" +192.168.0.106 | SUCCESS => { +[...] +``` +
+ +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) : + +
+``` +ansible --inventory-file hosts all --module-name authorized_key --args "user=login_x key='ssh-ed25519 AAAAC3NzaC1lZD...FD'" +``` +
+ +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) :
```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 ```
+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 -paquets). +`ansible_distribution` pour distinguer les gestionnaires de paquets à utiliser +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 ``` -La création de l'utilisateur se fait à l'aide du module -[`user`](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/user_module.html). +::::: {.exercice} À 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 : -  ; -  ; - . -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 ``` @@ -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.
@@ -424,8 +533,8 @@ Jinja2 : ```yaml - hosts: webservers vars_files: - - /vars/webservers_common.yml - - /vars/webservers_{{ ansible_os_family }}.yml + - vars/webservers_common.yml + - vars/webservers_{{ ansible_os_family }}.yml ```
@@ -451,4 +560,4 @@ tasks: 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). diff --git a/tutorial/ansible/project.md b/tutorial/ansible/project.md new file mode 100644 index 0000000..85b22fe --- /dev/null +++ b/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) : + +
+``` +./basis.yml +./securing.yml +./vitrine.yml +./name-server.yml +./collections/requirements.yml +./roles/requirements.yml +... +``` +
+ +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. diff --git a/tutorial/ansible/rendu-5.md b/tutorial/ansible/rendu-5.md new file mode 100644 index 0000000..7d6cba4 --- /dev/null +++ b/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) : + +
+``` +./basis.yml +./securing.yml +./vitrine.yml +./name-server.yml +... +``` +
+ +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. diff --git a/tutorial/ansible/rendu.md b/tutorial/ansible/rendu.md index 9e09cbb..7485aba 100644 --- a/tutorial/ansible/rendu.md +++ b/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 -vérifications élémentaires et de vous envoyer un accusé de réception (ou de -rejet). - -Ce service écoute sur l'adresse , 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, ...). +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, -en fonction de votre organisation ou de vos choix) : +cela dépendra de votre avancée dans le projet) :
``` -login_x-TP2/basis.yml -login_x-TP2/vitrine.yml -login_x-TP2/name-server.yml -login_x-TP2/matrix.yml +./basis.yml +./securing.yml +./vitrine.yml +./name-server.yml ... ```
- -## Signature du 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 pour savoir si votre -courriel est correctement signé et que je suis en mesure de vérifier la -signature. +Votre rendu sera pris en compte en faisant un [tag **signé par votre clef +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. -### 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. -
-``` -[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 -``` -
- -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 : - -
-``` -[FAIL] The username of your key is not explicit, I can't find you. -``` -
- -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 : - -
-``` -After analyzing your e-mail, I've decided to SKIP it. -``` -
- -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. +* 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. diff --git a/tutorial/ansible/tutorial-5.md b/tutorial/ansible/tutorial-5.md new file mode 100644 index 0000000..d63a5e4 --- /dev/null +++ b/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**. +... diff --git a/tutorial/ansible/tutorial.md b/tutorial/ansible/tutorial.md index fd4e408..ed63301 100644 --- a/tutorial/ansible/tutorial.md +++ b/tutorial/ansible/tutorial.md @@ -1,24 +1,15 @@ --- -title: Administration Linux avancée -- TP n^o^ 2 -subtitle: "Maatma : l'hébergeur DIY" +title: Administration Linux avancée -- TP n^o^ 4 +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 à au plus tard - le **jeudi 31 mars 2022 à 23 h 42**. Consultez la dernière - 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/). + Ce TP contient un projet à rendre pour le **mercredi 12 avril à + 23 h 42**. Consultez la dernière partie pour plus d'informations. ...