VUBBS(tm) Copyright 1995 Tycho Softworks.  All rights reserved.
VERY PRELIMINARY DOCUMENTATION FOR VU BBS BETA-3
FIRST EDITING DRAFT ONLY

PATCH LEVEL 5
-------------
This simply incorperates changes made in patches 1-4 to Beta-3.  If you
already have VU BBS and those patches installed, you do not need this.

HOW TO INSTALL
--------------

This is very easy to do!  Simply run the VU BBS 'package' utility from
the shell prompt.  Package will open up 'package.tgz', display an
introductory message further explaining how to install VU BBS, and provide
a selection menu to choose installation packages to use.

SYSTEM ADMIN SERVICES
---------------------

It may seem a strange way at first to begin a BBS with a set of system 
administration tools.  However, our view of BBS systems under UNIX is that
they are really an integrated component of the UNIX environment, and not
just a stand-alone, isolated, and in some cases redundent environment.
With this in mind, the system administration package of VU BBS attempts to
re-dress much that has been difficult in administering a BBS with a large
pool of UNIX system accounts.

The system administration environment is composed of two elements. One is
a visual 'shell' or 'menu' that allows selection of system administration
tools.  This menu can be used to grant full 'root' permission to non-root
users who can then be assigned specific system administration duties in a
controlled manner.

The second element are those system administration tools which are actually
called from the admin menu, and that actually perform useful work.  The
following tools are now part of the VU BBS system admin services:

	*	USERS	manage user accounts
	*	LOGS	manage log files
	*	EDITOR	edit VU BBS text files
	*	LINEMON	realtime line status
	*	PACKAGE	software update installer
	*	BACKUP	tape backups

In addition, several deamons are provided, such as purge_users and auto-
event, to allow further automation of system administration.		

The VU system admin environment finally provides a uniform and standard 
environment for the development of interactive system administration tools for
Linux.  It also answers the question of how admin 'services' that 
require 'root' permission can be dooled out to non-root users in a controlled
manner.

The following commands are provided with VU BBS System Admin Services:

ADMIN

A menu shell for granting root access to alternate admininstrators and for
running useradm, newusers, backup, etc.  The configuration for this
utility is found under /usr/lib/tycho/admin.conf.

USERADM

A general purpose pick-list driven program for editing/removing users, adding
users to/removing users from groups, updating passwords, etc.  Generally,
everything one normally edits /etc/passwd, etc/group, and /etc/shadow by
hand or, if lucky, from shell commands and scripts.

useradm will now automatically detect if you use shadow passwords or not,
and is controlled by /usr/lib/tycho/users.conf.

NEWUSERS

Generally identical to useradm (linked).  The difference is that only user
accounts that login as the selected 'guest' group are shown.  The concept
here is that new user accounts are formed under the 'guest' gid, and can
then be easily found and reviewed under 'newusers'.  If set to another
group (such as a default 'user' gid), then they are validated.  If undesired,
they can be removed.  This simplifies finding these new accounts from 
what can be a large list of users.

LINEMON

The line monitor shows you the current real-time status of your modem lines,
who is using them, and 'how' they are currently being used, in both dial-in
and dial-out situations.  The devices linemon will watch are listed in
/usr/lib/tycho/lines.conf.

LOGS

Logs allows viewing of log files that are current or that have been archived
by auto-event.  Logs uses the 'logs' section of autoevent.conf.

EDITOR

The Admin editor will show files which require full screen editing in a full
screen window.  There are many VU text files that are presented within a
64 x 16 popup window, however, and the VU editor will open these text files
in a similarly sized editing window to make it easier to format these files
correctly.

BACKUP

The tape backup system allow the definition of a preset 'group' of tape
backups which may then be picked from a pick list.  Various support modules
(such as ftape.o) can be set to auto-load when you enter backup and auto-
unload when you exit.  The program is controlled by backup.conf.

Backup does not perform scheduling or directly allow restoring of backup
tapes.  Those operations should be performed by the actual system admin.
Backup, when used in conjunction with admin, simply allows a lower-level
staff person to perform routine backups in a controlled fashion.

PACKAGE

Package is now the standard installation tool for all Tycho Softworks
products under Linux.  You will use package to install future updates for
VU BBS and other Tycho Softworks products.

PURGE_USERS

