NAME

sntop —

top-like console network status tool

SYNOPSIS

sntop [options]

DESCRIPTION

sntop (simple network top) is a console utility, in the spirit of top, that polls a list of hosts at a regular interval to determine if they are online, displaying the results in a formatted table. This list is read on load from a config file, sntoprc, located (by default) in ~/ or /etc. The polling is done via ICMP ping (1)

Optionally, the results can be used to generate an html page or ellicit the execution of a file.

Interactive run-time commands exist:

q - quit

r - reload config file

w - toggle html page generation

any other key - force a refresh

COMMAND-LINE PARAMETERS

-d, --daemon - daemon mode: make sntop capable of running in the background. note, it wont automatically fork into the background.

-o, --once - poll and display results once, then exit

-c, --nocolor - toggle the use of ncurses color for pretty formatting

-p, --ping - use 'ping' in lieu of 'fping'. note, ping (in particular on DOWN hosts) is slower than fping -- the performance of sntop will suffer.

-w, --html - generate html output of results

-s, --secure - secure mode. command keys are disabled. SIGINT must be used to terminate the program. this allows sntop to run nicely on spare terminals galore. something like the following in /etc/passwd can facilitate that:

sntop:x:123:123:sntop:/:/usr/local/bin/sntop -s

-e <file>, --wfile=file - output html to <file> instead of sntop.html

-f <file>, --conf=file - read conf data from <file> instead of ~/.sntoprc. note, sntop will still try to read from /etc/sntoprc if <file> fails. if both fail, sntop will exit.

-r <time>, --refresh=time - refresh every <time> seconds instead of 180

-a <file>, --alarm=file - alarm mode: execute <file> when a site first goes DOWN

-l <file>, --log=file - log mode: execute <file> whenever the status of a site changes

-b <bytes>, --byte=bytes - Number of bytes of ping data to send

-v, --version - display version information and exit

-h, --help - display command-syntax help and exit

Command Execution Syntax

In alarm or log mode a file is executed on the occurence of change in status of a given host. sntop will fork and exec the specified file, passing as arguments information about the event. those arguments are:

<display name of host> the 'display' name (first sntop collumn) of the machine, ie "MyBox"

<host name/IP> the explicit hostname or IP address of the machine, ie "snaggle" or "192.168.55.12"

<status> the new status of the machine, "UP" or "DOWN," this would obviously always be DOWN for alarm mode

Note, DOWN hosts will be logged in both modes upon load (ie, if they are down when sntop loads, <file> is executed). No action is taken in any modes for hosts that originate as UP -- thus, the default status is UP. We execute an external file to remain in the UNIX tradition -- small, simple programs that do one thing damn well. Thus, a logging option is not even provided -- a two-line shell script will do fine, there. However, the possibilities are powerful: administrator paging, for instance. See alarm.sh for an example script.

FILES

~/.sntoprc default config file location

/etc/sntoprc if a user's config is not found, this system-wide one is read

/usr/man/man1/sntop.1.gz the man page

alarm.sh sample alarm-execute script

/usr/local/bin/sntop the sntop executable

CONFIG FILE

An example config file, sntoprc.EXAMPLE, is included in the standard distribution. However, the config file syntax is simple. Entries are RETURN terminated. Trailing whitespace is ignored. '#' signifies a comment and can be used inline. By default, upto 32 characters will be read, per line. All entries should be a single word, except comments. The syntax:

Display Name

IP or host

Display Comments

Example:

Jimi

192.168.23.1

linux/sparc; firewall, http, ftp

sntop will first attempt to read the config file from ~/.sntoprc (or another location specified by -f). If that fails, the system config file will be read from /etc/sntoprc. If both fail, sntop will exit.

AUTHORS

sntop was written by Robert M. Love <rml@tech9.net> and Christopher M. Rivera <cmrivera@ufl.edu>. Send us bug reports, suggestions, and hardware.