Introduction
Une automatisation fiable des fichiers distingue la source du contrôleur, les copies gérées et les artefacts collectés en retour pour inspection. Des noms de fichier corrects ne démontrent pas à eux seuls l'intégrité du contenu, les permissions ou l'identité des hôtes.
Vous déploierez une bannière, examinerez ses métadonnées SHA-256 réelles avec stat et register, générerez des rapports opérationnels par hôte et récupérerez ces rapports avec fetch dans des chemins distincts du contrôleur. L'environnement SSH préparé à deux hôtes et le modèle de privilèges sont les mêmes que précédemment.
Distribuer un fichier avec des permissions gérées explicites
Dans cette étape, vous copierez une source privée du contrôleur dans un répertoire géré protégé et choisirez explicitement le propriétaire et les permissions distants.
Ouvrez le Terminal et entrez dans le projet :
cd /home/labex/project
Créez la source réutilisable du contrôleur, avec son saut de ligne final :
printf 'Managed service banner\n' > site-banner.txt
chmod modifie les permissions d'un fichier local. Le mode 0600 donne la lecture/écriture à son propriétaire et aucun accès au groupe ni aux autres. Gardez cette source du contrôleur privée tout en choisissant volontairement des permissions gérées différentes :
chmod 0600 site-banner.txt
Écrivez un playbook de distribution :
cat > deploy-banner.yml <<'EOF'
- name: Distribute the managed banner
hosts: all
gather_facts: false
become: true
tasks:
- name: Prepare the managed site directory
ansible.builtin.file:
path: /srv/ansible-site
state: directory
owner: root
group: automation
mode: "0750"
- name: Copy the controller banner with explicit managed permissions
ansible.builtin.copy:
src: /home/labex/project/site-banner.txt
dest: /srv/ansible-site/banner.txt
owner: root
group: automation
mode: "0640"
EOF
Le become au niveau du play demande l'élévation sur les nœuds gérés, où l'écriture sous /srv et l'attribution du propriétaire root la nécessitent. Il ne transforme pas le processus de lecture de source du contrôleur en connexion root.
Le répertoire appartient à root, au groupe automation, avec le mode 0750. La bannière appartient à root, au groupe automation, avec le mode 0640. Cela permet au compte ordinaire automation de traverser le répertoire et de lire la bannière sans lui accorder l'écriture. Le mode géré explicite est indépendant du mode 0600 de la source du contrôleur.
Vérifiez et appliquez le playbook :
ansible-playbook deploy-banner.yml --syntax-check
ansible-playbook deploy-banner.yml
Les deux hôtes doivent terminer sans échec. Testez l'accès en lecture ordinaire sans become :
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/banner.txt'
Chaque hôte doit afficher Managed service banner. Cela démontre l'accès distant en lecture par le groupe prévu tout en gardant la source et les copies gérées comme fichiers distincts.
Enregistrer et consommer des métadonnées de fichier structurées
Dans cette étape, vous examinerez la bannière réellement gérée et écrirez un rapport opérationnel par hôte à partir de ses métadonnées.
Le module stat renvoie les informations d'un fichier au lieu de le copier. checksum_algorithm: sha256 sélectionne SHA-256 pour vérifier le contenu. register stocke le résultat de cette tâche pour les tâches suivantes sur le même hôte ; son champ stat contient les métadonnées du fichier.
Créez un playbook d'inspection :
cat > inspect-and-collect.yml <<'EOF'
- name: Inspect the banner and prepare host reports
hosts: all
gather_facts: true
tasks:
- name: Inspect managed content and permissions
ansible.builtin.stat:
path: /srv/ansible-site/banner.txt
checksum_algorithm: sha256
register: banner_info
- name: Display the structured file metadata
ansible.builtin.debug:
var: banner_info.stat
- name: Write the per-host report from real metadata
become: true
ansible.builtin.copy:
dest: /srv/ansible-site/node-report.txt
content: |
host={{ inventory_hostname }}
distribution={{ ansible_facts.distribution }}
banner_sha256={{ banner_info.stat.checksum }}
owner: root
group: automation
mode: "0640"
EOF
Le module debug affiche une variable existante avec var ; banner_info.stat révèle donc des champs tels que exists, mode, noms du propriétaire/groupe, size et checksum. Afficher des métadonnées ne crée pas de fichier et ne prouve pas la réussite d'une opération ultérieure.
La tâche copy consomme banner_info.stat.checksum avec inventory_hostname et le fait de distribution. Son become au niveau de la tâche est nécessaire pour écrire le rapport appartenant à root. Les tâches d'inspection elles-mêmes utilisent l'accès en lecture ordinaire.
Exécutez l'inspection et la génération des rapports :
ansible-playbook inspect-and-collect.yml
Les métadonnées doivent identifier un fichier ordinaire avec le mode 0640, le propriétaire root et le groupe automation. Chaque rapport possède son propre nom d'hôte et une valeur SHA-256 dérivée de la véritable bannière distante.
sha256sum calcule l'empreinte SHA-256 d'un fichier local et affiche l'empreinte suivie de son nom. Comparez l'empreinte de la source du contrôleur aux métadonnées et aux valeurs des rapports :
sha256sum site-banner.txt
Lisez les deux rapports distants :
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/node-report.txt'
Chaque résultat doit contenir host=web1 ou host=web2, distribution=Ubuntu et banner_sha256 suivi de l'empreinte correspondante de 64 caractères. Gardez les observations liées à chaque hôte réel au lieu de les remplacer par un message debug constant.
Récupérer des rapports distincts sur le contrôleur
Dans cette étape, vous collecterez les deux rapports gérés sans écraser le résultat d'un hôte par celui de l'autre.
copy envoie normalement une source du contrôleur vers une destination gérée. fetch fonctionne dans l'autre sens : son src est sur le nœud géré et son dest est un répertoire du contrôleur. Avec flat false, fetch inclut le nom d'hôte d'inventaire et le chemin distant sous dest.
Ajoutez cette tâche au playbook d'inspection existant. Alignez son indentation sur celle des autres entrées de tâche ; >> ajoute sans remplacer les tâches stat, register et de rapport précédentes :
cat >> inspect-and-collect.yml <<'EOF'
- name: Collect each managed report without flattening host paths
ansible.builtin.fetch:
src: /srv/ansible-site/node-report.txt
dest: /home/labex/project/reports/
flat: false
EOF
Exécutez la procédure complète d'inspection et de collecte :
ansible-playbook inspect-and-collect.yml
Le premier fetch doit créer les deux copies sur le contrôleur. Il s'exécute sous le compte ordinaire automation sur chaque cible, car les permissions de groupe du rapport autorisent déjà la lecture.
Examinez localement chaque artefact collecté :
cat reports/web1/srv/ansible-site/node-report.txt
cat reports/web2/srv/ansible-site/node-report.txt
Les chemins préservent l'identité indépendante des hôtes. Le champ host de chaque rapport doit correspondre à son chemin, et les deux champs checksum doivent correspondre à la source déployée. Aplatir les deux résultats vers un seul nom de fichier partagé ferait perdre l'artefact d'un hôte.
Répétez la procédure complète :
ansible-playbook inspect-and-collect.yml
Si la source, les faits et l'état des fichiers sont inchangés, les deux hôtes doivent indiquer changed=0 et aucun échec ni résultat unreachable. Vous disposez maintenant de rapports collectés indépendamment et fondés sur les métadonnées réellement gérées.
Résumé
Vous avez distingué l'état des fichiers du contrôleur et des nœuds gérés, déclaré les propriétaires et permissions distants et consommé les métadonnées stat enregistrées au lieu de simplement afficher un message de réussite. Les rapports par hôte ont enregistré de véritables informations d'intégrité SHA-256, et fetch a préservé les artefacts des deux hôtes dans des chemins distincts du contrôleur avec des répétitions stables.