This is a special daemon that can be ran daily or weekly through cron.  This
daemon will purge (remove) specified users who have been inactive x number
of days automatically for you.  Different login groups (gid's) can have
different purge settings.

DOORWAY
-------

Why, in a world crowded with getty programs, do we have yet another one?
To answer that question right off, let me say that doorway attempts to
destinguish itself in the following needs:

1) Multiple configurations

   This means, doorway can answer in different ways, and support very 
   different modems on different ports.  I recall that, mgetty in
   particular, has most of it's modem configuration either compiled in
   or set once globally, and that much of it's behavior is predefined
   at compile time.  Doorway let's you do all sorts of unusual things
   on different lines at runtime.

2) Polling

   Doorway provides polling for different connection types.  This allows
   polling for different terminal types at connection.  In addition,
   mailer requests, such as uucp, and pppd selection, can be performed
   through doorway.  Doorway can run multiple login programs and initiate
   network protocol sessions on demand in a fully configurable way, and
   do so in different ways on different sets of ports.

In addition, doorway supports uucp port locking to co-exist with dial-in and
dial-out apps as one would expect from a modern getty program.  In addition,
modem collects the actual connection speed and stores it into an env
variable, 'BAUD'.  VU applications use BAUD to determine how to scale
back visual features for low speed users on baud-locked modems.

Doorway also prefers to run modems in non-autoanswer mode.  This allows
better modem control (such as collecting baud rate).  Our preferred
means of operation is in 'long' connect message mode, whereby your modem
would sent something like:

CARRIER xxxxxx              (example)  CARRIER 14400
PROTOCOL xxxxx                         PROTOCOL MNP
CONNECT xxxxxx                         CONNECT 38400

This seems to be a &W1 or &W2 setting on many modems.  If this is not
possible, the next choice is a setting that returns 'DTE' speed in the
connect string.  In all cases, we are interested in determining the
'effective' speed of the remote user, and NOT the baud rate locked port
speed.

Providing 'manual' answer offers several other benifits.  Several 'broken'
modems (such as early PCP modems) would not raise DCD until AFTER they
sent the connect message, and it would be lost.  Also, if your system goes
down, you do not have the modem picking up a dead caller.


What doorway does NOT do is several 'legacy' operations found in most
getty programs.  This includes prompting for a user's login and then
attempting to figure out parity and upper/lower case based on what the
user enters.  Since virtually all modern BBS callers use 8/n/1 and have
lower case, this legacy behavior is not supported by doorway.  Furthermore,
this allows doorway to run a visual login program directly after user
connect.

While doorway is intended to be used with VU BBS, it can act as a stable
front-end getty-like program for virtually any remote connection support.

Doorway is actually broken down into two seperate programs; modem and
doorway.  Modem is the actuall getty agent, and performs all modem related
control operations.  Once a connection is established, doorway is called
to provide polling services.  The modem program will eventually be augmented
to support FAX and other 'modem' related services.  Modem can be replaced
with programs such as mgetty, which can then invoke doorway, if the
login prompt can be suppressed and alternate login programs ran.

Typically, modem is ran from init.  A typical inittab entry might look
as follows:

     # what if we have a hayes on two lines for low speed callers?
	S1:???:respawn:/usr/sbin/modem hayes-2400 /usr/sbin/doorway lowspeed
    S2:???:respawn:/usr/sbin/modem hayes-2400 /usr/sbin/doorway lowspeed

     # we have a dedicated pppd link number!
    S3:???:respawn:/usr/sbin/modem usr-28800 /usr/sbin/pppd

     # our multiplexed mail/net/everything lines!  Last rollover old modem
    S4:???:respawn:/usr/sbin/modem intel-28800 /usr/sbin/doorway
    S5:???:respawn:/usr/sbin/modem usr-28800 /usr/sbin/doorway 
    S6:???:respawn:/usr/sbin/modem intel-14400 /usr/sbin/doorway

The modem definitions are kept in a config file called /etc/modem.conf.
Entries are provided for a Intel-144e and Infotel-1428vqe, since those are
what I currently have!  Condolences accepted.  Additional entries can be
defined and used very easily.  Please review modem.conf.  I have included
part of my actual inittab below:

# Getties for the normal runlevels.
# BEWARE of the tty names here!
c1:2345:respawn:/usr/bin/hello console tty1

