color support, pcre and pf_ring issues

Carter Bullard carter at qosient.com
Fri Oct 19 12:50:15 EDT 2012


Gentle people,
Very happy to see action on the list, thanks for all the bug reports and dialog !!!!!

Old business first:
  I'm going to do the PCRE and PF_RING configure.ac support in the next coming
  week.  I've gotten great help on the PCRE effort, and I should have a configure.ac
  and new Makefile.in(s) soon.  For those that are using PF_RING, if you have time
  to send comments on how you're getting the compiles done, that would be great
  help in getting a good mature solution for automatically doing the right thing to
  get pf_ring support into argus.

OK, I mentioned that I'll be releasing a new ratop(), completely rewritten to provide
support for color.  The problem of course is that once you color something, you need
to color everything, so its time to talk about what we want in a color ratop() tool.

To turn color on, there is a new .rarc variable, and it takes yes and no for an answer.
   RA_COLOR_SUPPORT="yes"

ratop() currently is working off of a 16 color palatte, with 8 monotone colors and
8 accent colors.  I've also got 16 colors of grey to use, assuming that our target
terminal type supports up to a 256 color wheel.   We'll need to provide some form
of semantic color mapping, if you want to have alarms / alerts / conditional indicators.
That turns into a configuration problem to me, but I'm hoping that the list will have
some ideas on what to do.

One thing that has been added is color support for LOCAL_ADDRS.  We paint 
   1) the current host IPv4 addr BLUE, (which we can derive from the interfaces on the host that is running ratop())
   2) the local IPv4 CIDR network addresses AQUA
   3) multicast/broadcast addresses dark grey
   4) foreign (other) addresses white.

whether its against a dark or light background.  Column headers and status on top and bottom
are bright whte.

You configure addresses using ralabel()s method for specifying addresses, so
there is really good support for you to specify complex groups/enterprises and
have ratop() realize what is local and what is remote. 

The .rarc variables for this support is currently:

   RA_LOCAL=/usr/local/argus/local.addrs       //  ralabel()s IANA address config format
   RA_LOCAL_DIRECTION="local:left"

This is the contents of QoSient's local address configuration at /usr/local/argus/local.addrs.

#   
#  Local Address Classifications
#   

192.168.0.0/16                  QoSient
192.168.0.0/24                  Wired
192.168.0.67                    SMTP
192.168.1.0/24                  Switzerland
192.168.2.0/24                  Wireless
207.237.36.98                   Public QoSient.com

Now I haven't thought this completely through, so if we can have some dialog on
this, that would be most excellent.

Some sites, based on observation domain, would probably want to use L2 ethernet addresses,
or source MPLS or VLAN tags to say what is local.  And I suspect some would like to have
an extensive list of CIDR addresses, and want to put a " color to use " in the configuration.
I suspect that coloring the network part, and the host part of an address different colors would
be interesting… but not sure if that is useful.

I would also like to have additional coloring on things like VLANs, Country Codes
etc… but I need to get an idea of how to do that.  It will cause us to have to define
styles, or color maps, which I don't have yet.

So, if there are opinions on color, and how to use it, I'd love to hear about it before
I release the color version of ratop().


OK, time to get back to it being a rainy Friday afternoon in NYC.

Hope all is most excellent,

Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121019/d17a82bf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121019/d17a82bf/attachment.bin>


More information about the argus mailing list