The latest version of this document is always accessible from the scotty World Wide Web (WWW) page. The URL for the WWW page is:
http://wwwsnmp.cs.utwente.nl/~schoenw/scotty
A mirror of this Web page as well as a Japanese translation is at:
http://scotty.saino.ne.jp/
This document sometimes refers to parameters such as pathes that might
differ from one installation another. This document therefore does not
explicitely refer to these parameters. Instead, this document frequently
uses Tcl variables that contain the installation dependent parameters.
For example, instead of using the path to the Tnm library directory
(e.g. /usr/local/lib/tnm2.1.11), this document refers to
$tnm(library), which is a global variable provided by the Tnm
extension and which contains the path applicable on your system.
Scotty is the name for a software package which allows to implement site specific network management software using high-level, string-based APIs. The software is based on the Tool Command Language (Tcl) which simplifies the development of portable network management applications. The scotty source distribution includes two components:
Some people say it has something to do with the startrek series. Scotty was the character who had to make the impossible possible in order to keep the starship flying and the scotty package may do the same for your network. Others say that this name happened by accident because the author of the Scotty package was just too lazy to come up with a better name...
The Tnm extension for the Tool Command Language (Tcl) provides access to various TCP/IP network protocols. The protocol interfaces allow to retrieve a buch of information needed to write simple but powerful network management scripts in Tcl. Scotty includes its own SNMP protocol stack, a SNMP MIB parser as well as a GDMO MIB parser and an interface to the CMIP protocol implementation called OSIMIS. You can also query the domain name system (DNS), send ICMP requests, use generic TCP/UDP services, invoke selected SUN RPCs, send and serve HTTP requests, and more.
The Tkined network editor is a graphical user interface for a network management system. Applications are running as independent processes that can manipulate the network map maintained by the Tkined using a RPC style protocol between Tkined and the application. The distributions contains some sample applications written in Tcl by using the Tnm extension.
The current scotty version is 2.1.11 (which includes tkined). It is based on Tcl/Tk 8.3. Older versions that are compatible with earlier Tcl versions are still available from the FTP side but they are no longer supported.
The sources are available via FTP from ftp.ibr.cs.tu-bs.de [134.169.34.135] in the directory /pub/local/tkined. Retrieve the file scotty.tar.gz which is a symbolic link to the current official version.
The following sites have a copy of the Scotty sources:
Please drop us a note if something is incorrect here or if there are additional mirror sites that are not listed here.
Making binary distributions takes time and our experience is that binary distribution do not reduce the number of questions per week (because most systems simply look too different). Therefore, we do not provide binary distributions.
There is a mailing list which serves as a forum for announcements, discussions, bug reports etc. related to Tkined and Scotty. Messages that should appear on the list should be send to <tkined@ibr.cs.tu-bs.de>. All routine administrative requests (including subscriptions and unsubscriptions) concerning this mailing list are handled by an automated server called majordomo, a list processing software written by D. Brent Chapman.
To subscribe to the list, send the following in the body (not the subject line) of an email message to <majordomo@ibr.cs.tu-bs.de:
subscribe tkined
This will subscribe the account from which you send the message to the tkined list. If you wish to subscribe another address instead (such as a local redistribution list), you can use a command of the form:
subscribe tkined other-address@your_site.your_net
To unsubscribe from the tkined list, send the following in the body (not the subject line) of an email message to <majordomo@ibr.cs.tu-bs.de>:
unsubscribe tkined
This will unsubscribe the account from which you send the message. If you are subscribed with some other address, you'll have to send a command of the following form instead:
unsubscribe tkined other-address@your_site.your_net
To find out more about the automated server and the commands it understands, send the following command to <majordomo@ibr.cs.tu-bs.de>:
help
If you feel you need to reach a human, send email to <tkined-approval@ibr.cs.tu-bs.de>.
The mailing list is archived. The archive can accessed by sending the following in the body (not the subject line) of an email message to <majordomo@ibr.cs.tu-bs.de>:
index tkined help
The index command returns the list of files and the help command returns instructions on how to download the files. The archive is also accessible via the world wide web. The archive is split into several pieces, each one covering one year:
First, make sure that you have read all the related documentation to make sure you really found a bug. Once you are sure you have a bug you have two options. The first one is to explore the myths of Tcl and the Scotty package, track down the bug and send us a patch which fixes the problem together with a test for the test-suite so that we can be sure that this problem will not show up again.
Not everybody has the time to do this. We are also happy to get bug reports without a patch. However, you should help us to find the problem by providing as much information as possible. This includes at the Tcl/Tk/Scotty version you are using and a description of your runtime environment. Describe what you were trying to do, what you expected to happen and what actually happened. Include the Tcl traceback if you experience a Tcl error or the C stack traceback if you get a core dump. (You can get this traceback by running a debugger on the core file and typing the appropriate command, e.g. "gdb scotty core" and the command "bt" or "dbx scotty core" and the command "where".) The fastest way to get a bug fixed is to work out a small (portable) example that triggers the problem so that we can play with it and add a test for the testsuite.
Send the bug report via email to either the tkined mailing list or directly to <schoenw@ibr.cs.tu-bs.de>. Do not send core files since they are useless without the corresponding binary and take up far too much space in our mail system. Finally, make sure that your mail contains a valid return address. (It is really annoying if mail bounces after you have spend some time to track down a problem.)
The Tcl extensions provided by the Scotty package run on most UNIX systems that support Tcl7.6 and Tk4.2 or Tcl8.0 and Tk8.0. The default Makefiles are written in a way to make use of dynamic loading and the Tcl package system. Scotty is regularily tested on SunOS 5.5, SunOS 4.1.X, IRIX 6.4 and Linux 2.0.X systems. Note, some UNIX versions (e.g. SunOS 4.1.X) require systems specific changes when compiling the sources. Please read the porting.notes file which is contained in the unix directory of the source tree for details.
The scotty sources are organized in a way that allows to port them to different platforms supported by Tcl. The current version includes makefiles for Borland C++ and Microsoft VC++ to compile the scotty package on Windows NT. The Tnm extension supports all command except the icmp command on Windows NT. The Tkined editor compiles but it needs more work since fileevents are not supported in the current version of Tcl on Windows NT. Note, this is work in progress and there might be all kinds of bugs. Be prepared to see unexpected behaviour on the NT platform. Please contact us if you want to contribute to the Windows NT port of scotty.
An up-to-date version of the porting.notes file is available on the Web at http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/porting.notes .
The best solution is to find out how to implement dynamic loading on your OS and to forward the required changes to the Tcl group at Sun. The second option is to write a new Makefile which allows a static version of the extensions and to create another wish and tclsh binary which includes the static version of the extension. You have to adapt the tclAppInit.c and tkAppInit.c files from the Tcl and Tk distribution to initialize the extension. This requires some basic knowledge about the Tcl internals. Finally, the third option is to change the operating system.
The scotty package usually compiles with a couple of warnings about incompatible pointer types. This usually happens in the Sun RPC modules (*_clnt.c and *_xdr.c). These modules are created by rpcgen(1) which is usually not able to create correct prototypes. These warnings do not cause any problems at runtime.
There might be additional warnings in other modules depending on your OS and your compiler. It is usually safe to ignore them. It is sometimes difficult to get rid of these warnings without adding complex configure code. The best example is the warning issued by gcc about the usage of uninitialized variables. This warning is sometimes raised even though the variable is initialized before its use. It is simple to avoid this warning by adding an initialization. However, other compilers recognize that this initialization is not needed and hence they issue a warning about a value assignement that is never used.
Lets assume you compiled Tcl/Tk and the Scotty distribution into a the following directory tree. (You can do this easily by using the --prefix=/tmp/scotty option for all relevant configure scripts.) The resulting file system layout will look like this (assuming you are using Tcl7.6 and Tk4.2):
/tmp/scotty/bin/tclsh7.6 (PATH) /wish4.2 (PATH) /scotty2.1.11 (PATH) /tkined1.4.11 (PATH) /straps (TNM_STRAPS) /ntping (TNM_NTPING) /lib/tcl7.6/ (TCL_LIBRARY) /tk4.2/ (TK_LIBRARY) /tnm2.1.11/ (TNM_LIBRARY) /tkined1.4.11/ (TKINED_LIBRARY) /libtcl7.6.so (LD_LIBRARY_PATH) /libtk4.2.so (LD_LIBRARY_PATH) /tnm2.1.11.so (LD_LIBRARY_PATH) /tkined1.4.11.so (LD_LIBRARY_PATH) /man/ (MANPATH)
The right column above indicates the environment variable that is responsible to control the location of the file or directory given at the left side.
You can move this setup to a different place (e.g. /opt/scotty) by makeing a tar archive of /tmp/scotty and unpacking the archive again in /opt/scotty without recompiling it. However, you have to set several environment variables. The relevant variables are:
PATH # Should include the path /opt/scotty/bin MANPATH # Should include the path /opt/scotty/man LD_LIBRARY_PATH # Should include the path /opt/scotty/lib TCL_LIBRARY # Should point to /opt/scotty/lib/tcl7.6 TK_LIBRARY # Should point to /opt/scotty/lib/tk4.2 TNM_LIBRARY # Should point to /opt/scotty/lib/tnm2.1.11 TNM_STRAPS # Should point to /opt/scotty/bin/straps TNM_NTPING # Should point to /opt/scotty/bin/ntping TKINED_LIBRARY # Should point to /opt/scotty/lib/tkined1.4.11
Under Windows NT, the registry will be used to obtain the installation pathes at runtime. It is the job of the install wrapper to setup the correct entries in the Windows registry. I have been told that under Windows you never move things around. Instead, you de-install and afterwards you install again.
SNMP aliases are used to maintain a database of SNMP session options for all the SNMP agents. An SNMP alias is a definition of a string which contains one or more SNMP session configuration options.
snmp alias toaster { -address 1.2.3.4 -community "white bread" }
This example defines an alias toaster which refers to the SNMP
agent at IP address 1.2.3.4 and with community white bread. Note,
it is possible to reference alias definitions within an alias. This
allows to share the definition of a community name between a large set
of agents while making updates very simple.
snmp alias com { -community foo -writecommunity bar }
snmp alias toaster { -address 1.2.3.4 -alias com }
snmp alias fridge { -address 5.6.7.8 -alias com }
See the snmp(n) man page of the Tnm package for a complete description of legal SNMP session options.
There are two places where you can put SNMP alias definitions. The first
one is the site specific initialization file
$tnm(library)/site/init.tcl. Definitions in this file are shared
between all users on a single system. If you do not want to share a
definition, just out it in your personal ~/.scottyrc.
Lets assume that you want to add a MIB definition for your toaster that
is stored in the file toaster.mib. The first step is to feed the
MIB definition into the MIB parser to check whether the Tnm extension is
happy with the MIB. You can do this by typing
mib load toaster.mib
into a Tcl interpreter which has the Tnm extension loaded. Everything is
fine if you do not see any warning or error messages. If you get errors,
please check if the MIB is broken or if you need to load additional MIB
definitions before you can load the toaster.mib.
The best way to install the MIB file is to create a directory
$tnm(library)/site which is used to hold site specific files.
Copy the toaster.mib file into this directory and create a site
specific initialization file $tnm(library)/site/init.tcl. This
line should contain a command like
lappend tnm(mibs) toaster.mib
which adds the new MIB to the set of MIBs that are loaded automatically.
You can do the same by changing your personal ~/.scottyrc if you
do not want to make this MIB available to everyone.
Here are some rules of thumb that might help you if you are faced lots of proprietary MIBs:
An OCTET STRING value like 73:63:6f:74:74:79 can be converted into a readable string (DisplayString) by formatting it according to the DisplayString textual convention. The mib format command can be used for this purpose:
mib format SNMPv2-MIB!sysDescr 73:63:6f:74:74:79
The reverse conversion can be implemented by using the mib scan command:
mib scan SNMPv2-MIB!sysDescr scotty
These explicit conversion are more or less like casts in the C language
and can be avoided if the MIB definition uses an appropriate textual
convention. Some old SNMPv1 MIBs do not provide these textual
conventions. In some cases, it can be useful to provide them in the
$tnm(library)/mibs/compat.tc file.
There are actually two solutions for this problem. The first solution is
to define an attribute called SNMP:Config which contains SNMP
session configuration options as defined in the Tnm snmp(n) man page.
The second solution is to define an attribute called SNMP:Alias
which contains the name of a Tnm SNMP alias. For example, you might want
to set the attribute SNMP:Alias to the value toaster. Every SNMP
session created by one of the SNMP scripts will now use the
configuration for the Tnm SNMP alias toaster. (See above for hints on
how and where to set Tnm SNMP aliases.)
The second solution has the advantage that you can use the same alias definition everywhere while the first one only works with scripts that interact with the Tkined editor.
The solution is the same as described for the community strings. You can
either define a Tnm SNMP alias and set the SNMP:Alias attribute
of the node, or you define the SNMP:Config attribute. For
example, you can define the value "-port 8042 -address
feist.ibr.cs.tu-bs.de" to make sure the SNMP tools talk to the SNMP
agent on feist.ibr.cs.tu-bs.de which is listening on port number 8042.
Several attributes can be assigned to Tkined objects to control the behavior of Tkined applications. There is a simple naming convention for these attributes that control the behavior of Tkined applications. An attribute name consists of a sequence of names separated by colons. The first part of the sequence is usually an identification who will make use of the attribute. Each name should start with a capitalized letter. This allows to distinguish between control attributes and temporary attributes used to display results. The following attributes are currently used by the scripts contained in the source distribution:
This document was generated on 26 June 2002 using the texi2html translator version 1.51a.