On Tuesday, May 10, 2016 03:25:36 PM Warron S French wrote:
> The lab works as expected, but my production environment does
not. %-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do the
same on the server to see if events are getting there. Then look in syslog
for anything that might give a clue. And then you can also tail -f
/var/log/audit/audit.log to see if things are getting written to disk.
\\ Steve, I know that I am receiving inputs to the server; because I can see
events that I am purposely triggering based on 2 rules that I added and
know how to cause an event; it is just that the node=client1 (for example)
aren't being sent along with the line being recorded. Does this
troubleshooting step still make sense anyway?
No. If you are getting events at the server and audispd.conf has name_format=
hostname, it should be working.
If this was set after the audit daemon on the clients started, then you need
to restart the audit daemon for the name to take effect. As written, it
collects the name one time at start up and uses it in all future events. This
could be changed but that is how its doing today.
If you restart auditd on a non-systemd OS, this will cause the admin's auid to
get stuck into the audit daemon's task structure and will cause problems. So,
the cleanest thing to do is reboot the work station so that audispd has the
hostname and your auid is not in daemons.
-Steve