Audit data going to syslog

I have three machines that I upgraded to Leap 15 and on one of them audit records are going to /var/log/messages but on the other two this is not happening. All three machines have virtually identical configurations and run syslog-ng.

Can anyone give me a clue as to why one is doing this and not the others. I would like to stop it on the one that is doing it as there is no point in having the audit records in syslog as well.

Looking at a Red Hat question on this theme, the following questions have to be asked:

  1. Is the boot parameter ‘audit=1’ present in the Grub configuration?
  2. Within ‘/etc/audisp/plugins.d/syslog.conf’ on the ‘args’ line, is LOG_LOCAL0 present?
  3. Within ‘/etc/syslog.conf’ on the line for “/var/log/messages” is ‘;local0.none’ present among the selectors?

The Red Hat discussion <https://access.redhat.com/discussions/650853> indicates that:

  • ‘audit=1’ should not be present in the Grub configuration;
  • ‘/etc/audisp/plugins.d/syslog.conf’ should have the line “args = LOG_LOCAL0”;
  • ‘/etc/syslog.conf’ should have ‘;local0.none’ included among the selectors for “/var/log/messages”.

I’ve seen these threads. audit=1 is not set in grub and the other lines are not present. But then none of those lines are present on the two machines which are not exhibiting this problem.

A possible try is to force re-install syslog-ng.

zypper in -f syslog-ng

If that doesn’t work, then fully uninstall, then re-install syslog-ng.

TSU

I would still like to know why this is different on one machine but in the end I decided that I don’t really need auditing anyway so I’ve turned it off.

Possibly due to the default behaviour of syslog-ng on that machine – you mentioned that, on the other machines you didn’t need to explicitly setup the audit behaviour with respect to /var/log/messages – possibly due to a setup somewhere in /usr/lib/ rather than in /etc/ …

Computing is still extremely complex under the hood no matter how simplified it might appear to humans.
My suggestions are based on the idea that re-installation and re-setting what causes the re-direction of syslog data would fix your problem.

TSU