S2:234:respawn:/usr/sbin/modem ttyS2 infotel-1428vqe /usr/sbin/doorway
S3:234:respawn:/usr/sbin/modem ttyS3 intel-144 /usr/sbin/doorway

If doorway is given no option, it uses the '[default]' configuration in
doorway.conf.  Different options for different behaviors can be identified
by name, assuming a [section] appears in doorway.conf for them, hence
the first example with 'doorway lowspeed'.  Please review doorway.conf for
additional details.

I have included some termcaps and tics we use which are not normally
found in Linux distributions.  We have come up with our own 'generic'
ansipc to cover ANSI emulations as represented by most PC telecomm
programs as best as we can.  VU applications provide additional support for
scan-code 'doorway' mode programs as well.

In addition, modem is cross-linked to 'setmodem'.  This is used to set
NOVRAM paramaters for the modem from the modem.conf file to the values
modem is expecting, as defined by the entry.  This is useful when setting
up a new modem for the first time to run with 'modem'.

Just use setmodem /dev/ttyS? name, as in setmodem /dev/ttyS3 intel-144.

NOTE: Since doorway uses manual answer mode, doorway will keep your
/dev/ttySx device open at all times.  This means that /dev/cuaxx will
be inaccessable.  To use uucp or ppp outgoing with doorway, these programs
should be setup to use /dev/ttySx, and NOT /dev/cuaxx.

DSCAN
-----

DSCAN provides a visually oriented browse list of a directory from which you 
can tag and download files.  Subdirectories can also be opened and accessed.  
In fact, like all VU utilities, seeing is often sufficient for understanding.

dscan uses your existing rz/sz commands (or alternate programs of your
choice) to perform actual file transfers.  The dscan.conf has definitions
for invoking these utilities.  You should make sure any new protocol you
add to dscan.conf is also referenced in /usr/lib/user-setup/setup.conf.

The key to dscan is in the setup of the config files, especially since dscan
makes use of setuid() where nessisary.  dscan can be used to provide access
to common public areas (such as ftp or uucppublic directories) as well as
to private file areas which normally do not have files or directories with
public read permission.  dscan can select or deny access to specific
individuals and groups of users, and can also provide for restricted access.

You would normally invoke dscan from a shell or menu program, with an
argument provided to select the file 'area' you will try to access and
work in.  If no area is specified, dscan uses the '[default-area]' area
definition found in dscan.conf.  Other areas can be referenced by name
and are defined in dscan.conf.  Several sample dscan.conf sample setups are 
provided to give some idea of how this works.  Please review them carefully.

A special area can be defined that is called '[home-area]'.  If a 'home'
area is defined and dscan is invoked as 'dscan home', then the user will
be taken to his or her own personal home directory and will see the files
found there through dscan.  This allows users to upload and download from
a personal file area.

For public file areas, dscan will revert to the user's original uid() and
gid() permissions after opening the log files.  In private areas, it is
often nessisary to 'promote' the user to the gid() needed to access the
otherwise isolated area.  dscan can do this automatically.  The shell=f
option can be used to prevent 'promoted' users from having 'fun' with
thier new gid() and the private file area(s).

SPECIAL FILES

Special files are placed on each directory and subdirectory, where
appropriate and needed, for the file transfer area(s) you specify.

.index

If a .index file is found on any given directory, then the information it
contains can be used to show file 'abstracts'.  In certain situations, the
one line 'descriptive' header may also be shown in place of the filename.

A typical .index file may appear as follows:

dscan_b1.tar.gz:	VU BBS File Transfer System
	This is the first beta release of the VU BBS visual directory
    scan utility.

Notice that the filename has a trailing ':', and each line of the summary
is indented.  A blank line must sperate each entry in .index.

.message

If a .message text file is found on a newly entered directory, it is splashed
to the user's screen in a window.

.fn83

This little gem is used to allow 'mapping' of long filenames to MS-DOS style
8.3 format.  It is a sub-directory off each directory, and, at preset,
requires public write permission.  If you have setup a private file area
with a unique group id, then chmod 770 will be sufficient and will keep those
nosy shell users out.

Whenever a file request is made with truncation enabled, a link is made to
the '8.3' truncated filename in .fn83.  If the directory is missing, then
no harm will be done, other than the fact that long file names cannot be
truncated for MS-DOS users.

