On Fri, 2008-09-12 at 16:33 -0400, DJ Delorie wrote:
> So any clue as to why I get a "bad magic number" on
this version?
Nope. It means the server sent back a header that was corrupt, or
sent back something other than a header.
The header is defined in lib/private.h
After looking at this I had a hunch - the collector machine is 32-bit,
the sender 64-bit.
I reverse the sender/collector and I don't get this error anymore.
The machine architecture is not representative of the intended final
deployment, just the available machines I was using to test.
So now the bad news is that I still do not see events passing from
sender to collector. This may be to an incorrect assumption on my part.
I assume that all events on the sender make it to the collector. Is this
true always? I send in a forced event (on the sender):
[root@fryspc audisp]# auditctl -m TEST
[root@fryspc audisp]# ausearch -ts recent -i | grep TEST
type=USER msg=audit(09/12/2008 18:34:34.930:126) : user pid=4866 uid=root auid=root ses=11
subj=unconfined_u:unconfined_r:auditctl_t:s0-s0:c0.c1023 msg='TEST: exe=/sbin/auditctl
(hostname=?, addr=?, terminal=pts/2 res=success)'
But I cannot see this event on the collector.
The good news is that I see the connection on both ends (using port 1237=tsdos, lsof
results):
collector:
auditd 9422 root 11u IPv4 55889 TCP
comms:tsdos390->fryspc:55303 (ESTABLISHED)
collector:
sender:
audisp-re 4846 root 3u IPv4 26741 TCP
fryspc:55303->192.168.31.142:tsdos390 (ESTABLISHED)
Should I see this event, and if so, do you have any idea as to why I do
not? I also have the same thing from another 64-bit sender.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com