Add latest tutorial revision
This commit is contained in:
parent
98b9ebdd7e
commit
3627de3afe
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
================
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
|
|
@ -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
|
||||
<https://login-x.adlin2024.example.tld/>.\
|
||||
- `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
|
||||
<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
|
||||
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 :
|
||||
|
||||
<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
|
||||
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
|
||||
<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
|
||||
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
|
|||
```
|
||||
</div>
|
||||
|
||||
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 :
|
||||
|
||||
- <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_{{ ansible_os_family }}.yml
|
||||
- vars/webservers_common.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).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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 <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, ...).
|
||||
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) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
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
|
||||
...
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## 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 <signcheck@nemunai.re> 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.
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
[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.
|
||||
* 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.
|
||||
|
|
|
|||
|
|
@ -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**.
|
||||
...
|
||||
|
|
@ -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 à <adlin@nemunai.re> 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.
|
||||
...
|
||||
|
|
|
|||
Reference in New Issue