Einführung
Zuverlässige Dateiautomatisierung unterscheidet zwischen der Quelle auf dem Controller, den verwalteten Kopien und den zur Untersuchung zurückgeholten Artefakten. Korrekte Dateinamen allein belegen weder Inhaltsintegrität noch Berechtigungen oder Hostidentität.
Sie verteilen ein Banner, untersuchen dessen tatsächliche SHA-256-Metadaten mit stat und register, erzeugen hostspezifische Betriebsberichte und holen diese Berichte in separate Controller-Pfade zurück. Die vorbereitete Zwei-Host-SSH-Umgebung und das Berechtigungsmodell entsprechen den zuvor geübten.
Eine Datei mit ausdrücklichen verwalteten Berechtigungen verteilen
In diesem Schritt kopieren Sie eine private Controller-Quelle in ein geschütztes verwaltetes Verzeichnis und wählen entfernten Eigentümer und Berechtigungen ausdrücklich aus.
Öffnen Sie das Terminal und wechseln Sie ins Projekt:
cd /home/labex/project
Erstellen Sie die wiederverwendbare Controller-Quelle einschließlich ihres abschließenden Zeilenumbruchs:
printf 'Managed service banner\n' > site-banner.txt
chmod ändert die Berechtigungen einer lokalen Datei. Modus 0600 gibt ihrem Eigentümer Lese-/Schreibzugriff und ihrer Gruppe sowie anderen keinen Zugriff. Halten Sie diese Controller-Quelle privat und wählen Sie bewusst andere verwaltete Berechtigungen:
chmod 0600 site-banner.txt
Schreiben Sie ein Verteilungs-Playbook:
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 auf Play-Ebene fordert erhöhte Rechte auf den verwalteten Knoten an, wo das Schreiben unter /srv und die Zuweisung von root als Eigentümer diese erfordern. Es verwandelt den quellenlesenden Prozess auf dem Controller nicht in eine root-Anmeldung.
Das Verzeichnis gehört root, ist der Gruppe automation zugeordnet und hat Modus 0750. Das Banner gehört root, ist der Gruppe automation zugeordnet und hat Modus 0640. Dadurch kann das gewöhnliche Konto automation das Verzeichnis durchqueren und das Banner lesen, ohne Schreibzugriff zu erhalten. Der ausdrücklich angegebene verwaltete Modus ist unabhängig vom Modus 0600 der Controller-Quelle.
Prüfen Sie das Playbook und wenden Sie es an:
ansible-playbook deploy-banner.yml --syntax-check
ansible-playbook deploy-banner.yml
Beide Hosts sollten ohne Fehler abschließen. Testen Sie gewöhnlichen Lesezugriff ohne become:
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/banner.txt'
Jeder Host sollte Managed service banner ausgeben. Dies zeigt den vorgesehenen entfernten Gruppenlesezugriff, während Quelle und verwaltete Kopien separate Dateien bleiben.
Strukturierte Dateimetadaten registrieren und verwenden
In diesem Schritt untersuchen Sie das tatsächliche verwaltete Banner und schreiben aus seinen Metadaten einen hostspezifischen Betriebsbericht.
Das stat-Modul liefert Dateiinformationen, statt sie zu kopieren. checksum_algorithm: sha256 wählt SHA-256 zur Inhaltsprüfung aus. register speichert das Ergebnis dieser Aufgabe für spätere Aufgaben auf demselben Host; sein Feld stat enthält die Dateimetadaten.
Erstellen Sie ein Untersuchungs-Playbook:
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
Das debug-Modul zeigt mit var eine bestehende Variable an; banner_info.stat macht somit Felder wie exists, mode, Eigentümer-/Gruppennamen, Größe und Prüfsumme sichtbar. Die Anzeige von Metadaten erstellt keine Datei und belegt nicht den Erfolg einer späteren Operation.
Die copy-Aufgabe verwendet banner_info.stat.checksum zusammen mit inventory_hostname und dem Distributions-Fact. Ihr become auf Aufgabenebene ist erforderlich, um den Bericht mit Eigentümer root zu schreiben. Die Untersuchungsaufgaben selbst verwenden gewöhnlichen Lesezugriff.
Führen Sie Untersuchung und Berichtserzeugung aus:
ansible-playbook inspect-and-collect.yml
Die Metadaten sollten eine reguläre Datei mit Modus 0640, Eigentümer root und Gruppe automation ausweisen. Jeder Bericht hat seinen eigenen Hostnamen und einen SHA-256-Wert, der vom tatsächlichen entfernten Banner abgeleitet ist.
sha256sum berechnet den SHA-256-Hash einer lokalen Datei und gibt den Hash gefolgt vom Namen aus. Vergleichen Sie den Hash der Controller-Quelle mit den Metadaten und Berichtswerten:
sha256sum site-banner.txt
Lesen Sie beide entfernten Berichte:
ansible all -m ansible.builtin.command -a 'cat /srv/ansible-site/node-report.txt'
Jedes Ergebnis sollte host=web1 oder host=web2, distribution=Ubuntu und banner_sha256 gefolgt vom passenden 64-stelligen Hash enthalten. Beziehen Sie Beobachtungen auf jeden tatsächlichen Host, statt sie durch eine konstante debug-Nachricht zu ersetzen.
Separate Berichte zum Controller zurückholen
In diesem Schritt sammeln Sie beide verwalteten Berichte ein, ohne das Ergebnis eines Hosts mit dem des anderen zu überschreiben.
copy sendet normalerweise eine Controller-Quelle an ein verwaltetes Ziel. fetch arbeitet in der Gegenrichtung: Seine src liegt auf dem verwalteten Knoten und seine dest ist ein Controller-Verzeichnis. Bei flat false nimmt fetch den Inventarhostnamen und den entfernten Pfad unter dest auf.
Hängen Sie diese Aufgabe an das bestehende Untersuchungs-Playbook an. Richten Sie ihre Einrückung an den anderen Aufgabeneinträgen aus; >> hängt an, ohne die früheren stat-, register- und Berichtsaufgaben zu ersetzen:
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
Führen Sie den vollständigen Untersuchungs- und Sammelablauf aus:
ansible-playbook inspect-and-collect.yml
Der erste fetch-Aufruf sollte die beiden Controller-Kopien erstellen. Er läuft auf jedem Ziel als gewöhnliches Konto automation, weil die Gruppenberechtigungen des Berichts bereits Lesen erlauben.
Untersuchen Sie jedes gesammelte Artefakt lokal:
cat reports/web1/srv/ansible-site/node-report.txt
cat reports/web2/srv/ansible-site/node-report.txt
Die Pfade erhalten unabhängige Hostidentität. Das Feld host jedes Berichts sollte seinem Pfad entsprechen, und beide Prüfsummenfelder sollten mit der verteilten Quelle übereinstimmen. Würden beide Ergebnisse auf einen gemeinsamen Dateinamen abgeflacht, ginge das Artefakt eines Hosts verloren.
Wiederholen Sie den vollständigen Ablauf:
ansible-playbook inspect-and-collect.yml
Bei unveränderter Quelle, unveränderten Facts und unverändertem Dateizustand sollten beide Hosts changed=0 und keine Fehler/unerreichbaren Ergebnisse melden. Sie verfügen nun über unabhängig gesammelte Berichte, die auf tatsächlichen verwalteten Metadaten beruhen.
Zusammenfassung
Sie haben Controller- und verwalteten Dateizustand getrennt gehalten, entfernte Eigentümer und Berechtigungen deklariert und registrierte stat-Metadaten verwendet, statt lediglich eine Erfolgsmeldung auszugeben. Hostspezifische Berichte hielten tatsächliche SHA-256-Integritätsinformationen fest, und fetch bewahrte die Artefakte beider Hosts in separaten Controller-Pfaden bei stabiler wiederholter Ausführung.
