In the last part of this post we discussed the methods of extracting logs from OpenVMS systems for processing by ArcSight SmartConnectors.

This installment will focus on transferring these logs to a machine (in our example a Unix-type system like Linux or Solaris) that runs the SmartConnector and processes the delivered log files.

OpenVMS and IP Connectivity

Most seasoned OpenVMS admins know that TCP/IP is not an integral part of OpenVMS, but is a layered product that is an optional extra.

There are in fact three choices when it comes to TCP/IP stacks, namely:

From a user's point of view they all operate more or less the same way, offer much of the same functionality but there are slight differences. (The admin interface to the three varies considerably however).

Our example script will use the simplest method: FTP process to a system running HP TCP/IP services. SFTP / SSH services would be more secure, of course, but the performance impact can be a bit heavy for some of the older systems out there, especially VAXes. This is exacerbated by the fact that HP only began supporting SSH in the TCP stack from OpenVMS 8 upwards, whereas the latest version available for VAXes is 7.3.

The Script

Before you run the script, create a directory with empty files for each machine's output you are about to download. These will be uploaded to the server at the end of the fetch process, as the extraction script uses the date of the last log file to figure out when to start extracting logs.

Sound confusing? In my setup, I have three machines that create files called:

CHIMPY-LOGS-OUT.LOG
RHESUS-LOGS-OUT.LOG
GORVAX-LOGS-OUT.LOG

You can create these files on a Unix-style system by simply issuing the command:

touch [log file name]

The rest of the script is quite simple.  It creates a temporary file into which it insert a number of FTP commands, namely:

  1. Log into the server
  2. Change the remote directory to the log file one
  3. Change the local directory to the one where the SmartConnector expects log files
  4. Retrieve the logs
  5. Turn of "globbing" (VMS FTP servers may do strange things with special characters, we don't want this)
  6. Delete all log files on the server
  7. Upload the 0 byte files for each logged machine (remember that the log extraction script looks at the last log output file to figure out when to start extracting logs)

And here is the script itself:

#!/bin/bash
TEMPFILE=/tmp/getvmslogs         # Where to put the temporary FTP script
SERVER=rhesus.inside.sampsa.com  # Server which stores the log extacts, and credentials
USERNAME=foo
PASSWORD=bar                     
SRVLOGDIR=/dka0/arcsight         # Directory where the server stores the log file extracts
LOCALDIR=/vmslogs                # Where the SmartConnector expects to see the log files
FAKELOGDIR=/root/tools           # This is where the 0 byte logs to be uploaded are stored

## Create temp file, make sure it's only readable by us (as credentials will go into it)
touch $TEMPFILE
chmod og-rxw $TEMPFILE
echo user $USERNAME $PASSWORD > $TEMPFILE

## Go to the relevant locations to pull the files
echo cd $SRVLOGDIR >> $TEMPFILE
echo lcd $LOCALDIR >> $TEMPFILE

## Pull the files
echo 'mget *.log;*' >> $TEMPFILE

## Turn globbing off
echo glob off >> $TEMPFILE

## Delete the old log files on the server
echo 'del *.*.*' >> $TEMPFILE			
# The '*.*.*' really isn't a typo - it's a way 
# to refer to the version number of the file

## Go to the dir with the 0 byte log files and upload them
echo lcd $FAKELOGDIR >> $TEMPFILE
echo 'mput *.log' >> $TEMPFILE

echo quit >> $TEMPFILE

ftp -i -v -n $SERVER  < $TEMPFILE
rm $TEMPFILE

Security Implications

The aim of this post is to present a 'shortest path' approach for accessing the VMS log files.  Needless to say, this script file should be strongly protected as it contains unencrypted credentials.  There are better ways of pulling files off VMS devices, such as with SFTP using public key authentication, but these may not always available.  Network access controls should also be considered to reduce exposure risk associated with using insecure protocols like FTP.