A check is made to assure the inode in the .fn83 is really linked to the
same inode as the original file in the base directory. 

A table of extensions and 'hints' for 8.3 filename subsitutions can be
found in dscan.conf.

FILES.BBS

DSCAN will also recognize and use the 'files.bbs' index file found on many
CD-ROM software archives.

LUNA GATEWAY MAIL
-----------------

VU BBS uses a new front-end visually oriented (client) mail system, known as
LGM (or Luna Gateway Mail).  It promises to be easier to use than similar
programs such as 'elm', and a lot more fun (visually).

LGM can act as a mail agent with either standard or MMDF style mail
spool files.  LGM supports elm style mailbox lock files and works best
when used in conjunction with a local mail delivery program that does
the same under smail or sendmail, such as 'deliver'.  LGM does not yet
support MIME, but future versions will.

There are unique features in lgm, such as the ability to download email.
Other features that are present include the ability to address e-mail
through browse lists.  Browse lists include 'white' and 'yellow' pages. 
The 'white pages', which is built by the mkwpages daemon, is a listing of
all active 'user' accounts who have chosen to allow their address to be
published in the setup_mail utility.  The 'yellow' pages is a generic
system-wide alias file for anything appropriate.  A 'personal' alias file
with a pull-down list is not yet supported.

The mail_setup utility is ran by individual users to specify the behavior
they want for lgm.  This information is kept in a file called $HOME/.setup
and may also be edited by hand.  Mail_setup runs as a component of
our generic 'user setup' system.  Please uncomment the mail_setup line of
/usr/lib/user-setup/setup.conf if you already have the setup module.
The yellow pages pull-down can be used to store aliases and other non-
user specific mailboxes.  This file is built by hand.

A special daemon, mkwpages, builds the white pages browse list.
The mkwpages deamon should be ran in crontab.  Run it once to build an
initial wpages file after installation.  Make sure at least one account
has ran setup_mail or user setup first.

Mkwpages builds the white pages from those user accounts listed in
/etc/passwd that also have a .setup in their home directory.  Users who
decide to have an unpublished mailbox through setup_mail will be ignored.

Another unique feature of lgm is auto-address conversion.  Lgm recognizes
and converts Compuserve email addresses to internet passable format.  LGM
does the same for 'fido' mail addresses.  For example, if a user specifies
'John smith @ 117/31', lgm will correctly convert this to an internet
form of address.  Fido domains can also be specified, such as
'joe wayne @alternet:113/33' or 'jay day @ 17:32/33'.  

HELLO
-----

This segment covers login and logout, the two most common activities on any
BBS.  This activity is controlled by two programs; hello and goodbye.

HELLO

After giving consideration to the fact that network users can often bypass
login, such as anon ftp, or telneting into a mud, we decided, why should
dial-in users be left at a disadvantage.  As a result, the visual login
program, hello, can be setup with a 'menu' that appears after connect and
before actual user login.  This also is a convient place to let users
leave feedback if they are completely lost.  However, you do not need to
use a menu if you do not wish to; simply comment out or remove the relevant 
section of hello.conf.

As stated, hello is the visual front-end login for VU BBS.  This program
is normally invoked in response to a dial-in user or a telnet connection.  
It provides a friendly login environment.  Hello can also be invoked as
the 'default' login for your console sessions.  Simply add an inittab
entry such as:  c1:????:respawn:/usr/bin/hello console	in place of the
getty's normally used for the console.  The hello 'console' option gives
you the ability to shutdown your system with a single CTRL-D very quickly.
See hello.conf for details.

If you want to see what your users will get after connection through
doorway, simply type 'exec hello' at your login shell.  This will give
you an idea if any changes you make are working correctly.

GOODBYE

This program generally sequences a series of one or more windows on the
users screen for 'logoff' messages.  It is normally called by menu.  This
provides an opertunity to put signoff messages.

MENU SHELL
----------

This set of programs comprise the 'core' modules of the VU BBS menu
interface.  The menu interface is a generic menu 'shell' program that is 
supported by a very simple external text file browser.  The two will
eventually be merged into a single hyper-text browsing & menuing tool, but
not at this release level...

BROWSE

