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 a role-internal fingerprint mechanism that logs begin and success markers for the crypto_policies role to syslog and verify them in tests.

New Features:

• Introduce the sr_fingerprint Ansible module to write timestamped fingerprint messages to syslog for role diagnostics.
• Record begin and success fingerprint messages for the linux-system-roles.crypto_policies role executions.

Tests:

• Extend the default test playbook to assert that the role’s begin and success fingerprint messages appear in the system journal when syslog is available.

Chores:

• Add Ansible sanity ignore files for multiple supported Ansible versions.

[sourcery-ai]

Reviewer's Guide

Adds a new Ansible module sr_fingerprint to log role lifecycle fingerprints to syslog and wires it into the crypto_policies role along with a journal-based test, plus supporting sanity ignore files and test role library path.

Sequence diagram for role lifecycle fingerprint logging

sequenceDiagram
    actor Admin
    participant AnsibleController
    participant CryptoPoliciesRole
    participant SrFingerprintModule as sr_fingerprint
    participant Syslog

    Admin->>AnsibleController: Run playbook with crypto_policies role
    AnsibleController->>CryptoPoliciesRole: Start role execution

    Note over CryptoPoliciesRole: set_vars.yml
    CryptoPoliciesRole->>SrFingerprintModule: begin fingerprint (sr_message)
    SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds()
    SrFingerprintModule->>Syslog: module.log("begin system_role:crypto_policies ... <timestamp>")

    CryptoPoliciesRole->>CryptoPoliciesRole: Apply crypto policies tasks

    Note over CryptoPoliciesRole: main.yml
    CryptoPoliciesRole->>SrFingerprintModule: success fingerprint (sr_message)
    SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds()
    SrFingerprintModule->>Syslog: module.log("success system_role:crypto_policies ... <timestamp>")

    Syslog-->>Admin: Logs visible via journald/log aggregator

Loading

Class diagram for the new sr_fingerprint Ansible module

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

    class AnsibleModule {
        +params dict
        +check_mode bool
        +log(message)
        +exit_json(changed, message)
    }

    sr_fingerprint_module ..> AnsibleModule : uses

    class _local_iso8601_no_microseconds_helper {
        +_local_iso8601_no_microseconds() string
    }

    sr_fingerprint_module ..> _local_iso8601_no_microseconds_helper : calls

    class Role_crypto_policies_tasks {
        +set_vars_yml()
        +main_yml()
    }

    class Task_Record_role_begin_fingerprint {
        +sr_message string
    }

    class Task_Record_role_success_fingerprint {
        +sr_message string
    }

    Role_crypto_policies_tasks o-- Task_Record_role_begin_fingerprint : includes
    Role_crypto_policies_tasks o-- Task_Record_role_success_fingerprint : includes
    Task_Record_role_begin_fingerprint ..> sr_fingerprint_module : invokes
    Task_Record_role_success_fingerprint ..> sr_fingerprint_module : invokes

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module to log fingerprint messages to syslog with timestamps.	Add custom module sr_fingerprint.py under library/ implementing sr_message parameter and using AnsibleModule Generate a local ISO8601 timestamp without microseconds, preferring system local timezone Log combined fingerprint message and timestamp via module.log without marking the task as changed Support check_mode by skipping logging and returning an explanatory message	library/sr_fingerprint.py
Emit begin and success role fingerprints from the crypto_policies role.	Add a 'begin' fingerprint task early in set_vars.yml with role name, Ansible version, and distribution info Add a 'success' fingerprint task at the end of main.yml after policy application and fact gathering Use sr_fingerprint module with structured sr_message text including role and platform information	tasks/set_vars.yml tasks/main.yml
Add test coverage to verify fingerprints are written to the system journal when syslog is available.	Check for /dev/log presence before running fingerprint-related assertions Capture the current datetime as the start bound for journalctl search Run the role, then use journalctl since the captured time and grep to assert presence of begin and success fingerprints, excluding generic 'Invoked with' messages Mark the fingerprint verification shell task as not changing and skip it when /dev/log is absent	tests/tests_default.yml
Adjust ancillary files for Ansible sanity and role local library path in tests.	Add versioned .sanity-ansible-ignore-2.xx.txt files to silence or adjust sanity checks for the custom module Create tests/roles/linux-system-roles.crypto_policies/library directory to make the module available in tests	.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 .sanity-ansible-ignore-2.22.txt tests/roles/linux-system-roles.crypto_policies/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 journal-based test currently assumes the syslog format will contain sr_fingerprint in the log line; relying on Ansible’s internal log format is brittle across versions, so it would be safer to grep only for the stable message content (e.g. begin system_role:crypto_policies / success system_role:crypto_policies) rather than the module name.
• The sr_fingerprint module skips logging in check mode, which means role executions with --check won’t leave any fingerprints; if the goal is to trace all role invocations, consider logging even in check mode while still returning changed=False.
• The shell-based journalctl check runs two nearly identical pipelines and filters out " Invoked with" lines with grep -v, which may accidentally drop other relevant lines; you could simplify and harden this by using a single journalctl invocation and more precise grep patterns anchored on the fingerprint message structure.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The journal-based test currently assumes the syslog format will contain `sr_fingerprint` in the log line; relying on Ansible’s internal log format is brittle across versions, so it would be safer to grep only for the stable message content (e.g. `begin system_role:crypto_policies` / `success system_role:crypto_policies`) rather than the module name.
- The `sr_fingerprint` module skips logging in check mode, which means role executions with `--check` won’t leave any fingerprints; if the goal is to trace all role invocations, consider logging even in check mode while still returning `changed=False`.
- The shell-based journalctl check runs two nearly identical pipelines and filters out `" Invoked with"` lines with `grep -v`, which may accidentally drop other relevant lines; you could simplify and harden this by using a single `journalctl` invocation and more precise grep patterns anchored on the fingerprint message structure.

---

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.}