$ Set Device /Reset=Error_Count  

I use Kronos to run this program every 15 minutes:

$       Set NoOn
$       show intrusion/type=intruder
$       if $status .eq. 1
$        then
$         if .not. f$trnlnm("Intruder$Alert") then pipe show intrusion/type=intrder | -
           search sys$pipe intrusion,--------/match=nor | -
           mail sys$pipe system/subject="Intruder alert"/NoSig
$         define /system Intruder$Alert True
$         submit/noprint/user=system Kronos_Root:[Misc]BlockIntruder.com
$        else
$         define /system Intruder$Alert False
$        endif

What's this do? It checks to see if there are any intruders listed, and if so, emails a notification and then runs the procedure named BlockIntruder.com. Note the logical prevents the system from checking again if the last run of this program discovered an intruder.

The next procedure does the real work. BlockIntruder.com:

$       pipe sh intr/type=intruder | search sys$pipe network | -
         ( read sys$pipe intruder ; def/job intruder &intruder )
$       Intruder = f$edit(f$trnlnm("Intruder"),"Trim,Compress")
$       Attempts = f$elem(2," ",Intruder)
$       Intruder = f$elem(5," ",Intruder) - "SSH_PASSWORD:"
$       Intruder = f$elem(0,":",Intruder)
$       write sys$output f$fao("Blocking !AS after !AS attempts.",Intruder,Attempts)
$       TCPIP Set route 'Intruder' /Gateway=Bitbucket

This one checks the output of the Show Intrusion command (performing some normal pipe & logical name machinations to get symbols out of a pipe subprocess using job logicals), then simply sets the route for the "intruder" host to be the Bitbucket. What's that host name translate to? A non-existent host on my network.

What's the net effect? Any inbound packet from that host gets responded to, but not to the host in question. All I do is redirect any output from my host via a non-existent path, the remote host never hears back from me, communications fail, and they go away, thinking I've dropped off the net.

There are many ways this could be improved. Theoretically, it should all be done in one program, not two. Additionally, only one intruder is handled at a time (if I get multiple simultaneous intruders, only the first one is processed, the others are ignored). Some intruders use spoofed addresses, so when they hit my system, the intrusion record shows up as a host name that doesn't necessarily correspond to the real host (although statistically, the vast majority are not quite that elegant) -- meaning I block the wrong host. And it sure would be nice if this program would run whenever an intrusion occured, rather than once every 15 minutes.

But, it sure is nice to see the system get nailed with hundreds of intrusions, only to have that host never bother me again!

I just had to try it!

I did some checking around on the PmWiki website. Unlike a lot of open source projects, this one is pretty well documented -- one of the benefits of a project built for people who want to write documentation, I guess!

The feature-set looked pretty thorough; it has the features I was looking for, and then some. Due to the deliberate modular design, PmWiki has a wide variety of "plug-ins" or "add-ons"; in PmWiki parlance, they're called "recipes". And of course, recipes belong in a cookbook. Here you'll find a variety of items, including CMS, blogging, multimedia tools, RSS recipes, and one I'm anxious to investigate even more, security and authentication recipes.

Another subset of the cookbook is the skins area -- one thing I think is really important with just about any modern web site or project. This area is full of a lot of creativity.

