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 custom Ansible module and role hooks to write start and success fingerprints for the trustee_server role to syslog, and validate them via tests.

New Features:

• Introduce sr_fingerprint Ansible module to log structured fingerprint messages to syslog for diagnostic and auditing purposes.
• Record begin and success fingerprint messages for the trustee_server role including Ansible version and platform details.

CI:

• Add Ansible sanity ignore configuration files for multiple Ansible versions to accommodate the new custom module in CI.

Tests:

• Extend default role tests to detect syslog availability and verify that the trustee_server role emits the expected begin and success fingerprint entries via journalctl.

[sourcery-ai]

Reviewer's Guide

Adds a new sr_fingerprint Ansible module to log role start/success fingerprints to syslog and wires it into the trustee_server role with accompanying journal-based tests and Ansible sanity ignores.

Sequence diagram for sr_fingerprint module logging to syslog

sequenceDiagram
    actor Operator
    participant AnsibleController
    participant sr_fingerprint_module
    participant AnsibleModule
    participant Syslog

    Operator->>AnsibleController: Run trustee_server role
    AnsibleController->>sr_fingerprint_module: Invoke sr_fingerprint sr_message
    activate sr_fingerprint_module
    sr_fingerprint_module->>sr_fingerprint_module: _local_iso8601_no_microseconds()
    sr_fingerprint_module->>AnsibleModule: Create instance with argument_spec and supports_check_mode
    activate AnsibleModule

    alt Check mode enabled
        sr_fingerprint_module->>AnsibleModule: exit_json(changed=False, message="Check mode: message not logged ...")
    else Normal execution
        sr_fingerprint_module->>AnsibleModule: module.log(log_message)
        AnsibleModule->>Syslog: Write log_message
        sr_fingerprint_module->>AnsibleModule: exit_json(changed=False)
    end
    deactivate AnsibleModule
    deactivate sr_fingerprint_module

    AnsibleController-->>Operator: Report role completion

Loading

Class diagram for sr_fingerprint Ansible module

classDiagram
    class sr_fingerprint_module {
        <<module>>
        +_local_iso8601_no_microseconds() str
        +run_module() void
        +main() void
    }

    class AnsibleModule {
        <<external>>
        +log(msg)
        +exit_json(**kwargs)
    }

    sr_fingerprint_module ..> AnsibleModule : uses

Loading

Flow diagram for trustee_server role begin/success fingerprints

flowchart TD
    A[Start trustee_server role] --> B[set_vars.yml]
    B --> C[Task: Record role begin fingerprint
sr_fingerprint sr_message='begin system_role:trustee_server ...']
    C --> D[Other set_vars tasks
Determine if system is ostree, set flags, etc.]
    D --> E[tasks/main.yml]
    E --> F[Main role tasks
trustee_server_secret_registration, trustee_server_trustee, etc.]
    F --> G[Task: Record role success fingerprint
sr_fingerprint sr_message='success system_role:trustee_server ...']
    G --> H[End trustee_server role]

Loading

File-Level Changes

Change	Details	Files
Introduce sr_fingerprint Ansible module to write timestamped messages to syslog without reporting configuration changes.	Create custom Ansible module sr_fingerprint.py under library/ using AnsibleModule to accept a required sr_message parameter. Implement helper _local_iso8601_no_microseconds to generate local ISO8601 timestamps, including a fallback for older Python without datetime.timezone. Log combined sr_message and timestamp via module.log, honoring check mode and always returning changed=False.	library/sr_fingerprint.py
Emit role begin and success fingerprints from trustee_server role using sr_fingerprint with role, Ansible, and platform metadata.	Add 'Record role begin fingerprint' task at the start of set_vars.yml using sr_fingerprint to log a 'begin system_role:trustee_server' message with ansible_version and distribution info. Add 'Record role success fingerprint' task at the end of tasks/main.yml using sr_fingerprint to log a 'success system_role:trustee_server' message with the same metadata. Ensure fingerprints encode platform via distribution and distribution_version facts and are non-intrusive (no state changes).	tasks/set_vars.yml tasks/main.yml
Extend default tests to assert fingerprints are written to the system journal when syslog is available.	Add a stat task to check existence of /dev/log and conditionally enable fingerprint checks only when syslog logging is available. Capture a __journal_start_time fact based on ansible_facts['date_time'] before running the role to bound the journalctl search window. Add a shell task that uses journalctl since __journal_start_time, filters out 'Invoked with' noise, and verifies presence of both 'begin' and 'success' sr_fingerprint messages for system_role:trustee_server; mark task as not changed. Wire tests/roles/linux-system-roles.trustee_server/library to expose the custom module in the test role path.	tests/tests_default.yml tests/roles/linux-system-roles.trustee_server/library
Adjust Ansible sanity configuration to ignore the custom module for specific Ansible versions.	Introduce .sanity-ansible-ignore-2.14.txt through .sanity-ansible-ignore-2.22.txt to suppress or adjust sanity checks for the new module across multiple Ansible versions.	.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

---

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.

[richm]

[citest]

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="library/sr_fingerprint.py" line_range="7-10" />
<code_context>
+
+__metaclass__ = type
+
+DOCUMENTATION = """
+---
+module: sr_fingerprint
+short_description: Write a message string to syslog using Ansible C(module.log) function.
+description:
+    - Writes the given string to the system log using Ansible C(module.log) function.
</code_context>
<issue_to_address>
**issue:** The documentation claims syslog logging, but `module.log` doesn’t always map directly to syslog across all connections.

`module.log` writes to the Ansible log, which may or may not end up in syslog depending on controller configuration and callbacks. Relying on this to always appear in the system syslog is therefore inaccurate. Please update the wording to either refer to the Ansible log, or clearly state under which configurations the messages will appear in syslog.
</issue_to_address>

---

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

[sourcery-ai]

issue: The documentation claims syslog logging, but module.log doesn’t always map directly to syslog across all connections.

module.log writes to the Ansible log, which may or may not end up in syslog depending on controller configuration and callbacks. Relying on this to always appear in the system syslog is therefore inaccurate. Please update the wording to either refer to the Ansible log, or clearly state under which configurations the messages will appear in syslog.