argus-server: argus interface monitoring confusion

[Carter Bullard]

Hey Yotam,
   Having a definitive statement on this will
make it much better, so I'm glad that we've got 
critical mass to make a decision on this.
So let me describe the current state of things
and we can get to where we want to go.

   The notion of hierarchical configuration files
happens all the time, as argus always opens /etc/argus.conf
and then processes any other configuration files and
command line options.  Argus does this to support the
concept of system wide defaults/policies, such as what
interface to use and the level of security for the
SASL configuration.

   User supplied configuration files, that are in
the $ARGUSPATH are then opened, and used to override
the system wide values, a kind of personal customization.
This was added so that you just needed to type "argus"
and can get a rather complex runtime environment.

   Argus then processes command line arguments, in
left to right order, using standard getopt() processing.
So, if you put a "-F file" in the middle of a list of
arguments, it will be processed in the middle.  As a
result we have order sensitive configuration.  I personally
think that is ok, but I may be in the minority here.

   The "-i", "-r" and "-w" options are all additive at
the moment, in that any number of these are simply
added to a list.  All of them have the problem of
supporting duplicate entries.

   There is a command line option 'X' to revert all
configuration options to default, so if you don't
like the current values, you can use '-X' to blow them
all away and start again.  It is position sensitive.

   Now we evolved to this state, because we went from
a small number of command line options, to where we
had more options than letters, and we moved the values
to a configuration file, leaving some of the options for
command line specification.  We do have options that
have no command line equivalent.

   Ok, so, that is a fair presentation of the existing
situation.  I'm for having simple rules, to minimize
confusion.  So this would be my suggestions for how
to change what we have.

   1. Continue to use /etc/argus.conf as a base default
      configuration file.

   2. Eliminate the automatic searching for argus.conf
      files through the $ARGUSPATH variables and the
      current directory,  as that is where some unexpected
      behavior comes from.

   3. Keep the -X option to eliminate any effects of
      the /etc/argus.conf file.

   4. Fix all the options that are additive in order to
      ignore duplicates.

   That seems like a good start.  The final issue, if
I'm reading the situation correctly, is to process
all -F options on the command line first, in left to
right order, and then process the other options, in
left to right order.  

   That will tackle much of the problems, but there is
still one difficult situation, what to do with the
additive options "-i", "-r", "-w".  If you have them
on the command line, do we blow away the existing
lists?  What to do if I have this situation:

   argus -i eth0 -i eth1

do you only get /dev/eth1?

One solution is to have [-|+] before these additive
options:

   argus -i +eth0 -i +eth1

and then finally, should we support this type of
directive?

   argus -i eth0 eth1


Opinions?



Carter





> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu 
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of 
> Yotam Rubin
> Sent: Friday, May 16, 2003 3:05 AM
> To: argus-info at lists.andrew.cmu.edu
> Subject: Re: argus-server: argus interface monitoring confusion
> 
> 
> On Thu, May 15, 2003 at 11:42:26PM -0400, Carter Bullard wrote:
> 
> Initially, I did not intend for the patch to included only in 
> the Debian
> version of argus, that's why I CC'd the list.
> 
> > Hey Andrew,
> >    I'm going to be fixing one aspect of this problem
> > this weekend, where we should only open an interface
> > once, but Yotam is raising another issue which is
> > not necessarily correct.  Do command line specifications
> > have precedence over configuration file specs?
> > 
> >    One of the biggest issues with command line switches
> > that can also be specified in configuration files, is
> > the order of the specification.  How should argus
> > deal with this scenario, for example:
> > 
> >    argus -i eth0 -F argus.conf
> > 
> > where the argus.conf file specifies interface eth1?
> > 
> > Compare this to this next call:
> > 
> >    argus -F argus.conf -i eth0
> 
> In all cases, command line arguments should have precedence over the 
> configuration file. Command line arguments are more explicit 
> than configuration
> file directives, in the sense that the user must specifically 
> request them
> upon invocation, as opposed to configuration file directives 
> which have 
> probably been present prior to the invocation.
> 
> > should argus behave the same in both situations?  It
> > is not clear that they should be the same.
> > And with calls such as:
> > 
> >    argus -F arg1.conf -F arg2.conf -F arg3.conf
> 
> Is the feature of stacking configuration files being used by 
> many users?
> It is a bit problematic, since it's not obvious what sort of 
> implications it
> has:
>  * Are stackable options being stacked across configuration files?
>  * What about boolean directives?
> 
> If this feature isn't being used extensively already, I think 
> it should be
> removed altogether, as to avoid common confusions. A less preferable 
> alternative would be to document the behavior of this feature 
> extensively.
> 
> 	Regards, Yotam Rubin
> 
> 
>