Last Call re: argus-server: argus interface monitoring confusion

[Carter Bullard]

Hey Richard,
   Well I'm all for only one command line
configuration file.  If there is a "-F" option,
we don't read /etc/argus.conf, and anything
on the command line is set last, in left to right
order, after the "-F" option is processed.
Additive command line for -i and -w options,
and they reset any existing interface or output
file specifications.  Right now we only support
one -r source packet file, and I'd like to keep
it that way.

  This seems very simple, and digestible.

Ok group, last call on this.  Is this a reasonable
solution?  I've implemented most of it already,
so if we're close, then I can zip up the patient
and post the code, maybe tomorrow?

Carter



> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu 
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of 
> Richard Gadsden
> Sent: Tuesday, May 20, 2003 5:03 PM
> To: argus-info at lists.andrew.cmu.edu
> Subject: RE: argus-server: argus interface monitoring confusion
> 
> 
> On Tue, 20 May 2003, Carter Bullard wrote:
> 
> > Hey Richard,
> >    Your example is best done with two independent
> > images of argus, especially from an OS perspective.
> 
> Yup, that's how we do it today... as far as I can tell, using multiple
> argus instances isn't just the -best- way, it's the -only- 
> way to get such
> things to work.
> 
> But I'm sure there are others besides myself who, especially 
> in the early
> stages of learning argus, have spent a lot of time trying things with
> command line options and configuration files that looked like 
> they should
> work, but turned out not to. Eliminating some of the 
> ambiguity (not quite
> the right word) in the user interface would be helpful to 
> future users.
>  
> >    I think that the problem is that people are not
> > happy with a lot of flexibility and want the software
> > to keep them from making dumb mistakes.  Since you
> > can specify multiple interfaces in configuration
> > files and the command line, it doesn't seem too
> > long of a stretch to imply the desire of the user.
> > Does he/she really want to open two interfaces?
> > If so they should explicitly declare that in a
> > single place, rather than putting one in one file
> > and having to add the second in another.
> 
> No argument here. The root of most of the dumb mistakes and confusion
> seems to be the (often surprising) way that additive options in config
> files are currently being interpreted. Which strategy would 
> best honor the
> principle of least surprise:
> 
>  1) No more than one configuration file allowed per invocation?
> 
>  2) Multiple config files allowed, but no 'overlapping' 
> additive options
> allowed between them?
> 
>  3) Multiple config files allowed, but options which are 
> additive on the
> command line don't behave additively -within- config files?
> 
>  4) Multiple config files allowed, but options which are 
> additive on the 
> command line don't behave additively -between- config files?
> 
>  5) A simpler and more intuitive strategy which eludes me?
> 
> Personally, I think 2), 3) & 4) are too complicated. So the 
> choices on the
> table are so far rather limited...
> 
> Thanks,
> Richard
> 
> 
>