<div dir="ltr"><div><div>I set heartbeat to 60 on the client and idle to 120 on the server. Reconnects seem fine now, although I never did nail down the exact conditions under which reconnects failed.</div><div><br></div><div>But I still have the problem of weird buffering on the client side. If I run `sudo ls` on the client side, locally I get something like:</div><div><br></div><div> node=<a href="http://grax.sea.marchex.com">grax.sea.marchex.com</a> type=SYSCALL msg=audit(1468448156.161:3288765): arch=c000003e syscall=59 success=yes exit=0 a0=8f81e8 a1=8f7578 a2=8febf0 a3=7ffd3d956370 items=2 ppid=19387 pid=19388 auid=2288 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=399 comm="ls" exe="/bin/ls" key="rootcmd"</div><div> node=<a href="http://grax.sea.marchex.com">grax.sea.marchex.com</a> type=EXECVE msg=audit(1468448156.161:3288765): argc=1 a0="ls"</div><div> node=<a href="http://grax.sea.marchex.com">grax.sea.marchex.com</a> type=CWD msg=audit(1468448156.161:3288765): cwd="/tmp"</div><div> node=<a href="http://grax.sea.marchex.com">grax.sea.marchex.com</a> type=PATH msg=audit(1468448156.161:3288765): item=0 name="/bin/ls" inode=132438 dev=09:01 mode=0100755 ouid=0 ogid=0 rdev=00:00</div><div> node=<a href="http://grax.sea.marchex.com">grax.sea.marchex.com</a> type=PATH msg=audit(1468448156.161:3288765): item=1 name=(null) inode=71179 dev=09:01 mode=0100755 ouid=0 ogid=0 rdev=00:00</div><div><br></div><div>But remotely, I just get:</div><div><br></div><div> node=<a href="http://grax.sea.marchex.com">grax.sea.marchex.com</a> type=SYSCALL msg=audit(1468448156.161:3288765): arch=c000003e syscall=59 success=yes exit=0 a0=8f81e8 a1=8f7578 a2=8febf0 a3=7ffd3d956370 items=2 ppid=19387 pid=19388 auid=2288 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=399 comm="ls" exe="/bin/ls" key="rootcmd"</div><div><br></div><div>Just the first line of the audit record. No matter how long I wait. If I then run `sudo ls` again, *then* the rest of the lines show up in the server's log.</div><div><br></div><div>The buffering appears to be on the client side, because if I restart the server's auditd, those lines are not lost: they still appear in the remote log ... but not until the next time I run `sudo ls` on the client side.<br></div></div><div><br></div><div>This is on 1.7.x. This does not happen on 2.4.x or 2.6.x.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 11:38 AM, Steve Grubb <span dir="ltr"><<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday, July 13, 2016 10:51:07 AM EDT Chris Nandor wrote:<br>
> The only reason I am even upgrading is because of the issues with<br>
> audisp-remote, the not-reconnecting, and the apparent client-side<br>
> buffering, that went away with 2.4.x and 2.6.x. So if we decide to ship<br>
> logs a different way than with audisp-remote, then it might be best to<br>
> stick with 1.7.x.<br>
<br>
</span>This sounds a lot like the idle detection is not set right. In audisp-<br>
remote.conf there is a setting heartbeat_timeout. This should be set to<br>
something like 60 or 120. Then on the server in auditd.conf there is a setting<br>
tcp_client_max_idle which should be over twice as high as heartbeat_timeout.<br>
So, you'd set it to 180 or 300.<br>
<span class=""><br>
> That said, so far I see no issues, so we're going to forge ahead and see<br>
> what happens. I just need to keep in mind what our mitigation plan would<br>
> be if we do run into issues.<br>
<br>
</span>Old utilities won't know what to do with enriched events. AFAICS, that would<br>
be the long term issue. You'll need to do aperl, awk, or cut command to trim<br>
off the unknown part of the event in your logs.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Steve<br>
</font></span></blockquote></div><br></div>