So, last night I tried installing it. Download kits are available in both tar.gz and zip formats (I grabbed the zip). Unzipping the file (using Info-Zip's 6.0 beta, which handily deals with ODS-5 volumes and extended file names) resulted in a subdirectory with the kit's version number (with lots of periods) in the name. I changed the name to shorten it, then launched my browser pointing at the pmwiki.php file therein.

I went through the initial setup, creating the [.wiki^.d] subdirectory (the first time through, I forgot to apply an ACL to allow Apache access. Tappity-tap, refresh, and poof, no errors! Since this contains the wiki itself, don't forget to make this directory writable.) I copied the config.php file to the [.local] directory as suggested, did some edits, but couldn't see the appropriate changes. You guessed it (well, maybe you did) -- I needed to set an ACL on this file, too.

I then grabbed a skin as a test. This time, I rememberd to set the ACL before it became a problem, and things worked as advertised. Skin management is a simple matter of creating a new directory in the [.pub.skins] subdirectory, then editing a single line in the config.php file to point to the new skin. That's how things should be!

You can view the installation in my playground here. No guarantees that this link will remain up for long, but feel free to kick the tires on it if you want.

To give you some idea of performance, this system's an AS800 5/400 with 256MB of RAM, and the net connection is about 350Kbps. Don't expect too much as far as performance, but that said, PmWiki still performs admirably.

Throughout this entire process, I didn't come across a single error or U*X-ism that caused me grief. If you're looking for a quick and simple wiki for documentation or CMS that you want hosted on OpenVMS, I give PmWiki 5 stars!

I can't say enough good about the D-Link DIR-655's capabilities, but that's probably because I'm coming from such a cheap piece of hardware from LinkSys. This new unit is more like the industrial strength firewalls I regularly use in my work environment, with plenty of professional features. The one I really like is the SysLog logging facility. Sure, it's not as clean and robust as OPCOM, but there's a piece of freeware on the OpenVMS Freeware CD #8 that allows a VMS system to collect syslog messages and store them in log files, or send them back out again via OPCOM. Note that there are 2 zip files in this directory -- the fw80_syslogd.zip file contains 2 items: the freeware_readme.txt file and the syslogd.zip file. Unless you want to run UNZIP twice, you'll be okay getting the syslogd.zip file.

I've used this program before, and installation is not exactly straightforward. While there is documentation included in the zip file, there are some caveats I'd like to explore.

First, this program makes extensive use of the UCX prefix. Call me anal, but I had to go through all the routines and replace them with TCP or TCPIP references.

Next, I had to modify the build program by adding the /NoTraceback switch to the Link command. This was required so that I could install the program with privs, rather than assign privs to the service account. To do the installation, I created a new command procedure that does it, as well as step #4 in the syslogd_ucx.doc file, enabling the service. My new command procedure, that's called in my SyStartup_VMS.com routine, looks like this:

$! SysLog startup routine
$!  Install executable with privs...
$
$  Install Replace Sys$SysRoot:[TCP$SysLogd]TCP$SysLogd.exe /Priv=(SysPrv,Oper)
$
$!  And start the service...
$
$  TCPIP Enable Service SysLog

Besides these changes, there's not a whole lot different from the info in the .doc file. Don't forget to set your service account with /Flag=Restrict, create a blank LOGIN.COM for it, and make sure all your file names match the paths and names in the various command procedures and the service definition. Once you're ready, try running the above startup procedure, then check the log files in the account's login directory for the results. If all's going well, you should also see a new system process with the name SYSLOGD_#.

If you chose to setup your .cfg file to log entries in separate log files, you can use Type /Tail and also /Page=Save to conveniently examine your logs.

Finally, I've setup a Kronos job on my system to cycle the logs every month, using the included LOGGER.EXE program with the "-c r" switch.

I've now got a great way to log events on my WiFi router on my OpenVMS host as well as notify me via OPCOM of significant events happening on my network. I find this to be a very useful tool!

$ Analyze /Media /Exercise=Full

Good job, Marty!

My servers are still Digital.

For posterity's sake, here's my Ode to Alpha, penned shortly after the demise of the Alpha processor was reported.

There once was a 'puter named Alpha,
Of which none could boast to be faster,
'til sadly one day
marketing blundered away
Alpha to the computer hereafter.

Here are instructions on setting up the client on your system. NB: don't install this on a system that you do not have authorization to run it on. From a security perspective, the source code is included -- it is up to you to review the code and build it for your system. I am not responsible for software that YOU install on YOUR system.

I've hosted the ZIP file kit on this system for your use. (Note: file updated 17-Feb-2008 with new database host definition. Both Alpha and VAX .exe's have been rebuilt.) You'll need an unzip utility to extract the contents.

Before you start, request a key from the Uptimes Project server via the "Signup" menu item on the site. Extract your kit, examine it as you need, and @Build the object and executable.

Included in the kit are two .com scripts that will allow you to run the program -- unfortunately, they only allow you to run it as a subprocess or a batch job. Personally, I wasn't enthralled with either of these options, so I created a very simple account with its own UIC (in a non-priv'd group) so that I could run the program as a detached process instead. I used Sys$Examples:AddUser.com to create the account, and then tweaked it by specifying /Flag=(DisUser,Restricted) /NoBatch /NoLocal /NoDialup /NoRemote /Network. This combination prevents the account from being used for any other purpose, just as any good dedicated service account should be set.

