# Target System Change Logs? **URL:** \ **Category:** Ansible Project\ **Created:** [March 1, 2013, 10:16pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441 "2013-03-01T22:16:57Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Christopher\_Snapp](https://avatars.discourse-cdn.com/v4/letter/c/a8b319/32.png) [@Christopher\_Snapp](https://forum.ansible.com/u/Christopher_Snapp)\ **Post date:** [March 1, 2013, 10:16pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441/1 "2013-03-01T22:16:57Z")
In my environment (due to auditing policy) all machines currently have a changelog file residing on the system. As I bring these machines under ansible’s control I lose the ability to do a simple one line entry should a change occur. I understand there is very verbose logging being sent to syslog, but I’m aiming to simply inject a timestamped line containing the username of the person logged in who is running ansible with the “name” of the task only if the action produced a change. My first thought was to look into a global handler, so I came to submit a feature request for global handlers and did a quick search and it looks like someone brought up a desire for registering global handlers where they wanted to do service restarts. I agree with Michael’s statement about how service restart notifications should be explicit, but I don’t think the idea of global handlers should necessarily be dismissed due to a (questionably) poor use case. This is loosely related to my previous request for the “ansible\_user” variable ([https://groups.google.com/d/topic/ansible-project/BHCnJb768e4/discussion](https://groups.google.com/d/topic/ansible-project/BHCnJb768e4/discussion)) Anyone have an idea of how I could implement this? ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [March 1, 2013, 10:31pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441/2 "2013-03-01T22:31:12Z")
I'm confused. Is this about system change logs or handlers or timestamps? I tend to benefit from seeing examples of syntax. What is the ideal syntax of the hypothethical thing you want to see, in terms of a playbook or command line syntax? ---
**Author:** ![Christopher\_Snapp](https://avatars.discourse-cdn.com/v4/letter/c/a8b319/32.png) [@Christopher\_Snapp](https://forum.ansible.com/u/Christopher_Snapp)\ **Post date:** [March 1, 2013, 10:44pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441/3 "2013-03-01T22:44:55Z")
Fair enough, I’m a poor communicator 🙂 Take the following snippet of stdout from a hypothetical ansible run against [example.com](http://example.com) TASK: [logcheck - configure (logfiles)] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* changed: [[example.com](http://example.com)] TASK: [logcheck - configure (violations)] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* changed: [[example.com](http://example.com)] TASK: [logcheck - configure (ignored violations)] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ok: [[example.com](http://example.com)] From this snippet we see that two tasks detected a change made on [example.com](http://example.com). I’d therefore like to see two new lines in [example.com](http://example.com)’s /var/adm/changelog that looks like this: 20130301 snappca logcheck - configure (logfiles) 20130301 snappca logcheck - configure (violations) My opening ramble was based on my original hope that it’d be relatively trivial to implement this feature request using some form of global handler. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [March 1, 2013, 11:07pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441/4 "2013-03-01T23:07:17Z")
It sounds like it's best done via a callback actually. The playbook callback "playbook\_on\_stats" is done at the end of an Ansbile run, and has access to the stats object to return what is changed. Now, that stats object does not keep a list of what changed per host \*presently\* but with some minor modifications it could. Part of our near term work though is to keep more detailed central logging about all of this. Logging on the host is nice, but then a user can change it, and you can't easily compare between hosts, etc. I guess what I'm saying is I'm not going to be working on this specifically, however the enhancements to leverage more of ansible data via callbacks will be directly useful in getting you to where you want to be. ---
**Author:** ![Christopher\_Snapp](https://avatars.discourse-cdn.com/v4/letter/c/a8b319/32.png) [@Christopher\_Snapp](https://forum.ansible.com/u/Christopher_Snapp)\ **Post date:** [March 1, 2013, 11:29pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441/5 "2013-03-01T23:29:48Z")
swell, I’ll certainly keep an eye out for any update to the stats object that might enable me to check this off my todo list. I understand your point about changelogs on the target and see the benefit of the central logging, but I haven’t (yet) bought into the concept of forcing myself (and coworkers) into managing all machines from a central location. I see one of the huge benefits of ansible as being very light-weight enabling me to manage machines from my workstation via my git tracked playbooks utilizing ssh’s jump hosts to get me to any machine I need to manage. So far, it is only when I need high performance (managing 100’s of cluster nodes via fireball) where I choose to manage from a central location. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [March 2, 2013, 12:56am UTC](https://forum.ansible.com/t/target-system-change-logs/12441/6 "2013-03-02T00:56:47Z")
Yeah, sure thing. the tracker bug for this is [https://github.com/ansible/ansible/issues/search?q=context](https://github.com/ansible/ansible/issues/search?q=context) and we probably need to make sure the runner is attached to this context such that you can make execute\_module calls. ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [March 2, 2013, 1:24am UTC](https://forum.ansible.com/t/target-system-change-logs/12441/7 "2013-03-02T01:24:49Z")
You should also be able to update the changelog files per host by adding a preprocessor into your syslog that writes to the file when it sees ansible log. This way you can update the file with root permissions even if your users don't have such, which prevents them from modifying it. ---
**Author:** ![Benjamin\_Ritcey](https://avatars.discourse-cdn.com/v4/letter/b/e495f1/32.png) [@Benjamin\_Ritcey](https://forum.ansible.com/u/Benjamin_Ritcey)\ **Post date:** [March 4, 2013, 3:12pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441/8 "2013-03-04T15:12:28Z")
Can’t this be done via notify? - name: logcheck - configure (logfiles) action: … notify: - logcheck configure changed handlers: - name: logcheck configure changed action: shell … A bit tedious to have a handler for each action, but do-able - or am I missing something? ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [March 13, 2013, 4:56pm UTC](https://forum.ansible.com/t/target-system-change-logs/12441/9 "2013-03-13T16:56:45Z")
I'd be concerned with the amount of information that needs to be tracked until the end of a run. Especially with our large provisioning/retrofitting playbooks and a large set of systems. [Granted, I do not recommend running large playbooks on large sets of systems as I tend to prefer having some control over what is running on which systems. And the blocking nature of Ansible giving you this control tends to work poor with large sets of systems. It's a good thing really 🙂 For the same reason I prefer push over pull. I've seen a few disasters with uncontrolled pulls on large sets of systems. And I was glad I was not involved in those designs ;-)]