Abstract. This document describes the SNMP daemon programmed in TCL and running under the Scotty environment. Today's business networking environments are very complex and different from another. The SNMP is today's networking standard for monitoring networks. It's simple and that makes it consistent. RFC 1514 on Host Resources MIB explains a lot of portable information for different hosts, and most of the non-commercial SNMP daemons available today do not support this information in the MIB II tree. The SNMP daemon presented in this document, will try to provide the host resources information consistently in a portable way.
Network management systems should also be able to work with a large variety of operating systems and workstation platforms. The SNMP daemon, abbreviated snmpd from now on, is written in the portable script language Tcl. Non-heterogeneous operating systems have totally different ways of providing information to the user. By using the appropriate routines depending on the running OS, the snmpd fills in the appropriate variables in the MIB-2 resources tree.
Snmpd was not designed to be an independent SNMP daemon. Being more of an extension providing the Host Resources MIB (RFC 1514), it is recommended that the system administrator has an additional SNMP daemon running on port 161 (the original SNMP port). See below for ways to multiplex two agents on the snmp port.
Snmpd supports the following platforms: HP-Unix (v10.20), IRIX (v6.2), NetBSD (v1.2), SunOS (v5.5) and Linux (v2.0.30). The numbers in parentheses show under what version the snmpd was tested under. Snmpd is meant to be run as a normal user (i.e. you don't have to run this program with root properties). The port multiplexor does, however, need root privileges to bind to the port 161.
||Supported variables are shown
as a purple book, while the
unsupported are gray.
The MaxProcesses is currently
The hrMemorySize is currently
Device scanning is only
ProcessorLoad is not
The partition table is
2) Run ./configure and let it do everything for you. The output
should be something like this (output is grabbed running the configure
script on HP box):
Checking standard external programs for
Checking who... ok!
Checking lpstat... ok!
Checking uname... ok!
Checking hpux platform dependent external programs...
Checking ioscan... ok!
Checking ioscan for its set-group ID... ok!
Checking vmstat... ok!
Searching for scotty...
Guessed newest scotty at /store/bin/scotty2.1.6
Updating Tcl script 'snmpd' with information... ok!
Building snmpd-sys which is a low-level C program...
gcc -O3 -s -o snmpd-sys snmpd-sys.c -DOS_UNIX -DSPEC_HPUX
Compilation was a success.
cp snmpd-sys ..
rm -f snmpd-sys core *~ *.o
Copying snmpd-sys to snmpd dir...
Building snmpd-mux which is a SNMP port 161 2-multiplexor...
cc -O -s -Ae -o snmpd-mux snmpd-mux.c
Compilation of snmpd-mux was a success.
cp snmpd-mux ../lib/
rm -f snmpd-mux snmpd-sys core *~ *.o
Copying snmpd-mux to snmpd/lib dir...
Setup program finished.
Now, a few words about the configuration file. The UpdateHr*Int settings tell snmpd how often it is supposed to update the variables in the specified class. Formally, it is the number of seconds between each variable update upon user request.
The TotalUpdateInt is the interval between a complete update of all the variables.
To avoid memory leaks or any problems, snmpd has been designed to automatically shutdown and restart itself. The RestartAgentInt setting tells the number of seconds between each agent restarting procedure. After removing a lot of memory leaks from this program, the recommended value should be at least more than a week. This could of course vary under severe system load (a lot of SNMP queries). The whole restarting procedure takes less than 10 seconds. All the set variables are restored on restart.
The RebuildVarsListCount tells snmpd to regenerate the list of set operations after a number of set requests. In true spirit of making the common case fast, the restructuring of the data file is only done after a given number of set requests towards snmpd. Thus, this speeds up the set operation since it only concatenates changes to a file when a set operation comes along. This list is used to make the agent remember and override static variable settings by the user the next time it is fired up.
Next, there are three settings for the logging system of the snmpd. You can specify a valid directory and an arbitrary name where you want the log file of snmpd to be placed. Use the intuitive LogfileLocation for this. The LogEventLevel variable tells snmpd what events you would like to have an entry in the log file. There are four levels here: nothing, min, normal (recommended) and max. "nothing" will not place anything in the log file - no matter what goes wrong, while "max" will place a lot of information (example: snmp get requests, set requests and other various operations performed by the agent). The "normal" setting puts the most common stuff in the log file, while "min" only puts the most crucial information in the log.
The last of the three variables, LogToSyslogLevel, is quite similar to the one just mentioned except that it specifies which of the events should go into the system's log (syslog). The level granularity is the same as with LogEventLevel.
The observant reader then notices that there are two port settings for this agent - logically there should only be one. In reality, that's how it works, too: ThisAgentSnmpdPort specifies the port number snmpd expects requests on. However, the OtherAgentSnmpdPort is used by the port multiplexor. The latter is a program specifically written for this snmpd in order to concatenate the Host Resources snmp tree together with the standard enterprise snmp agent shipped with your machine (normally). In this way, the snmpd becomes more of an snmpd extension in itself rather than a standalone snmp agent. As mentioned earlier, the first port variable, ThisAgentSnmpdPort, tells the port number of this agent. The latter, OtherAgentSnmpdPort, is for the other standard snmpd agent normally running on port 161 on every machine (enterprise version). You need to configure your original snmp agent to run on a different secure port than port 161, if you decide to use the multiplexor (see below how).
Be aware that the static variable settings given in the configuration file are standard default values and can be overridden by the user's SNMP set requests.
# Common settings #
# Intervals #
# Logging #
# Level: nothing min normal max #
# Ports (multiplexor) #
# Static variable settings #
sysContact.0 SysContact "FMS@uit.no, phone: +47 776 45999"
sysName.0 sysName "slibo.cc.uit.no"
sysLocation.0 SysLocation "EDB-Sentret, University of Tromso, Breivika,N-9037 Tromso"
sysServices.0 sysServices "2"
4) Run snmpd. Voila!
5) Run snmpd-mux port multiplexor to make the commercial standard agent work together with this agent. You need to stop any agents occupying port 161, configure your newly stopped agent to run on a different secure port (e.g. port 1702), restart the original agent with the new settings and lastly, run lib/snmpd-mux :)
Hot tip: You are advised to set the snmp time-out in your snmp browser to 10 seconds if you're running an old out-ranged HP Unix 700 series machine with approximately 30 percent load. This way, you will never get annoying time-outs.
|snmpd-sys||used for a lot of internal stuff. See 2)||All|
|who||used to figure out number of users logged on||All|
|ps||used to find number of procs and names of procs||All except HPUX|
|ioscan||used to scan devices for HPUX||HPUX|
|hinv||used to scan devices and memSize for IRIX||IRIX|
|vmstat||used to get CPU load for unix's (except IRIX)||All except IRIX|
|lpstat||used to check printer jobs||All|
|uname||used to determine operating system name||All|
|systune||used to get MaxProcesses on IRIX||IRIX|
|snmpd||the main program.|
|configure|| the setup program which is completely platform
|doc/||the HTML documentation is found here.|
|etc/snmpd.conf||the snmpd configuration file|
|etc/snmpd.log||the default snmpd log file (optional).|
|etc/snmpd.vars|| the set variables file (optional). When a variable
is set by the user, the change is saved here. This
way, the setting is permanent when agent restarts.
|lib/snmpd-sys|| the low-level C program needed to get certain
system specific information.
|lib/snmpd-mux|| the C program that does the port multiplexing of
standard snmp port 161 (optional).
|src/Makefile||the Makefile for the low-level C program.|
|src/snmpd-sys.c||the C source for the low-level program.|
|src/snmpd-mux.c||the C source for the port multiplexor program.|
I will now discuss some of the Tcl implementation. The parseCfgVar is a useful procedure simplifying process of reading variable settings stored in the snmpd configuration file. It has two arguments: the name of the variable to retrieve and its default value if it isn't present in the configuration file. The return value is either the value found in the configuration file or the default value.
updateVars is a procedure to run a complete update of all the variables in the snmpd engine on regular occasions (very seldom). This is to avoid having the users wait for a while when requesting variables about e.g. installed software - if the snmpd has to parse through store to figure this out (because of old variables), it could become quite time consuming :)
As part of the assurance of having a stable agent, I have written the restartAgent procedure. To avoid using the execl extended Tcl command in order to maintain a strict Tcl requirement only, this procedure creates a Bourne Shell script to launch itself by.
The CreateSafe doesn't create a safe Tcl agent at all. Recommendations from Scotty developers: "Tcl8.0 will be quite different anyway and hence the time to make the old Scotty code to work, is not very well spent." Conclusion: Wait till next Scotty version and the Tcl 8.0 release to fix this.
Note that all the global variables binded to a snmp instance are stored in an array called mibVals. This two-dimentional array has indices on snmp variable name and level indexes.
The current operating system is also listed as a running process in the process table. Since process IDs are usually in the range of 0 to 65535, the ID of the OS is hardwired at PID 9999999.
File used to get information about store is /store/store/Adm/reports/report.out. Edit the Tcl script to change this.
Add a line to run the new procedure handling the actual update of the new variables. This is done by adding the procedure call in updateVars. This way, your new variables are updated as the system decides to do a full value update.
Implement the procedure for the new branch of the MIB tree to be supported. The procedure retrieves the values from the system and these are reflected to the snmp engine.
Add an update interval for that particular new set of variables. This step includes adding a variable setting in the configuration file and a new global variable UpdateHr[proc name]Int.
Add a line in Main in order get a variable update upon agent startup.
The last step is to bind the new procedure to the appropriate MIB OID. That is done in the if regexp structure found at the of the Main procedure. Hot tip: You can figure out the OID of the new variable tree by inserting puts "Request received: OID = [lindex [lindex %V 0] 0]" in the bind code block.
In order to add a new low-level functionality, you firstly have to define a new opcode for new function intended in the #define section at the beginning of the C source.
Add the new opcode to the dispatch routine (switch-case statement) in main.
Write the C function doing all the actual work printing out the information to standard output.
Extending the multiplexor to handle more than two agents, you should at first get the OID for the new branch of the MIB to be supported (see last bullet on notes for snmpd). Add this OID to the if structure in main. The variable client controls the destination agent after receiving a user request.
In the beginning of main: add a client entry using setclientsock. If the second parameter is NULL, then you indicate the default agent running on the current machine. On the other hand, if the second parameter is an IP address, you are setting the socket for the extra client. The third argument of this procedure is the port number in ASCII to the agent specified. Note: you can actually place the extra agent on a different machine than the localhost (127.0.0.1) - just write the correct internet address in the second argument. The first agent points to the client structure. You have to adjust the array allocations to compensate for your agent addings.
Adding another agent implies another port number. Adjust the configuration file to include this new port number and update this C code to read the new configuration variable, as well.
A product like this makes it possible for e.g. Snmp Monitor Ex to monitor resources on remote machines handling disk space, cpu utilization, device list, memory, file system and process information across the net. Most importantly, this program uses the SNMP to communicate - SNMP is today's networking standard for monitoring networks.
This package is also shipped with a port multiplexor for port 161, the standard SNMP port. Such a tool makes it possible to simply add the MIB Host Resources tree into your favorite snmp daemon program (commercial or non-commercial) already running on your machine. Very few of these standard snmp daemons support this host resources branch of variables. With this program, you can have the best of both worlds - the resources tree and the enterprise specific ones.
Although the development of this product has only been less than a month, I believe that the software has great potential. I have made new friends in the SNMP / Scotty community - a pity this software can't be released as freeware (property of University of Tromsoe).
So, what we have here is an agent. Being an agent, it's very dumb by
definition. It only answers questions raised. Listening to the thirty-nineth
IETF meeting held in Munich, Germany, 11-15 August 1997 (MBone broadcast),
they briefly discuss the SNMP v3 - they are talking about restructuring
the communication architecture in SNMP.
When the v3 goes into general use in network monitoring programs, putting more "smarts" into the agent remains to be seen. Also, moving this snmp from being just an extension to a full-blown snmp agent could be one interesting thing to do in the future.
Finally, as a last minute note, please read the ChangeLog below. It contains a lot of information about Snmpd.
Bugfix: no variables could be accessed while the system was updating.
To ensure reliability of the program, a restart option timer has been added. This way, all forthcoming memory leaks etc. are flushed e.g. every 5 days. The agent kills itself and restarts after 5 seconds.
Bugfix: Process memory shown was only physical memory usage. Fixed now under IRIX and HPUX.
It is no longer necessary to use the external program ps under HP-UX. I wrote my own little ps program :)
version 1.0.1 PR2:
version 1.0.1 Release:
version 1.0.2 Release:
version 1.0.3/1.0.4 Release:
Include support for more variables. Especially the partition tables, hard drives etc.
Processors load support is not implemented for IRIX. Unfortunately, it would appear to me that SGI hasn't made this information accessible using pfStats ("The PFSTATSHW_CPU pfStats statistics class for accumulation of statistics on CPU usage are not yet implemented for IRIX6.x operation (64bit or 32bit)." as it says in one of their release notes.)
MaxProcesses, MemorySize and device scanning hasn't been implemented for SunOS or NetBSD.
Incorporate safe Tcl interpreter with Tcl v8.0 when released.
Add traps to the agent.
Go to the download section to start downloading.