New URL conventions

Tue Mar 10 20:35:28 EDT 2009

Hi Carter,

I am not very active on this list, but I do read the exchanges regularly.

I think this is a very good idea, which has a lot of potential, and would standardize output options.

My 0.02 cents.

Brgds.
-Real.

----- Message d'origine -----
De: argus-info-request at lists.andrew.cmu.edu
Date: Lundi, 9 Mars 2009, 12:00
Objet: Argus-info Digest, Vol 43, Issue 8
À: argus-info at lists.andrew.cmu.edu

> Send Argus-info mailing list submissions to
> 	argus-info at lists.andrew.cmu.edu
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
> or, via email, send a message with subject or body 'help' to
> 	argus-info-request at lists.andrew.cmu.edu
> 
> You can reach the person managing the list at
> 	argus-info-owner at lists.andrew.cmu.edu
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Argus-info digest..."
> 
> 
> Today's Topics:
> 
>    1.  New URL conventions (Carter Bullard)
> 
> 
> -----------------------------------------------------------------
> -----
> 
> Message: 1
> Date: Mon, 9 Mar 2009 11:39:26 -0400
> From: Carter Bullard <carter at qosient.com>
> Subject: [ARGUS] New URL conventions
> To: Argus <argus-info at lists.andrew.cmu.edu>
> Message-ID: <469781EA-E640-4876-8D7F-67C2A5E5AD65 at qosient.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
> 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 
> currentstrategy 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
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Argus-info mailing list
> Argus-info at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
> 
> 
> End of Argus-info Digest, Vol 43, Issue 8
> *****************************************

____________________________
Réal Melançon