feat: add role fingerprints to syslog#499
Merged
richm merged 1 commit intolinux-system-roles:mainfrom Apr 25, 2026
Merged
Conversation
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>
Reviewer's GuideImplements a new Ansible module sr_fingerprint that writes timestamped role fingerprint messages to syslog, wires it into the logging role to record begin/success events, and adds a test that asserts the fingerprints are written by inspecting the system journal when /dev/log is available. Sequence diagram for logging role fingerprints via sr_fingerprint modulesequenceDiagram
actor Admin
participant AnsibleController
participant LoggingRole
participant SrFingerprintModule
participant Syslog
Admin->>AnsibleController: Run playbook with logging role
AnsibleController->>LoggingRole: Execute tasks
rect rgb(235, 245, 255)
LoggingRole->>LoggingRole: Ensure ansible_facts via setup
LoggingRole->>SrFingerprintModule: Call sr_fingerprint
activate SrFingerprintModule
SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds
SrFingerprintModule->>Syslog: module.log(begin fingerprint + timestamp)
SrFingerprintModule-->>LoggingRole: exit_json(changed=False)
deactivate SrFingerprintModule
end
LoggingRole->>LoggingRole: Configure logging (rsyslog or other)
rect rgb(235, 245, 255)
LoggingRole->>SrFingerprintModule: Call sr_fingerprint
activate SrFingerprintModule
SrFingerprintModule->>SrFingerprintModule: _local_iso8601_no_microseconds
SrFingerprintModule->>Syslog: module.log(success fingerprint + timestamp)
SrFingerprintModule-->>LoggingRole: exit_json(changed=False)
deactivate SrFingerprintModule
end
Admin->>Syslog: Inspect logs for begin/success fingerprints
Class diagram for the new sr_fingerprint Ansible moduleclassDiagram
class sr_fingerprint_module {
+str sr_message
+run_module()
+main()
+_local_iso8601_no_microseconds() str
}
class AnsibleModule {
+dict params
+bool supports_check_mode
+log(msg)
+exit_json(changed, message)
}
class datetime_module {
+datetime now()
+timezone utc
}
class time_module {
+str strftime(format, t)
+struct_time localtime()
}
sr_fingerprint_module ..> AnsibleModule : uses
sr_fingerprint_module ..> datetime_module : uses
sr_fingerprint_module ..> time_module : fallback uses
sr_fingerprint_module : run_module()
sr_fingerprint_module : main()
sr_fingerprint_module : _local_iso8601_no_microseconds()
sr_fingerprint_module : builds log_message = sr_message + ISO8601 timestamp
sr_fingerprint_module : check_mode -> exit_json(changed=False, message)
sr_fingerprint_module : normal -> module.log(log_message)
sr_fingerprint_module : exit_json(changed=False)
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- The
sr_fingerprintmessages for begin/success are duplicated inset_vars.ymlandtasks/main.yml; consider centralizing the message formatting (e.g. via a variable or template) so changes to the format or contents only need to be made in one place. - The journal check task assumes
journalctlis available and systemd is in use whenever/dev/logexists; if this role may run on non-systemd systems with/dev/log, consider guarding the task with a systemd/journalctl availability check or handling the absence more gracefully.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `sr_fingerprint` messages for begin/success are duplicated in `set_vars.yml` and `tasks/main.yml`; consider centralizing the message formatting (e.g. via a variable or template) so changes to the format or contents only need to be made in one place.
- The journal check task assumes `journalctl` is available and systemd is in use whenever `/dev/log` exists; if this role may run on non-systemd systems with `/dev/log`, consider guarding the task with a systemd/journalctl availability check or handling the absence more gracefully.
## Individual Comments
### Comment 1
<location path="library/sr_fingerprint.py" line_range="10-12" />
<code_context>
+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.
+ - Intended for role-internal or diagnostic use.
+author: Rich Megginson (@richm)
</code_context>
<issue_to_address>
**suggestion:** Clarify whether this logs to the controller log or actual system syslog on the managed host.
Since this uses `module.log`, the message is written to the Ansible controller log (which may or may not be syslog), not to the managed host’s system syslog. Please reword the description to make clear this is controller-side module logging so it’s not mistaken for host-local syslog behavior.
Suggested implementation:
```python
short_description: Write a message string to the Ansible controller log using Ansible C(module.log) function.
```
```python
- Writes the given string to the Ansible controller log using Ansible C(module.log) function.
- This uses controller-side logging and does not write to the managed host's local syslog directly.
```
```python
description: Text to record in the Ansible controller log.
```
```python
- name: Record a fingerprint message in the Ansible controller log
```
</issue_to_address>
### Comment 2
<location path="library/sr_fingerprint.py" line_range="28" />
<code_context>
+ sr_message: "system_role:ROLENAME"
+"""
+
+RETURN = r""" # """
+
+from ansible.module_utils.basic import AnsibleModule
</code_context>
<issue_to_address>
**suggestion:** Use a proper RETURN block or remove it to avoid confusing tooling and readers.
The current sentinel value (`RETURN = r""" # """`) is non-standard and may confuse ansible-doc or other tooling that inspects `RETURN`. If you don’t need return docs, omit `RETURN` entirely, or use an empty but valid block such as `RETURN = r"""
"""` to keep module docs and sanity checks predictable.
```suggestion
RETURN = r"""
"""
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+10
to
+12
| 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. |
There was a problem hiding this comment.
suggestion: Clarify whether this logs to the controller log or actual system syslog on the managed host.
Since this uses module.log, the message is written to the Ansible controller log (which may or may not be syslog), not to the managed host’s system syslog. Please reword the description to make clear this is controller-side module logging so it’s not mistaken for host-local syslog behavior.
Suggested implementation:
short_description: Write a message string to the Ansible controller log using Ansible C(module.log) function. - Writes the given string to the Ansible controller log using Ansible C(module.log) function.
- This uses controller-side logging and does not write to the managed host's local syslog directly. description: Text to record in the Ansible controller log.- name: Record a fingerprint message in the Ansible controller log| sr_message: "system_role:ROLENAME" | ||
| """ | ||
|
|
||
| RETURN = r""" # """ |
There was a problem hiding this comment.
suggestion: Use a proper RETURN block or remove it to avoid confusing tooling and readers.
The current sentinel value (RETURN = r""" # """) is non-standard and may confuse ansible-doc or other tooling that inspects RETURN. If you don’t need return docs, omit RETURN entirely, or use an empty but valid block such as RETURN = r""" """ to keep module docs and sanity checks predictable.
Suggested change
| RETURN = r""" # """ | |
| RETURN = r""" | |
| """ |
Collaborator
Author
|
[citest] |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 role fingerprint logging to syslog and verify it via system journal tests.
New Features:
Enhancements:
Tests: