Argus 2.0 wishes

[Carter Bullard]

Hey Neil,
  Yes this is quite possible, we just need to define
what we want.  I'm all for a configuration file, and
using signals to reinitialize a running Argus.

  This topic gets us into the general discussion of
signal processing for Argus.  We are already processing
USR1 and USR2 signals now, in order to "turn on"
and "off" different levels of debug information
reporting for a running Argus.  The best signal for
your condition may be a SIGINT, at least from an
historical Unix perspective.  If I remember, sendmail()
rereads its configuration file when it receives a SIGINT,
and init() reinitializes if you send a SIGINT to it
(PID 0) (at least my memory sez that this is true ;o)

   Argus does not process all the signals that it should,
as an example, we don't deal with SIGPWR, the powerfail
signal, gracefully.  So we should try to define what
signals we want to catch and what we should do with them.
Most are straight forward.  In the SIGPWR, we definately
want to shut things down by turning off the packet
source, flushing out all the cached Argus records, and
then sending a Closed Argus management record with the
signal status somewhere in the man record.

   If we do extend the signal processing, we will want
to report signal reception and processing in Argus
management records, so we can detect that something
is happening.

Carter

> -----Original Message-----
> From: Neil Long [mailto:neil.long at computing-services.oxford.ac.uk]
> Sent: Thursday, March 16, 2000 9:39 AM
> To: Bullard, Carter [NYPAR:DS33:EXCH]; 'Russell Fulton';
> argus at lists.andrew.cmu.edu
> Subject: Re: Argus 2.0 wishes
> 
> 
> Either a filter file or perhaps have the clients use an ENV pointing
> at a file for such options - the command lines can get awfully 
> long otherwise.
> 
> I like the filter file option for argus itself - I can modify it and
> see the effect the next time that cron scripts re-start it.
> 
> For argus wouldn't (or is) support for a -HUP signal (or USR1, etc)
> to re-read the filter file be useful? 
> There are often times when I would like the running process to 
> temporarily ignore (or not) a host or port but at present I have to 
> stop and start it.
> 
> On a busy network monitoring point I have been pondering on ways to 
> reduce the cpu load - adding long or complex filter expressions
> seems to have an impact on cpu utilisation. Has anyone tried using 
> something along the lines of ipfilter to drop IPs or ports before they
> get passed up the stack (or does the BPF filter defeat this line of
> reasoning on Solaris?) on the Argus host? Otherwise I might 
> try a simple bridge
> firewall like Drawbridge to reduce the traffic. I can see 
> there will be
> trade-offs.
> 
> Neil
> 
> 
> 
> On Mar 16,  6:13am, Carter Bullard wrote:
> > Subject: RE: Argus 2.0 wishes
> > 
> > Hey Russell,
> >    For Argus clients, we already have a configuration
> > file, of sorts, to support long filter defintions.
> > Do we want to just extend that with additional
> > configuration data?
> > 
> >    I really like the idea.  I'll try to come up with
> > the set of data primitives that we can generate, and
> > lets see what we have after that.  I'll try to have
> > it by next week.
> > 
> > Carter
> > 
> > > -----Original Message-----
> > > From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> > > Sent: Tuesday, March 14, 2000 6:49 PM
> > > To: argus at lists.andrew.cmu.edu
> > > Subject: Re: Argus 2.0 wishes
> > > 
> > > 
> > > More wishes ;-)
> > > 
> > > I would like to see a argus confirguration file in which on 
> > > can specify 
> > > things like timestamp formats (I have patched ra to print 
> dates in a 
> > > non ambiguous format).  It would also be useful to allow 
> one to set 
> > > default flags for clients and even, possibly, default 
> output (in a 
> > > string like strftime). This would be really useful where one 
> > > is feeding 
> > > ra output to a perl script e.g. you specify just the data you 
> > > want and 
> > > have the fields separated by tabs -- "%T\t%F\t%P\t%S\%s\..."
> > > 
> > > %T -- timestamp 
> > > %F -- flags
> > > %P -- Protocol
> > > %S -- source IP
> > > %s -- source port
> > > 
> > > etc.
> > > 
> > > in perl:
> > > 
> > > while (<RA>) {
> > >    my ($time, $f, $p, $src, $srcp ... ) = split("\t", $_);
> > > 
> > > }
> > > 
> > > At the moment I use unpack to split up the record but 
> occasionally 
> > > fields overflow and then unpack returns garbage for some 
> > > fields. split 
> > > should be faster than unpack too.
> > > 
> > > I'd be happy to contribute code to parse the config file -- I 
> > > have done 
> > > something similar for the netramet project.  (No it isn't in the 
> > > current release).
> > > 
> > > Cheers, Russell.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Dr Neil J Long, Computing Services, University of Oxford
>  13 Banbury Road, Oxford, OX2 6NN, UK Tel:+44 1865 273232 
> Fax:+44 1865 273275
>  EMail:       Neil.Long at computing-services.oxford.ac.uk  
>  PGP:    ID 0xE88EF71F    OxCERT: oxcert at ox.ac.uk PGP: ID 0x4B11561D
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20000316/a88943c1/attachment.html>