Browse is a very simple text file viewer at present.  It can handle
text files with embedded tabs or control characters.  It is often used in
an auxillory role to present live doc files to users when called by either
hello or menu.  It is also used to present the 'message of the day' for
hello.

Browse is invoked with a 'file id'.  Browse can also be linked, as in
'browse-target' and then ran through the alias.  This file id matches an entry
found in the browse.conf file (normally found in /usr/lib/browse).  The
entry in browse.conf tells browse the real name of the file to display,
as well as display properties to use.

MENU

Menu can act as a utility and as a login shell.  When used as a login
shell, it cannot process a 'profile' script, but it can set initial
values in the user's environment space (such as PATH, EDITOR, etc).
Menu presents menu choices based on entries found in menu.conf.  Menu
will normally begin operation under the 'root' menu tree (not to be
confused with either 'root' userid or 'root' permissions).  

If a 'restricted' entry is specified, and the user has logged in with his
login gid matching the restricted group, then menu will display a file
name matching the name of the group from /usr/lib/newuser, and select
a menu tree under the id of the group.  Our BBS does this with newly
added 'guest' users, though you can change this behavior any way you like.

Non-restricted menus can be cascaded to other sub-menus.  The choices
shown in various menus depend entirely on a permission field.  This
permission can be set to '*' to allow anyone to see the menu, to
'userid', to only allow a specific userid to see it, or to @group.
If @group is used then, if the user is either shown as a member of
'group' in /etc/group, or if the user's real gid matches the group,
the user will be given that menu choice.

In addition to chaining submenus, menu choices, when selected, can
run external programs or set 'macros'.  The latter is used to build
menu entries for 'who' and paging the sysop.  Menu can also display
text files without the use of browse.  See menu.conf for more info.  

Menu also supports a special 'bookmark' menu.  The bookmark allows
each user to form a personal quick access (short-cut) menu to their
favorite locations within the BBS.  Various modules, such as dscan,
support bookmarking in this way.

FEEDBACK

Feedback is an editor and wrapper for sending mail to a specific feedback
target mail account.  This is used by a number of programs.  Different
'targets' for feedback can be specified by multiple entries in
feedback.conf.  This can be done by either entering 'feedback targetid'
or by aliasing feedback as 'feedback-targetid'.  The latter is used
to support feedback from hello, which normally doesn't support multiple
command arguments.

Several VU BBS modules can be setup to invoke feedback when access has
been denied to an area.  This allows the user to immediately write to
someone who could 'rectify' this situation without first having to back
out to mail, and then figure out who one should send mail to.  For example,
if you have someone who moderates 'file areas' under dscan, non permitted
users can be directed to send mail to that person through proper use of
feedback, instead of irritating root.

NEWUSER

We have also included the newuser program.  This program guides new
users through the difficult path of constructing a new user account.  It
can form a userid for them and even genorate a password for them.  The
newuser program saves address information in ~/.setup so that it may be
reviewed under useradm and newusers.

The newuser program uses several text files that are found in /usr/lib/
newuser.  Examples are provided from Marvin BBS.  The first file is
named 'welcome', and is shown when the user initially enters the
newuser program.  The second file is 'newact', and is presented to the
user after completing new user registration.  Generally, the latter
should instruct the user what to do now that they have a userid to
login with.

Newuser uses values found in users.conf (see admin-b1) to create a new
account.  Generally, we assume new user accounts are created with menu
as the login shell and a home directory in /home.  A unique uid is
assigned based on the range of values specified in users.conf, and the
users gid is normally assigned to the 'guest' group, at least on my
BBS.

Newuser logs new user accounts in logpath/newuser.  logpath is specified
in users.conf (see admin-b1).

MISC.
-----

COLORS

Colors will allow you to create custom colorset tables.  If you do not like
the default color scheme in VU, you can change it, and users can select
which one they wish to use from the user setup utility.  With a little work,
you too can create an eyesore!

Colors is invoked with the pathmame of a new color table to use.  The
colorsets can be placed anywhere, such as 'colors /etc/VUhomecolors', etc.

A word about colors in view is probably in order.  VU defines a set of 64
colors that are mixed and matched on the screen.  Of those colors, most
are collected into 'sets of 8' and associated with a specific class of
window images in VU.  It would be wise to expairement a lot before
committing to any scheme.

