feat: add role fingerprints to syslog

[richm]

Feature: Add a fingerprint string to the system log to indicate when the role began
successfully, and when the role finished successfully. The fingerprint string indicates
the role name, a timestamp, and the platform.

Reason: Users can see when the role was used and if it was used successfully. This
information from the system log can be collected by log scanners and aggregators
for further analysis.

Result: The role logs fingerprints to the system log.

This also adds a test to check if the fingerprints were written upon a successful
role invocation.

Signed-off-by: Rich Megginson rmeggins@redhat.com

Summary by Sourcery

Add syslog fingerprinting for the aide system role and verify it via tests.

New Features:

• Introduce an sr_fingerprint Ansible module to write timestamped fingerprint messages to syslog.
• Record begin and success fingerprint messages for the aide system role, including Ansible and platform metadata.

Tests:

• Extend the default role test playbook to assert that begin and success fingerprint messages are written to the system journal.

[sourcery-ai]

Reviewer's Guide

Adds a custom sr_fingerprint Ansible module to write standardized begin/success role fingerprints to syslog, wires it into the aide role lifecycle, and introduces a journal-based test plus ansible-lint sanity ignores to validate fingerprint logging without affecting idempotency.

Sequence diagram for role fingerprint logging to syslog

sequenceDiagram
    actor User
    participant AnsibleController
    participant ManagedHost
    participant sr_fingerprint_module as sr_fingerprint
    participant Syslog

    User->>AnsibleController: Run playbook with aide role
    AnsibleController->>ManagedHost: Execute set_vars tasks
    ManagedHost->>sr_fingerprint_module: sr_fingerprint sr_message="begin system_role:aide ..."
    activate sr_fingerprint_module
    sr_fingerprint_module->>sr_fingerprint_module: _local_iso8601_no_microseconds()
    alt check_mode enabled
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=False, message="Check mode: message not logged - [...]")
    else normal mode
        sr_fingerprint_module->>Syslog: module.log("begin system_role:aide ... <timestamp>")
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=False)
    end
    deactivate sr_fingerprint_module

    AnsibleController->>ManagedHost: Execute aide role main tasks
    ManagedHost->>sr_fingerprint_module: sr_fingerprint sr_message="success system_role:aide ..."
    activate sr_fingerprint_module
    sr_fingerprint_module->>sr_fingerprint_module: _local_iso8601_no_microseconds()
    alt check_mode enabled
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=False, message="Check mode: message not logged - [...]")
    else normal mode
        sr_fingerprint_module->>Syslog: module.log("success system_role:aide ... <timestamp>")
        sr_fingerprint_module-->>ManagedHost: exit_json(changed=False)
    end
    deactivate sr_fingerprint_module

Loading

Updated class diagram for sr_fingerprint Ansible module

classDiagram
    class sr_fingerprint_module {
        +run_module()
        +main()
        -_local_iso8601_no_microseconds() str
    }

    class AnsibleModule {
        +params dict
        +check_mode bool
        +log(msg)
        +exit_json(**kwargs)
    }

    class datetime_module {
        +datetime
        +timezone
        +now()
    }

    class time_module {
        +strftime(format, t)
        +localtime()
    }

    sr_fingerprint_module ..> AnsibleModule : uses
    sr_fingerprint_module ..> datetime_module : uses
    sr_fingerprint_module ..> time_module : fallback uses

Loading

Flow diagram for aide role lifecycle fingerprints

flowchart TD
    Start["Start aide role execution"] --> SetVars["Run set_vars.yml"]
    SetVars --> BeginFingerprint["Task: Record role begin fingerprint (sr_fingerprint)"]
    BeginFingerprint --> AideTasks["Run main.yml aide tasks"]
    AideTasks --> SuccessFingerprint["Task: Record role success fingerprint (sr_fingerprint)"]
    SuccessFingerprint --> End["End aide role execution"]

    subgraph FingerprintFormat["Fingerprint message format"]
        BeginMsg["begin system_role:aide ansible_version=<version> <distro>-<version> <timestamp>"]
        SuccessMsg["success system_role:aide ansible_version=<version> <distro>-<version> <timestamp>"]
    end

    BeginFingerprint -. writes .-> BeginMsg
    SuccessFingerprint -. writes .-> SuccessMsg

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module to log fingerprint messages to syslog with a local ISO-8601 timestamp while remaining idempotent.	Create library/sr_fingerprint.py implementing a module that accepts an sr_message parameter and writes it to syslog via module.log Implement _local_iso8601_no_microseconds helper to generate local-time ISO 8601 timestamps with timezone and no microseconds, with a fallback for older Python versions Ensure module supports check mode by short-circuiting with changed=False and a descriptive message, and always exits with changed=False after logging to avoid affecting idempotency	library/sr_fingerprint.py
Emit role lifecycle fingerprints (begin and success) from the aide role using the sr_fingerprint module.	Add a begin fingerprint task early in tasks/set_vars.yml that logs role start with role name, Ansible version, and distro/version Add a success fingerprint task at the end of tasks/main.yml that logs role completion with the same contextual details Standardize fingerprint message format using tokens like 'begin system_role:aide' and 'success system_role:aide' for easy log parsing	tasks/set_vars.yml tasks/main.yml
Add an integration-style test that verifies fingerprints are written to the system journal during a default role run.	Capture a start timestamp fact before invoking the role to bound the journal search window After running the role, use journalctl piped through grep to assert presence of begin and success fingerprints, filtering out 'Invoked with' noise and failing explicitly if not found Mark the journal check task as not changed to preserve play idempotency semantics	tests/tests_default.yml
Update repository structure and tooling configuration to support the new module for multiple Ansible versions.	Add version-specific .sanity-ansible-ignore-2.x.txt files to bypass ansible-test sanity issues for the new module on various Ansible releases Add tests/roles/linux-system-roles.aide/library to expose the custom module to the test environment	.sanity-ansible-ignore-2.14.txt .sanity-ansible-ignore-2.16.txt .sanity-ansible-ignore-2.17.txt .sanity-ansible-ignore-2.18.txt .sanity-ansible-ignore-2.19.txt .sanity-ansible-ignore-2.20.txt .sanity-ansible-ignore-2.21.txt tests/roles/linux-system-roles.aide/library

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• The fingerprint message strings (begin system_role:aide / success system_role:aide) are hard-coded in multiple tasks; consider centralizing the role identifier in a variable or fact so it doesn’t need to be updated in several places if the role name or convention changes.
• The test that inspects journalctl assumes a systemd-based system and a working journal; you may want to guard this task with a condition like when: ansible_service_mgr == 'systemd' to avoid failures on non-systemd targets.
• The module treats check mode as a no-op and exits without logging; if fingerprints are expected during dry-runs as well, consider either logging even in check mode or adding an option to control this behavior explicitly.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The fingerprint message strings (`begin system_role:aide` / `success system_role:aide`) are hard-coded in multiple tasks; consider centralizing the role identifier in a variable or fact so it doesn’t need to be updated in several places if the role name or convention changes.
- The test that inspects `journalctl` assumes a systemd-based system and a working journal; you may want to guard this task with a condition like `when: ansible_service_mgr == 'systemd'` to avoid failures on non-systemd targets.
- The module treats check mode as a no-op and exits without logging; if fingerprints are expected during dry-runs as well, consider either logging even in check mode or adding an option to control this behavior explicitly.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[richm]

[citest]