Exercices Ansible corrigés type E6 SISR

1. inventaire/marseille.yml :

---
all:
  children:
    marseille:
      children:
        marseille_linux:
          children:
            marseille_web:
              hosts:
                mrs-web1:
                  ansible_host: 10.30.1.161
                mrs-web2:
                  ansible_host: 10.30.1.162
            marseille_bdd:
              hosts:
                mrs-bdd:
                  ansible_host: 10.30.1.163
        marseille_windows:
          hosts:
            mrs-fichiers:
              ansible_host: mrs-fichiers.ad.sorbier.example

Le serveur Windows est désigné par son nom complet : Kerberos a besoin d'un nom, pas d'une adresse.

2. inventaire/group_vars/marseille_linux.yml :

---
ansible_user: ansible

inventaire/group_vars/marseille_windows/vars.yml :

---
ansible_connection: winrm
ansible_port: 5986
ansible_winrm_transport: kerberos
ansible_user: svc-ansible@AD.SORBIER.EXAMPLE
ansible_password: "{{ vault_mdp_svc_ansible }}"

et vault_mdp_svc_ansible dans inventaire/group_vars/marseille_windows/vault.yml, chiffré par ansible-vault. Si Marseille fait partie du même inventaire que le siège, on peut aussi placer marseille_windows comme groupe enfant de windows et réutiliser ses variables, sans les recopier.

3. ansible-inventory -i inventaire/marseille.yml --graph et ansible -i inventaire/marseille.yml 'marseille:!marseille_web' --list-hosts, qui affiche mrs-bdd et mrs-fichiers.

1. when: interdire_root avec une chaîne : depuis ansible-core 2.19, une condition doit être un booléen ; "yes" est une chaîne, la tâche échoue (« Conditionals must have a boolean result »). Écrire interdire_root: true, ou when: interdire_root | bool.
2. ansible_distribution en variable de premier niveau : l'injection des facts est dépréciée depuis 2.20 et disparaîtra en 2.24. Écrire ansible_facts['distribution'].
3. Le redémarrage dans une tâche ordinaire : SSH est redémarré à chaque exécution, même sans changement, et la tâche n'est jamais idempotente. Il faut un handler, notifié par la modification du fichier.
4. Le nom du service : sur Debian, le service s'appelle ssh, pas sshd (le nom sshd existe comme alias sur certaines versions, mais ssh est le bon nom). Et reloaded suffit : il relit la configuration sans couper les sessions ouvertes.
5. Pas de validation : une erreur dans sshd_config empêcherait SSH de redémarrer, et Ansible ne pourrait plus se connecter. Ajouter validate: /usr/sbin/sshd -t -f %s.
6. mode: 644 : sans guillemets ni zéro initial, c'est le nombre décimal 644, soit les droits octaux 1204. Écrire mode: "0644".

---
- name: Durcir SSH
  hosts: linux
  become: true
  vars:
    interdire_root: true

  tasks:
    - name: Interdire la connexion de root
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^#?PermitRootLogin"
        line: PermitRootLogin no
        validate: /usr/sbin/sshd -t -f %s
      when: interdire_root
      notify: Recharger SSH

    - name: Afficher la distribution
      ansible.builtin.debug:
        msg: "Distribution : {{ ansible_facts['distribution'] }}"

    - name: Déposer la bannière
      ansible.builtin.copy:
        src: files/banniere.txt
        dest: /etc/issue.net
        owner: root
        group: root
        mode: "0644"

  handlers:
    - name: Recharger SSH
      ansible.builtin.service:
        name: ssh
        state: reloaded

Pour aller plus loin, le rôle socle du chapitre 8 dépose plutôt un fichier dans /etc/ssh/sshd_config.d/, ce qui évite de modifier le fichier du paquet ligne par ligne. La bannière n'est affichée que si sshd_config contient Banner /etc/issue.net.

roles/outils/defaults/main.yml :

---
outils_paquets:
  - tcpdump
  - dnsutils
  - rsync
outils_paquets_hote: []
outils_motd: "Serveur de Sorbier Logistique : accès réservé au service informatique."

roles/outils/tasks/main.yml :

