home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1994 #1
/
monster.zip
/
monster
/
BBS_UTIL
/
BFE3100P.ZIP
/
BFE3100P.EXE
/
DOCS
/
GATEWAY.DOC
< prev
next >
Wrap
Text File
|
1994-03-12
|
26KB
|
540 lines
▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄
█ ▄▄ █▄ █ ▄▄▄▄█ █ ▄▄▄▄█
█ ▄▄▄ █ █ ▄▄█ █ ▄▄▄█▄
█▄▄▄▄▄█ █▄█ █▄▄▄▄▄█
▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄ ▄▄▄
█ ▄▄▄▄█ █ ▄▄▄ █ █▄▄ ▄▄█ █ ▄▄▄▄█ █ █▄█ █ █ ▄▄▄ █ █▄▀█▀▄█
█ █▄▄ █ █ ▄▄▄ █ █ █ █ ▄▄▄█▄ █ ▀▄▀ █ █ ▄▄▄ █ ▀█ █▀
█▄▄▄▄▄█ █▄█ █▄█ █▄█ █▄▄▄▄▄█ █▄█▀█▄█ █▄█ █▄█ █▄█
─────────────────────────────────────────────────────────────────────────────
A special feature of the enhanced version of BFE!
─────────────────────────────────────────────────────────────────────────────
For years now, the vast majority of the world's amateur online BBS systems
have been DOS-based Bulletin Board packages. Packages such as Scott Dudley's
Maximus CBCS and Andrew Milner's RemoteAccess BBS have gained large sysop
followings, and have each spawned no less than a dozen clones. The last
estimate was around 30,000+ public access BBS systems in the United States
alone. Not bad when you think that most of this started from a man named
Ward Christensen's garage back on a snowy night in February, 1978, in
Chicago.
Now imagine a real-time network which connects millions of users and systems
scattered across the globe. Internet. The final word in cyberspace
computing. With the advent of the "NII" (information superhighway), the
Internet is growing by leaps and bounds.
Sound good so far? Well, the fact of the matter is, that most of the systems
belonging to the Internet are UNIX based systems, not DOS based. So, how do
we provide access to those UNIX systems via our DOS-based BBS packages? With
BFE's gateway feature, of course!
Let's face it, telephone lines are expensive these days. Why have a separate
dedicated dialup line for your UNIX system? Use BFE's gateway to simply
"gate" calls to your DOS system through a standard NULL modem cable that you
can even make yourself! Whether you intend to access your UNIX system to
provide e-mail services, telnet, and ftp, or if you simply want a convenient
method of gaining access to your UNIX system via your DOS-based BBS package,
BFE's gateway system is at your disposal.
BFE's gateway feature is an integral part of BFE which provides a direct
serial connection to a UNIX-based system such as SCO/UNIX, Xenix, AIX, Linux,
Coherent, etc., from a DOS-based BBS system. Keep the flexibility and
functionality of your existing DOS-based BBS intact, and simply use the
gateway to shove those advanced users over to the UNIX side of things! DOS
is pretty, UNIX is powerful - now, you can have both!
As of BFE v3.10.0, there are two methods of using BFE/Gateway. The first,
which was supported in release 3.00.0p, provides a system shell to the UNIX
server. This was great for system administrators or experienced UNIX users
but not so hot for beginners. UNIX is terribly cryptic in nature, and not
something you want to thrust your neophyte DOS users into right away. Now,
BFE takes a more "Client/Server" approach to things. Through the use of
special BFE menu and scripting options, you can now create a complete
menu-driven interface to your UNIX server.
** NOTE: The gateway performs "raw" data interpretation, which essentially
means that your users can use literally any terminal emulation your UNIX
system supports (i.e. ansi, vt100, vt220, wyse, IBM/3151, etc).
Through inexpensive SLIP connections with true Internet hosts, it is now
possible to provide "live" Internet access to your users! Imagine being
able to provide "telnet" and "ftp" access to your DOS-based BBS subscribers!
And even if you do not run a SLIP connection directly to the Internet, it
provides a nifty way of providing affordable Usenet newsgroups and Internet
E-Mail to your users. Read onward!
────────────────────────────────────────────────────────────────────────────
┌──────────────────────┐
▄│ Gateway Operation │
█└──────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
There really isn't much (externally, at least) in the operation of a BFE
gateway. The gateway cannot be set up as a menu option, at least directly.
It must be run from a BFE/Script. Set up a menu option to run a script file
(we'll call ours UNIX.SCR). It should look something like:
main()
{
gateway(1, 1);
}
In the above example, we are creating a gateway using fossil port 1 (COM2)
as a gateway port. The gateway port (obviously) must be different than the
port the user is currently connected to. The second argument specifies
whether or not BFE should perform IPC checking to determine if the gateway
connection has been established. This is particularly handy, as you will
see later on.
When the user executes the BFE script, and all goes well, he/she should see
your UNIX login prompt on his remote screen. As the user is entering UNIX
commands, logging activity will occur on the local system console.
Scenario: 1) User calls in on modem (COM1), connects to BFE
2) User selects "gateway" option from a BFE menu
3) BFE runs the script file associated with that menu option
4) User gets "shuttled" out to UNIX system through COM2
5) User ends his UNIX session by entering the escape sequence.
6) User returns to BFE
If you run into problems, the first suspect should be the fossil driver.
Make sure that you have set your fossil up with the proper settings for
each port involved. It is possible to set the BFE port to one speed, and
set your UNIX port to another, as long as the fossil reflects the difference!
This is crucial. The above scenario dictates a very minimal BFE gateway
setup. For more advanced information, read on.
Make sure you read over the GATETIPS.DOC file included with the archive. It
provides answers to most common questions.
────────────────────────────────────────────────────────────────────────────
┌──────────────────────┐
▄│ Escape Sequences │
█└──────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
As mentioned above, BFE's gateway feature supports special "escape sequences".
These sequences are there to let BFE know how to handle the user in certain
situations. The following sequences are available, and configurable via the
external BFE.LNG (language) file.
GW_EXIT - This server string will log the user off of the UNIX system and
returning to BFE.
GW_RETN - If this string comes across the BFE console from the UNIX
system, the connection to the gateway will remain live, but the
user will be returned to BFE. Here is where the interaction
begins (more later).
────────────────────────────────────────────────────────────────────────────
┌──────────────────────┐
▄│ Transmit2Gateway │
█└──────────────────────┘
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
A menu type called "Transmit to Gateway" has been implemented which will
allow you to transmit remote strings to your UNIX server, after a login has
been established. This may sounds tricky, and it is, so pay attention here!
As a simple example to illustrate the feature, let's create a simple UNIX
login and menuing script which will log the user in, and provide a few menu
options for him. This is known as the "Client" script, or the "Client"
portion of our "Client/Server" approach to things. We'll tackle the "Server"
portion in a moment.
This simple script will simply establish the gateway connection, log the user
into the UNIX server, and handle a few simple UNIX commands for them via
hotkeyed menu items.
-----------------[ UNIX.SCR - Cut here ]
/* UNIX.SCR - BFE Script file to gate callers to SCO/Unix 3.2 through COM2 */
main()
{
int rc;
/* Etablish the gateway connection if it has not been setup already */
rc = IsGateway();
if(rc == 0) {
gateway(1);
}
/* Call our simple menu function */
SCO_Menu();
}
SCO_Menu()
{
int breakflag;
int rc;
char key;
int ansi;
while (breakflag == 0) {
ansi = checkansi();
clearscreen();
SETCOLOR("bright yellow on black");
centermsg("Interactive SCO/UNIX Menu");
putsnl("");
menuline("Who is on the system", "1");
menuline("Enter Visual SCO Desktop Shell", "2");
menuline("Quit SCO Menu", "Q");
key = menu("12Q");
setcolor("flashing bright white on black");
if(key == 'Q') {
breakflag = 1;
}
if(breakflag == 0) {
if(key == '1') {
Transmit2Gateway("bfewho", 1);
}
if(key == '2') {
Transmit2Gateway("bfescosh", 1);
}
}
}
}
-----------------[ End of UNIX.SCR - Cut here ]
As you can see from above, we first establish the gateway connection through
the use of the "gateway()" function call. Before we do that, however, we
make a quick call to the "IsGateway()" function, to determine whether or
not the connection to the gateway has been established already.
Once the user logs into the system properly, and control is passed back to
BFE (more on this later!), then he will be faced with our sample interactive
menu. Then, based on the user's selection, the internal Transmit2Gateway()
function is called to pass a remote string to the UNIX system (prompt).
** NOTE: The second argument to the Transmit2Gateway() function is used to
determine whether or not the command is PASSIVE or ACTIVE. Interactive
tasks such as mail editing, UNIX shells, etc, are examples of ACTIVE tasks.
The user will remain in control of the server until the application returns
control to BFE. PASSIVE tasks are those tasks which simply need to be
initiated, and not interacted with. Examples of PASSIVE tasks include all
UNIX daemons, cleanup programs such as uulog, etc. If a task is PASSIVE in
nature (2nd argument is 0), then control will be immediately returned to BFE
after the command has been sent to the UNIX server through the gateway. The
user will not be able to interact with the UNIX system using PASSIVE commands.
You will notice that instead of calling the normal UNIX "who" function if the
user presses the "1" key, we call a custom UNIX script appropriately called
"bfewho". Please note that this is not necessary, but allows you to more
with it to clean things up.
Here is our sample UNIX "bfewho" script which resides in /usr/bin on our
system:
------------[ /usr/bin/bfewho ]
clear
who | more
/usr/bin/retbfe
------------[ end of /usr/bin/bfewho ]
As you can see, we simply clear the screen, and pipe the call through the
UNIX "more" filter, in case the output runs past the bottom of the screen.
Then we call our /usr/bin/retbfe script, which passes control back to BFE.
This script looks like:
------------[ /usr/bin/retbfe ]
echo
echo Press ENTER to return to BFE:
read $DUMMY
echo *RETURN2BFE*
------------[ End of /usr/bin/retbfe ]
Above, we simply place a "continue" prompt on the screen, and read in a
dummy variable. Then, the "*RETURN2BFE*" string is echoed, which BFE's
gateway will interpret accordingly, and return back to our sample menu.
The /usr/bin/retbfe script used above is used with all of our "Server"
side (UNIX) scripts, in order to pass control back to BFE.
This sounds tricky, but it's really quite simple once you get your basics
down. If you need assistance, once again, we stand ready to help you.
Our example menu above will continue, until the user presses "Q" to quit
the script and return back to the calling BFE menu. Although the gateway
connection itself must be established through a BFE scriptfile, the actual
UNIX commands may appear in standard BFE menus. Let's create a sample
standard BFE menu which will establish a connection, and provide some
rudimentary Internet e-mail facilities.
Our first menu item will allow the user to log on properly to establish
the connection:
┌───────────────────────────────────────────────────────[ BFE/Setup v3.00.0 ]┐
│ - - --─── ───-- - - │
└────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────── Menu Option Editor ─────────────────────────────┐
│ Description │
│ Log on to the SCO/UNIX Server │
│ Hotkey 1 │
│ Flavor NORMAL │
│ Option Type S Run a BFE script program │
│ Security 0 │
│ Portspeed TRUE │
│ PassParms Yes │
│ Prompt │
│ Secondary Field logon.scr │
│ Process │
│ Showafter │
│ Password │
│ Color Override │
│ Create Dropfile None │
│ Dropfile Path │
└────────────────────────────────────────────────────────────────────────────┘
This will simply call the "logon.scr" script file, which should look something
like:
main() {
int rc;
/* Is the gateway already active for this session? */
rc = IsGateway();
if(rc != 0) {
Error("You are already connected to the gateway!");
return;
}
gateway(1, 1);
DisplayFile("CONNECT");
}
Next, we will add an option which will allow the user to check his or her
Internet E-Mail:
┌───────────────────────────────────────────────────────[ BFE/Setup v3.00.0 ]┐
│ - - --─── ───-- - - │
└────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────── Menu Option Editor ─────────────────────────────┐
│ Description │
│ Check your Internet E-mail │
│ Hotkey 2 │
│ Flavor NORMAL │
│ Option Type 8 Active Transmit to Gateway │
│ Security 0 │
│ Portspeed TRUE │
│ PassParms Yes │
│ Prompt │
│ Secondary Field /usr/bin/bfemail │
│ Process │
│ Showafter │
│ Password │
│ Color Override │
│ Create Dropfile None │
│ Dropfile Path │
└────────────────────────────────────────────────────────────────────────────┘
Here, we are passing the string "/usr/bin/bfemail" to the UNIX prompt through
the gateway. Here is a sample /usr/bin/bfemail:
---
mail
/usr/bin/retbfe
---
Next, we need to create an option to allow the user to actually ENTER an
Internet E-mail message:
┌───────────────────────────────────────────────────────[ BFE/Setup v3.00.0 ]┐
│ - - --─── ───-- - - │
└────────────────────────────────────────────────────────────────────────────┘
┌───────────────────────────── Menu Option Editor ───────────────────────────┐
│ Description │
│ Enter an Internet E-mail Message │
│ Hotkey 3 │
│ Flavor NORMAL │
│ Option Type 8 Active Transmit to Gateway │
│ Security 0 │
│ Portspeed TRUE │
│ PassParms Yes │
│ Prompt To: │
│ Secondary Field /usr/bin/bfemailenter │
│ Process │
│ Showafter │
│ Password │
│ Color Override │
│ Create Dropfile None │
│ Dropfile Path │
└────────────────────────────────────────────────────────────────────────────┘
In this example, we are using BFE's custom prompt feature to obtain a field
of user input. This is automatically passed to our /usr/bin/bfemailenter
script by BFE. By doing this, they actually enter the recipient's e-mail
address or name, and BFE will pass it to the script.
Here is a sample /usr/bin/bfemailenter script:
---
mail $1
/usr/bin/retbfe
---
Next, let's create an option which will take them into the SCO visual
desktop shell:
┌───────────────────────────────────────────────────────[ BFE/Setup v3.00.0 ]┐
│ - - --─── ───-- - - │
└────────────────────────────────────────────────────────────────────────────┘
┌───────────────────────────── Menu Option Editor ───────────────────────────┐
│ Description │
│ Enter the SCO Desktop Shell │
│ Hotkey S │
│ Flavor NORMAL │
│ Option Type 8 Active Transmit to Gateway │
│ Security 0 │
│ Portspeed TRUE │
│ PassParms Yes │
│ Prompt │
│ Secondary Field /usr/bin/bfescosh │
│ Process │
│ Showafter │
│ Password │
│ Color Override │
│ Create Dropfile None │
│ Dropfile Path │
└────────────────────────────────────────────────────────────────────────────┘
A sample /usr/bin/bfescosh script:
---
scosh
/usr/bin/retbfe
---
Finally, let's create an option to provide a normal UNIX command shell. Note
that this time, we are running a script called SHELL.SCR, which disables the
IPC checking capabilities of the gateway system. We do this, so that the
gateway doesn't think we are trying to establish a new session, but rather
to simply provide the user access to a session already open.
┌───────────────────────────────────────────────────────[ BFE/Setup v3.00.0 ]┐
│ - - --─── ───-- - - │
└────────────────────────────────────────────────────────────────────────────┘
┌───────────────────────────── Menu Option Editor ───────────────────────────┐
│ Description │
│ Enter a UNIX Shell │
│ Hotkey X │
│ Flavor NORMAL │
│ Option Type S Run a BFE Script Program │
│ Security 0 │
│ Portspeed TRUE │
│ PassParms Yes │
│ Prompt │
│ Secondary Field shell.scr │
│ Process │
│ Showafter │
│ Password │
│ Color Override │
│ Create Dropfile None │
│ Dropfile Path │
└────────────────────────────────────────────────────────────────────────────┘
The "shell.scr" BFE script mentioned above, would look something like:
---
main()
{
int rc;
rc = IsGateway();
if(rc == 0) {
Error("You have not established your gateway session yet!");
return;
}
gateway(1, 0);
}
---
As you can see, all of our UNIX scripts end by calling /usr/bin/retbfe.
Keep in mind that the "/usr/bin" path could be any path, that is just where
we keep the BFE supplemental scripts on our system here. The theory is
simple, but powerful. Call the UNIX command, and return control to BFE by
sending the string specified as the GW_RETN string (BFE.LNG) across the port.
Voila! Keep in mind that this method of returning control to BFE only
pertains to those tasks which are considered ACTIVE. PASSIVE tasks do not
require this at all, as BFE will handle it for you.
Using our new sample menu outlined above, the user will select "1" to log
on to the UNIX system. Once they enter the appprpriate name and password
information at the UNIX login prompt, the normal startup procedures are
carried out (i.e. the user's login sequence and/or various profiles).
Unless you want the user to remain in the UNIX shell until they manually
exit, you will need to send the "*RETURN2BFE*" string as mentioned above.
The best thing to do is inform your users to run the /usr/bin/retbfe script
when they want to exit the shell and return to BFE.
A good place to put this is usually at the end of their login .profile, or
in /etc/profile. Another nifty thing to do is simply check the tty line of
the gateway port, and if it is the same as your gateway port, then you can
return. By performing this check, you can limit the immediate return after
logging in only to gateway users, and not local users or dialin lines. Here
is a sample SCO/UNIX ksh snippet to do this:
---[ Start of /usr/bin/bfelogin ]
TTY=`tty`
if [ "$TTY" = "/dev/tty1a" ]
then
/usr/bin/retbfe
fi
---
We call the /usr/bin/bfelogin script at the end of everyone's own .profile
in their home directory. This way the environment gets set up the way it
should be, and then you can return control to by testing the tty line, and
calling the /usr/bin/retbfe script.
BFE will automatically send the "exit" string to the UNIX server whenever
there is a loss of carrier, BFE receives the CTRL [EXIT] sequence, or the
user exits BFE (errorlevel exit, goodbye, etc). This way, your users will
be logged off properly under most, if not all circumstances.
Keep in mind that all of the above UNIX scripts were written for the UNIX
"korn" shell. If you wish to utilize these same scripts, you will need to
make sure that all of your users who will be accessing your UNIX server
are running the Korn shell. Of course, you could always rewrite the scripts
to use whatever shell type you prefer.
* NOTE: Be security conscious! Password protect your UNIX shells and other
sensitive menu options from would-be hackers. Once you have your gateway
setup tested thoroughly, you might want to use shell commands to trap
break characters (such as CTRL-C or [DEL] in SCO/UNIX). You can do this
by placing the following block of ksh code at the top of each of your
UNIX scripts:
trap abort_func 1 2 3
function abort_func {
echo "\n\rAborted!\n\r"
/usr/bin/retbfe
exit
}
Confused? Call us.... :-)
