This manual describes the installation, configuration, and operation of WATCHER, an idle terminal monitor for VMS systems.
Revision/Update Information: This is a revised manual.
Operating System and Version: VAX/VMS V5.4 or later
OpenVMS Alpha V6.1 or later
OpenVMS Industry Standard 64 V8.2 or later
Software Version: V4.2
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTI
This manual describes the installation, configuration, and operation of WATCHER, an idle terminal monitor for VMS systems.
Revision/Update Information: This is a revised manual.
Operating System and Version: VAX/VMS V5.4 or later
OpenVMS Alpha V6.1 or later
OpenVMS Industry Standard 64 V8.2 or later
Software Version: V4.2
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Portions of the software were adapted from other open source projects. Refer to the Release Notes for copyright and license information.
The following are trademarks of Hewlett-Packard Development Company, LP:
| AXP | DEC | OpenVMS |
| VAX | VMS |
UNIX is a registered trademark of USL, Inc.
| Contents | Index |
One of the first programs a new VMS system manager usually needs is an "idle terminal monitor" (ITM). That is, a program to monitor terminal activity and logout those users whose terminals remain inactive for an extended period of time. An ITM helps ensure that system resources are not wasted and helps reduce the possibility of intruders using unattended terminals as a means of entry into the system.
Unfortunately, an ITM can also be an annoyance to system users. A simple ITM can victimize legitimate users who may need to remain logged in but idle while they are at work. This can lead to clever users devising "hacks" to evade the ITM, defeating the purpose of using the ITM in the first place.
WATCHER has a high degree of flexibility, allowing system managers to decide how to accommodate users' needs while still addressing operational and security issues. WATCHER is fully configurable, providing the following features:
Through the use of these features, the system manager should be able to configure WATCHER to handle most types of terminals and accommodate most users.
This manual is intended for the system manager or other person responsible for installing and configuring WATCHER.
This document consists of two parts. The first describes the installation and use of WATCHER. The second describes all of the WATCHER Control Program (WCP) commands in detail.
There is no formal support for WATCHER.
To use WATCHER, you need the following files:
| WATCHER.COM | Command procedure that executes WATCHER |
| WATCHER.EXE | The main WATCHER image |
| WCP.EXE | The WATCHER Control Program |
| FORCE_EXIT.EXE | $FORCEX program for use in custom logout procedures |
| WCP_HELPLIB.HLB | Help library for WCP |
| DECW_STARTLOGIN.COM | Part of DECwindows support |
| WATCHER_CONFIG.WCFG | You create this file with WCP |
| WATCHER_STARTUP.COM | Sample startup command procedure |
| WATCHER_SHUTDOWN.COM | Sample shutdown command procedure |
| SAMPLE_CONFIG.WCP | Sample configuration commands |
| WATCHER_LOGOUT.TEMPLATE | Template for custom logout procedures |
The package comes with the object code files and libraries and a command procedure called LINK.COM, for creating the two images.
It is easiest to simply place all of the files in the distribution in
one directory, run LINK.COM to create the images, then edit
WATCHER_STARTUP.COM and the sample configuration commands in
SAMPLE_CONFIG.WCP as needed for your system. Then all you need to do is
to run WCP, execute the WCP command file you created from the sample,
which in turn creates a WATCHER_CONFIG.WCFG file, then execute
WATCHER_STARTUP.COM to start the Watcher process.
1.1 Required Logical Names
The three system-wide logical names WATCHER requires are:
| WATCHER_DIR | Should point to location of images and command procedures |
| WATCHER_CONFIG | Configuration file to be used |
| WATCHER_TRACE | Trace file; use NL: if debug disabled |
They should all be defined in executive mode.
1.1.1 Logical Name for Help Library
The help library for WCP may be placed in SYS$HELP, or, if you define
the logical name WCP_HELPLIB to be the full path name of the file,
anywhere else on the system. The sample WATCHER_STARTUP.COM includes
the necessary DEFINE command to do this for you.
1.2 Privileges Required
The account that is used for the WATCHER process requires the following privileges:
| CMKRNL | Required for DECwindows support and disconnects |
| PRMMBX | For defining the command mailbox |
| PSWAPM | Required for disconnects |
| SHARE | For sending warning messages to other users' terminals |
| SYSNAM | For defining the command mailbox |
| SYSPRV | (optional) to ensure access to appropriate files |
| WORLD | For getting information about and killing processes |
SYSPRV is not needed if you make sure that WATCHER has enough access to
read its configuration files and write its log and trace files (if
used). Both CMKRNL and SYSPRV are required for DECwindows support.
CMKRNL and PSWAPM are required to perform virtual terminal
disconnections.
1.3 Other Requirements
The RUN command in WATCHER_STARTUP.COM should provide the WATCHER process with sufficient quotas to operate on most systems. CPU and memory requirements will vary depending on the number of rules in the WATCHER configuration, peak number of interactive users, and peak number of watched users. You may wish to refer to the following table in computing expected memory resources needed by the WATCHER process:
| Memory required per WATCH rule | 206 bytes |
| Memory required per EXCLUDE or OVERRIDE rule | 507 bytes |
| Memory required per interactive process | 465 bytes |
| Memory required per watched process | 531 bytes |
| Size of WATCHER code (approximate) | 18K bytes |
DECwindows support also requires additional overhead for access to the job logical name tables of all interactive and detached processes on the system.
The WATCHER Control Program (WCP) is used to create WATCHER configurations. WCP is designed to be executed as a VMS foreign command. To set up the foreign command, define the symbol
$ WCP :== $WATCHER_DIR:WCP |
Once the symbol is set up, you can invoke WCP with the command:
$ WCP |
WCP will automatically load the contents of your defined WATCHER_CONFIG
file, if it exists.
2.1 Setting up WATCH Rules
The WATCH command sets up rules that determine which terminals get watched, how to determine whether the terminals are active, and how long terminals must be inactive before a user can be forced off. For example:
WCP> WATCH *$RT*/MEASURE=PROCESS_IO/LOGOUT=00:15:00 |
This command sets up a rule for watching all DECnet remote logins, using changes in total process I/O (buffered plus direct) to determine process activity, and causing logouts to occur after 15 minutes of inactivity.
You must have at least one WATCH command in your configuration. |
WATCH commands take any wildcard pattern. All terminal device names that match the specified pattern are watched. The device names used by WATCHER are the physical device names of terminals; if the system is part of a VMScluster, SCS node name is prefixed to the device name, as is normally done by VMS with cluster-accessible devices.
If the terminal device driver supports remote port identification, as does the LTDRIVER for LAT terminals, the remote port information can also be used as a match criterion by using the /ACCPORNAM qualifier. The port name can be specified as a wildcard pattern. For example:
WCP> WATCH *$LT*/ACCPORNAM="TRMSRV/*" |
This command would cause the terminals attached to terminal server
TRMSRV to be watched.
2.1.2 WATCH Criteria
WATCHER gives you the choice of using one or more of the following measurements as criteria for judging whether a terminal or user is active:
| TERMINAL_IO |
the I/on workstation terminal devices.
For any of these measurements you can specify a minimum threshold value. When WATCHER performs a comparison, the difference between the current measured value and the last measured value sses, in centiseconds |
| PROCESS_IO | the sum of the buffered and direct I/O counts of the process owning the terminal plus all of its subprocesses |
If WATCHER is currently running, you can have the new configuration
take effect immediately with the RESET command, which will cause the
óS ê @ng aê @e of them is active, they will all remain logged in.
2.2 Exclusions and Overrides
WATCHER's behaviour towards a terminal or user can be modified through the definition of exclusion and override rules. Exclusions and overrides can be based on any combination of username, terminal/port name, UIC, image being run, privileges, a held identifier, and time of day. Exclusion rules prevent WATCHER from taking any action towards a user, while override rules merely modify how the terminal is watched (i.e., the activity criteria and inactivity periods). For example (taken from a VMScluster system):
WCP> EXCLUDE SYSTEM/TERMINAL=*$OPA0: WCP> OVERRIDE JONES/TERMINAL=NODE1$TXA3:/DURING=(PRIMARY:8-16)- _WCP> /LOGOUT=02:00:00 |
The first command prevents WATCHER from taking any action against the
SYSTEM account while it is logged into the system console. The second
command extends the logout inactivity period to two hours for user
JONES weekdays from 8 am to 4:59 pm, while JONES is logged into the
terminal in her office, which is on port TXA3 on system NODE1.
2.3 Saving Configurations
Once you have established the rules you need for your configuration,
you should create the configuration file with tng as one of them is active, they will all remain logged in.
2.2 Exclusions and Overrides
WATCHER's behaviour towards a terminal or user can be modified through the definition of exclusion and override rules. Exclusions and overrides can be based on any combination of username, terminal/port name, UIC, image being run, privileges, a held identifier, and time of day. Exclusion rules prevent WATCHER from taking any action towards a user, while override rules merely modify how the terminal is watched (i.e., the activity criteria and inactivity periods). For example (taken from a VMScluster system):
WCP> EXCLUDE SYSTEM/TERMINAL=*$OPA0: WCP> OVERRIDE JONES/TERMINAL=NODE1$TXA3:/DURING=(PRIMARY:8-16)- _WCP> /LOGOUT=02:00:00 |
The first command prevents WATCHER from taking any action against the
SYSTEM account while it is logged into the system console. The second
command extends the logout inactivity period to two hours for user
JONES weekdays from 8 am to 4:59 pm, while JONES is logged into the
terminal in her office, which is on port TXA3 on system NODE1.
2.3 Saving Configurations
Once you have established the rules you need for your configuration, you should create the configuration file with the SAVE command:
WCP> SAVE WATCHER_CONFIG |
If WATCHER is currently running, you can have the new configuration
take effect immediately with the RESET command, which will cause the
WATCHER process to reload its configuration information from the file.
2.3.1 VMScluster Environments
For mainly homogeneous VMScluster environments, you should be able to
use one configuration file for all nodes in the cluster. If you have a
mix of nodes, however, it may be easier to create multiple
configuration files and define the WATCHER_CONFIG logical name
differently depending on the system.
2.3.2 Editing Configurations
The WATCH, EXCLUDE, and OVERRIDE commands all have a /DELETE to allow you to remove rules from the database, and you can add rules as well. However, you cannot control the order of the new rules (order is important because WATCHER searches the rule lists in the order you enter them until one matches). To assist in making complex changes to the configuration, the SHOW command has a /COMMAND qualifier that causes the configuration information to be displayed as commands you would enter to build the configuration:
WCP> SHOW/COMMAND/OUTPUT=CONFIG.WCP ALL |
Once you dump the commands to the command file, you can edit the command file as needed and create a new configuration with the commands:
$ WCP/NOFILE WCP> @CONFIG WCP> SAVE WATCHER_CONFIG |
Instead of editing the configuration, it may be easier just to maintain a WCP command file with the necessary commands in it and build a new configuration each time you need to make a change.
| Next | Contents | Index |