Information about Troth's Finger package Rick Troth BMC ** ) Copyright 1995, Richard M. Troth, all rights reserved. ** (this package hasn't changed much over the past three years) This is the README file for Troth's CMS Finger package. As with most TCP/IP based applications, you can use the client without installing the server, and vice-versa. As I was [re]packaging this for the '96 VM Workshop, I found some problems that must be corrected before I can let it out. So I've removed FINGER VMARC from the tools tape drop-off disk. Sorry. A corrected version will hopefully be available from http://casita.houston.tx.us/~troth/software/finger.vmarc or http://ua1vm.ua.edu/~troth/software/finger.vmarc I was quite surprised when I took the job at BMC Software to find that NO systems ran finger (and most still don't). Why not? I haven't found out, but I hope to, or (better) I hope to change the situation. Finger is a handy tool for locating users on-line. And that's about all. It's not a security threat. It's not much of a privacy threat either. (that may be a matter of taste) CMS FINGER CLIENT This CMS Finger client is "load and go". It uses REXX/Sockets to do all of the TCP/IP work. It uses CMS Pipelines for formatting and all terminal I/O. Typical command syntax is: finger user@host.domain The pieces of the client are: FINGER EXEC tiny wrapper around a PIPE command FINGER REXX this does most of the work, and calls ... PIPESOCK REXX ... to do a few other things. USERLIST REXX interprets your <userid> NAMES file UNTAB REXX expands <tab> characters to 8-column stops Finger (both EXEC and REXX) will run stand-alone. Ie: you do *not* have to run the server (FINGERD) in order to run FINGER (the client). CMS FINGER SERVER The various response generators are independent. This should make anyone *love* CMS Pipelines. If one fails, the next doesn't care. If they all fail (extremely difficult to make FNG#LIST or FNG#TERM fail), then the finger client gets a benign empty response. The pieces of the server are: FINGERD EXEC called by server's PROFILE EXEC FINGERD CONFIG configuration file (modify this locally!) FNG#INIT REXX reads the config file and initializes vars, etc TCPSHELL EXEC interface between TCP/IP socket and Pipelines gem PIPESOCK REXX does some work for TCPSHELL; talks to FINGERD REXX FINGERD REXX all the FingerD specific work is done here FNG#TERM REXX formats user/terminal pair output FNG#STAT REXX processes NETSTAT TELNET output for above FNG#LIST REXX lists all connected users (filters CP Q NAMES) FNG#USER REXX looks-up an individual user <node> NAMES FNG#MAIL REXX checks the user's mailbox (reader, class M) FNG#PLAN REXX reads the user's <userid> PLAN file, if any FNG#LSVW REXX performs a LISTSERV /WHO lookup FNG#RSCS REXX does "cross domain" fingering into BITNET FNG#PROB REXX fingers problems from the excellent Cornell Problem Tracking System In order for FNG#USER to correctly find a <node> NAMES file, You'll have to create that. At Rice, we extracted certian information nightly from the CP Directory to create RICEVM1 NAMES. Some of this is in comments in the directory source. Your implementation is completely up to you. If FNG#USER fails, it's harmless to the server and harmless to your system. For FNG#MAIL to work, the server must have class D privileges. There is no "back door" whereby this might constitute a security hole, unless you consider the revelation of mail status to be such. If you remove FNG#MAIL from the server's disk, you'll get a several- line pipelines error message, but everything continues just fine. FNG#PLAN tries to find the user's "home directory", either a 191 minidisk or a 192 or an SFS top level directory. Once that has been found, FNG#PLAN looks for the file <userid> PLAN and reads it if there. If the user has no "plan file", no harm done, no noise to client. In order for FNG#LSVW to work, you'll have to have the LISTSERV /WHO local command implemented. The operation of FNG#LSVW is simple. It reads a file maintained by LISTSERV of the form "address name", looking for records that match the user being fingered. If it fails, no harm done anywhere. FNG#RSCS is intended to work with RSCS. It issues CP Q USER to a remote RSCS-connected node. Clients on any TCP/IP platform can finger user@bitnethost.BITNET@yourvmhost.yourdomain to get this effect. It's probably NOT a major load on your system. If you have the Cornell Problem Tracking System, you should not need any modifications to it for the FNG#PROB piece here to function. The way it works is: someone on any host, any platform, can finger prob-####@yourvmhost.yourdomain That's P R O B dash number where number is the number of the problem record that the client wishes to view. It's something that we hacked into the older finger server back at Rice a long time ago.