Skip to content

feat: add role fingerprints to syslog#29

Merged
richm merged 1 commit into
linux-system-roles:mainfrom
richm:fingerprint
Apr 27, 2026
Merged

feat: add role fingerprints to syslog#29
richm merged 1 commit into
linux-system-roles:mainfrom
richm:fingerprint

Conversation

@richm
Copy link
Copy Markdown
Collaborator

@richm richm commented Apr 27, 2026

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 to the trustee_client role and verify it via system journal tests.

New Features:

  • Introduce sr_fingerprint Ansible module to write timestamped fingerprint messages to syslog.
  • Record begin and success fingerprint messages for the trustee_client system role including platform and Ansible version.

Tests:

  • Extend default role tests to capture a start time and assert that expected fingerprint messages appear in the system journal when syslog is available.

Chores:

  • Add Ansible sanity ignore configuration files for multiple supported Ansible versions and test role library path.

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>
@richm richm requested a review from spetrosi as a code owner April 27, 2026 19:03
@sourcery-ai
Copy link
Copy Markdown

sourcery-ai Bot commented Apr 27, 2026

Reviewer's Guide

Adds a new sr_fingerprint Ansible module to write structured role fingerprint messages to syslog, wires it into the trustee_client role at begin/success points, and extends the default test playbook to validate the fingerprints via journalctl when /dev/log is available while updating sanity ignore files for the custom module across supported Ansible versions.

Sequence diagram for trustee_client role fingerprints to syslog

sequenceDiagram
    actor User
    participant AnsibleController
    participant AnsibleEngine
    participant TrusteeClientRole
    participant SrFingerprintModule
    participant Syslog

    User->>AnsibleController: run playbook with trustee_client role
    AnsibleController->>AnsibleEngine: execute playbook
    AnsibleEngine->>TrusteeClientRole: start role tasks

    Note over TrusteeClientRole: Begin fingerprint task
    TrusteeClientRole->>SrFingerprintModule: sr_fingerprint sr_message=begin system_role:trustee_client
    SrFingerprintModule->>SrFingerprintModule: build log_message with timestamp
    alt check_mode
        SrFingerprintModule-->>AnsibleEngine: exit changed=false, message=Check mode
    else normal_mode
        SrFingerprintModule->>Syslog: module.log(log_message)
        SrFingerprintModule-->>AnsibleEngine: exit changed=false
    end

    Note over TrusteeClientRole: Main role tasks (e.g. encrypt_disk)
    TrusteeClientRole->>TrusteeClientRole: perform trustee_client tasks

    Note over TrusteeClientRole: Success fingerprint task
    TrusteeClientRole->>SrFingerprintModule: sr_fingerprint sr_message=success system_role:trustee_client
    SrFingerprintModule->>SrFingerprintModule: build log_message with timestamp
    alt check_mode
        SrFingerprintModule-->>AnsibleEngine: exit changed=false, message=Check mode
    else normal_mode
        SrFingerprintModule->>Syslog: module.log(log_message)
        SrFingerprintModule-->>AnsibleEngine: exit changed=false
    end

    AnsibleEngine-->>AnsibleController: role completed
    User->>Syslog: inspect fingerprints via journalctl or syslog tools
Loading

Class diagram for sr_fingerprint Ansible module

classDiagram
    class SrFingerprintModuleFile {
        +_local_iso8601_no_microseconds() str
        +run_module() void
        +main() void
    }

    class AnsibleModule {
        +params dict
        +check_mode bool
        +log(message str) void
        +exit_json(**kwargs) void
    }

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

    class TimeModule {
        +strftime(format str, struct_time)
        +localtime() struct_time
    }

    SrFingerprintModuleFile ..> AnsibleModule : uses
    SrFingerprintModuleFile ..> DatetimeModule : uses
    SrFingerprintModuleFile ..> TimeModule : legacy fallback

    class SrFingerprintInvocation {
        +sr_message str
        +log_message str
    }

    SrFingerprintModuleFile ..> SrFingerprintInvocation : constructs

    class TrusteeClientRoleTasks {
        +Record_role_begin_fingerprint
        +Record_role_success_fingerprint
    }

    TrusteeClientRoleTasks ..> SrFingerprintModuleFile : calls sr_fingerprint

    class SyslogService {
        +receive_log(message str) void
    }

    AnsibleModule ..> SyslogService : module.log forwards to syslog
Loading

File-Level Changes

Change Details Files
Introduce sr_fingerprint custom Ansible module to log fingerprint messages to syslog without marking the task as changed.
  • Define sr_fingerprint module interface with required sr_message parameter and documentation metadata.
  • Implement timestamp helper to generate local ISO8601 timestamps without microseconds and with timezone handling fallbacks.
  • Use AnsibleModule with check_mode support, formatting log messages as '<sr_message> ' and logging via module.log while always returning changed=False.
library/sr_fingerprint.py
Emit role begin and success fingerprints from the trustee_client role with role name, Ansible version, and platform in the message.
  • Add a 'Record role begin fingerprint' task early in set_vars.yml using sr_fingerprint with a 'begin system_role:trustee_client' message including ansible_version and distribution facts.
  • Add a 'Record role success fingerprint' task at the end of main.yml using sr_fingerprint with a 'success system_role:trustee_client' message including ansible_version and distribution facts.
tasks/set_vars.yml
tasks/main.yml
Extend default tests to capture a start time and verify fingerprint messages in the system journal when syslog is available.
  • Add a stat task to check existence of /dev/log and register the result for conditional testing.
  • Record __journal_start_time fact from ansible_facts.date_time before running the role when /dev/log exists.
  • Add a shell task after running the role that uses journalctl --since __journal_start_time and grep to assert presence of begin and success sr_fingerprint messages for system_role:trustee_client, ignoring 'Invoked with' noise and not marking the play as changed.
tests/tests_default.yml
Update Ansible sanity configuration to account for the new custom module across supported versions and link it into the test role library path.
  • Add empty .sanity-ansible-ignore-2.14.txt through .sanity-ansible-ignore-2.22.txt files to adjust sanity checks for the collection.
  • Add tests/roles/linux-system-roles.trustee_client/library path for exposing the custom module 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.trustee_client/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

@richm
Copy link
Copy Markdown
Collaborator Author

richm commented Apr 27, 2026

[citest]

Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've left some high level feedback:

  • The sr_fingerprint module currently accepts any string, including empty/whitespace-only values, as sr_message; consider adding simple validation/normalization (e.g., strip and fail on empty) to avoid writing useless entries to syslog.
  • The journal check in tests_default.yml uses a long shell pipeline with journalctl | grep -v | grep ...; you could improve robustness and readability by using journalctl --grep (or separate command invocations with -q) and failed_when on the return code instead of hand-rolled set -eo pipefail logic.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The `sr_fingerprint` module currently accepts any string, including empty/whitespace-only values, as `sr_message`; consider adding simple validation/normalization (e.g., strip and fail on empty) to avoid writing useless entries to syslog.
- The journal check in `tests_default.yml` uses a long shell pipeline with `journalctl | grep -v | grep ...`; you could improve robustness and readability by using `journalctl --grep` (or separate `command` invocations with `-q`) and `failed_when` on the return code instead of hand-rolled `set -eo pipefail` logic.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@richm richm merged commit 805711f into linux-system-roles:main Apr 27, 2026
37 checks passed
@richm richm deleted the fingerprint branch April 27, 2026 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant