170 lines
8.5 KiB
HTML
170 lines
8.5 KiB
HTML
|
<HTML>
|
||
|
|
<HEAD>
|
||
|
|
<META http-equiv="Content-Type" content="text/html; charset=ISO 8859-1">
|
||
|
|
<META http-equiv="Content-Style-Type" content="text/css">
|
||
|
|
<META name="author" lang="en" "content="Michiel Broek">
|
||
|
|
<META name="copyright" lang="en" content="Copyright Michiel Broek">
|
||
|
|
<META name="description" lang="en" content="MBSE BBS Manual">
|
||
|
|
<META name="keywords" lang="en" content="MBSE BBS, MBSE, BBS, manual, fido, fidonet, gateway, tosser, mail, tic, mailer">
|
||
|
|
<TITLE>Running a BBS under Linux.</TITLE>
|
||
|
|
<LINK rel=stylesheet HREF="manual.css">
|
||
|
|
</HEAD>
|
||
|
|
<BODY>
|
||
|
|
<BLOCKQUOTE>
|
||
|
|
<h5>Last update 06-Jun-2001</h5>
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H1>Running a BBS under Linux.</H1>
|
||
|
|
<P>
|
||
|
|
|
||
|
|
<h3>Introduction</H3>
|
||
|
|
<P>
|
||
|
|
Everyone who has been running a (single line) BBS under DOS until now will
|
||
|
|
need to understand that running a BBS under Linux (or any other multitasking
|
||
|
|
os) is completly different of what you are used to. Under DOS things were
|
||
|
|
quite simple, from AUTOEXEC.BAT you started a new .BAT file that would run
|
||
|
|
forever and started all needed programs after each other.
|
||
|
|
The programs that where started
|
||
|
|
depended on the errorlevel of the previous program. Only one program could
|
||
|
|
run at the same time.
|
||
|
|
<P>
|
||
|
|
People who had previous run a BBS on another multitasking os, or were running
|
||
|
|
a BBS on a small lan with a fileserver and workstations for each line, are
|
||
|
|
already more used to the idea of running more programs at the same time,
|
||
|
|
and to "signal" what to do next with semafore files.
|
||
|
|
<P>
|
||
|
|
The Linux aproach is more or less the same, but there are more differences.
|
||
|
|
The main difference is that there is no mailer connected with the modem waiting
|
||
|
|
for a call, instead there is a getty process watching your modem(s). Another
|
||
|
|
big difference is that you don't see what's happening, there is no screen
|
||
|
|
with the mailer or bbs picture on it. All programs run in the background. If
|
||
|
|
you don't like that, stop now and go back to your old DOS bbs. It's just the
|
||
|
|
way everything is done.
|
||
|
|
<P>
|
||
|
|
Programs that must start at specific times (events in DOS), are started from
|
||
|
|
cron, this is the event scheduler for Linux (and other Unixes). With this
|
||
|
|
program maintenance can be started, polls created etc. For starting programs
|
||
|
|
when they are needed there is a taskmanager loaded at system bootup. This
|
||
|
|
taskmanager "watches" the semafore directory of the bbs and will start what
|
||
|
|
is needed.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H3>Waiting for a call .....</H3>
|
||
|
|
<P>
|
||
|
|
Under Linux this is done with the mgetty program, this is the
|
||
|
|
process that is connected with each modem (or ISDN adapter) and waits for a
|
||
|
|
call. The mgetty program (written by Gert Doering, gert@greenie.muc.de) will
|
||
|
|
detect the call, and find out what or who did make the call. It can detect
|
||
|
|
incoming humans who want a login prompt, PPP calls from users who want to
|
||
|
|
make a PPP connection (browsing your BBS whith netscape for example), A fax
|
||
|
|
machine trying to deliver a fax and finally a mailer trying to establish
|
||
|
|
an EMSI, FSC-0006 or FSC-0001 session. The mgetty program is responsible for
|
||
|
|
starting the right client programs. How to do this is explained in the
|
||
|
|
installation manuals, but be sure to compile it with Fido and PPP support.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H3>A Human is calling.</H3>
|
||
|
|
<P>
|
||
|
|
This could be a bbs user. For each user to login to your bbs there must be a
|
||
|
|
unix account. They automatic create such an account the first time they login
|
||
|
|
with the <b>bbs</b> account. During the creation of their account the shell that is
|
||
|
|
installed for there account is the mbsebbs binary, so that's the only thing
|
||
|
|
that they get if they call in. When they logout the bbs, or drop carrier etc,
|
||
|
|
the session is ended and mgetty takes over the line again.
|
||
|
|
Note that they will never can get a Unix shell
|
||
|
|
unless you install a <b>door</b> in the bbs that calls a shell for them.
|
||
|
|
<P>
|
||
|
|
There are probably more accounts on your system that can callin, <b>mbse</b> is
|
||
|
|
such an account, this is the MBSE BBS maintenance account. This user will
|
||
|
|
get the shell prompt. Use good passwords for shell accounts, and never change
|
||
|
|
your setup so that the <b>root</b> user can directly login except from the console.
|
||
|
|
If you need root access, login as <b>mbse</b> and type <b>su</b> at the prompt to become
|
||
|
|
root. You might consider installing SSH on your system for remote maintenance.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H3>A PPP call is detected.</H3>
|
||
|
|
<P>
|
||
|
|
Installing a PPP server on your system is beyound the scope of this project.
|
||
|
|
However if you did install it, users can login your bbs with their favourite
|
||
|
|
browser and use your bbs. Note that the necessary tools to automatic create
|
||
|
|
newsgroups don't excist at this time. With the proper setup you can automatic
|
||
|
|
create and maintain html pages for the file areas.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H3>A mailer call is detected.</h3>
|
||
|
|
<P>
|
||
|
|
If a mailer is detected by mgetty, the <b>mbcico</b> program is started and will
|
||
|
|
take over from mgetty. It will establish a mail session with the caller and
|
||
|
|
the mail and or files will be exchanged just like any DOS mailer would do.
|
||
|
|
After the call, mbcico will hangup and mgetty will take control of your modem
|
||
|
|
again. If there is any mail received, mbcico will place the semafore <b>mailin</b>
|
||
|
|
so that another process can take care of the received mail. Mbcico will also
|
||
|
|
detect some IEMSI terminal programs (Frontdoor), and will start the bbs.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<h3>There is mail in the inbound</h3>
|
||
|
|
<P>
|
||
|
|
As I said before, if the <b>mailin</b> semafore is present, the task manager will
|
||
|
|
then start the <b>mbfido</b> program that will toss the mail, process any files
|
||
|
|
received and if necessary it will create other semafore's for example to link
|
||
|
|
the message bases, start the nodelist compiler etc. Note that this can be done
|
||
|
|
while there may be a new mailsession going on, a bbs user is online, it doesn't
|
||
|
|
matter. Processing mail and files can be done real multitasking without any
|
||
|
|
damage to other processes.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H3>It's time to poll a node</h3>
|
||
|
|
<P>
|
||
|
|
At the time that you whish to poll a node, let cron create "poll" requests.
|
||
|
|
When a poll is created, the semafore <b>scanout</b> is also created.
|
||
|
|
The taskmanager will then start mbcico at regular intervals so that mail will
|
||
|
|
get out. If there is no more mail to send, the <b>scanout</b> semafore is removed.
|
||
|
|
If a timeslot ends, you can just remove the "poll" requests that didn't succeed.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H3>It's Zone Mail Hour, so now what</h3>
|
||
|
|
<P>
|
||
|
|
Relax, if you have netmail ready for nodes the
|
||
|
|
mailer script will try to send these mails to those nodes. If it was crash
|
||
|
|
mail, and the destination was a non CM node, the mailer will try to send those
|
||
|
|
mails too. Note that other crashmails are send anytime. Also note that packed
|
||
|
|
mail and files are not send during ZMH. If a node calls you during ZMH he will
|
||
|
|
get everything that's waiting, including packed mail and files. The task manager
|
||
|
|
(more on that later) calculates the Zone Mail Hour from UTC time, you don't
|
||
|
|
have to change anything for summer- and wintertime.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<H3>Daily maintenane</h3>
|
||
|
|
<P>
|
||
|
|
This is started by cron jobs. There is no need to take
|
||
|
|
your bbs lines down during maintenance, you can do it any time of the day.
|
||
|
|
I have made several scripts for this, daily, weekly and monthly.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<h3>How about system load</h3>
|
||
|
|
<P>
|
||
|
|
Because Linux is a 32 bit os, not bothered with a graphical user interface
|
||
|
|
(unless you install it), it has all the time in the world to serve your
|
||
|
|
bbs programs. Background programs are build to release time to the Linux os,
|
||
|
|
they don't need to run fast because it's background processing. The bbs and
|
||
|
|
the mailer, have a low server load although there is no timerelease build
|
||
|
|
in. Only the bbs has some short moments when it needs a lot of your system,
|
||
|
|
for example when a user logs in and scans for new mail. The bbs I run is a
|
||
|
|
486-DX4 100 MHz, 20 MB ram, with 2 analogue lines, this seems to work fine.
|
||
|
|
When this system's MOBO died, I used a 386DX33 for several months with
|
||
|
|
20 MB ram, and the only thing users ever noticed was that scanning for new
|
||
|
|
mail was slower. I think this is the slowest harware that will work.
|
||
|
|
However, you must always use 16550A uarts for the COM ports. For best
|
||
|
|
performance use SCSI disks. I noticed that old 5"FH SCSI disks perform better
|
||
|
|
for bbs usage then modern EIDE disks. This is probably caused by the fact that
|
||
|
|
the kernel needs more time for the cheap IDE bus.
|
||
|
|
If you want to use X11 on your bbs, you need more ram and a faster CPU or a
|
||
|
|
separate machine via a lan and export the display to that machine.
|
||
|
|
<P> <P>
|
||
|
|
|
||
|
|
<A HREF="index.htm"><IMG SRC="images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||
|
|
</BLOCKQUOTE>
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|
||
|
|
|