no node= in ausearch
Just as an aside, I was sending in the auditctl event because I do not see the "node=" information in the ausearch results on my collector. So I wasn't certain which machine might be initiating the event.
Thx,
LCB.
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 4 lines
Just as an aside, I was sending in the auditctl event because I do not see the "node=" information in the ausearch results on my collector. So I wasn't certain which machine might be initiating the event.
Locally generated events won't have the node= (at least, on my machine they don't). Remotely generated events should have the node= on them.
Quoted 6 lines · DJ Delorie
Quoted 3 lines
Just as an aside, I was sending in the auditctl event because I do not see the "node=" information in the ausearch results on my collector. So I wasn't certain which machine might be initiating the event.
Locally generated events won't have the node= (at least, on my machine they don't). Remotely generated events should have the node= on them.
I thought there was a distinction as to where it was assigned, as in auditd.conf vice audispd.conf. The raw data (in the log) does have it locally.
So anyway, if I see no node= events in the collector I know that it isn't getting any events.
Also the sender's audispd sends log messages saying the queue is full and it must drop the events.
LCB.
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 5 lines · On Friday 12 September 2008 21:40:23 LC Bruzenak wrote:
Quoted 2 lines
Locally generated events won't have the node= (at least, on my machine they don't). Remotely generated events should have the node= on them.
I thought there was a distinction as to where it was assigned, as in auditd.conf vice audispd.conf.
Yes. For remote logging the one in audispd.conf is used. I'll be unifying things sometime in the next few months.
-Steve
audit collection
In reply to DJ DelorieOn my F9 machines I still get no events (that I can tell) across.
I have changed to sending from / receiving on 64-bit machines only, since that's what I have for now.
I have made the "name_format = user", "name = hugo" on the sender in audispd.conf just to be certain it is unique.
===================
On the sender I see:
messages log (hundreds of these):
Sep 15 11:48:14 comms audispd: queue is full - dropping event
I assume this indicates the problem - sending isn't happening so the audispd queue fills. I'd have expected an audisp syslog error though.
lsof:
[root@hugo audit]# lsof | grep sdos
audisp-re 5082 root 3u IPv4 92619
TCP comms:41065->dell1:tsdos390 (ESTABLISHED)
===================
On the collector I see:
[root@dell1 audit]# lsof | grep sdos
auditd 5790 root 9u IPv4 34892
TCP *:tsdos390 (LISTEN)
auditd 5790 root 10u IPv4 35068
TCP comms:tsdos390->hugo:41065 (ESTABLISHED)
and nothing in the messages log.
I'm not seeing any of the events in the collector log from the sender (reading the audit.log file directly until Steve's ausearch node= patch is applied).
I'm also sending between machines with the same MLS policy in permissive mode.
Any ideas? I guess I can go check the code where the send happens to see if there is any debug I can add.
Thx,
LCB.
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Re: audit collection
Quoted 5 lines
Sep 15 11:48:14 comms audispd: queue is full - dropping eventI assume this indicates the problem - sending isn't happening so the audispd queue fills.
Yes, this means nothing is getting across the network. Have you tried running tcpdump on the client side? Or running gdb on the running audisp-remote to see where it's stuck.
Quoted 1 line
I'd have expected an audisp syslog error though.
I do log all the errors I could detect, so I don't know what's happening here. Those syslog errors are likely from audisp itself, not the remote plugin.
It would help if you could try it between two 32 bit hosts. At least that would remove the "int size bug" possibility.
Re: audit collection
Quoted 8 lines · DJ Delorie
Quoted 4 lines
Sep 15 11:48:14 comms audispd: queue is full - dropping eventI assume this indicates the problem - sending isn't happening so the audispd queue fills.
Yes, this means nothing is getting across the network. Have you tried running tcpdump on the client side? Or running gdb on the running audisp-remote to see where it's stuck.
(gdb) where
#0 0x0000000000892590 in __read_nocancel () from /lib64/libc.so.6 #1 0x00007f25874db914 in main (argc=<value optimized out>, argv=<value optimized out>)
at /usr/include/bits/unistd.h:45
I suppose I'd need to run the debug code to get a better analysis.
LCB.
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Re: audit collection
Quoted 8 lines
(gdb) where
#00x0000000000892590in__read_nocancel() from/lib64/libc.so.6#10x00007f25874db914in main (argc=<value optimized out>, argv=<value optimized out>)
at/usr/include/bits/unistd.h:45I suppose I'd need to run the debug code to get a better analysis.
Or build your audisp-remote with -g -O0.
Quoted 3 lines · On Friday 12 September 2008 19:56:08 LC Bruzenak wrote:
Just as an aside, I was sending in the auditctl event because I do not see the "node=" information in the ausearch results on my collector. So I wasn't certain which machine might be initiating the event.
That was fixed yesterday afternoon in:
https://fedorahosted.org/audit/changeset/98
-Steve