
          --------------------------------------------------------------
          |  Welcome to the Internet Rover Network Monitor Release 2.0 |
          --------------------------------------------------------------

    Since we have moved to a RS6000 AIX platform, all the rover code has 
by default been made for this platform.  ( It also works well on the
PS/2 AIX and should work on the 3090 AIX, but I degress... )

    At Tom Easterday's urging, I have also ported it to the Sun Sparcstation.
make -f Makefile.sparc should get you guys going.

    Before making, do a:

	setenv PINGKYVERSION v2.0

    This way the make will tag each piece of code with a version number. I do
the setenv in my .cshrc during development cycles.

    There is, as usual, a curses-based text display that shows the current
network problems, and allows operators to update the status of problems.

    I have built a Motif-based display program that has similiar functions
as the text-based version, but using a motif widgets.  Hence you gets a 
scrolled list of network problems, status updates occur by clicking on the
problem, etc...

    Both display programs have a feature called "Filtering".  This allows one
to use regular expressions to associate nodes to networks, and then filter out
alerts associated with that network.  So, for example, if your local gateway to
a network is dead, and you know about it, and don't want the screen filled with
"side-effect" problem reports, you can filter out all alerts associated with
the network.

    There is a *VERY* low volume mailing list: rover-list@merit.edu.

    As always, please note, I have included the source to ping-this MUST be made
before running this package.  Follow the instructions described in this
distribution, then cd into the rover/InetRoverd directory and make ping as root.

PLEASE...........
   Send me a email message to let me know that you have gotten this
distribution!!!  This way I can send email messages out regarding updates, 
peoples donated extensions to test neat things, etc.  Thank you, Bill.

If you find it useful, we'd encourage you to let us know.  If you have ideas
to make it easier to install, make better makefiles, do different things, etc
please let me know.  We have found it to be very useful, and expect other
NOCs in the future could add more network monitoring protocol modules and 
use this as a cheap (free) network monitoring system.... 


                            Thank you,

                         Bill Norton
                         Merit Computer Network
                         wbn@merit.edu or wbn@home.merit.edu
                         (313) 936-2656

PS - unfortuneately, this time I won't be able to make many changes, especially
for commercial companies, on other than a consulting basis.

File Structure of Distribution:
---------------------------------------------------------------------------
Data Collector Directories:
            InetRover -  Makes InetRoverd, all network query code
Common Problem Manager Code:
	    ProblemManager - Read/Write to the PROBLEM.FILE
Display the PROBLEM.FILE:
            Displays  -  Source code for the Display Programs
Miscellaneous:
	    Ctools    -  Miscellaneous "C" code

Expanded Functionality:
--------------------------------------------------------------------------
  Pingky started out being a simple stupid background ping task for a NOC
with need of a problem manager - something that simply maintains a screen
of current problems and allow people to update the status field of a 
problem locally or remotely as things get looked int.  As time went on
other services needed to be tested.  " Bill we need to know that this box
is up and allowing people to TELNET, FTP, and assure that SMTP and NAMED
services work! "  So we made pingky extensions so that if a node requried
special attention, one could easily add a few lines of "C" code to do
just about anything and add or delete a problem based on the return code.
That is precisely what we have here with pingky.  We have and continue to
come up with simple UNIX commands  that check alert files, mail files, etc.
If you can write a script or program that returns a 0 or 1 return code, 
you can add extensions!

Current Extensions:
-------------------------------------------------------------------------
  If your configuration file is set up so that certain hosts (nodes) get
special attention (i.e. after seeing that the box is up, test FTP, TELNET,
SMTP, and/or NAMED services) you will need to put the services test programs
into your path.  So far we have 2 programs to test these services called
ns and connect.  ns is a program Paul Killey(UM) wrote to test a name server
at the address specified by the 1st parameter, and it returns a 0 or 1 based on
success or failure.  connect is a program written to test port a port
on a node by opening a socket to the box.  This script was also written by
Paul Killey(UM) and as always returns a 0 or 1 based on success or failure.

   In fact, all services including our invocation of ping must indicate succes
and failure via a 0 or 1 return code.  The netquery.c module contains all of
the protocol testing routines which at this time include PING(),TELNET(),
FTP(),SMTP() and NAMED().  This is where you can add your favorite SNMP
and SGMP, CMOT etc. implementations.  By the way, this turns out to be a
good platform upon which you can add commands to use SGMP/SNMP etc. by
using the fact that session and community names for each host are in the
hostfile.  We are hoping to come up with extensions that invoke the MIT
or preferably the (Steve Waldbusser)CMU SNMP distribution for public release.

Notes:
	--------------------------------------------------------------

        Overview:
        
             Pingky has grown out of the need for Merit to monitor a 
        heterogeneous group of network, and the need to use multiple
        protocols to achieve that goal.  For example, not only does
        pingky detect if a node is up or down, but it also tests various
        services that that node provides (i.e. tests the SMTP, FTP, NAMED,
        TELNET, SGMP, SNMP, etc.).  
 
             Configuration is easy.  All you need to do is untar the
        distribution, and build the code on the target machine if you
        are not using a Sun.  There is one configuration file that you need
        to create or modify: hostfile.  This is the file with the list of
        hosts that you wish to monitor and the list of services to test/use.
        For Example:
        UM-Annex         35.1.1.44      ANNEX.HELP  PING() TELNET() SNMP(common)

        This is one entry in the hostfile that tells pingky to monitor the 
        box at 35.1.1.44, and if the PING() module returns a 0 return code,
        add a problem to the PROBLEM.FILE which the Display program will 
        present. If the PING() module DOES respond, it is up and therefore
        also call the following modules and add or delete a problem entry
        based on whether the module returns a ITWORKS or ITBROKE return code. 
  
            This archetecture is simple and very extensible.  All of the 
        network query modules are in netquery.c, and everything is in the
        "C" programming language.  If you can write a routine to test
        something, and it can return a 0 or 1, to indicate success or failure
        of something, you can add Network Tests.  I ended up using the 
        unix system command to simple invoke a shell which does several pings
        for the PING() protocol.  In the Unix tradition, I have tried to 
        simply supply the building blocks upon which everyone may build a 
        neat portable Network Monitoring Tools.
 
            The SNMP(common) entry in the above example, is given to present
        a point.  We need a place to store node-specific values so we can
        use a protocol to monitor a device (SGMP: session name, SNMP community)
        So, we can write pieces that work off of this file/data structure.
        For example, we may want to query a node for the number of interfaces
        that it has, and determine the status of each one.  Let's provide a
        a mechanism so that the protocols supported by the node are listed in
        the file/data structures used, and the program (transparently) will
        call each of the listed modules to ask if that module can get that 
        variable from the gateway.  Maybe SMTP can't get the status, but SNMP
        can and it will return the value.   This is something to work towards.
 

            Have fun with the code.

        I would encourage you to use the code, send any comments you have,
        and more importantly, I would encourage you to send protocol modules
        to plug in (i.e. better PING(), SNMP(), etc routines) for inclusion
        in the next release. 
 
                              Bill Norton
                              Merit Computer Network

