New URL conventions

Carter Bullard carter at qosient.com
Mon Mar 9 11:39:26 EDT 2009


Gentle people,
In the new clients distribution, there is support for accessing data  
from
databases, and in the next wave, we will have additional transport
strategies for Argus, to support not only multiple unicast strategies  
(tcp and udp),
but also  multicasting of argus records to a group of collectors.

The idea is to modify the "-S" option to handle new transport  
strategies, and
then to shift this strategy so that it is handled by the "-r" option,  
so that we
don't have to continue to make a distinction between files or sockets.

Currently we support the '-S' option to read from remote servers.  The  
format
for this option is being extended to support additional transport  
mechanisms,
and so the suggestion is to adopt a URI scheme that allows us to do  
that.  The
default should still be the same that we've been using.

The proposal is for the new format is:

    -S  [argus[-tcp | -udp]://]host[:port]

with these as examples:
    -S localhost
    -S argusServer:12345

    -S argus://10.0.1.14
    -S argus-tcp://10.1.1.4

(its amazing to realize that the IETF doesn't provide a means to
  specify the transport strategy for protocols in a standard way using  
URLs.  I am
  suggesting that we adopt a newest proposal from an internet-draft,  
but its
  not the best solution.  that suggestion is to append the transport  
as a "-proto"
  after the service name).

The examples above specify the existing, TCP based transport strategy.
The examples below specify the UDP transport strategy.  Our current
strategy for reading Cisco Netflow records can also be handled by this
scheme, and so I'll try to retire the "-C" option that we use for  
cisco records.

    -S argus-udp://10.3.5.46
    -S argus-udp://any:561
    -S argus-udp://224.1.34.4:23456
    -S netflow://any:1669

The keyword 'any', allows us to receive multiple streams at the same  
time,
or allow us to receive data for hosts that we are not configured for.

For argus and radium, to use these additional transport schemes, they  
will
support 'writing' to remote sites using the '-w URI' option.  The '-w'  
option will
work the same as it does now, to write to files, but this will also  
work:

    -w argus-udp://224.1.34.4:23456
    -w argus-udp://localhost

This is an extension of the new strategy to "write" and "read" to and  
from
databases that use a mysql URI,  "mysql://[user:pass@]host/db/table".

New options will be available to specify these target destinations in  
the
/etc/argus.conf file.

# Argus can write its output to one or a number of remote hosts.
# The default limit is 5 concurrent output streams, each with their
# own independant filters.
#
# The format is:
#      ARGUS_OUTPUT_STREAM="URI [filter]"
#      ARGUS_OUTPUT_STREAN="argus-udp://host:port 'tcp and not udp'"
#
# Most sites will have argus listen() for remote sites to request
# argus data, but for some sites and applications sending records  
without
# registration is desired.  This option will cause argus to transmit  
records
# that match the optional filter, to the configured targets using UDP  
as the
# transport mechanism.
#
# Commandline equivalent   -w argus-udp://host:port
#

#ARGUS_OUTPUT_STREAM=argus-udp://10.4.5.16:561


This is a suggestion, proposal, based on our prior work.
Of course, if you have any opinions, I'd love to hear them,
and nothing in this is final, so ....

What do you think?

Carter




More information about the argus mailing list