Last Call re: argus-server: argus interface monitoring confusion
carter at qosient.com
Tue May 20 18:28:57 EDT 2003
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?
> -----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...
More information about the argus