Rasplit compression support

Matt Sheridan mattmail5050 at gmail.com
Mon Nov 16 14:48:34 EST 2009


Hi Carter -



Running with -D1 ran without error, however nothing was written to .debug. I
created .debug in /usr/local/bin (as root) where rastream is located.



[root at xxxxxxxx ~]# rastream -S localhost:561 -M time 10m -B 10s -f
/opt/IDS/argus/etc/rastream.sh -w
/opt/IDS/argus/log/\$srcid/argus.%Y_%m_%d_%H%M.out -D1

Deleting



[root at xxxxxxxx bin]# ls -lh .debug

-rw------- 1 root root 0 Nov 16 14:20 .debug



[root at xxxxxxxx ~]# ps -eaf |grep rastream

root      1253 28839  0 14:40 pts/0    00:00:00 [rastream.sh] <defunct>

root      1390 29044  0 14:42 pts/3    00:00:00 grep rastream

root     28839 25835  9 14:21 pts/0    00:02:03 rastream -S localhost:561 -M
time 10m -B 10s -f /opt/IDS/argus/etc/rastream.sh -w
/opt/IDS/argus/log/$srcid/argus.%Y_%m_%d_%H%M.out -D1

root     31337 28839  0 14:30 pts/0    00:00:00 [rastream.sh] <defunct>



I have noticed other things not working as expected - is it possible that my
64bit RHEL5 is at odds with this build? I have noticed two things so far:



1) ra does not parse any filtering logic when reading files using the "-r"
[file] option. If I use filters such as "host 10.10.10.10", it does not
implement the filter, and simply returns all results. Using the same filter
against the argus server - it DOES work (using -S localhost:561)



2) ratop does not work. It simply hangs on carriage return. This is over an
SSH session using SecureCRT, so originally ignored it as a possible terminal
issue.





On Tue, Nov 10, 2009 at 10:45 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Matt,
> So what does your rastream.sh do? Just compression?
>
> Run rastream() in the foreground (without the -d option), with the -D1
> option.
> (be sure and create a .debug file in the clients root directory and rerun
> ./configure;make clean;make to enable the -D option if it doesn't work).
>
> rastream() will printout what it thinks is going on with regard to the
> scripts and
> the processes forked to run them.  The short time ranges shouldn't matter.
> We're doing the right thing with waidpid() for these processes, so there
> shouldn't be zombies, but shouldn't and is are not always in agreement.
>
> Can we keep this on the list?  Best to capture these threads.
>
> Carter
>
> On Nov 6, 2009, at 3:35 PM, Matt Sheridan wrote:
>
> > Hi Carter-
> >
> > Actualy, I did the 30 seconds to quickly reproduce/cut and paste results.
> I am typically running in 10 minute slices - which produces the same
> results. I am running 10 minute slices right now and see
> >
> > uname -a
> > Linux XXXXXXXXXX 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009
> x86_64 x86_64 x86_64 GNU/Linux
> >
> > root     10132     1  9 14:10 ?        00:08:26 rastream -S localhost:561
> -M time 10m -B 10s -f /opt/IDS/argus/etc/rastream.sh -w
> /opt/IDS/argus/log/$srcid/argus.%Y_%m_%d_%H%M.out -d
> > root     10430 10132  0 14:10 ?        00:00:00 [rastream.sh] <defunct>
> > root     11556 10132  0 14:20 ?        00:00:00 [rastream.sh] <defunct>
> > root     12415 10132  0 14:30 ?        00:00:00 [rastream.sh] <defunct>
> > root     13346 10132  0 14:40 ?        00:00:00 [rastream.sh] <defunct>
> > root     14162 10132  0 14:50 ?        00:00:00 [rastream.sh] <defunct>
> > root     15386 10132  0 15:00 ?        00:00:00 [rastream.sh] <defunct>
> > root     16345 10132  0 15:10 ?        00:00:00 [rastream.sh] <defunct>
> > root     17262 10132  0 15:20 ?        00:00:00 [rastream.sh] <defunct>
> > root     18105 10132  0 15:30 ?        00:00:00 [rastream.sh] <defunct>
> > root     18372 16010  0 15:34 pts/0    00:00:00 grep rastream
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20091116/55d1d750/attachment.html>


More information about the argus mailing list