Now, let's say you have created a new colorset and wish to allow your
users to select it.  How do you modify /usr/lib/user-setup/setup.conf
to be aware of it?  Well, unfortunately, with the B1 release of setup,
you cannot.  You can set VU_COLORSET in the environment to point to the
path/filename of your newly created table and have it as the system-wide
default, however.

Color files are normally collected together in /usr/lib/colorsets.  This
is the location used by 'display setup' in user setup to select colors.

TERMLIB

Termlib has a hash-indexed database for quick lookup of terminal
properties.  The terminal properties I chose to store in termlib were those
that interested me in the construction of standard VU applications.  The
easiest approach would be to examine an existing entry and see if it can be
modified for your specific need.  The use Insert to build it.

VUaliases is used to map between $TERM names and termlib names for
terminals in case they differ.  Since termlib looks at a smaller and less
complex subset of properties than does termcap or terminfo, you can usually
map multiple termcap/terminfo entries to a single termlib entry and save
on work.

Most VU BBS apps tend to assume you have at least a 78 x 20 character
screen.  You can certainly define entries for systems with more than 80
characters, but going much smaller may cause undersirable consequences.

USER-SETUP
----------

A unique component now found in VU BBS system is a standardized visual
user utility program called 'setup'.  'Setup' is used to collect utilities
which perform preference settings for each individual user under a single
menu system.  The setup program then farms it's work out to these seperate
utilities.

Setup and it's related modules manage common information stored in ~/.setup
for each user.  This holds information such as the way e-mail will be ordered
in e-mail programs, the users file transfer protocol of choice, etc.  The
one option related to system administration found in setup is the ability
to set contact information and address.  This allows the administrator, from
the useradm utility, to get address and phone numbers.

QUOTAS
------

Daily time quotas are iplimented in VU BBS.  Daily time quotas can be
assigned either to a specific user group (gid) or specific user id (uid).
The assignment of quotas is handled in /usr/lib/tycho/usage.conf, and
their enforcement is left to a special VU BBS deamon utility; usaged.

Usaged is capable of monitoring daily usage and will send a warning to
a user a few minutes before his time is up for the day.  If the user is
still found, usaged will knock the user off the system after his time is
used up.

Both hello and dscan are also 'quota aware', in that dscan will not allow
you to select more files for downloading than you have time left for the
day, and hello will not let you back on that day if your time has expired.

You can examine daily time use by user id through the files kept by usaged
in /usr/spool/usage.  These are text files, and old logs are automatically
purged by usaged.  Sufficient info is present to note who was on during
each given day and how much time they used.

The 'totaluse' utility will total up daily usage for each day and give
you an idea of how busy your system has been.  Timecheck may be used to
see how much time a given user id has left for the current day.  We will
later add an ability for the sysop to grant or remove time from the daily
quota.

NEWS
----

VU BBS provides a news program, called 'news'.  This news agent is a
visually oriented news reader.  It can operate in conjunction with your
systems existing news services (such as c-news or inn).  In addition,
VU BBS supplies it's own set of news utilities to impliment a small-scale
news system if you do not already have one setup.

The VU BBS news system operates a little like c-news, though it uses two
utilities, get_news and put_news, to send and receive articles at pre-
scheduled times to/from nntp servers on the internet.  If you have a
part-time internet connection, get_news and put_news can be used in
conjunction with ipdemand to nail-up a connection, grab some news, and
then knock it back down, all at pre-scheduled intervals.

No facility is provided to allow the VU BBS news system to feed other
news sites.  If this is important, than we recommend installing c-news or
inn instead.  All configuration info for news is found in news.conf.

The following utilities comprise the VU BBS 'mini' news system:

GET_NEWS and PUT_NEWS

These are used to retreive and post articles through nntp servers.  A special
file, /usr/lib/news/xxx?, is kept for each news server you use.  This tracks
the last read message number from that server.

ADD_NEWSGRP, ADD_PVTGRP, DEL_NEWSGRP

These allow you to quickly add and delete newsgroups from your local news
database.  You may still need to add routing information in news.conf and
modify the last-read server file if this is a non-local newsgroup.

Add_newsgrp and add_pvtgrp differ in that add_pvtgrp does not set public
read permissions for the newsgroup spool directory.  This will keep out
pesky shell users.  The VU news program can be configured to restrict access
from certain newsgroups.