A simple UpClient$Startup.com file can be added to your SyStartup_VMS.com to start the detached process (edit this file to customize your file locations):

UpClient$Startup.com

$       Run /Detach -
         Sys$System:Loginout.exe -
         /Input=Disk$User0:[UpClient]UpClient_Detached.com -
         /Output=Disk$User0:[UpClient]UpClient.log -
         /Process_Name="UpClient" -
         /Priority=1 -
         /UIC=[UpClient]

This program requires one other, the target of the /Input qualifier. This script looks very similar to the UpClient_Batch.com file that's included in the kit and is included here:

UpClient_Detached.com

$ D = F$ENVIRONMENT("Procedure") ! Presumes this .COM and the .EXE are colocated
$ E = f$Parse(D,,,"Device") + f$Parse(D,,,"Directory") + "UPCLIENT-" + F$GETSYI("ARCH_NAME") + ".EXE"
$ upclient = "$" + E
$ write sys$output "%UpClient-I-Exe, UpClient executable ''E'"
$
$!***
$! Customize the client command line below. For instance:
$!
$! upclient -k <key>
$! upclient -k <key> -p http
$! upclient -k <key> -p http -x proxy -xp port
$!
$!***
$
$RunIt:
$ upclient -k {YourKeyHere}
$ write sys$output "%UpClient-W-ImgExit, UpClient executable terminated unexpectedly at ''f$time()'."
$ wait 00:05:00.0  ! Wait 5 minutes before trying again.
$ goto RunIt

Note that in either of these scripts, you'll need to edit it to add your key to the upclient command line as a value for the "-k" switch.

You can place all of these files -- the executable and any supporting files, as well as the 2 .com scripts above, into the login directory of the new account you've created. Set the security on the files to be only accessible from the owner (which should be the new account you created) and the system account -- no one else should need access to these files or logs.

Execute the startup procedure and you should see your uptime reflected on the server in just a few minutes! If you don't get an update, you can define the foreign command for the upclient program and test the program in an interactive debug session using the following syntax:

$ upclient -k {YourKeyHere} -d 

Based on my experience, I hope your system's on a UPS! If you look at this system's "Reboot reasons", you'll see that the majority of my reboots have been caused by power issues. A powerful UPS and I've gone almost 2/3rds of a year without a reboot as of this writing.

Happy uptimes, all!

And I was! Thanks, HP!

Although it's hard to tell in this picture (I shot it with my Nokia N800's camera), the lettering is quality stitching, not a silkscreened image.

HP has created this special website to commemorate this anniversary. Pat Thibodeau of ComputerWorld has written another OpenVMS article, HP tries to assure OpenVMS users that OS still has a future that I was interviewed for, but I presume the outlook I expressed was too bland and too positive to be used to draw in readers.

I had just turned 20 and was still in college. I remember all the buzz in Kingsbury Hall at the time about the "new computer" that we were getting! (And I was curious why we would be losing 4 bits -- wasn't that a step backwards?) However, it would be another half dozen years before I got to touch my first VMS box, and that would be my own 11/750 at Boeing Flight Test, running VMS v3.4, IIRC.

So, happy birthday, OpenVMS. The first 30 are just the beginning!

Update: Pat Thibodeau's written a second article, this one printed on November 5, "OpenVMS Still Has Road Ahead Of It, HP Says", does quote me.

$ exit 2928

The trick here being that you need to include the 0 (zero)! f$fao("!%D") is nonsensical!