Введение
Надёжная автоматизация файлов различает исходный файл управляющего узла, управляемые копии и объекты, собранные обратно для проверки. Одни лишь правильные имена файлов не подтверждают целостность содержимого, права и идентичность хоста.
Вы развернёте баннер, изучите его фактические метаданные SHA-256 через stat и register, создадите эксплуатационные отчёты для каждого хоста и получите эти отчёты через fetch в отдельные пути управляющего узла. Подготовленное окружение SSH из двух хостов и модель привилегий совпадают с отработанными ранее.
Распространите файл с явными управляемыми правами
На этом шаге вы скопируете закрытый исходный файл управляющего узла в защищённый управляемый каталог и явно выберете удалённого владельца и права.
Откройте терминал и перейдите в проект:
cd /home/labex/project
Создайте многократно используемый исходный файл управляющего узла, включая завершающий перевод строки:
printf 'Managed service banner\n' > site-banner.txt
chmod меняет права локального файла. Права 0600 дают его владельцу чтение/запись и запрещают доступ группе и остальным. Сохраните этот исходный файл управляющего узла закрытым, намеренно выбрав другие управляемые права:
chmod 0600 site-banner.txt
Напишите плейбук распространения:
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
become уровня play запрашивает повышение привилегий на управляемых узлах, где запись внутри /srv и назначение владельца root требуют этого. Он не превращает процесс чтения источника на управляющем узле во вход от root.
Каталог принадлежит root, имеет группу automation и права 0750. Баннер принадлежит root, имеет группу automation и права 0640. Это позволяет обычной учётной записи automation проходить по каталогу и читать баннер без права записи. Явные управляемые права не зависят от прав 0600 исходного файла управляющего узла.
Проверьте и примените плейбук:
ansible-playbook deploy-banner.yml --syntax-check
ansible-playbook deploy-banner.yml
Оба хоста должны завершиться без сбоев. Проверьте обычный доступ для чтения без become:
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/banner.txt'
Каждый хост должен вывести Managed service banner. Это демонстрирует нужный удалённый доступ группы для чтения, сохраняя исходный файл и управляемые копии отдельными файлами.
Зарегистрируйте и используйте структурированные метаданные файла
На этом шаге вы изучите настоящий управляемый баннер и запишете эксплуатационный отчёт каждого хоста из его метаданных.
Модуль stat возвращает сведения о файле, а не копирует его. checksum_algorithm: sha256 выбирает SHA-256 для проверки содержимого. register сохраняет результат задачи для последующих задач на том же хосте; его поле stat содержит метаданные файла.
Создайте плейбук обследования:
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
Модуль debug отображает существующую переменную через var, поэтому banner_info.stat показывает поля exists, mode, имена владельца/группы, size и checksum. Отображение метаданных не создаёт файл и не подтверждает успех последующей операции.
Задача copy использует banner_info.stat.checksum вместе с inventory_hostname и фактом дистрибутива. Её become уровня задачи нужен для записи отчёта, принадлежащего root. Сами задачи обследования используют обычный доступ для чтения.
Запустите обследование и создание отчётов:
ansible-playbook inspect-and-collect.yml
Метаданные должны определять обычный файл с правами 0640, владельцем root и группой automation. Каждый отчёт имеет собственное имя хоста и значение SHA-256, полученное из фактического удалённого баннера.
sha256sum вычисляет дайджест SHA-256 локального файла и выводит его, а затем имя файла. Сравните дайджест исходного файла управляющего узла со значениями метаданных и отчётов:
sha256sum site-banner.txt
Прочитайте оба удалённых отчёта:
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/node-report.txt'
Каждый результат должен содержать host=web1 или host=web2, distribution=Ubuntu и banner_sha256 с последующим совпадающим дайджестом из 64 символов. Связывайте наблюдения с каждым настоящим хостом, не заменяя их постоянным сообщением debug.
Получите отдельные отчёты обратно на управляющий узел
На этом шаге вы соберёте оба управляемых отчёта, не перезаписав результат одного хоста результатом другого.
copy обычно отправляет исходный файл управляющего узла в управляемое место назначения. fetch работает в обратном направлении: его src находится на управляемом узле, а dest — каталог управляющего узла. При flat false fetch включает имя хоста инвентаря и удалённый путь внутри dest.
Добавьте эту задачу в существующий плейбук обследования. Сохраните отступ на уровне других записей задач; >> добавляет содержимое без замены предыдущих задач stat, register и отчёта:
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
Запустите полный процесс обследования и сбора:
ansible-playbook inspect-and-collect.yml
Первый fetch должен создать две копии на управляющем узле. Он выполняется от обычной учётной записи automation на каждом целевом узле, поскольку групповые права отчёта уже разрешают чтение.
Изучите каждый собранный объект локально:
cat reports/web1/srv/ansible-site/node-report.txt
cat reports/web2/srv/ansible-site/node-report.txt
Пути сохраняют независимые идентификаторы хостов. Поле host каждого отчёта должно соответствовать его пути, а оба поля checksum — развёрнутому источнику. Сведение обоих результатов к одному общему имени файла привело бы к потере объекта одного хоста.
Повторите полный процесс:
ansible-playbook inspect-and-collect.yml
При неизменных источнике, фактах и состоянии файлов оба хоста должны сообщать changed=0 и отсутствие сбоев/недоступных результатов. Теперь у вас есть независимо собранные отчёты, основанные на настоящих управляемых метаданных.
Резюме
Вы различали состояние файлов управляющего и управляемых узлов, объявили удалённого владельца и права и использовали зарегистрированные метаданные stat вместо простого вывода сообщения об успехе. Отчёты отдельных хостов записали реальные сведения о целостности SHA-256, а fetch сохранил объекты обоих хостов в отдельных путях управляющего узла со стабильным повторным выполнением.
