home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Otherware
/
Otherware_1_SB_Development.iso
/
amiga
/
comms
/
misc
/
serserve.lzh
/
SerServer.doc
< prev
next >
Wrap
Text File
|
1990-04-30
|
16KB
|
374 lines
***************************************************************************
* *
* SerServer & Con1-Handler *
* *
* All parts (c) Copyright 1990 by Michael R. Mossman. *
* *
* Released for private, non-commercial use. *
* *
* Compiled with Lattice 5.04. *
* *
***************************************************************************
SerServer - Version 1.03
What is it?
Maybe a better name would have been CliBBS, but I started
with SerServer and so it will stay. It is a personal (with the
lack of a better word) BBS program. It gives the user a full
CLI with restrictions setup by the sysop. I don't like the word
BBS in this case, because, any program that offers a CLI to
strangers, can be a lot of trouble. I wrote the program so that
I can log on to my computer from work and do all of the things
that I do from home in a CLI. I do not recommend that you let
any Tom, Dick or Harry in to use this program. You will end up
with formatted hard drives and sleepless nights. It has three
user levels, and full Zmodem UP/DOWNLOAD. It could be a very
useful program for a few friends and your self to use, when
working on a common project. A place to share files. It
offers limited message sending and receiving.
What files are in the zoo?
Con1-Handler - this is the DOS handler for the CLI.
SerServer - this is the serial device interface and
it talks to Con1-Handler.
SySop - This program configures the "BBS" and
maintains the user/password list.
help - This is just a text file that you edit,
to tell users what commands and devices,
are available to them.
logon - Another text file that the user gets
before they enter their name and
password.
greeting - Another text file that the user gets
after login.
mountlist - This shows how to enter the Con1-Handler
in your mountlist.
Zmodem.zoo - This zoo contains sz and rz. The two
public domain external protocols Zmodem
handlers. Sz is the upload handler and
rz receives the files.
NoRequests.zoo - This public domain program prevents
requesters from coming up when the user
asks for a disk or a drive that is not
present in the system. You can't click
off a requester when your sitting at a
remote terminal! SerServer calls this
program when it firsts starts up.
Setting it up!
First off make a mountlist entry for the Con1-Handler.
Make a directory somewhere called "bbs". Then assign it, eg -
"assign bbs: device:subdirectory/bbs". Create a subdirectory
off of bbs: and call it "mail". Next sit down with a pen
and paper and think. Write down all the devices that are
available to level 1 users (the lowest level). Think very
carefully about what devices you select. (I try to keep people
off my hard drive.) Then select the commands that level 1 users
can execute. (Format seems to be a bad choice.) Commands that
open their own window, should not be used because most of them
will not return control to the CLI and the remote user can
not close the window. Do the same thing for level 2 users. You
might ask, why two levels? I find that I can trust some people
more then others. You might loan your Corvette to some friends
and the Volkeswagon to others. There must be one device
that is common to all level users. This is called the "HOME
DIRECTORY DEVICE". The root of this device is where all level
of users will start from when they log on. It is also the area
that all uploads and downloads take place. A file must be moved
here, before it can be sent. Received files will arrive here.
Do not use Ram: as your "HOME DIRECTORY DEVICE". Rz checks how
much space is left on Ram: before it receives a download file.
Ram: then says that it has 0 blocks free and rz aborts the transfer.
Decide what level can download from your system. Decide what
level can upload to your computer (this is much more dangerous
then downloading and should require a higher level). If you
select a level of 4 for up/downloading then no level user will be able
to send or receive files. The modem string has to be just right for
this program to work. I use ATE0 L0 M1 Q0 V1 &D2 on a Supra 2400.
I will explain each entry in case your modem is not a Supra.
E0 - Modem does not echo back commands (this is
important.
L0 - Low speaker volume (does not matter).
M1 - Speaker on until carrier received (does not
matter).
Q0 - Modem returns result codes after commands (this
is important).
V1 - Selects Verbal result codes (this is important).
&D2 - Modem hangs up, disables autoanswer, and goes to
command state upon ON-to-OFF transition of DTR
line (this is important).
DO NOT PUT THE MODEM IN THE AUTOANSWER MODE eg. ATS0=1.
Now execute Sysop and select "Configure". It will
put a file in the assigned BBS: subdirectory called config.
Enter the previous well thought out data.
Now move SerServer, Sysop, NoRequest, logon,
help and greeting into the assigned BBS: subdirectory (the text files
help, greeting and logon, do not have to be present for SerServer to
work). Copy sz and rz into the C: subdirectory. Copy Con1-Handler into
the L: subdirectory. The DOS commands copy, cd and endcli,
must be in the C: subdirectory. Use Sysop
to enter yourself and who ever, in the userlist. This will create a
file called passwords in the assigned BBS: subdirectory.
Make sure that the sysop is the first entry in the password file and
remember the password. You will be asked for this password every time
you run this program to make changes. The program does this to prevent
someone from uploading the file to the BBS and making changes to the
config or passwords. The program also writes to the log if you fail the
password.
Now do the following:
mount con1: (done after a reboot and not yet mounted)
assign bbs: device:subdirectory/bbs (after a reboot)
newcli con1: (every time the program is started)
SerServer (every time the program is started)
Now the program is up and running and ready for someone to
logon. The text that is received from the Con1-Handler and the
serial device is send to the CLI window that serserver is
started up from. The program can be terminated by selecting the
CLI window and typing Control C. People logging on should set
their terminal programs for 8N1.
Commands
SerServer will parse the command line for level 1 and 2 users. If
a user types "df0:dir" then the parser will eliminate the "df0:" and
only "dir" will be sent to CLI (this assumes that dir is an allowed
command). This along with alias (as shown later) will prevent users
from renaming files (to an allowed command name) and then uploading and
executing them.
Commands that should not be allowed to level 1 and 2 users are
execute, alias, assign, protect, endcli and format.
Help
A user can type help or "?" along the command line and get a help file
if the Sysop provides a text file called "help".
Mail
At a CLI prompt a user can type "mail" and they can leave private
or public mail. Private mail is created in a file under the users
name (the name of the user who is to receive the mail). Private mail
will be deleated after it is read by the user. Public mail is put
in a file called "ALL". It will grow in size until the sysop either
deletes it or edits it. (Some text editors can handle this file.)
All messages are saved in "bbs:mail/".
Things to think about!
Level 3 is the highest level user. There is no parsing of
the command line for a level 3 user. If format is in the
command path and a level 3 user says "format drive DH0: name
NOTHING" then your brand new hard drive will erase it's brains.
The same thing can happen with any level user, if you make the
command available to them. If you make Alias available as a
command then users can do things like "alias dir format" and
type "dir drive DH0: name NOTHING" and format your hard drive
if DH0: is one of the available devices and dir is an allowed
command.
How about if you make zoo an available command and a user puts
format renamed as dir in the zoo. They can then de-zoo the file
and format your hard drive because the CLI will find dir
command in the current path (really format) before it goes to
c:.
Endcli will terminate SerServer from a remote. I felt that this
was handy for the sysop to drop the program from a remote
terminal but can be a problem, if it is an allowed command.
What I'm trying to say is, pick your commands and devices
carefully. And most important, know who the hell your letting
on your computer!
Timings and Stuff
Anyone is allowed one minute to type in their name at the
login prompt, another minute for the password. Everyone is
allowed three tries and then it hangs up. Level 1 and level 2
users are allowed two minutes of inactivity at a CLI prompt
before the program drops them. Level 3 users can be at a CLI all
day and do nothing and the program will not hang up. In the Mail
section of the program, time outs will happen to any level user.
There is no limit to the over all on time for any level user as long
as they are doing something.
Log Keeping
The program keeps a log in the BBS: subdirectory called "log'.
This requires that BBS disk NOT be write protected.
Zmodem Stuff
The program uses Zmodem for up/downloads. Sending from a
remote is easy. I used Online!, Telix and JrComm for testing.
Just select 32 bit CRC (16 bit works also) and at a CLI prompt
in the BBS, select upload in Online!, JrComm, or Telix. Pick
the files and then sit back and wait (have a beer) till they
all arrive at the BBS.
Sending files requires a little more work. First the files
have to be in the "HOME DIRECTORY DEVICE" root. Use copy to
move them there. Then along the CLI prompt line type:
send file1 file2 file3 (etc)
Make sure your terminal program is setup for auto downloads.
"Send" will also accept several options, like so:
send -ao file1 file2
The options are these:
+ - append to existing file.
a - (ascii) change NL to CR/LF in text file.
b - binary file transfer.
e - escape all control characters.
n - send file if source is newer.
N - send file if source is newer or longer.
o - use 16 bit CRC checking.
p - protect existing destination file.
r - resume/recover interrupted file transfer.
y - overwrite existing file.
Not all of the options of sz are supported in SerServer, and it
will prevent unsupported options from being used.
Neet Things
There are some neet things that you can do with Alias. It can provide
a whole bunch of extra commands this way. Say you want users to be
able to read the log file but don't want them to have access to Df0:
where the bbs: files are kept. You can then set up an Alias that reads
like this:
Alias log type bbs:log
You then add log as a command to the Sysop program, and users can read
the log file.
Say you have a bunch of users that don't know dos commands. You can add
help files for each allowed command by doing somthing like this. Create
a subdirectory off bbs: called "help". Then put a text file in there called
"dir". This text file will explain the "Dir" command and it's options.
Then set up an Alias like this:
Alias what type bbs:help/[]
The user then types "what dir" and gets a help file on "Dir". What has to
be added to the allowed commands.
Scripts
Here are a couple example scripts to show you how to set up the the
BBS and use the alias command.
assign bbs: df0:bbs
c:mount con1:
newshell con1: from s:remote-shell <---- This starts the remote-shell script.
stack 10000
bbs:serserver
endcli
And here is the remote-shell script.
stack 10000
cd vd0:
Prompt "(%N) %S>>
alias dir c:dir <---- You should have an entry like these
alias list c:list for every allowed command for
alias type c:type Level 1 & 2 users. This helps prevent
alias echo c:echo <---- users uploading and executing a file.
alias copy copy [] NOPRO BUF=10 <---- allows copyied protected files to be deleted.
alias log type bbs:log <---- Gives the log to users.
alias what type bbs:help/[] <---- If you want help files.
Bugs and Other Critters of the Night
Well this is version 1.03, so what can I say. People doing
buffer dumps and hanging up in the middle of things can always
be a problem. I have tried to catch these problems, but bugs
always seem to surface. I am releasing the executable but will
retain the source on this one. Let me know if you find any
problems. Please don't say it just locked up, try to tell me
what the program was doing, when it locked up!
Things to Do
Programs like this always have things that can be added. I
might add a chat feature in the future. But for now, this meets my
needs. I program for me first and you last.
CopyRight and Things
I am retaining the copyright on Con1-Handler and SerServer Version 1.03
but will release it's use to the public for non-commercial use.
How To Rip Me Apart
You can contact me on CompuServe, my UI is 76515,3017. You can also
reach me on Fido Net 1:255/1 or Punter Net Node 95.
Thanks
Many thanks to Wayne Marchand and the Mad Scientist for debugging and
helpful comments. A real big thanks goes out to Mad for pulling down
his bbs and putting up SerServer. This found bugs, that would have
taken years to find by using a term prog on my 500 and SerServer
installed on my 2500.
History
Version 1.00 - Orginal alpha testing version. Not released to public.
Version 1.01 - Fixed bug in dropped carrier lockup. Program was
waiting on timer message that never came. Fixed
PassWordMaker so that it did not wreck the password
file when editing user entries. Not released to public.
Version 1.02 - Added log keeping and moved sz & rz into the C:
subdirectory from the "HOME DIRECTORY". Not released
to the public.
Version 1.03 - PassWordMaker was rewritten by The Mad Scientist and
called Sysop. Thanks a lot Doug! (call his BBS at
506-648-9196). Added the mail feature and caught a
few more bugs. Added Mail to the Sysop program so
the sysop can read his own mail (or anyone's).
Made level 1 and 2 users command line get parsed
so a path can not be set to a command. Password
protected the Sysop file.