NOTABLE: If =1, use statements to structure display.
If not specified (or if =0), a TABLE will be used.
Example: BBS?DIR=SpotDog/Files¬able=1
NOICONS: If=1, then do NOT insert small descriptive icons next to file names.
(default is to include these icons).
Example: BBS?DIR=SpotDog/Files&noicons=1
NODIR: If =1, then do NOT display parent and child subdirectories.
Example: BBS?DIR=SpotDog/Files&nodir=1
NOTIME: If =1, then do NOT dispay creation time
Example: BBS?DIR=SpotDog/Files¬ime=1
NODATE: If =1, then do NOT display date (or time)
Example: BBS?DIR=SpotDog/Files&nodate=1
NODESC: If =1, then do NOT display a description.
Example: BBS?DIR=SpotDog/Files&nodesc=1
NOSIZE: If =1, the do NOT display file size
Example: BBS?DIR=SpotDog/Files&nosize=1
NOCACHE: If =1, then suppress the use of caching.
That is, force the generation of a listing, rather then using a
cached listing.
Example: BBS?DIR=SpotDog/Files&nocache=1
ROOTDIR: If =1, then this request is treated as the "root" of a tree.
The user can go to subdirectories, but not to the parent. Note
the user is allowed to go backwards after going to one of the child
subdirectories (there is no suppression of "parent directory" links
of child subdirectories).
SHORT: If =1, then a very short form of display is used
(no icons, no time, no date, no description).
Example: BBS?DIR=SpotDog/Files&short=1
SIZEFMT: If =ABBREV, use nnnK or nM. If not, use 12,345 format.
Example: BBS?DIR=SpotDog/Files&sizefmt=ABBREV
SORTBY: Sort by NAME, EXT, SIZE, or DATE; or NOSORT.
Default is NAME.
Example: BBS?DIR=SpotDog/Files&sortby=NAME
Example: BBS?DIR=SpotDog/Files&sortby=DATE
TIMEFMT: If =24, use 15:03 format. If not, use 3:03p format.
Example: BBS?DIR=SpotDog/Files&timefmt=24
USE_WINDOW: Display files in a viewer window
Example: USE_WINDOW=1
If 1, then BBS will display files in a "viewer window" (using
target="viewer" attributes in HREF elemenets).
If 0, files will be displayed in the same window as the file listing
(will over write in standard HTML fashion).
Note that the DEF_USE_WINDOW parameter is used as the default value
of USE_WINDOW.
ZIPFILE: A .ZIP archive to "open and display".
Example:
Display contents of GIFS.ZIP:
BBS?dir=foo1/wow&zipfile=GIFS.ZIP
This option is typically generated by BBS when it creates
directory listings.
=======================================================================
IX) Description of BBS initialization parameters.
These description are in more or less alphabetical order. You can modify them
by editing (with your favorite text editor) the BBS.INI file. Or, you can use
the BBS configurator -- just point your browser at:
http://your.server/bbsconfg?
Note: there a few parameters in BBS.CMD you might want to "change by hand".
In particular, the TRCOLORS. parameters can be used to use alternating
background colors in the rows of tables.
List of BBS.INI parameters --------------
The following lists the various parameters set in BBS.INI
Parameter Name Description
ADMIN_EMAIL E-mail address of BBS adminstrator
AUTO_DESCRIBE Enable "auto description" of files.
BBS_PARAM_DIR Location of BBS support files
BYTES_NEWUSER Bytes "credited" to new users
FILES_NEWUSER Files "credited" to new users
BBS_SMTP_GATEWAY The SMTP gateway to use for optional mail messages
BBSCACHE_DIR Location of BBS "cache" files
CACHE_FILES Maximum number of files to store in BBSCACHE_DIR
CACHE_DURATION Lifespan of a BBS cache file
CACHE_CHECK Check filestamp of cache file before use
CELL_SPACING Space between table cell border and contents, in pixels
CHECK_DIR_ACCESS Suppress display of inaccessible directories
CONTINUATION_FLAG The continuation flag used in multi-line descriptions.
DEF_BIN_TEXT_LINKS The default "bin_text_links".
DEF_BIN_TEXT_MOUSEOVER The default "include mouseover javascript in bin_text_links".
DEF_USE_WINDOW Display files in a seperate window
DEFAULT_DESCRIPTION Used when no description is available
DEFAULT_DESCRIPTION_DIR Used when no description is available for a directory.
DEFAULT_DATEFMT Default format for displaying date information
DEFAULT_RATIO Default file downloads/file uploads ratio
DEFAULT_BYTE_RATIO Default byte downloads/file uploads ratio
DESCRIPTION_FILE Name of file(s) that contains descriptions.
DEFAULT_SORT_TYPE The default sort type.
DESCRIPTION_TEXT Descriptions displayed as HTML, or as text
DESCRIPTION_TEXT_LENGTH Control line length of text descriptions.
DESCRIPTION_TEXT_LENGTH_1LINE Controls format of 1-line descriptions
EXCLUSION_FILE Name of file(s) contains file exclusion information.
FILE_DIR Fully qualified name of the (default) root of the BBS.
GET_Z_ZIP_DESCRIPTION Extract -z description from .ZIP files
HEADER_FILE Name of file(s) containing header (displayed to client)
FOOTER_FILE Name of file(s) containing footer (displayed to client)
HEADER_TEXT Display header as HTML or as text
FOOTER_TEXT Display footer as HTML or as text
ICONS.1 .. List of custom icons for specific files/directories.
ICONS.N
IMAGEPATH Location of .GIF files
INCOMING_DIR Default location to store uploaded files
INCLUSION_MODE_FILE Name of "inclusion mode" file
MUST_WAIT Number of days "too many downloads" clients must wait
OWN_NAME_PRIVILEGE Add a !username to client's privilege list.
OWN_UPLOAD_DIRECTORY Default "root" of own upload directory (used by BBSNEWU)
OWN_DOWNLOAD_DIRECTORY Default "root" of own download directory (" " " )
OWN_FLAG Default "prefix" for own download directory (" " " )
PRIV_RATIO.!name1 List of "privilege specfic" upload/download ratios.
PRIV_RATIO.!nameN
PRIV_WEIGHT.!name1 List of "privilege specfic" download weights.
PRIV_WEIGNT.!nameN
SEND_ALERT Send an e-mail alert (via BBS_SMTP_GATEWAY) to ADMIN_EMAIL.
TABLE_BORDER Width of table border (or 0 for no border)
TR_COLOR Enable use of colors in table
UPLOAD_MAXSIZE Maximum size, in kbytes, of uploadable files.
UPLOAD_MINFREE Minimum disk space free, in kbytes, after upload.
UPLOAD_QUICK_CHECK Check upload directory for matching name before uploading.
USE_COOKIES Use "cookies" to send username/pwd information.
USERLOG_DIR Directory containing user logs (username,password,history,etc)
USE_SERVERNAME Colloquial name of your server
WRITE_DETAILS Write details to the user log files
ZIP_HEADER_FILE Header file(s) to use in ZIP expansions
ZIP_DESCRIPTOR_FILE Alternate for FILE_ID.DIZ file
Detailed Descriptions ---- (in more or less alphabetical order) -------------
ADMIN_EMAIL
The e-mail address of the BBS administrator. Used when SRE-http sends
e-mail alerts (as when a successful upload occurs).
Example: ADMIN_EMAIL='admin@foo.bar.net'
AUTO_DESCRIBE
Controls whether BBS should attempt to create an "automatic description" for
files that do not have a explicit description.
If =0, auto describe is NOT attempted.
If >0, then auto describe is attempted.
Auto describe constructs a description from:
* and <META EQUIV NAME="CONTENTS"> headers in HTML files
* -z comments, or FILE_ID.DIZ files in .ZIP files
* The first several hundred bytes in text files
For other types of files, automatic descriptions are NOT created.
Notes:
* The value of auto_describe controls the maximum length of
the description.
Examples: AUTO_DESCRIBE=200
-- a max 200 character description is created
AUTO_DESCRIBE=0
-- no automatic description is attempted
* If AUTO_DESCRIBE=1 is used, then a max 120 character description is
generated.
* The description can be broken into seperate lines, using the
DESCRIPTION_TEXT_LENGTH variable (or using a value of 30, if
DESCRIPTION_TEXT_LENGTH=0) -- see DESCRIPTION_TEXT for
details.
BBS_PARAM_DIR
Directory containing BBS control, etc. files. If a relative directory is
entered, it is assumed to be relative to the GoServe working directory
Example: bbs_param_dir='BBSDATA'
If the GoServe working directory is E:\GOSERVE, the above example
refers to E:\GOSERVE\BBSDATA.
Notes: bbs_param_dir\bbs.ctl contains the "access control" and "directory
privileges" information.
bbs_param_dir\bbs.cnt contains counts (by file) of downloads
bbs_param_dir\upload.log contains record of all uploads
BYTES_NEWUSER and FILES_NEWUSER
Bytes and file "downloads" granted to new users. This lets them
have a first shot at the system.
Examples:
bytes_newuser=10000
files_newuser=1
BBS_SMTP_GATEWAY
The valid IP address of an SMTP Gateway. This is used if you want
to send e-mail alerts to the WEB_ADMIN address (see below) when succesful
file uploads occur.
Example: BBS_SMTP_GATEWAY='MAIL.OURSITE.NET'
Note: this is NOT necessarily the same as the the SRE-http SMTP_GATEWAY
variable -- though it can be the same.
BBSCACHE_DIR
The directory to store the BBS cache files. THIS SHOULD BE A DEDICATED
DIRECTORY -- since it will fill up with files, and since BBS occasionally
clears it out. If a relative directory is given (not starting with a drive
letter or a /), it is assumed to be relative to the BBS_PARAM_DIR directory.
Example: BBSCACHE_DIR='BBSCACHE'
CACHE_FILES
The size of the BBS cache, in files. After this number of files have been
stored (with each file representing a unique request string), BBS will
delete the oldest files.
Example: Cache_files=100
Note: to suppress caching, set CACHE_FILES=0
CACHE_DURATION
This is the number of days (fractional days are allowed) that a BBS cache
will be valid for. Thus, if a cached "request" is more then CACHE_DURATION
days old, it will not be used (in fact, it will be replaced).
Example: cache_duration=0.5
Note: a tiny (say 0.000001) cache duration is equivalent to a
CACHE_FILES value of 0.
CACHE_CHECK
Before using a cache entry, BBS can perform a simple check for any file
modifications (either to the files in a directory, or to the .ZIP file
chosen for expansion). If modifications are detected, the cache is not used
(in fact, it will be replaced).
To enable this check, set CACHE_CHECK=1.
Example: cache_check=1
Notes:
* BBS uses a simple CRC on file dates. This should find most, but not
NOT all changes. For example, changes in "generic" FOOTER and HEADER
files will not be detected.
* Use of CACHE_CHECK will slow throughput down somewhat. You may want
to consider using the BBSCACHE daemon instead.
* The Toronto Virtual File System (TVFS) has a bug which may impact the
use of CACHE_CHECK (the effect of this bug is to cause BBS to over-
refresh the cache, leading to slower throughput).
If you are running TVFS, you might want to set CACHE_CHECK=0.
CELL_SPACING
Space between cell border and cell content (in a table), in pixels.
Set to 0 for "no extra spacing". This is useful as an alternative
to the TABLE_BORDER option (helps visually offset rows of the table).
Example: cell_spacing=2
CHECK_DIR_ACCESS
If set to 1, then BBS will NOT display directories that a client can not access.
That is, in the listing of directories, directories for which a client does not
have privileges (as determined by BBS.CTL and the clients privileges) will
not be dipslayed.
Set to 0, and they will be displayed, but the client will not be able to access them.
Caution: CHECK_DIR_ACCESS sometimes does not work when caching is on (BBS tries
to suppress caching when there might be suppressed directories, but
cases can occur where a cached listing, containing suppressed files,
will occur).
If you notice problems, you might want to suppress caching.
Example:
CHECK_DIR_ACCESS=1
CONTINUATION_FLAG
Continuation flag is a character string used to indicate a "continuation"
line in the description_file.
Example: continuation_flag=','
Another popular example is ' |' (space followed by a |).
Note: if your continuation flag starts with a space, and has a non-space
second character, then BBS will match the "first space in the
continuation_flag" to an arbitrary number (>0) of spaces in the
description file. For example, if continuation_flag=' |',
it WILL match
| first line of description
| second line
| third line
However, it will NOT match
| bad line.
(note that in this example, the | is the first character in the line)
For this case, you MUST set the continuation flag ='|'. However,
if continuation_flag='|', the prior 3 examples will NOT be matched.
Notes
* The SRCHINDX add-on also can read these "multi-line description
files" (that is, it understands continuation flags)
If you intend to "share" description files between BBS and SRCHINDX,
please note that SRCHINDX is not as sophisticated as BBS:
it treats any line, whose first non-space character is equal to
the stripped-of-spaces continuation flag, as a "continuation line".
* If you are using INCLUSION_MODE_FILEs, the CONTINUATION_FLAG must start
with a space.
DEF_BIN_TEXT_LINKS
The "default BIN_TEXT_LINKS" is used to control whether multiple download
options are to be included for each file. That is, when
DEF_BIN_TEXT_LINKS is enabled (is set to 1), then each file
will have three links: a text download link, a binary
download link, and a "mime-type" download link. If set to 0,
only one link is used (the mime type link).
Note: this setting can be overridden by the BIN_TEXT_LINKS request
line option.
Example: DEF_BIN_TEXT_LINKS=1
DEF_BIN_TEXT_MOUSEOVER
The default value for the BIN_TEXT_MOUSEOVER "include javascript in BIN_TEXT_LINK
links" option.
DEF_USE_WINDOW
If 1, then BBS will display files in a "viewer window" (using
target="viewer" attributes in HREF elemenets).
If 0, files will be displayed in the same window as the file listing
(will over write in standard HTML fashion).
Note that the USE_WINDOW option will override this parameter.
Example: DEF_USE_WINDOW=1
DEFAULT_DESCRIPTION:
The "default description". Used if no description for a file can
be found in the (appropriate) description_file.
Can be useful as a filler when tables are used to display descriptions.
Example: default_description='...'
DEFAULT_DESCRIPTION_DIR:
The "default description" for directory entries.
Used if no description can be found, for a directory, in the
(appropriate) description_file.
Example: default_description=' '
DEFAULT_DATEFMT
The default "date format" to use. This is used if a DATEFMT option
is not included in the URL. See the description of the DATEFMT
parameter (in section VIII) for a list of acceptable values.
Note: if a bad value of DEFAULT_DATEFMT is used, BBS wil use
a value of 'N' (i.e.; 15 Feb 1994)
DEFAULT_RATIO and DEFAULT_BYTE_RATIO
The default download/upload ratios.
The default_ratio is for files,
The default_byte_ratio is for bytes.
These are assigned to a user when they "register".
In general: if either are exceeded, downloads are not permitted.
This ratio can be overridden through the use of "privilege specific"
ratios. For further details, see the description of the PRIV_RATIO.!
parameters, or see section VI of this document.
Notes:
If both values are 0, it means "no limit" (unless overridden).
If one is -1 means, it means "downloads denied" (unless overridden).
If both values are very high (say, 1000000), it effectively means
"no limit" (and can NOT be overridden).
Examples:
default_ratio=0
default_byte_ratio=0
default_ratio=10
default_byte_ratio=100
default_ratio=-1
DESCRIPTION_FILE
The "description file". It contains short descriptions of each
file in the directory. It also can contain descriptions of "directories".
BBS looks for the description_file in two locations: the "directory
being examined", and the BBS_PARAM_DIR directory. If both places contain
a description file, the results are concatenated. Thus, a description
may come from an "own directory" description file, or from the "default"
(BBS_PARAM_DIR directory) description file.
Note that if a match occurs in both files, the "own directory" entry
is used. However, exact matches in the BBS_PARAM_DIR version are used
instead of "wildcard" matches in the "own directory" version.
Example: description_File='BBS.DSC'
DEFAULT_SORT_TYPE
The default "sortby" critieria (used to sort the list of files).
The options are the same as for the SORTBY request option.
By default, files will be sorted by Name.
Example: DEFAULT_SORT_TYPE='NAME'
DESCRIPTION_TEXT
This is used to control how descriptions are displayed. When =1,
<PRE> is used to display descriptions "as they are written". Otherwise,
descriptions are displayed as regular HTML text (i.e.; line breaks
are ignored).
Example: DESCRIPTION_TEXT=1
DESCRIPTION_TEXT_LENGTH
This is used to control how "text" style descriptions are displayed.
When =0, it is ignored. When >0, line lengths are limited to the
selected value (<BR> elements are inserted to create these line lengths).
Example: DESCRIPTION_TEXT_LENGTH=25
(lines in the description will be approximately 25 characters
long, with breaks inserted between words)
DESCRIPTION_TEXT_LENGTH_1LINE
When set =1, this signals that the DESCRIPTION_TEXT_LENGTH variable only
be applied to 1 line descriptions. That is, multi-line descriptions will
be left "as is", but 1-line descriptions will be broken up.
Example: DESCRIPTION_TEXT_LENGTH_1LINE=0
EXCLUSION_FILE
The "exclusion file" contains file names (and subdirectory names)
that will NOT be displayed.
The EXCLUSION_FILE is assumed to be in the "requested directory".
If not found, the BBS_PARAM_DIRECTORY directory is searched. Note that
these are NOT cumulative -- the first "exclusion_file" found is used.
Example: exclusion_file='BBS.EXC'
Notes:
* the default BBS.EXC file contains further details on the use of
exclusion files.
* the "exclusion file", "header file", "description file", etc.
are NOT automatically excluded!
FILE_DIR
Fully qualified root directory of the "bbs tree".
This is the default "root" of requested directories (where a request
is accomplished by a "DIR=xxx" option in the request string).
Note that information in the BBS.CTL file, or DOWNLOAD_DIR entries in the
user's user log file, may override this "default".
Example: file_dir='g:\goserv\BBSFILES'
Note: Section XII of this document, and the default BBS.CTL file, contain
further descriptions of how the "root directory" may be set on a
requsted-directory specific basis.
GET_Z_ZIP_DESCRIPTION:
If =1, then the internal zip file description is displayed
(if it is available) using a <PRE> format.
Example: GET_Z_ZIP_DESCRIPTION=1
Note: The internal zip file description can be modified by using
ZIP.EXE's -z switch.
HEADER_FILE and FOOTER_FILE
The "header file" and "footer file". The header file is displayed at the
top of the "directory listing", the footer file at the bottom.
They are both assumed to be in the requested directory.
If not available, then the BBS_PARAM_DIRECTORY directory is searched.
If not in either location, no footer is displayed, and a generic header
is displayed.
** Important Note: You MUST include a <BODY> element in your HEADER_FILE. **
Other notes:
* The BBS.HDR and BBS.FTR files that are shipped with BBS contain
additional details on the use of HEADER and FOOTER files.
Examples: header_file="BBS.HDR"
footer_file="BBS.FTR"
HEADER_TEXT and FOOTER_TEXT
Flags (if set to 1) which signal "display the HEADER and FOOTER
files as text" -- text files will be displayed with the
help of <PRE> elements.
Examples: header_text=1
footer_text=1
ICONS.n
A list of entries that are used to provide "custom" icons for selected
files. This list should contain entries that look like:
FILENAME.EXT <IMG SRC="...">
where filename.ext can contain the * wildcard character.
Note that you can have as many entries as you want, with n going from
1 (the first) to N (the last entry). You should also have an N+1 entry
set to 0.
Examples (each example should be on one line; we split them onto two
lines JUST for 80 character display purposes):
icons.1='*.CMD <IMG Src="/imgs/blueball.gif"
height=24 width=24 alt="[cmd]" >'
icons.2='PERSONAL.HTM <IMG src="/imgs/mypic.gif"
height=30 width=30 alt="[me]">'
icons.3='\USERS\BOB <img src="/usr/pics/bobby.gif
height=22 width=22 alt="[bobs]">'
icons.4 =0
Notes:
* If a file does not match one of these ICONS.n entries, one of the
generic icons will be used.
* In the above example, icons.3 is used for a directory -- don't forget
that you MUST preceed "directory" entries with a \ (or a /).
IMAGEPATH
Directory, relative to the Goserve DATA directory (NOT the BBS_PARAM_DIR
directory), that contains the file-type icons (.gif files).
Example: imagepath="imgs/"
Note that a leading / will be ignored -- it does NOT signal a "fully
qualified" directory
INCOMING_DIR
Default directory for file uploads.
If a relative directory is used, it is assumed to be relative to the
BBS_PARAM_DIR directory
This is used if there is no (matching) UPLOAD_DIR parameter specified in a
given user's .IN file.
If a "matching" UPLOAD_DIR parameter does exist, then the INCOMING_DIR is
ignored. Note that this UPLOAD_DIR parameter should be a fully qualified
directory.
Example: If:
UPLOAD_DIR: up1 d:\private\JOE\STUFF
INCOMING_DIR = 'newfiles'
BBS_PARAM_DIR = 'e:\bbs'
Then uploads to up1/foo.bar will map to:
d:\private\joe\stuff\foo.bar
And uploads to up2/foo.bar will map to
e:\bbs\newfiles\up2\foo.bar
INCLUSION_MODE_FILE
The INCLUSION_MODE_FILE contains file names and subdirectories that will be
displayed, as well as comments and descriptions. Only these files and
directories will be displayed (with possible exclusions due to the
EXCLUSION_FILE).
Examples:
INCLUSION_MODE_FILE=0
Do not use an inclusion_mode_file.
INCLUSION_MODE_FILE='FILES.BBS'
For further details on the use of the INCLUSION_MODE_FILE, see section IIa of
this document.
MUST_WAIT
If default_ratio is exceeded, client must wait this many days before he can
download 1 more file (after this 1 download, the "must-wait clock
restarts"). Fractional days are allowed.
Example: must_wait=0.1
OWN_NAME_PRIVILEGE
If =1, include a !username in the user's privilege list.
This can facilitate assignation of privileges on a user specific basis.
Note that a ! is appended to the username-- this is done as a security
precaution (to preclude a randomly chosen username from matching
a privilege; since usernames can NOT start with !).
Example: own_name_privilege=1
(if the user is JOEY, then a !JOEY privilege is added to his
privilege list).
OWN_DOWNLOAD_DIRECTORY
The OWN_DOWNLOAD_DIRECTORY is used by the BBS new user registration facility
(BBSNEWU.HTM). It should either equal 0 or " " (in which cases it is
ignored), or it should equal an existing fully qualified directory.
When a new user is registered (and if OWN_DOWNLOAD_DIRECTORY<>0), a
Download_dir entry will be added to the users's .IN file.
For example,
if OWN_FLAG='PERSONAL' (see below),
the username is JOEY
and OWN_DOWNLOAD_DIRECTORY='D:\BBS2
then the following will be added to JOEY.IN
Download_dir: PERSONAL D:\BBS2\JOEY
Notes:
* If it doesn't exist, D:\BBS\JOEY will be created
* A request for dir=/personal will yield a listing of the contents of
D:\BBS2\JOEY
* See section XII for further details
OWN_FLAG
The OWN_FLAG is used by the BBS new user registration facility
(BBSNEWU.HTM). It's used in conjunction with the OWN_DOWNLOAD_DIRECTORY
and OWN_UPLOAD_DIRECTORY.
Example: OWN_FLAG='PERSONAL'
OWN_UPLOAD_DIRECTORY
The OWN_UPLOAD_DIRECTORY is used by the BBS new user registration facility
(BBSNEWU.HTM). It should either equal 0 (in which case it is ignored), or
equal an existing fully qualified directory.
When a new user is registered (and if OWN_UPLOAD_DIRECTORY<>0), then an
Upload_dir entry will be added to the user's user log file.
For example,
if OWN_FLAG='PERSONAL'
the username is JOEY
and OWN_UPLOAD_DIRECTORY='D:\NEWUP'
then the following will be added to JOEY.IN
Upload_dir: PERSONAL D:\NEWUP\JOEY
Notes:
* Uploads to PERSONAL/ will be placed in D:\NEWUP\JOEY (rather
then in the PERSONAL subdirectory of the INCOMING_DIR).
* See section XII for further details
PRIV_RATIO.!
The PRIV_RATIO.! entries are used to assign a download/upload ratio on
a "privilege specific" basis. These are used in conjunction with the
user's default ratio (set in the RATIO: entry of the user log file),
and the "required privileges" (set in bbs.ctl on a directory specific
basis).
Note that these parameters are a little different then other
"stem" variables -- you do not put a number after the ".".
Instead, put a !, followed by a "privilege name".
The value of these parameters should be a string containing two
numbers, the file ratio and the byte ratio.
Example (first number is file, second number is byte):
PRIV_RATIO.!PREFERRED='50 1000'
PRIV_RATIO.!NEWGUY='10 50 '
For more details on BBS's use of "privileges", please see section VI.
PRIV_WEIGHT.!
These are similar to the PRIV_RATIO.! variables. They are used to set a
"privilege specific" download weight. Lower download weights mean that
a download will result in a smaller number of bytes being added to a
users "downloaded bytes count" (and a smaller number of files).
Note that the default weight is (not suprisingly) 1.0.
Example: PRIV_WEIGHT.!PERSONAL='0.5'
Requests to a directory for which a "PERSONAL" privilege applies
(as set in BBS.CTL or in a download_dir entry) will use a
download-weight of 0.5.
SEND_ALERT
Set this to 1 to instruct BBS to send an e-mail alert to the WEB_ADMIN
(see below), via the SMTP_GATEWAY (see above) whenever a succesful
file upload occurs.
Example: SEND_ALERT=1
TABLE_BORDER
Width of borders, if table is used. Set to 0 for "no border".
Note: see the cell_spacing option for an alternative method
of visually delineating rows in a table.
Example: table_border=1
TR_COLOR
Enable use of alternating colors in rows of a table.
Use 1 to enable, 0 to disable.
Any other value, the value of TRCOLOR.0 (in BBS.CMD) is used.
Note that TRCOLOR.1 and TRCOLOR.2 (in BBS.CMD) is used to set the color values.
Example: tr_color=1
UPLOAD_MAXSIZE and UPLOAD_MINFREE
UPLOAD_MAXSIZE: Maximum size, in kbytes, of uploadable files.
UPLOAD_MINFREE: Minimum disk space free, in kbytes, after upload.
Examples: upload_maxsize=5000
upload_minfree=20*1000
Note: This is NOT THE SAME as the SRE-http UPLOAD_MAXSIZE and
UPLOAD_MINFREE parameters.
UPLOAD_QUICK_CHECK
To speed up "pre-existing file" UPLOAD error responses, BBSUP can
perform an early check to see if the selected filename already
exists. To do this, set upload_quick_check=1.
Although speeding up "error response" a bit, this requires that:
No "alternative" file name is used -- the "client's own" filename
is used, and it is to be placed in the "root" of the INCOMING_DIR
directory. If you use "alternative file names", you should
set UPLOAD_QUICK_CHECK=0.
Furthermore, if any UPLOAD_DIR entries have been specified, then
UPLOAD_QUICK_CHECK is disabled.
USE_COOKIES
BBS will attempt to use "cookies" (request header information) to
store the username and password information. To suppress this
feature, set USE_COOKIES=0; to enable it set USE_COOKIES=1.
The primary advantage of cookies is that the username and password
will not be displayed on the URL -- this gives a little more
security to the user. The primary disadvantage is that it requires
more cache files.
Example: USE_COOKIES=1
Notes:
Many older browsers do not understand cookies. BBS can recognize
this, and will use the request-string-based username/password technique.
When cookies are being used, otherwise identical requests will result
in different "cache files" on the basis of whether the browser is
cookie-capable.
The request-string-based technique is still used on the first call to
the BBS (that is, from BBSHELLO.HTM). To remove this last bit
of exposure, you can try to use POST method in your
welcoming FORM (see BBSHELLO.HTM for an example).
For further discussion of "authorization modes", see section II of
this document.
USERLOG_DIR
Directory containing BBS "user log" files.
If a relative directory is entered, it is assumed to be relative to the
BBS_PARAM_DIR directory.
Example: userlog_dir='USERLOG'
Notes
* "user log files" have names of UserName.IN.
* for further discussion of "user log" files, see section
III of this document.
USE_SERVERNAME
Optional. If available, this value will be used in $SERVERNAME
string replacements in the HEADER_FILE, ZIP_HEADER_FILE, and FOOTER_FILE.
If =0, then look up the server name (from GoServe if available,
otherwise from OS/2).
Examples:
use_servername=0
use_servername='The Free-to-all Project Web Site '
WRITE_DETAILS
Write request info to the user-log file.
If =1, "request specific" information is recorded in the user's .IN
files. This includes the name of the file uploaded, and
the date of transaction.
If 0, just the "upload counts", or "download counts", are augmented.
Examples: write_details=1
ZIP_HEADER_FILE
Similar to the HEADER_FILE, this is displayed at the top of
"ZIP file extraction" listings.
The ZIP_HEADER_FILE is assumed to be in the directory
being displayed. If not, then the bbs_param directory is searched.
If not in either directory, a generic header is displayed.
Notes:
* You MUST include a <BODY> element in your ZIP_HEADER_FILE.
* A ZIP_HEADER_TEXT_ONLY option is NOT currently available (that is, the
ZIP_HEADER_FILE is assumed to be HTML).
* A ZIP_FOOTER_FILE is NOT currently available.
Example: zip_header_file="BBSZIP.HDR"
ZIP_DESCRIPTOR_FILE
The "within .ZIP file" header file. If found (in a .ZIP file)
it will be extracted and displayed at the top of the document
(along with -z comments and the ZIP_HEADER_FILE).
Examples: zip_descriptor_file='FILE_ID.DIZ'
Notes:
* ZIP_DESCRIPTOR_FILE should NOT contain path info
* Display of ZIP file contents is more rudimentary then directory
displays; with no file exclusion, no file descriptions, and <PRE>
used instead of TABLES.
========================================================================
X) Creating Use Statistics
The BBSSTAT.CMD file, that you copied to your USERLOG_DIR directory, can be
used to generate some simple usage statistics. BBSSTAT.CMD should be run from
an OS/2 command prompt -- it is NOT an SRE-http add-on!
You will be asked to provide a few pieces of information: the number of
entries to display, and an output file. For example, if you choose 10
entries, then the 10 "busiest" users (for each of several variables) are
listed.
The output file will contain these lists as plain text (no HTML elements).
You may want to:
a) modify it (say, with a few HTML tags),
b) copy it to your GoServe data directory.
c) include a link to it in BBSHELLO.HTM (or whatever you use as your BBS
"welcome" page).
The variables reported are:
File downloads, file uploads, byte downloads, byte uploads,
download/upload ratio for files and for bytes,
and the most recent users.
In addition, the total (weighted) number of files (and bytes)
downloaded (and uploaded), and the number of users in the
last m days, are reported.
========================================================================
XI) Using the Caching Daemom
The BBS caching daemon, BBSCACHE.CMD, can be used to prevent the BBS cache
from becoming seriously out of date. To use this, simply open up an OS/2
window, change directories to your GoServe working directory (where BBS.CMD,
BBSCACHE.CMD, etc. are installed), and run the BBSCACHE.CMD program.
There is one important consideration when using BBSCACHE. BBSCACHE requires a
"reference" cache-index -- it uses this reference as a list of "request
strings" whose output will be cached.
The notion is that the administrator will save the BBSCACHE.IDX file
(the cache index file) after a representative time period. Alternatively,
she could issue an BBS?INIT=1 request, and then meticulously browse the
most important (or most frequently demanded) file areas (and .ZIP files).
If this administrator-intensive approach is adopted, note that "cookie" and
"non-cookie" versions are cached separately -- you might want to hit your
favorite file areas with both kinds of browsers.
Regardless of the source of this "reference" cache index; it should be saved
in the BBS_PARAM_DIR directory -- and NOT in the BBSCACHE_DIR directory. One
convenient way to do this is by running BBSCACHE.CMD -- it will ask if you
want to save your cache index. Of course, once you've saved a good
cache-index, the next time you run BBSCACHE.CMD (say, after shutting down your
machine for maintenance), you probably do NOT want to "save the current cache
index" again.
After asking if you want to save the current cache index, BBSCACHE will ask
you to provide the name of the cache index you wish to use.
If you have just "saved" the current cache index, you'll probably
want to use it (it's the default)!
It will then ask for a frequency of cache refreshes (in minutes) --
or you can tell BBSCACHE to do it "just once" (but don't forget to
re-run BBSCACHE in a timely fashion).
BBSCACHE will then enter a "scan, refresh, sleep" loop:
1) Scan through the lists of "request strings" stored in the cache-index you
selected
2) For each "request string", generate a cache file containing the correct
output.
3) The working cache-index is refreshed. Note that this is NOT the
same as the cache-index you selected (although it may contain
similar information, especially if you "saved the current cache index").
4) BBSCACHE sleeps for the specified number of minutes.
5) Jump to step 1.
Notes
* If you selected "do it just once", BBSCACHE will exit after step 3.
* By default, BBSCACHE is installed in your GoServe working directory.
* BBSCACHE expects to see a copy of BBS.CMD in the
GoServe working directory. Therefore:
** To use BBSCACHE.CMD, you MUST copy BBS.CMD to the GoServe
working directory (from the addon subdirectory)
========================================================================
XII) Using "own" upload and download directories
By default, BBS will assume that all requested downloads are "relative" to
the FILE_DIR directory. Similarly, all uploads will be placed into the
INCOMING_DIR. While this may be adequate for most installations, there may
be cases where "customization" is desired. In order to fill this need,
you should consider the use of "own" upload and download directories.
A point about more general control methods is worth mentioning:
If you've read this far, you are aware of the use of privileges, in
conjunction with the BBS.CTL file, to control access to directories. In
many cases, the use of BBS.CTL may be more then adequate (especially when
you have a few large classes of users). In other words, you may want to
review the material in section IV.
That said, the beauty of the "own" directory strategy is the fine control it
gives. In short, you can specify directories that will only be accessible by a
single user (or a small set of users).
In particular:
i) You can specify one, or several, "own" upload directories.
ii) You can specify one, or several, "own" download directories.
Specification of "own" upload and download directories is done by
adding entries to the user's .IN file. That is, for a username of JINX,
you would add entries to the JINX.IN file.
For uploads, these entries take the form:
UPLOAD_DIR: prefix fully-qualified-directory weight_factor
Download entries take the form:
DOWNLOAD_DIR: prefix fully-qualified-directory privilege_list
where:
prefix: the "leading sub-directory" of the requested-directory.
fully-qualified-directory: where to read (or write) files from (to)
weight_factor: (optional) weighting factor (default value is 1.0)
privilege_list: (optional) list of privileges
Let's define the above in greater detail:
requested-directory:
the directory that appears after a dir=, or
the directory portion of a file download (or upload) request.
For example, if a client requests (ignoring username/password):
bbs?dir=animals/primates
the "requested-directory" is "animals/primates".
prefix: the "first sub-directory" in the "requested-directory"
Some examples:
the prefix of "dir=animals/primates" is animals
the prefix of "dir=simple" is simple
"dir=/" does NOT have a prefix.
fully-qualified-directory:
a (fully-qualified) directory used as the upload (or download)
directory. It must already exist.
weight_factor:
usually BBS adds the actual number of bytes to the upload bytes-count.
The weight_factor instructs BBS to multiply the byte-count by
the "weight_factor".
Thus, a weight_factor of 0.5, in conjunction with an upload of
10000 bytes, would increase the upload-bytes-count by 5000.
If this is not specified, a value of 1.0 is used.
privilege_list:
as with the privilege list in BBS.CTL, it's used to determine the
appropriate "upload/download" ratio(s), and the "weighting factor".
However, it is not used to control access (since these are "personal
directories", it would be annoying and redundant to "require"
privileges).
Examples:
* If INCOMING_DIR='D:\BBS\UPLOAD'
and the username is JINX
and JINX.IN contains an entry of: Upload_dir: myup d:\others\jinx
then
a BBS upload to myup\foo.1 will write results to
d:\others\jinx\foo.1
If there were no Upload_dir entry, results would be written to
D:\BBS\UPLOAD\MYUP\FOO.1
* If FILE_DIR='D:\BBSFILES'
and the username is JINX
and JINX.IN contains an entry of:
Download_dir: personal d:\private\jinx
then a request for dir=/personal
would yield a listing of the files in d:\private\jinx
* If JINX.IN contained two entries:
Download_dir: personal d:\private\jinx
Download_dir: group1 d:\groups
then a request for dir=group1/party
would yield a list of the files in d:\groups\party
Notes:
* You can have multiple download_dir and upload_dir entries -- just
be sure you use a different prefix for each one (though you can use
the same prefix for a download_dir and an upload_dir).
Also note that sub-directories are always allowed (as in the
third example) -- you should NOT use the * to signal "directories are
okay" (contrast this to BBS.CTL).
* Please be aware that the "fully-qualified-directory" is used as an
"alias" for the "prefix". In contrast, BBS.CTL assumes the
entire "requested directory" is under the "alternate root directory"
(though you can use the xx\yy\.. syntax in BBS.CTL to modify this logic).
Example:
Assume a request for dir=/newstuff/dir0
a BBS.CTL entry of: newstuff/* * , g:\BBS2
would yield a listing of: g:\bbs2\newstuff\dir0
a USERS.IN entry of: DOWNLOAD_DIR: newstuff g:\bbs2
would yield a listing of: g:\bbs2\dir0
a BBS.CTL entry of newstuff/* *, G:\bbs\..
would also yield a list of of: g:\BBS\DIR0
* The "own download directory" is checked before BBS.CTL -- if a
matching "own download directory entry" is found, BBS.CTL will not be
examined. Thus, in the above example, if both entries existed the latter
(g:\bbs\dir0) would be used.
* The DEFAULT prefix has a special meaning for both UPLOAD_DIR and
DOWNLOAD_DIR. DEFAULT signals that "this fully-qualified-directory
should be used instead of the FILES_DIR (or the INCOMING_DIR)".
It's a "user-specific" general replacement: if a requested-directory does
NOT match a BBS.CTL entry or some other DOWNLOAD_DIR (or UPLOAD_DIR)
entry, then the DEFAULT directory will be used.
Example: download_dir: DEFAULT d:\special\users\files
* Automatically creating "own" directories.
You can always add, delete, and modify entries in the various .IN files.
This can become tedious, so the new user registration offers a simple way
to automatically create these entries.
Three BBS.INI parameters are used by this automatic creation facilty:
OWN_DOWNLOAD_DIR, OWN_UPLOAD_DIR, and OWN_FLAG. The first two should
be fully qualified directories, or 0. The last should be a short string.
If OWN_UPLOAD_DIR<>0, then the following entry is added to the user's .IN
file:
Upload_dir: OWN_FLAG Own_upload_dir\username
For example,
if:
OWN_UPLOAD_DIR='E:\STOREF', and E:\STOREF exists,
username is COYOTE
own_flag='PERSONAL'
then the following entry is created,
Upload_dir: personal E:\STOREF\COYOTE
and an upload from COYOTE to personal/ will be placed in
E:\STOREF\COYOTE
Similarly, if OWN_DOWNLOAD_DIR<>0, then the following entry is added to the
user's .IN file:
Download_dir: Own_flag Own_download_dir\username
For example:
if OWN_DOWNLOAD_DIR='E:\MYOWN' (and E:\MYOWN exists),
and the username is COYOTE
and OWN_FLAG='PERSONAL'
then the following entry is created,
Download_dir: PERSONAL E:\MYOWN\COYOTE
* a request (from COYOTE) for dir=personal will yield a listing of
E:\MYOWN\COYOTE
* a request for dir=personal/kids will yield a listing of
E:\MYOWN\COYOTE\KIDS
Notes:
* In both of these examples, note that use of OWN_FLAG. By default, it
equals PERSONAL, but you can change it to suit your tastes.
* If the "own_upload_dir\username" directory, or the
"own_download_dir\username" directories do not exist, they will be
created.
* These three parameters (OWN_DOWNLOAD_DIR, OWN_UPLOAD_DIR, and
OWN_FLAG) are only used in "new user registrations". If you prefer,
you can always hand-enter entries into the various .IN files -- in which
case you can freely assign directory names (and "requested directory
prefixes").
-- End of BBS documentation.