World of Shareware - Software Farm 2/wosw_2.zip/wosw_2/CPROG/KILLCO.ZIP/KILLCONN.DOC

Text File | 1991-04-20 | 12KB | 313 lines

             DOCUMENTATION FOR KILLCONN.EXE
            (Copyright 1991 Thomas R. Bruce)

In general:

KillConn is a utility which permits authorized users to clear
workstation connections on a Novell network via the command
line or from a batch file. It is useful for clearing stations prior to
running system backup and maintenance procedures, particularly if these
are being run unattended.  The user should keep in mind that
however useful it may be it is also somewhat dangerous, particularly if
it is being used in the unattended mode.

KillConn has been tested under Netware 2.15 and 3.10 and it is
therefore probably safe enough to assume that it will work well with
any version of Netware above 2.10. (I'd love to hear about any
exceptions to this naive generalization).

//////////////////////////////////////////////////////////////////////

Additional notes for version 1.1:

Version 1.1 is appearing only a few days after version 1.  This is
owed not (thank heavens) to any major flaws in the original software,
but instead to the astute comments and observations of Gary Banks at
the University of Virginia Law School; 1.1 adds a couple of features
and solves some problems Gary was having with it. (Report bugs and
I'll mention your name too....)

First, KILLCONN now attempts to disconnect the victim five times
before failing with an appropriate error message to the log file;
Novell versions prior to 2.15 seem to have some problems with a
single pass.  Previously KILLCONN's failures went unnoticed in the
log.  You can change the retry count with the RETRIES=nn command line
parameter (see below).

Second, I thought that some of the more merciful among you-- those who are
not running this program late at night-- might appreciate the ability
to warn users prior to dropping their connections.  See the
WARNING=nn parameter below.



//////////////////////////////////////////////////////////////////////


Safety nets:

KillConn cannot be run by anyone who does not have console operator
rights on a target file server.  It can also be configured (via the
confirm=YES option -- see below) to require a keyboard response before
it clears anyone, if you are not running it unattended. You can also
set up a Netware group called IMMORTAL; KillConn will skip any of its
members no matter what.  This is handled on a per-file-server basis, so
if you're running KillConn on an internetwork, you'll have to set up
the group on each server; whether you do this with the same members on
all servers or not is up to you.

KillConn will not clear ANY connection belonging to a user with the
same login_name as the workstation from which it is being run.  This
can be a problem if the user running KillConn is logged in from multiple
locations, and you wish to retain only one, but I had to draw the
line somewhere.

Using the WARNING=nn parameter permits you to give the user an
appropriate amount of warning before disconnecting her.  Of course,
too short a length of time is open to interpretation as a subtle
psychological torture....

//////////////////////////////////////////////////////////////////////


Power tools:

KillConn can be configured to clear groups of users in two ways- either
by using the group=SOMEGROUP parameter on the command line, which will
cause all members of a Netware group to be cleared, or by using
wildcard characters (* and ?, just as with DOS) in the user= command
line parameter (for example user=LABMACHINE*).  Of the two methods, I
prefer using the 'group =' parameter.  It involves a little more
administration, but it's also a great deal more obvious what's going on
and more difficult to make unintentional errors.

KillConn is set up to work automatically on all servers on an
internetwork; you can restrict its scope with the 'server='
command-line parameter if you only want to clear connections from one.
The 'user=' and 'group= ' parameters are still in effect (indeed, one
or the other is required).  Of course, the workstation from which
KillConn is run must be attached to any server you wish to clear,
regardless of how you set the scope.

If you experience trouble with certain stations not clearing when you
know KILLCONN has found them, you may set KILLCONN to retry each
station a number of times before moving on.  See RETRIES=nn below.


//////////////////////////////////////////////////////////////////////

Notification:

KillConn sends a regular Novell-type broadcast message to all stations
which it clears.  The message give the date and time at which the
station was cleared, presumably for the victim to find the next morning.
Note that the date and time are taken from each server individually, so
that occasional discrepancies will result if your servers do not have
their system times synchronized.

You may also, via the 'log= logfilename' and 'logadd= logfilename'
parameters, configure KillConn to keep a log of its nefarious
activities.  Using 'log=' causes an existing logfile with the same name
to be overwritten; 'logadd=' appends new information to an existing
logfile.

//////////////////////////////////////////////////////////////////////


Imaginative uses:

Primarily, KillConn is intended to clear stations out of the way so
that you can grab the system away from the end-users and get on with
whatever it was you wanted to do.  I can also see it being used as a
way of plugging security holes created by users who leave workstations
running at all hours.

//////////////////////////////////////////////////////////////////////


ENOUGH, ALREADY! How do I use it?:

Command-line parameters:


USER=SOMEBODY
USER=WILD*CARD or WILD????
GROUP=NOVELL_GROUP        (one and only one required)

USER=SOMEBODY will disconnect user SOMEBODY anywhere they are logged
in, no matter how many times they are logged in, unless SOMEBODY is a
member of IMMORTAL or the scope is restricted via the SERVER= option.
USER=WILD*CARD will similarly disconnect all users with names that
match the wildcard pattern (which follows DOS rules- * represents any
number of characters, ? only one).

GROUP=NOVELL_GROUP will disconnect all members of a group.  Note that
if the group membership varies from server to server so will the people
disconnected; KillConn looks at only one bindery at a time.

You must use one of these and you may use only one.  Anything else you
want to do can probably be handled either by setting up an appropriate
group with SYSCON or by running KillConn repeatedly from a batch file.

////////////////////////////////////////////////////////////////////////

SERVER=SERVERNAME

KillCon ordinarily works across all file servers to which the
workstation running it is attached (internetwork scope).  If you want
to restrict this, you can limit it to server SERVERNAME by setting this
parameter.

////////////////////////////////////////////////////////////////////////

CONFIRM= YES or CONFIRM = NO

The default is CONFIRM= NO, so be careful.  Normally, KillConn doesn't
ask anyone's permission before it blasts some heathen off the network.
If you set CONFIRM=YES at the command line, an operator at the
workstation running KillConn will be able to abort it on a case-by-case
basis.  I recommend using this the first time you try a wildcarding
scheme, just to make sure nothing untoward shows up.

////////////////////////////////////////////////////////////////////////

LOG=filename or LOGADD=filename

If either one of these appears on the command line, KillConn will write
a log to file 'filename'.  Of course, 'filename' may be a full DOS path
up to 255 characters in length.  Using LOG= causes an existing file of
the same name to be overwritten; LOGADD= will create the file if it
doesn't exist, and append to it thereafter.

////////////////////////////////////////////////////////////////////////

HELP
-H
/H

Any one of these three produces a cryptic and potentially frustrating
help screen, as is traditional in the industry.

//////////////////////////////////////////////////////////////////////

WARNING=nn

Sends the user a broadcast message a minimum of nn seconds before
disconnecting them; you can set this as high as is necessary to allow
people to log out.

//////////////////////////////////////////////////////////////////////

RETRIES=nn

By default, KILLCONN will attempt a disconnection five times before
giving up; it seems that on certain networks stations do not respond
quickly enough.  You can set the retry count higher or lower with
this parameter.  There's probably no advantage to setting it lower
unless you're in one heck of a hurry.

//////////////////////////////////////////////////////////////////////


EXAMPLES:

Let's suppose we have a three-server internetwork with servers named
BOZO, CARDOZO, and SHLOMO-- I'm running KillConn as user BIGDEAL, who
has console privileges on all three servers.

KILLCONN USER=TOM

would clear TOM off of all three, provided that the workstation is
logged into all three.

KILLCONN USER=TOM SERVER=SHLOMO LOG=K:\HOME\BIGDEAL\KILLED.LOG

would kick TOM off SHLOMO only, and record this fact in the file
KILLED.LOG in the specified directory.  If we then ran

KILLCONN USER=TO* LOG=K:\HOME\BIGDEAL\KILLED.LOG

users TOM, TORRID, TORRENTIAL, and TORTOISE would be cleared from all
servers.  The log file would be overwritten with this information.
To retain the information from our previous session, we would use

KILLCONN USER=TO* LOGADD=K:\HOME\BIGDEAL\KILLED.LOG

If we wanted to skip the log, but have individual control over each
of the four users, we could use:

KILLCONN USER=TO* CONFIRM=YES

and manually confirm each clear from the workstation running
KillConn. Finally

KILLCONN GROUP=DINGBATS SERVER=BOZO

would zap all users in the group DINGBATS from server BOZO.  Of
course, this assumes that none of the people mentioned above are
members of the IMMORTAL group.

Got it?

//////////////////////////////////////////////////////////////////////


YOUR RIGHT TO USE THIS PRODUCT:

KillConn is being marketed under a 'conscience-ware' scheme, whereby
I as author am not really seeking any compensation, but am also very
open to the possiblity that people might send me $10 or so if they find
it useful.  More to the point, I really enjoy hearing from people who
are using the silly thing; it's nice to know someone's using something you
built.  So, regardless of whether you send cash or not, drop me a line
or give me a call. As I say, it's nice to feel that this stuff isn't
getting pitched into a void.

Naturally, though I won't strain your credulity by claiming that I like
to get bug reports, I _do_ want to hear about them, and I will continue
to maintain this code (on an admittedly as-time-permits basis) for as long as
people report problems.  Believe it or not I get a charge out of
writing little utilities and would therefore love to hear about any
ideas anyone may have for other small tools, new features, and so on.

KillConn _is_ copyrighted, and may not be distributed commercially or
in conjunction with any commercial product without the author's
permission; I also expect that should you post it to a bulletin board
or other public forum you will include this documentation, copyright
notice, and disclaimer.  The author, Thomas R. Bruce, may not be held
liable for any damages, loss of business, or other direct or indirect
consequences of your use of this product.  Put another way:


                                DISCLAIMER - AGREEMENT

         Users of KillConn must accept this disclaimer of warranty:

         "KillConn is supplied as is.  The author
         disclaims all warranties, expressed or implied, including,
         without limitation, the warranties of merchantability and of
         fitness for any purpose.  The author assumes no liability for
         damages, direct or consequential, which may result from the
         use of KillConn."





That said, enjoy using KillConn.  And don't forget to write:

Thomas R. Bruce
147 Chestnut St. E-22
Ithaca, NY 14850    (607)-273-2661

In cyberspace:  lemuel![e-mail]
        75360,542 (Compuserve), which I don't check real often.