Add_newsgrp uses three arguments; the inet name of the newsgroup (such as
alt.os.linux), the 'flag' mode, and the 'real name', "Alt os Linux", that
you may wish to show users.  This updates various /usr/lib/news files.

Valid modes include:

y		a read/write access newsgroup
n		a read/only newsgroup
m		a moderated newsgroup (postings only put to batch for put_news)
l		a local newsgroup (never post to batch)

POST_NEWS and RELAY_NEWS

Relay_news is used to insert news articles from get_news into the local
news database.  Post_news will do the same for locally originating articles.
Together, these two utilities serve the same purpose as 'inews' in c-news and
inn.

PURGE_NEWS

This is similar to c-news 'expire'.  News and tracking data can be purged
after x days.  Different newsgroups can have different purge settings.  This
allows disk space management.  See news.conf for details.

MS-DOS DOOR PROGRAMS
--------------------

VU BBS can be used to run many standard MS-DOS BBS door programs which use
'door.sys' dropfiles with the help of dosemu and the VU BBS dos door module!
All my doors are under /shared/doors, as in /shared/doors/gwar, etc.  This
matches the linuxfs path and batch file paths used in doscdrv stuff.

/etc/dosemu.bbs has the 'bbs door' default dosemu settings.  In addition,
each 'door' application can have it's own .dosemu to override this, as in
/shared/doors/gwar/.dosemu, etc, as needed.

Generally, dosemu is set to minimize real-mode memory and run in 80286 mode
without himem, dpmi, etc, whenever possible.  This reduces potential 
conflicts.

An /etc/group entry for 'door' must be added.  All door app directories 
should have chmod 770, with the gid set to 'door'.  This keeps nosy
shell users out of the door files!  dosemu itself runs with root
permissions, incidently.

The utility dosusers can be ran from a crontab.  It basically creates 
/etc/dosemu.users based on groups given permission to run dosdoors.
For example, run 'dosemu user door', to get an /etc/dosemu.users list
of all users who are either member of group user, group door, or have
a matching login gid.  This is used to control access and give it only
to those users you wish to have door access.

dosdoor is the utility to run from menu.  Just use the dosdoors.conf
section id, as in dosdoor gwar, for example.

If all works well, you too can run MS-DOS doors under VUBBS in Linux!


Assuming you have Global War in /shared/doors/gwar:

in /usr/lib/tycho/dosdoors.conf, we would have an entry for gwar
much like this:

[gwar]
path=/shared/doors/gwar
doorsys=t
group=door
truename=t
logpath=/var/log/users

in /shared/doors/gwar/.dosemu, we may typically have:

dosbanner on
timint on
keyboard {  layout us  keybint on  rawkeyboard on  }
HogThreshold 10000
ipxsupport on
terminal { charset ibm  color on  method fast }
X { updatefreq 8 updatelines 25 title "DOS in a BOX" icon_name "xdos" }
allowvideoportaccess on
mathco on           # Math coprocessor valid values:  on  off
cpu 80286           # CPU emulation valid values:  80286  80386  80486
bootC               # Startup drive valid values:  bootA  bootC
xms off            # XMS size in K,  or "off"
ems off            # EMS size in K,  or "off"
dosmem 320		   # why waste 640k if we don't need it!
dpmi off            # DPMI size in K, or "off"  Be careful with DPMI!
sillyint off    # this disables IRQ monitoring
speaker off        # or "off" or "emulated"
disk { image "/var/lib/dosemu/hdimage" }    # use diskimage file.
EmuSys BBS
EmuBat BBS
floppy { device /dev/fd0 threeinch }  

in config.bbs, we have:

break off
lastdrive = d
buffers = 5
device=emufs.sys /shared/doors  (prefix of all our doors in linux)
device=ansi.sys

in autoexec.bbs on the dosemu boot drive, we have:

@break off
@echo off
path c:\
unix -E DOORWAY
exitemu

in 'gwar.bat', called by '$DOORWAY', we have:

@break off
@echo off
d:
cd gwar
set comspec=c:\exitemu.com
war /d door.sys
c:
exitemu

AUTOEVENT
---------

The autoevent system allows you to automate several system services.
These include the ability to deliver flash messages to users and the
automatic maintenance of system log files.






















