Introdução
Uma automação confiável de arquivos distingue a origem no controlador, as cópias gerenciadas e os artefatos coletados de volta para inspeção. Nomes de arquivos corretos, por si só, não comprovam a integridade do conteúdo, as permissões nem a identidade do host.
Você implantará um banner, inspecionará seus metadados SHA-256 reais com stat e register, gerará relatórios operacionais por host e coletará esses relatórios com fetch em caminhos separados no controlador. O ambiente preparado de dois hosts SSH e o modelo de privilégios são os mesmos praticados anteriormente.
Distribuir um arquivo com permissões gerenciadas explícitas
Nesta etapa, você copiará uma origem privada do controlador para um diretório gerenciado protegido e escolherá explicitamente a propriedade e as permissões remotas.
Abra o Terminal e entre no projeto:
cd /home/labex/project
Crie a origem reutilizável no controlador, incluindo sua quebra de linha final:
printf 'Managed service banner\n' > site-banner.txt
chmod altera as permissões de um arquivo local. O modo 0600 dá ao proprietário acesso de leitura/escrita e nenhum acesso ao grupo ou aos demais. Mantenha essa origem no controlador privada enquanto escolhe deliberadamente permissões gerenciadas diferentes:
chmod 0600 site-banner.txt
Escreva um playbook de distribuição:
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
O become no nível do play solicita elevação nos nós gerenciados, onde gravar em /srv e atribuir a propriedade a root a exigem. Ele não transforma o processo de leitura da origem no controlador em um login root.
O diretório pertence a root, tem grupo automation e modo 0750. O banner pertence a root, tem grupo automation e modo 0640. Isso permite que a conta comum automation percorra o diretório e leia o banner sem receber acesso de escrita. O modo gerenciado explícito é independente do modo 0600 da origem no controlador.
Verifique e aplique o playbook:
ansible-playbook deploy-banner.yml --syntax-check
ansible-playbook deploy-banner.yml
Os dois hosts devem concluir sem falhas. Teste o acesso comum de leitura sem become:
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/banner.txt'
Cada host deve imprimir Managed service banner. Isso demonstra o acesso remoto pretendido de leitura pelo grupo, mantendo a origem e as cópias gerenciadas como arquivos separados.
Registrar e usar metadados estruturados de arquivos
Nesta etapa, você inspecionará o banner gerenciado real e escreverá um relatório operacional por host a partir de seus metadados.
O módulo stat retorna informações do arquivo em vez de copiá-lo. checksum_algorithm: sha256 seleciona SHA-256 para a verificação do conteúdo. register armazena o resultado dessa tarefa para tarefas posteriores no mesmo host; seu campo stat contém os metadados do arquivo.
Crie um playbook de inspeção:
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
O módulo debug exibe uma variável existente com var, portanto banner_info.stat revela campos como exists, mode, nomes de proprietário/grupo, size e checksum. Exibir metadados não cria um arquivo nem comprova que uma operação posterior teve sucesso.
A tarefa copy usa banner_info.stat.checksum junto a inventory_hostname e ao fato de distribuição. Seu become no nível da tarefa é necessário para gravar o relatório pertencente a root. As próprias tarefas de inspeção usam o acesso comum de leitura.
Execute a inspeção e a geração dos relatórios:
ansible-playbook inspect-and-collect.yml
Os metadados devem identificar um arquivo regular com modo 0640, proprietário root e grupo automation. Cada relatório tem seu próprio nome de host e um valor SHA-256 derivado do banner remoto real.
sha256sum calcula o resumo SHA-256 de um arquivo local e imprime o resumo seguido de seu nome. Compare o resumo da origem no controlador com os valores dos metadados e dos relatórios:
sha256sum site-banner.txt
Leia os dois relatórios remotos:
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/node-report.txt'
Cada resultado deve conter host=web1 ou host=web2, distribution=Ubuntu e banner_sha256 seguido do resumo correspondente de 64 caracteres. Mantenha as observações vinculadas a cada host real, em vez de substituí-las por uma mensagem debug constante.
Coletar relatórios separados de volta ao controlador
Nesta etapa, você coletará os dois relatórios gerenciados sem sobrescrever o resultado de um host com o do outro.
copy normalmente envia uma origem do controlador para um destino gerenciado. fetch funciona no sentido contrário: seu src fica no nó gerenciado e seu dest é um diretório no controlador. Com flat false, fetch inclui o nome do host no inventário e o caminho remoto sob dest.
Acrescente esta tarefa ao playbook de inspeção existente. Mantenha sua indentação alinhada às outras entradas de tarefas; >> acrescenta sem substituir as tarefas anteriores de stat, register e relatório:
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
Execute o fluxo completo de inspeção e coleta:
ansible-playbook inspect-and-collect.yml
A primeira coleta com fetch deve criar as duas cópias no controlador. Ela executa como a conta comum automation em cada destino porque as permissões de grupo do relatório já permitem a leitura.
Inspecione localmente cada artefato coletado:
cat reports/web1/srv/ansible-site/node-report.txt
cat reports/web2/srv/ansible-site/node-report.txt
Os caminhos preservam a identidade independente dos hosts. O campo host de cada relatório deve corresponder a seu caminho, e os dois campos de checksum devem corresponder à origem implantada. Achatar os dois resultados em um único nome de arquivo compartilhado perderia o artefato de um host.
Repita o fluxo completo:
ansible-playbook inspect-and-collect.yml
Com a origem, os fatos e o estado dos arquivos inalterados, os dois hosts devem informar changed=0 e nenhum resultado de falha ou unreachable. Agora você tem relatórios coletados de forma independente, baseados em metadados gerenciados reais.
Resumo
Você manteve distintos os estados dos arquivos no controlador e nos nós gerenciados, declarou propriedade e permissões remotas e usou metadados stat registrados em vez de apenas imprimir uma mensagem de sucesso. Relatórios por host registraram informações reais de integridade SHA-256, e fetch preservou os artefatos dos dois hosts em caminhos separados no controlador, com execução repetida estável.