---
- name: Installer les outils
  ansible.builtin.apt:
    name: "{{ outils_paquets + outils_paquets_hote }}"
    state: present
    update_cache: true
    cache_valid_time: 3600

- name: Déposer le message d'accueil
  ansible.builtin.copy:
    content: "{{ outils_motd }}\n"
    dest: /etc/motd
    owner: root
    group: root
    mode: "0644"

Le play :

---
- name: Installer les outils sur les serveurs Linux
  hosts: linux
  become: true
  roles:
    - outils

et host_vars/srv-web.yml reçoit outils_paquets_hote: [apachetop]. Comme Ansible remplace les listes au lieu de les fusionner, on sépare la liste commune et la liste propre à l'hôte, et la tâche les additionne.

roles/sauvegarde/defaults/main.yml :

---
sauvegarde_dossier: /var/backups/sorbier
sauvegarde_heure: 2
sauvegarde_minute: 15

roles/sauvegarde/tasks/main.yml :

---
- name: Installer rsync
  ansible.builtin.apt:
    name: rsync
    state: present

- name: Créer le dossier des sauvegardes
  ansible.builtin.file:
    path: "{{ sauvegarde_dossier }}"
    state: directory
    owner: root
    group: root
    mode: "0700"

- name: Déposer le script de sauvegarde
  ansible.builtin.copy:
    src: sauvegarde-etc.sh
    dest: /usr/local/sbin/sauvegarde-etc.sh
    owner: root
    group: root
    mode: "0750"

- name: Planifier la sauvegarde chaque nuit
  ansible.builtin.cron:
    name: Sauvegarde de /etc
    user: root
    hour: "{{ sauvegarde_heure }}"
    minute: "{{ sauvegarde_minute }}"
    job: /usr/local/sbin/sauvegarde-etc.sh >> /var/log/sauvegarde-etc.log 2>&1

Le script va dans roles/sauvegarde/files/sauvegarde-etc.sh : copy le trouve sans chemin. Le name de la tâche cron sert d'identifiant : Ansible l'écrit en commentaire au-dessus de la ligne de la crontab et s'en sert pour la retrouver, ce qui rend la tâche idempotente. Le play :

---
- name: Planifier les sauvegardes de /etc
  hosts: linux
  become: true
  roles:
    - sauvegarde

et host_vars/srv-journaux.yml reçoit sauvegarde_heure: 3. Une sauvegarde qui reste sur le serveur ne protège pas d'une perte du serveur : une copie hors de la machine (vers un NAS, un serveur de sauvegarde) est indispensable, comme l'explique le cours Sauvegarde et PRA.

---
- name: Appliquer le socle aux serveurs Windows
  hosts: windows

  tasks:
    - name: Régler le fuseau horaire de Paris
      ansible.windows.win_timezone:
        timezone: Romance Standard Time

    - name: Créer le dossier des outils
      ansible.windows.win_file:
        path: C:\Outils
        state: directory

    - name: Installer les outils AD et la sauvegarde Windows
      ansible.windows.win_feature:
        name:
          - RSAT-AD-Tools
          - Windows-Server-Backup
        state: present
      register: fonctionnalites

    - name: Arrêter et désactiver le spouleur sur les contrôleurs
      ansible.windows.win_service:
        name: Spooler
        state: stopped
        start_mode: disabled
      when: "'controleurs' in group_names"

    - name: Redémarrer si nécessaire
      ansible.windows.win_reboot:
      when: fonctionnalites.reboot_required

Le chemin C:\Outils est écrit sans guillemets : entre guillemets doubles, \O serait interprété par YAML. La condition 'controleurs' in group_names vise srv-ad et srv-ad2. Le redémarrage est en dernier : si plusieurs tâches peuvent l'exiger, on enregistre chacune et on combine les conditions, ou on utilise ansible.windows.win_reboot_info pour demander à Windows s'il attend un redémarrage. Sur des contrôleurs de domaine, ajoute serial: 1 au play pour ne jamais redémarrer les deux en même temps.

1. srv-journaux : tout s'est bien passé, rien n'a changé (configuration déjà conforme), une tâche sautée par une condition. srv-recette : injoignable, aucune tâche n'a tourné (VM arrêtée, réseau, SSH, clé). srv-web : 15 tâches réussies dont 3 modifications, puis un échec, qui a arrêté le playbook pour cet hôte : les tâches suivantes n'ont pas été exécutées, et les handlers notifiés avant l'échec non plus (sauf --force-handlers).
2. 4 : ansible-core renvoie 4 dès qu'un hôte est injoignable, ce code passant avant le 2 d'un hôte en échec. Un script qui teste seulement « différent de 0 » détecte les deux cas.
3. Remonter dans la sortie jusqu'à la tâche fatal: [srv-web] pour lire le message. Relancer en détail sur ce seul hôte : ansible-playbook site.yml --limit srv-web -v, voire --start-at-task "<nom de la tâche>" après correction. Pour srv-recette : ansible srv-recette -m ansible.builtin.ping -vvv, qui montre la commande SSH et l'erreur exacte. Une fois corrigé, relancer tout le playbook : il est idempotent.

1. Dans inventaire/hosts.yml, ajouter srv-recette aux groupes concernés :

        serveurs_web:
          hosts:
            srv-web:
              ansible_host: 192.168.10.225
            srv-recette:
              ansible_host: 192.168.21.186

Comme serveurs_web est un enfant de linux, srv-recette est aussi dans linux. Puis inventaire/host_vars/srv-recette.yml :

---
web_nom_site: suivi-recette.sorbier.example
web_racine: /var/www/suivi-recette
web_certificat: /etc/ssl/certs/suivi-recette.sorbier.example.pem
web_cle_privee: /etc/ssl/private/suivi-recette.sorbier.example.key

Une organisation plus propre, à terme, sépare les environnements dans deux inventaires (inventaire/recette/ et inventaire/production/, chapitre 15).

2. Sur un contrôleur de domaine, srv-ad (la zone est répliquée par l'annuaire) :

- name: Déclarer l'alias du site de recette
  hosts: srv-ad
  tasks:
    - name: Créer l'alias suivi-recette
      ansible.windows.win_dns_record:
        name: suivi-recette
        type: CNAME
        value: srv-recette.ad.sorbier.example
        zone: ad.sorbier.example
        state: present

Attention : suivi-recette.sorbier.example est dans la zone sorbier.example, pas dans ad.sorbier.example. Si le DNS interne ne porte pas la zone sorbier.example, il faut soit créer l'enregistrement dans cette zone là où elle est hébergée, soit nommer le site suivi-recette.ad.sorbier.example. C'est le genre de détail que la commission apprécie de te voir relever.

3. Rien dans site.yml : il vise des groupes, et srv-recette est maintenant dans les deux. Pour l'appliquer à la seule recette : ansible-playbook site.yml --limit srv-recette.

4. Deux exécutions de suite sur la recette : la seconde affiche changed=0 pour srv-recette dans le récapitulatif. Pour la production : ansible-playbook site.yml --limit srv-web --check --diff, qui doit annoncer changed=0 ; et le diff Git de la demande de fusion montre que seuls l'inventaire et host_vars/srv-recette.yml ont changé. Le pipeline vert (--syntax-check et ansible-lint) complète la preuve.

5. La clé privée est un secret : elle va dans un fichier chiffré, par exemple inventaire/host_vars/srv-recette/vault.yml (avec les autres variables dans host_vars/srv-recette/vars.yml), sous forme de variable multiligne vault_cle_tls_recette, chiffrée par ansible-vault. Une tâche ansible.builtin.copy avec content: "{{ vault_cle_tls_recette }}", mode: "0600" et no_log: true la dépose sur le serveur. Le certificat, public, peut rester en clair dans files/.

6. « Une copie à la main donne un serveur identique le jour de la copie, mais rien ne garantit qu'il le reste, ni que la copie était complète. Avec Ansible, la recette et la production sont construites par le même code, avec des variables différentes : ce que je teste en recette est exactement ce qui sera appliqué en production. Chaque modification est tracée dans Git, relue et contrôlée par le pipeline, et je peux reconstruire la recette en quelques minutes si la VM est perdue. Enfin, relancer le playbook corrige toute dérive : la deuxième exécution qui n'affiche aucun changement le prouve. »