oooooooooooooooo oooooooooooooooo oooooooooooooooo ooooooo o
BBBBBB""""BBBBBBo BBBBBB""""BBBBBBo BBBBBB""""BBBBBBo oBBBBB""""BBBo
BBBBBB BBBBB" BBBBBB BBBBB" BBBBBB BBBBB" BBBBBB "B
BBBBBB oBBBB"" BBBBBB oBBBB"" BBBBBB oBBBB"" BBBBBBBoo "
BBBBBBBBBBBBooo BBBBBBBBBBBBooo BBBBBBBBBBBBooo "BBBBBBBBBBBoo
BBBBBB" "BBBBBo BBBBBB" "BBBBBo BBBBBB" "BBBBBo "BBBBBBBBBBBBB
BBBBBB BBBBBB BBBBBB BBBBBB BBBBBB BBBBBB """BBBBBBBB
BBBBBB BBBBBBB BBBBBB BBBBBBB BBBBBB BBBBBB Bo BBBBBB"
BBBBBB oBBBBBB BBBBBB oBBBBBB BBBBBB oBBBBBB BBBo oBBBBB"
BBBBBBBooBBBBBBB" BBBBBBBooBBBBBBB" BBBBBBBooBBBBBBB" oBBBBBBBBBBBB""
""""""""""""""" """"""""""""""" """"""""""""""" """"""
Version 4.00 MP
Copyright (c) 1990-1999 Kim B. Heino and Tapani T. Salmi
System Operator's Manual
Quick Install
BBBS Table of Contents
BCFG4 Table of Contents
BBBS Homepage: http://www.bbbs.net/
BBBS Documentation Project: http://www.freezer-burn.org/bbbs/
BBBS Documentation Table of Contents
------------------------------------
1. Installing BBBS
1.1 First-time installation of BBBS
1.2 About this manual
2.3 How to get help
2. Configuring BBBS
2.1 Configuring BBBS - an overview
2.2 The BCFG4 Configuration Program
2.3 Basic security: Groups and access
2.4 File areas
2.5 Message conferences
2.5.1 Netmail conference setup
2.5.2 Email conference setup
2.6 External programs: external.bbb
2.6.1 Archivers: [af_*] section
2.6.2 Protocols: [t_*] section
2.6.3 Meta characters used in external.bbb
2.7 Groupmail support: alias.bbb
2.8 Login aliases: login.bbb
2.9 Internet access: inet.bbb
2.10 Language support: the bbbstxt-files
2.11 The menu system
2.10.1 Command configuration: the 'error'-script
2.10.2 Command configuration: commands.bbb
2.10.3 Removing and renaming commands in bbbstxt-files
2.10.4 *Creating script-based menus
2.12 The chat system
2.13 Color palette setup
2.14 Overview of used files
2.14.1 Multinode preconfiguration
3. Running BBBS
3.1 BBBS command line functions
3.2 The Waiting For Caller screen and BackDoor
3.3 Local SysOp keys
3.4 The BTERM terminal emulator
4. BBBS and FidoNet Technology Networks
4.1 Introduction
4.2 Nodelist definitions: [nodelist] section
4.3 Echomail definitions: [echomail] section
4.4 Node definitions: [nodes] section
4.5 Tick/File-echo definitions: [ticks] section
4.6 Agnet/QWK definitions: [agnet] section
4.7 Badecho definitions: [badecho] section
4.8 Badtick definitions: [badtick] section
4.9 Netmail bouncing/remapping definitions
4.10 AllFix FileFind configuration
4.11 BRoboCop and AreaFix
5. BBBS and TCP/IP (Internet) Networks
5.1 Introduction
5.2 BBBSD: The BBBS Network Daemon
5.3 BBBSD: The FTP Daemon
5.4 BBBSD: The HTTTP Daemon
6. BZ: The BBBS Programming Language
6.1 Introduction to the BZ programming language
6.2 Expressions
6.3 Functions and Variables
6.4 The functions in BZ49 runtime library
6.5 The variables in BZ49 runtime library
6.6 Other script languages in BBBS
7. Operating System Considerations
7.1 BBBS/D: BBBS for PC-DOS
7.2 BBBS/2: BBBS for OS/2
7.3 BBBS/NT: BBBS for Windows NT/95/98
7.4 BBBS for UNIX clones
7.5 BBBS for Amiga
7.6 OS environment variables
8. Appendices
8.1 Frequently Asked Questions
8.2 About regular expressions (regexp)
8.3 Wildcards in BBBS
8.4 The MG Reference Manual
8.5 The BBBS license, prices and order form
8.6 References
BBBS is a copyright of Kim Heino and Tapani T. Salmi, Copyright (c) 1990-1999
First of all, thank you for choosing BBBS, the powerful, all-in-one BBS
software solution!
Creating a working BBS system with BBBS is very simple. As you are reading
this, you probably have already extracted the BBBS distribution package to a
directory. This directory is called the "BBS directory". It is probably a good
idea to name it something like c:/bbbs, if for nothing but simplicity's sake.
To get a minimal configuration, you will need to run bcfg4 1, the
BCFG4 configuration program. You can do a lot of configuration there, but for
starters you will just have to configure the name of your BBS and your own
name. Other options should be ok at their default values, but you can check
them all if you like. If you run into trouble, you can at any time request help
with the F1 key.
When you are finished with BCFG4, select exit and save and wait for BCFG4 to
save the configuration you just created. Depending on how many conferences you
created (and a lot of other things), the saving procedure can take a short time
or a very long time. Remember that patience is a virtue
When BCFG4 is finished, you have a working configuration. Now all you need to
do is log in to the system once to register yourself as the system operator.
BBBS can be run in local mode by executing it with the command line bbbs 0. The
first user that registers into the system will be the main system operator or
"user 0", with access to everything. After you have done this, you have a fully
functional setup.
To get the most out of BBBS, though, you will need to do a bit more
configuring. Just a few things you might like to check are if your menu files
are ok, what kind of file areas you would like to have, if the
user access configuration is ok and especially if external programs, such as
archivers work. But otherwise, BBBS is now installed. Have fun!
If you are using UNIX and BBBS binaries are not in your PATH-environment then
you have to start BBBS with command ./bbbs. The same applies to all BBBS
binaries.
This manual is an ongoing work of progress. As BBBS is constantly evolving, so
is this manual. This manual will give you comprehensive information about
installing, configuring, updating, and maintaing your new (or old) BBBS system.
The manual is currently maintained by Vincent Danen. If you have any questions
or concerns about the manual, please direct them to Vincent instead of to Kim.
If Kim wanted to answer questions about the manual instead of programming BBBS,
he would write the manual. As it stands, he only puts in last-minute changes
before a new public version is released.
Updates for this manual can be found periodically on www.bbbs.net or at the
BBBS Documentation Project (www.freezer-burn.org).
For easy reference, you may wish to view the documentation in a different
format. This can be easily accomplished by issuing the following commands:
copy bag.exe ag2html.exe
ag2html sysop.gui >sysop.htm
- this will create an HTML file.
copy bag.exe ag2doc.exe
ag2doc sysop.gui >sysop.doc
- this will create an ASCII file with formatting.
copy bag.exe ag2txt.exe
ag2txt sysop.gui >sysop.txt
- this will create an ASCII file without formatting.
copy bag.exe ag2ipf.exe
ag2ipf sysop.gui >sysop.ipf
- this will create an OS/2 IPF (Information Presentation Facility) file
that can be compiled by ipfc (from the OS/2 toolkit) into an OS/2
.INF file.
So you're stuck. The manual, as detailed and comprehensive as it is, can't
help you (or you can't find what you need). There are a number of avenues that
can be used to find help on BBBS. This list is but a small one of the
available resources:
Homepage:
http://www.bbbs.net/
Support BBS's:
BCG-Box 4 : +358 2 240 7755
telnet://bbbs.net
http://bbbs.net/
Freezer Burn : telnet://bbs.freezer-burn.org
Email support:
Kim Heino, b@bbbs.net
Vincent Danen, vdanen@linux-mandrake.com
Echomail support:
FidoNet (zone 1 and 2): BBBS.ENGLISH
FidoNet (zone 2 only) : BBBS.BZ
BBBS.CHAT
BBBS.UTIL
BBBS.FINNISH
BBBS.SYSOP (registered users only)
Sysop's TechNet : STN.BBBS
BBBS, being a comprehensive, all-in-one system, has a lot of features and
therefore also has a lot to configure. The basic things are configured with the
BCFG4 Configuration Program, the rest with ASCII-format text files residing in
your BBBS-directory, which can be edited with your favorite editor or with the
BBBS's internal mg editor.
The most important one of these is the file groups. It is used to define user
access groups. Groups are the basis of BBBS security, so it is very important
that you have a thorough look into the file and how it is formed.
A set of important files are also the 'filedir*'-files. These are used to
create the file areas in your BBBS system. The BBBS filesystem, File/4, is a
very powerful "os-like" filesystem, with tree-structures and file manipulation
commands that are familiar from most operating system shells.
A lot of miscellaneous configuration items are in the external.bbb-file. In it
resides the configuration of external programs, such as archivers and
protocols. Also, a lot of configuration related to networking with other BBS
systems can be found in this file.
The configuration of BBBS groupmail features resides in the alias.bbb-file.
This is where things like mailing lists and comment receivers are defined.
BBBS has also a lot of internet access tools. The behavior of BBBS in internet
and other TCP/IP-networks can be defined in the file inet.bbb.
The BBBS chat system is also a very powerfull, channel-based one. The available
channels and feelings can be configured with the files in the
feelings-directory, defined in BCFG4.
In addition to these configuration files, there are also a lot of other files
that are used to do all sorts of miscellaneous configuration.
Examples of all configuration files come with the distribution package. In
addition to the examples in this manual, also refer to these files, as they are
pretty straightforward and self-explainatory.
The BCFG4 configuration program is used to do most of the configuration in
BBBS. The BCFG4 interface is very easy to use. If you run into trouble or do
not understand something, the F1 key will give you immediate help.
The BCFG4 program is called bcfg4. The calling convention of this program
is simple:
bcfg4 [node]
Where node is the number of the BBBS node you want to configure. In BCFG4,
the global configuration is always the same regardless of the node specified,
the local configuration is specific for each node.
There are some other commandline options for BCFG4 as well, but the above is
the most commonly used.
If you specify "bad" as the node-parameter, then BCFG4 will scan your
badecho-directory for nonexistant echos and create them according to the rules
in the badecho-section of external.bbb-file, if there is at least one "unnamed"
conference in your conference configuration.
The things you'll probably want to check are:
- The general stuff
- The global toggles
- The conference configuration
- The modem setup for each node
- If you want to have networks, the FidoNet configuration
Otherwise, the default values should be pretty much OK. You can (and should)
go through everything, though, just to make sure.
BBBS's powerful user access management is based on groups. Groups are
collections of other groups with a distinctive name. The groups you define are
global. That is, you can use them anywhere in the system. In every system you
will most likely run into a situation where you need groups. Just one of them
is when you need to create a "private" conference or a "news" conference. This
is all very easy with groups. All you need to do is to type a few lines.
Defining general groups
Groups are defined in the file groups, residing in the BBBS-directory. The
format of the file is as follows; blank lines and lines beginning with a
semicolon (';') are ignored:
name_of_group:group1{,group2{,...}}
As you can see, a group contains only other groups. Every user is a member of
the groups called all and first.last, where first is the first name of the user
and last is the last name. So, to define a group called bz with the users "Kim
Heino" and "Tapani Salmi", you write:
; Creating a simple general group with two users:
;
bz:kim.heino,tapani.salmi
Then, to create a group simka with the members of the bz-group and also the
users "Pertti Heikkinen" and "Rune Johansen", you would write:
; An example of creating a group called 'simka' with another group:
;
simka:bz,pertti.heikkinen,rune.johansen
Group names that include an exclamation mark ('!') have a special meaning: such
groups include all members of the group left of the exclamation mark, except
the members of the group at the right side of it. For example, the group
fsysop!bz contains all users of the group fsysop, except the members of the
group bz. A shortcut for all!foo is !foo. An example:
; Example of using exclusive groups:
;
simka:bz,pertti.heikkinen,tuomo.soini,rune.johansen
finnish:simka!rune.johansen
;
; Another example; group true has persons that are members of groups foo
; and bar:
;
foo=kim.heino,tapani.salmi,kalle.soiha,olli.törmä,sami.virtanen
bar=rune.johansen,kim.heino,olli.törmä,matti.luoma
temp=!foo,!bar
true=!temp
;
; So, the group true contains the users Kim Heino and Olli Törmä.
;
Remember that if you try to create group foo with the line:
foo:all!kim.heino,all!tapani.salmi
The result is that everybody is a member of the group foo, since they are
members of the first group or the second group and the group foo is the two put
together. The correct way to do this is would be:
bz:kim.heino,tapani.salmi
foo:all!bz
; or foo:!bz
Remember also that the group foo!foo has no sense: it is an empty group.
Another group name that has a special meaning is any group with a string like
@yymmdd added to it, where yymmdd is a date (yy specifies the year, mm the
month and dd the day). Groups like this have effect in the group they are being
added to only until the specified date is reached. 14 days before the date is
reached, the members of the group receive a message that their access in a
group will soon expire. When the date is reached, an exclamation mark is added
to the group name. An example:
; Example of a group with a member that will exist only for a specified
; time:
;
kids:toni.saari,samuli.suominen,olli.törmä@990903
;
; At 20.8. 1999, the line will change into:
;
; kids:toni.saari,samuli.suominen,olli.törmä@990903!
;
; Finally, at 3.9. 1999, user Olli Törmä will be removed from the group
; and the line will change into:
;
; kids:toni.saari,samuli.suominen
There are also so-called "unit" groups. These are defined as <x# or >x#, where
x is a letter (see below) and # is a number. For example letter 'a' defines an
age group. Every user whose age is under 18 years, belongs into the group <a18.
Likewise, every user whose age is over 17 years, belongs into the group >a17.
An example:
; Example of a group with age definition:
;
kids2:samuli.suominen,<a9
;
; In addition to the user "Samuli Suominen", everyone whose age is
; under nine years belongs into the group kids2.
The unitgroups are:
"<a#" matches users younger than # years, ">a#" older
"<c#" called less than # times, ">c#" more
"<r#" read less than # messages, ">r#" more
"<w#" written less than # messages, ">w#" more
"<u#" uploaded less than # kilobytes, ">u#" more
"<d#" downloaded less than # kilobytes, ">d#" more
"<p#" uploaded less than # files, ">p#" more
"<o#" downloaded less than # files, ">o#" more
"<l#" user has limit-value less than #, ">l#" more
Groups are also cumulative. That is, when you have created a group on one line,
creating it "again" on an another line simply adds to the already existing
group. The simka group defined above could have also been defined like this:
; Another example of creating a group called 'simka'.
;
simka:bz
simka:pertti.heikkinen,rune.johansen
This is good to remember as a single line in the groups file can only be 1023
characters in length. Remember also that the groups-file is read from top to
bottom.
Restricting conference access with groups
For every conference you generate, there is also a set of groups, defining who
can do what in the conference. Lets say you generate a conference called chat.
For it, there are also four groups:
chat@ - members cannot read or write the messages in the conference.
chat@r - members can only read messages in the conference.
chat@w - members can both read and write messages in the conference.
chat@s - members have SigOp access in the conference.
By default, all users are members of the chat@w-group, so they have full read
and write access to the "chat"-conference. An example: to have only the members
of the group simka and user "Kalle Soiha" be able to read the conference called
"BBBS.Simka", you would write:
; An example of how to restrict conference access:
;
; First disallow everyone to read the bbbs.simka-conference:
;
bbbs.simka@:all
;
; Then allow group "simka" and the user "Kalle Soiha" to read and
; write into it:
;
bbbs.simka@w:simka,kalle.soiha
But what if you have a lot of network areas in your BBS and would prefer not to
have the members of group newbies write into these conferences, only read? One
way to do this would be:
; A bad example of limiting access from a lot of conferences:
;
sf.aloittelijat@w:all
sf.aloittelijat@r:newbies
sf.amiga@w:all
sf.amiga@r:newbies
; etc. ad nauseam
The BBBS group system offers a much quicker way to achieve this. You can create
a group with a regular expression. There are four kinds of regexp groups:
name@=regexp - Members of the group cannot read or write any messages
to conferences matching the regular expression
"regexp".
name@r=regexp - Members of the group can only read messages from
conferences matching the regular expression "regexp".
name@w=regexp - Members of the group can both read and write messages
to conferences matching the regular expression
"regexp".
name@s=regexp - Members of the group have sigop access to conferences
matching the regular expression "regexp".
"name" can be any string you like, but it should be something that has
something to do with the actual function of the group. Note, that "name" is NOT
the name of the regular expression group. It is just an unique string that is
part of the name. The real name of the regexp group name@r=regexp is name@r.
As you probably have already guessed, regexp groups can be very powerful
indeed, though they can give you a major headache if you don't know a lot about
regular expression. It is very important to completely understand what regexp
is. "Normal" OS-shell wildcards like '?' and '*' are part of regexp, but they
have a completely different meaning in it.
As an example, let's see how we can easily solve the FidoNet access problem
with regexp groups:
; The correct way to limit access from a lot of conferences:
;
nonewbies@w=^sf\.:all
nonewbies@r=^sf\.:newbies
Notice the power of the regular expression. With just two lines, the
write-access of group newbies is removed from all conferences beginning with
the string "SF.". It doesn't matter how many conferences there are, the regexp
group automatically applies to all conferences matching the expression given.
Actually, as by default every user has read and write access to all
conferences, the first line in above example is redundant:
; The shortest way to limit write access from a lot of conferences:
;
nonewbies@r=^sf\.:newbies
Remember that the last specified conference group will take effect, not the
most "powerful" one; that is, if you first give a sigop access to a certain
group, and later on in the file give the same group a read-access, the group
will have only read-access, NOT sigop-access. This is also true for
regexp-conference groups.
List of all predefined groups that cannot be reassigned:
Group name Members
=======================================================================
all all users, always.
firstname.lastname user with the name "Firstname Lastname".
foo!bar users who are members of the group foo, but
not the group bar.
!foo users who are not members of the group foo.
>x# unit groups
<x# unit groups
account users who have an account defined and have
some credit/money left.
nomoney users who have an account defined, but don't
have any credit/money left.
noaccount users who don't have an account defined.
limit# users who have the limit value #.
sys# users who have the sysop access #.
node# user is in node #.
List of all groups that can be reassigned:
Group name Who should be members?
=======================================================================
conf@ users who have no read or write access to
conference conf.
conf@r users who have only read access to the
conference conf.
conf@w users who have both read and write access to
the conferece conf.
conf@s users who have sigop access to the conference
conf.
conf@=regexp users who have no read or write access to
conferences matching the regular expression
regexp.
conf@r=regexp users who have only read access to the
conferences matching the regular expression
regexp.
conf@w=regexp users who have read and write access to the
conferences matching the regular expression
regexp.
conf@s=regexp users who have sigop access to the conferences
matching the regular expression 'regexp'.
nochat users to whom sysop should always be
unavailable for chat.
okchat users to whom sysop should always be available
for chat.
nonode users to whom members of other nodes should
always be unavailable (i.e. users who should
not be able to send node messages).
nocreate users of this group can't create new chat
channels.
nofeel users who should not be able to use feelings.
okuser users who should be able to log in during a
"nouser"-event.
ftp users who should be allowed to use the main
menu command 'ftp' to FTP out.
url users who should be allowed to use the main
menu command 'url' to URL out.
rlogin users who should be allowed to use the main
menu command 'rlogin' to rlogin out.
telnet users who should be allowed to use the main
menu command 'telnet' to telnet out.
finger users who should be allowed to use the main
menu command 'finger' to finger out.
hunt users who should be allowed to use the main
menu command 'hunt' to play Hunt.
hack users who should be allowed to use the main
menu command 'hack' to play NetHack.
irc users who should be allowed to use the
BBBS groupchat to interface with the Internet Relay
Chat.
BBBS supports a wide variety of message conferences. It allows for support
of netmail, email, echomail, local mail, and newsgroup conferences. Echomail
conferences can support AllFix FileFind support and NameFix support (an
echomail-based user searching tool).
Conferences are defined in the BCFG4 program using it's menu-driven
fullscreen interface. A description of each configurable option can be found
in the Global: Confs section.
To setup specific "special" conferences:
Netmail conference setup
Email conference setup
Setting up a netmail conference is relatively painless. The netmail conference
must be defined as your first "echoed" conference (ie. it must be listed before
any email, echomail, or usenet conferences). This conference can have any name
you like (ie. "netmail" or "local.netmail" or anything else you might prefer).
The Fidoname of the conference should simply be "-". For the different flags,
you should have Post conf. and Fido area checked.
And that's it! Now all netmail for your system will be imported to and
exported from this conference.
Configuring the email conference is pretty easy. The email conference must be
defined after any netmail conferences you might have. It can have any name you
like (ie. "email" or "local.email" or anything else you might prefer).
The Fidoname should be a "-", as well the NNTPname should be a "-" also. Then
simply check Post conf. and you've finished setting up your email conference.
The format of email addresses in BBBS is firstname.lastname@yourdomain.com,
where yourdomain.com is defined in BCFG4://Global/General/Hostname.
NOTE: If you use a UUCP gateway for email (and won't be using the internal SMTP
and POP3 daemons), you need to check BCFG4://Global/Toggles/Email-O-Magic as
well. As well, you need to change a few things in the email conference setup.
Go back to the email conference you just defined and check the Fido area
toggle. Now put the gateway FTN address in the Moderator field. This will
rewrite all email into a netmail message destined for the defined Moderator (or
gateway).
If you are going to be using the SMTP or POP3 daemons, you can have BBBS
automatically send outgoing email by using the "bbbs bsmtp r mail.your-isp.com"
command on the commandline (you should make this a regular event so that email
goes out quickly). All incoming email received by the BBBS SMTP daemon will be
written into the conference you have just defined.
The BBBS filesystem, File/4, is a bit different than the filesystems on most
systems you've seen. File/4 has a tree-like structure and is based on a command
shell, so users familiar with most OS shells should feel pretty much at home.
The core of File/4 is the virtual directory structure defined in
filedir*-files. Virtual directory structure can but need not be the same as the
real directory structure in your hard disk. Individual directories are in turn
set up with descript.ion-files and the BBBS group system.
The virtual directory tree for File/4 is created with filedir-files in your
BBS root directory. This is the directory structure that the users see when
browsing your file areas. Filedir-files have a running number as their
extension. There are three kinds of filedir-files. For each type of
filedir-file the extension has a different meaning. The different types are:
1) The filedirg-files (named filedirg.nnn, starting from 000). These
are used to define the global file directories. Global file
directories are always added to the directory structure. The
extension number in filedirg-files has no special meaning, but you
can have multiple filedirg-files, if you have large fileareas and
want to keep different kinds of directories in different
filedirg-files.
2) The filedirn-files (named filedirn.nnn, starting from 001). These
are used to define directories specific for each node. For example,
directories that should be available only for node 1 should be
placed into the file filedirn.001. The first such line that
the user can write to in the filedirn-file defines the "hold"-directory
for that node and it must exist. Hold directory is used by the
users to temporarily hold files which they want to download or otherwise
handle. If you do not create a hold directory for a node, BBBS will
complain "hold not found" when a user enters the fileareas. Therefore,
you'll need a filedirn-file for each node you want to be able to access
files. For things to be universal in all BBBS systems, please name your
hold directory /tmp. For global configuration files, you can
also use the hash symbol ('#') to be substituted for the current node
number in the special global filedirn-file filedirn.000. Example:
filedirn.000:
/tmp /home/bbbs/node#/hold @rw:all @e Your personal hold dir
filedirn.001:
/tmp /home/bbbs/node1/hold @rw:all @e Your personal hold dir
3) The filedirc-files (named filedirc.nnn, starting from 000). These
are used to define directories specific for a certain conference.
For example, the file filedirc.012 specifies directories that are
added to the directory structure only when the user is in conference
number 12.
The structure of all filedir-files is simple. Each line of the filedir-file
specifies one directory entry. A single entry should consist of three fields:
virtual_directory real_directory description_and_flags
Virtual directory is the name of the directory that the user sees when browsing
the file areas. It should be written in lower case. Creating a directory like
/Windows/Games will not work, it will only show the directory /windows and not
its subdirectories.
Real directory is the actual directory on your hard disk or CD-ROM where the
files belonging to this directory should be stored. You must create these
directories.
It is very important that you use a forward slash ('/') as the directory
separator in BOTH virtual directory and real directory fields and NOT a
backslash ('\'). This is because backslash is used as an escape character in
BBBS. Also, it is very recommended that you use only lowercase characters in
virtual directory pathnames.
Description is simply a short description of what kind of files the directory
contains.
Flags are very important: they are used to specify various things for the
directory. One of these is the directory access. By default, everyone can read
the files in every file area. To define which groups are allowed to read and/or
write from/to the directory, the following flags can be used:
@r:group1{,group2{,...}} (specified groups are given READ access to
the directory)
@b:group1{,group2{,...}} (specified groups are given BROWSE access
to the directory)
@w:group1{,group2{,...}} (specified groups are given WRITE access to
the directory)
@u:group1{,group2{,...}} (specified groups are given UPLOAD access to
the directory)
@rw:group1{,group2{,...}} (specified groups are given both READ and
WRITE access to the directory)
(@wr flag is synonymous to the @rw flag)
READ access means that the users belonging to such a group can only read files.
That is, they can type or download files in the directory. WRITE access allows
users to also delete or move the files in the directory. Therefore, users
should normally have only READ access to most directories. BROWSE access
means the user can enter the directory and do a directory listing, but can
neither read nor write to the directory. UPLOAD access means the user can
upload a file to the directory, but cannot move or delete files.
An example of the @b flag might be in the case of adult files where you
might use an access string of @w:fsysop @r:pic18 @b:all. This would mean
that all the files in the directory can be manipulated by the group fsysop, can
be downloaded by the group pic18, and can be listed by all users.
The @e-flag, when added to the flags-field of the directory, is used to prevent
new files scanning for that directory. This is useful for directories that
don't change, like CD-ROMs.
By default, BBBS uses a file called descript.ion in the directory's real
directory as the description file for the directory. You can change this with
the @0 and @1-flags. The difference is that with @0, the file size and date are
read from the disk, with @1 they are read from the descript.ion-file. This is
useful with CD-ROMs.
For example, if you specify this in your filedir-file:
/ c:/root/ Root directory
/graph c:/pictures/ Assorted pictures
/graph/people c:/pictures/faces/ People @0c:/descs/faces.desc
BBBS would search the descriptions for files from the files
c:/descs/faces.desc, instead of c:/pictures/faces/descript.ion.
Note how the root directories for the directories /graph/people and /graph have
to be specified. Otherwise they would not show up in the directory listing.
Also, the description output can be formatted with the @n and @@ flags. @n
generates a single line feed to the description and the @@ creates one
'@'-character.
If a line in a filedir-file begins with a dot, then the filename after the dot
(separated with a space) must exist or the directory entries after the dot-line
will not be included to the directory tree. This feature can be used with
removable media, such as a CD-ROM. You can have one directory for all your
CD-ROMs as long as you define correct dot-lines to ensure that the disk in the
CD-ROM drive is autodetected.
Descriptions for files in a File/4 directory are stored in a 4DOS-compatible
descript.ion file. They can have a "hidden" attribute, but not read only, as
BBBS needs to rewrite the file from time to time. The format of a descript.ion
file is simple:
filename description_and_flags
Description is simply the description for the file. If there is a description
for a file that does not exist on the disk, then it is displayed in the
directory listing, but is marked "offline" by BBBS. In the description, some
flags can be used:
@r:group1{,group2{,...}}
Give READ access to the specified groups for this file. Members of
groups with READ access can read the file, that is, they can download
or type it.
@w:group1{,group2{,...}}
Give WRITE access to the specified groups for this file. Members of
groups with WRITE access can write to this file. That is, they can
for example delete it, if this has been enabled in BCFG4. Having a
WRITE-access to a directory overrides the read-only-access on a single
file.
@p:group1{,group2{,...}}
Make the file PRIVATE for the specified groups. Only the members of
these groups can see this file, except for users that have a WRITE
access to the directory that the file is stored in.
@@
Write a single '@'-character to the description at this point.
@n
Insert a new line to the description at this point.
@f
Make this file free. Free files can be downloaded by all users if
they have at least READ access to the directory. Free files can be
downloaded even by users without download access. You should make
especially useful files, like virus scanners, off-line mail programs
and the BBBS, free so that all users can download them immedately.
@ltruefile
The file is a link: the real file is stored at the directory pointed to
by truefile. The original file should still exist (use 0-byte files).
Note that truefile can also be a link to some other file. If you use a
lot of links, remember to run BLINKFIX daily.
@adate
The date date should be used as the file's date, specified in
yymmdd-format. This is used in description files referred to via
a @1-flag in the filedirg-files.
@ssize
The file should be marked as size bytes long, no matter what.
This is also used with the @1-flag.
@e
The file will not be included to new file scan.
@d
The number of downloads this file has received. This is incremented by
one every time someone downloads the file.
There are two special files that can be used to format the directory list
output. These files are "." and "..". You can specify multiple entries for
them. The description for the file "." is displayed in the directory list
as-is, without the dot. Files before and after the "."-file are sorted
separately by BFILSORT. The description of the file ".." is displayed right
after user changes to this directory, and again, without the ".." prefix.
Example:
.. The current BBBS version is 4.00 MP.
.
. The main files are:
.
bbbs_d.zip The BBBS executables for PC-DOS. @d223 @f
bbbs_2.zip The BBBS executables for IBM OS/2. @d543 @f
.
. Some other files:
.
bbbshelp The BBBS help file in English. @d72 @f
The external.bbb-file is used to configure most things that can be considered
"external". This includes archivers, external protocols and some
networking configuration.
The external.bbb-file is divided into sections. A section begins with the name
of the section in brackets ('[' and ']' characters) and continues until another
section starts. Like in all BBBS configuration files, empty lines and lines
beginning with a semi-colon (';') are ignored.
You can also implicitly force a certain section be used only if a certain
version of BBBS is run. This can be accomplished by naming the section
[section.os]. os can be any of the following, depending on the version of BBBS
you wish to use those definitions with:
os2 BBBS/2, the OS/2 version.
nt BBBS/NT, the Windows NT/95 version.
dos BBBS/D, the PC-DOS version.
sunos BBBS/SUM and BBBS/SOS, the SunOS versions.
irix BBBS/IRX, the Irix version.
hpux BBBS/HP, the HP-UX version.
ultrix BBBS/U, the Ultrix version.
sco BBBS/SCO, the SCO UNIX version.
solaris BBBS/SOL, the Solaris version.
unixware BBBS/UW, the UnixWare version.
linux BBBS/LiI, BBBS/LiS, BBBS/LiA, the 80386/SPARC/Alpha Linux version.
freebsd BBBS/FBI, the FreeBSD version.
Note that the OS-specific sections (such as [af_pack.os2]) must be listed
before "global" sections (such as [af_pack]), as BBBS will use the
configurations from the first usable section it encounters.
The archivers BBBS uses are configured in the external.bbb-file, in four
sections. In all sections one line defines one archiver: line #1 for archiver
#1, line #2 for archiver #2 and so on. For each archiver, all sections must be
defined. The character - in any line means that archiver is disabled.
The sections used are:
[af_ext]
In this section, the extensions used by the archivers are configured. The
extensions specified here are also used to identify the archiver used when the
user information is listed in the user editor.
[af_ident]
This section defines an unique "fingerprint" for each archiver. You need to
specify the offset of the fingerprint (starting from 0) and of course the
indent bytes, in hexadecimal, separated with a comma. If the indent bytes are
found from the specified offset in any file, then that file is assumed to be
packed with the archiver with the corresponding indent bytes.
[af_pack]
This section specifies the OS command string used to pack a single file into an
archive.
[af_unpack]
This section specifies the OS command string used to unpack a file or a set of
files from the packet to the current directory.
For the af_pack and af_unpack sections, you can use the standard
external.bbb meta characters to specify various things, like the name of the
archive.
If you add or remove archivers, you should also remember to edit the line 359
in your bbbstxt-files to reflect your archiver setup. Otherwise your users
might select archivers that are not available. In the bbbstxt-file, the
archiver names are separated with a slash ('/'). To add an archiver, simply
write an appropriate name at the end of the list. If you want to disable an
archiver, then just remove the appropriate archiver's name, but NOT the slash,
unless you remove it also from your external.bbb.
Note! In all command lines you should use the directory separator of your
operating system!
Example:
; Example of a single archiver definition:
;
[af_ext]
zip
;
[af_ident]
00,504b
;
[af_pack]
c:\bbbs\pack\zip.exe -9 -j %p %F
;
[af_unpack]
c:\bbbs\pack\unzip.exe -j -o -C -s -q %p %f
The file transfer protocols are configured in the external.bbb-file. For each
protocol, there are three sections that need to be configured. In each section,
the first line is for protocol #1, the second line for protocol #2 and so on.
The '-' character in any line means that protocol is disabled. BBBS can also
handle protocol numbers 1 to 11 internally, but you can use an external program
for them too if you like.
The sections used are:
[t_name]
This section simply defines the names of the protocols. The only place they are
shown is the user editor to identify the used protocol.
[t_download]
This section defines the OS command strings to launch the protocol to download
(send to the remote user) a set of files, the names of which are in a specified
file. The meta-character '%f' can be used to insert the name of this list file.
[t_upload]
This section defines the OS command strings to launch the protocol to upload
(receive from the remote user) files into the current directory.
As with archivers, you can use the external.bbb meta characters in the
t_download and t_upload-sections.
BBBS can handle 11 different protocols internally:
zmodem
ymodem
xmodem
slow-hydra
xmodem crc
ymodem batch
slow-zmodem
hydra
zedzap
kermit
uucode
If you add or remove protocols, you should also remember to edit the line 358
in your bbbstxt-files to reflect your protocol setup. Otherwise your users
might select protocols that are not available. In the bbbstxt-file, the
protocol names are separated with a slash ('/'). To add a protocol, simply
write an appropriate name at the end of the list. If you want to disable a
protocol, then just remove the appropriate protocol's name, but NOT the slash,
unless you remove it also from your external.bbb.
Note! In all command lines you should use the directory separator of your
operating system!
Example:
; An example to use the GSZ program instead of the internal ZModem:
;
[t_name]
ZModem
;
[t_download]
c:\bbbs\prot\gsz.exe portx %b,%i %h"handshake cts "sz @%f
;
[t_upload]
c:\bbbs\prot\gsz.exe portx %b,%i %h"handshake cts "rz
In the external.bbb-file, there is also several sections related to FidoNet
technology networking configuration. They are:
- The nodelist section (section nodelist)
- The FidoNet echomail area setup (section echomail)
- The FidoNet nodes setup ssection nodes)
- The file-echo configuration sections (sections tick.adopt and ticks)
- The node and NetMail remappers (sections node_remap, netmail_remap,
netmail_copy and netmail_bounce)
- Badecho configuration for BCFG4 (section badecho)
- Badtick configuration for BCFG4 (section badtick)
- AllFix FileFind configuration (section archive)
Also, an arcane AGNET/QWK-style network can be used with BBBS. Setup for
such a network is done with the external.bbb-section agnet.
FidoNet technology networks use nodelists to work out the destinations of
echomail messages. A nodelist is a list of all (or some) systems in the
network. In BBBS, the nodelists are listed in the external.bbb-file, under the
section nodelist. Under this section all nodelists that BNC should compile are
listed. After each name, an additional wildcard-specification for a nodediff
(used by BNDIFF) can be specified. If the second parameter starts with an
exclamation mark ('!'), then the nodelist specified is replaced by the file
specified by the second parameter. An ampersand character ('&') works like an
exclamation mark, but the second parameter must specify a compressed list.
Remember that full nodelists should be uncompressed, whereas nodediffs should
be in compressed form.
In all nodelist-section entries wildcards are allowed.
Example:
[nodelist]
; A normal nodelist for foonet:
c:/bbbs/nodelist/foonet.list
; lukki.lst in c:/bbbs/nodelist is replaced by lukki.list in c:/inbound
; when there is one...
c:/bbbs/nodelist/lukki.lst !c:/inbound/lukki.lst
; barnet.list is replaced with the one from the compressed file barnet.zip
; in c:/inbound when there is one...
c:/bbbs/nodelist/barnet.list &c:/inbound/barnet.zip
; Assuming all nodediff.* files in c:/bbbs/inbound/ are diffs for the nodelist
; below...
c:/bbbs/nodelist/nodelist.* c:/bbbs/inbound/nodediff.*
The FidoNet network echomail areas are defined under the section echomail, in
the external.bbb-file. This section is automatically updated by BCFG4 when it
saves the conference configuration, but you can modify it also by hand if you
like. Note that your 'NetMail' area should NOT be added to this section.
The format of the echomail-section is simple: one line defines one echomail
area. A single entry consists of six fields, separated with spaces. The fields
are (from left to right):
group A single character group ID for this echomail area. Any
character can be used. Areas from different networks should be
configured under a differing group ID. If you are running a
host or a hub, the accesses of your downlinks are defined with
these group IDs.
areatag The area tag for this echomail area. The echomail is
distributed between systems under this name.
bbbs name The name of the conference to which messages to this echomail
area should be written to. If the conference name has spaces,
enclose the name in quotes. If you want to give the conference
the same name as the areatag of this echomail area, use a single
'-' character here. A '!' character in this
field makes this area a passthrough area. For passthrough areas
at least one add-aka should be defined (see below).
add akas The list of akas that should be added for this area. BOGUS also
adds your default aka (defined in BCFG4) for this echomail area.
Note that you can specify multiple akas here. You should not
write the same aka twice. For passthrough-areas at least one
aka should be defined in this field.
flags Here you can specify one or more flags for this area. Just list
the flags you want to activate one after another. If you don't
want to use any flags, use the '-' character only. Allowed
flags are:
S Secure: incoming mail to this area is accepted only if the
the area's uplink is listed in the export list.
Whenever possible, use this flag.
V Visible: area is visible in areafix listings even to nodes
who don't have access to it.
D Don't perform any dupe checking for this area.
< Allow only message import (do not export to nodes).
> Allow only message export (do not import from nodes).
export The list of nodenumbers this echomail area should be exported
to. You can list as many nodes as you like. You can use only
net/node if the node is in the same zone as the previous node,
or only node if zone:net is the same. If you add a '>'-character
in front of a nodenumber, then it is marked only for export. If
you add a '<'-character in front of a nodenumber, then it is
marked only for import.
As with tick file-echoes, you can also specify a description for the
echomail area after all fields by prefixing it with a slash ("/") character.
If you don't specify a description here, then the one defined in BCFG4 is
used. This way you can add descriptions also for passthrough areas.
Example:
[echomail]
; An example echomail-section definition:
; gr areatag bbbs name add akas flags export
; -- -------------- ------------------- ----------- ----- --------------
B BBBS.ENGLISH - - S 47:1000/101
G GENERAL "MAIN BOARD" 40:765/151 S 40:765/765 49
P TESTAREA ! 40:765/151 S 40:765/765 49
The nodes in a FidoNet technology network you want to poll from or that poll
you are defined under the section nodes in the external.bbb-file. The format of
this section is simple: one line defines one node. In a single entry there are
ten fields, separated with spaces. From left to right, the fields are:
node The FidoNet address of this node.
spass The session password that is used with BBBS's internal BackDoor
mailer. If you want to run a secure system, you must specify
both mail session password and packet password for all nodes.
apass BRoboCop (areafix) requests from this node must have this
password in the subject of the message.
ppass The "packet-password"; a password stored in outbound packets
going to this node. This same password has to be also in inbound
packets from this node to make sure the packets are really from
that node.
tpass The password for TICK files.
gr The echomail area groups that are available for this node for
both reading and writing. Groups that are listed after the '!'
character, including the group '!', can not be disconnected,
only connected.
st Specifies the flags for this node, as well as the status of
outbound mail packets for this node. List the flags one after
another or use the '-' flag if the node is to have no flags
and "normal" status (mail is transferred regardless of the
poller). Normally the '-' flag is used. Available flags are:
C The mail packets for this node are automatically crashmail.
H The mail packets for this node are hold: they are not
polled anywhere. Instead, the node must pick up them.
! Do not route NetMails directly to this node.
B Do not use HYDRA protocol with this node.
R Do not use the EMSI handshake with this node.
X Do not use the xHYDRA protocol with this node.
D Do not use FTS-0001 handshake with this node.
pa Specifies the archiver that should be used with this node. It
should be a number, pointing to the appropriate archiver entry in
the external.bbb-file. 0 means "don't pack".
route The routings for this node. By default, BOGUS automatically
routes all NetMail to this node directly to it. With this field
you can specify more. You can list as many routings as you like.
One routing can be either zone:*, specifying all nodes in
that zone, zone:net/*, specifying all nodes in that net or
even a complete 4D-address (zone:net/node.point). Also, if you
add an asterisk, '*', in front of a routing, then BOGUS will scan
your nodelist for all downlinks of the hub or region specified
and route also their mails via this node.
email The destination email address of this node. This field
is only necessary if this node is to receive their mail archives
and file attaches via UUcoded email. The format is a simple
email address like filebot@bbs.semel.fi. For BBBS to
automatically decode incoming emails into your inbound mail
directory simply have your down/up-links send the email to
filebot@yourdomain.com (ie. if your defined domain name was
bbs.freezer-burn.org they should send file-mail to
filebot@bbs.freezer-burn.org). You can filter out unwanted
filebots by using inet.bbb or smtpfilt.bz.
Example:
; An example nodes-section:
;
[nodes]
; node spass apass ppass tpass gr st pa route
; --------- ------- ------- ------- ----- --- -- -- -------------------
47:1000/101 privat passw - fub BCD H 3 47:* 27:47/* 2:20/0
2:222/222 sesonly - - - - ! 3
2:222/0 boot boot boot boot BD ! 3
2:222/70 boot boot boot boot C - 3 1:* 2:* 3:* 4:* 5:* 6:*
2:222/71 boot - boot - - ! 3
; hub route:
2:22/222 session foopass pktpass tick B C 3 *2:22/222
; region route:
2:222/69 example foopass packet tick B C 3 *2:22/0
; email node:
23:58/4 blah blah blah blah F - 3 23:* blah@blah.com
Adopting files
FidoNet technology TICK-style file-echoes are configured with two sections in
the external.bbb-file: the tick.adopt section defines the files BTICK should
generate a TICK file for. For each file, three sequential lines under
tick.adopt should be listed. The first line should contain the TICK areaname
that should be used with the file. The second the file name, wildcards are
allowed. Finally, the third line should contain a description for the file.
Please be careful with the tick.adopt-section as there is no way to check who
originally sent the file for you!
Defining TICK file-echoes
The TICK file-echo areas are defined under the ticks-section. Under the
ticks-section, one line defines one file-echo. One entry consists of seven
fields, separated with spaces. The fields are, from left to right:
gr A single character group ID for this tick area. Any character can be
used as the group ID. Different types of file-echo areas and
especially file-echo areas of different networks should be grouped
under a differing group ID. If you are running a host or a hub, the
file-echo area accesses of your downlinks are specified in the
nodes-section with these group IDs, so be clear with them.
tag The name of this file-echo area.
path The directory to which incoming files for this area should be moved
to. This directory must exist.
aka The nodenumber that should be used with this file-echo area.
You can also list many akas. These are all listed in the TICK file.
afl The area flags for this area, listed one after the another. You can
use multiple flags. See below for export flags as you can use them
in this field, too. You can also use the '-' flag to disable all
flags, and usually you should. The available area flags are:
V Visible. Show the existence of this file echo even to those
areafix requesters who do not have access to this file echo,
ie. those who do not have the group flag assigned in the
[nodes] section. Note that they only see this area, they can
not connect to it.
Z file_id.diz should not be used in this area.
Do not autodescribe files on this file echo, not even if they
do not have a description field in .tic file
R Don't check CRC of the incoming file.
! Passthrough, do not update descript.ion-files.
A Appends the data of the received files to work/tickinfo and
work/tickinfo.<group> files; this can be used to create lists
of received files or new file announcements.
export The node numbers to which this file-echo area should be exported to.
You can list as many node numbers as you like. You can also use one
or more export flags in front of the node number. The available
flags are:
@ This node is unlinked, no files should be sent to it.
+ Do not send a tick file to this node, just forward the file.
< Accept files from this node, but do not send any.
> Only send files to this node.
H Mark files as hold, so that the node in question must pick up
them.
C Mark files as crash, so that you will poll them to the node.
N Mark files as normal (the default).
After these fields the slash character ("/") and the description for the
file-echo can follow, but are not mandatory.
Note that the password used with tick-files is configured in the nodes-section
of external.bbb!
Examples:
[tick.adopt]
[ticks]
; gr tag path aka afl export desc
; -- ----- ------------ ---------- --- -------------- -------------------
A BBBS d:/pub/bbbs/ 2:22/222 AH <2:222/222 @42 /BBBS and utilities
V LUKKI d:/pub/txt/ 40:765/151 HS 40:765/765 /LukkiVerkko
New file announcements can be easily automated this way as well by using a few
simple commands. If the A flag is set, information is placed in a file called
tickinfo.[group] in c:/bbbs/work. To announce new files you might use something
like:
bbbs btxt2bbs fido.announce c:/bbbs/work/tickinfo.txt /F SysOp /T All /S
New File Announcement
See BTXT2BBS-command for more information.
Let's look at an additional example:
M BBBS /home/bbs/tickfile/bbbs/ 2:211/16 A 2:211/37 220/851 /BBBS files
| | | | | | |
| | | | | | `- descr.
| | | | | `- list of up/down links
| | | | `- flags, see above
| | | `- your aka used in this file echo
| | `- real directory (where to put files)
| `- echo tag
`- group
This means, that
- The group flags was 'M'. This will cause the following:
- all nodes who do have 'M' in group flags field in their entry in [nodes]
section of external.bbb may connect or disconnect BBBS file echo
- announce data of the received files will be added to files
work/tickinfo and work/tickinfo.M
- the echo tag is "BBBS"
- incoming files to this file echo will be moved to /home/bbs/tickfile/bbbs
- you send files to this file echo as 2:211/16 and receive files to this
file echo if they are addressed to 2:211/16
- flags are 'A' (see above)
- You accept files from 2:211/37 and 2:220/851 and forward new files to
these nodes
- the area description field in .tic files and in areafix requests
will be "BBBS files"
With BBBS it is also possible to remap NetMail destinations and nodelist
entries. The sections node_remap, netmail_remap, netmail_copy and
netmail_bounce in the external.bbb-file are used to accomplish these things.
[node_remap]
The section node_remap can be used to add or override a nodelist entry. This is
useful for example points that need only one or few nodelist entries and not
the whole nodelist. One line of node_remap-section defines one remapping. The
syntax of one node remap entry is:
,4d_nodenumber,sitename,location,sysop,phonenumber,flags
All fields should be self-explainatory. The phonenumber-field can have multiple
phone numbers, separated with colons (':'). When BackDoor tries to dial this
system, one phone number is selected at random. Note that the
phone number conversion in BCFG4 is done to these phone numbers as well!
For telnet/binkp nodes, the phonenumber-field is used to indicate the domain
name or IP address of the remote system. Using the hash symbol ('#') after
the domain name or IP address specifies a non-standard port to use.
The flags-field is the standard FidoNet flags that are active with this system,
separated with commas. Some recommended special flags for telnet or binkp
nodes can be used as well, specifically IBN to indicate Binkp capabilities
and ITN to indicate telnet capabilities. If you also change the dialling
properties of any given node, you can use these flags to specify special
init strings (ie. ATR for Binkp/RAW nodes), or to restrict certain nodes to
dialing telnet/binkp systems on telnet nodes and not to dial such systems on
nodes connected to a regular dialin line. IBN and ITN flags are also used
in nodelists according to the FTS-500x specs.
Example:
[node_remap]
; A Foobar-site with three phonenumbers that can be dialled:
; Note that nodenumber is in 4D-format!
; Joe Hacker at 12:34/5 with three phone numbers to use:
,12:34/5.0,Foobar-site,Foobar_City,Joe_Hacker,555-4242:555-6969:555-5555,300
; Jim Hacker at 12:34/12 with an IP-only node running telnet on port 24:
,12:34/12.0,Foobar-site,Foobar_City,Jim_Hacker,foo.bar.net#24,300,ITN
[netmail_remap]
The section netmail_remap can be used to override the sender, receiver and
their node numbers. One line under netmail_remap-section defines one remapping.
The syntax is original#new where original is a regular expression matching the
string in the following format:
sender,senders_4d_fidonet_address,receiver,receivers_4d_fidonet_address
new is the sender, receiver and FidoNet addresses the message should be
remapped to, in the same format. In new, an empty field means that the original
value should be kept.
For example, if you specify the following under netmail_remap:
^.*,.*,dino-maintainer,2:22/222.666$#,,Kalle Soiha,2:22/222.0
Then all NetMails to the user "dino-maintainer" at node 2:22/222.666 should
be directed to the user Kalle Soiha at node 2:22/222.
NOTE! If you are not ABSOLUTELY SURE that you know what you are doing, do NOT
use netmail_remap. It can do you more harm than good and the results will very
likely not be what you want.
[netmail_copy]
The section netmail_copy can be used to copy incoming netmail to other receiver
too. Unlike with netmail_bounce, the original receiver will get a copy too. One
line under netmail_copy-section defines one copying. The syntax is original#new
where original is a regular expression matching the string in the following
format:
sender,senders_4d_fidonet_address,receiver,receivers_4d_fidonet_address
new is the sender, receiver and FidoNet addresses the message should be
copied to, in the same format. In new, an empty field means that the original
value should be kept.
For example, if you specify the following under netmail_copy:
^.*,.*,dino-maintainer,2:22/222.666$#,,Kalle Soiha,2:22/222.0
Then all NetMails to the user "dino-maintainer" at node 2:22/222.666 should be
copied to the user Kalle Soiha at node 2:22/222.
[netmail_bounce]
The section netmail_bounce can be used to bounce netmail based on specific
criteria. This is a potentially dangerous item to configure, so be sure you
know what you're doing before you start bouncing netmail! The syntax is
origin#file where origin is a regular expression of the format:
sender,senders_4d_fidonet_address,receiver,receivers_4d_fidonet_address
file is the full path and filename of the text file containing the bounce
message header text. BBBS will take this file and place it above a copy of the
bounced message so when it bounces a message it might look something like this:
[bounce header file]
--------------------------
[original netmail message]
This is a useful function to have to bounce netmail to problem systems or
users. PLEASE be sure that you are not accidentally bouncing netmail that
should not be bounced! Use this section with caution!
BBBS also supports the very arcane AGNET/QWK style of networking, in which the
off-line QWK and REP-packets are transferred to and from BBS's according to
certain rules. To set up this kind of network in BBBS, the section agnet in
external.bbb is used. Under this section, each line defines one remote system
and/or user name, in the following format:
name,areafile,suffix,route_regexp
name is the name of the AGNET-user that should execute the polling. The
areafile-parameter should be the name of the file remapping the QWK numbers to
local area names, see below for more information. suffix should be the AGNET
suffix that should be used for this system. route_regexp should be a regular
expression matching the systems that mail should be routed to.
For example:
BCG BOX,agareas,@BCG,@
This will make the AGNET username into "BCG BOX". Users writing messages from
this system will be, for example "Joe Hacker@BCG". Also, all incoming AGNET
mail to this system will be routed.
In the file specified by the areafile-parameter, the QWK index numbers should
be matched against the correct local conferences. In the file, one line defines
one conference in qwk_number,local_name-style format.
For example:
15,Net.Chat
16,Net.Computers
17,Net.BBBS
...
It is highly recommended that you do not use AGNET networking unless there
really is need for it, as the FidoNet style of networking is much more
advanced.
BCFG4 can autocreate conferences for such echomail areas that have inbound
mail, but have no conference configured. This can be accomplished by running
the BCFG4 program with the "bad"-parameter.
The badecho-section can be used to control the behavior of the automatic
conference creator of BCFG4. If the badecho-section exists, then only the areas
matching the criterias defined in the section will be created. Remember also
that you must have at least one "unnamed" conference in your conference
configuration or no conferences are added. This is accomplished by entering
BCFG4, Global: Confs, and changing the Total conf field to one higher than the
number of conferences you have. For example, if you have 550 message
conferences, you must set the total to 551 (current + 1). You will see that
your next conference is called "unnamed".
Note that when you define badecho-entries and run BCFG4 with the "bad"
parameter, your echomail-section in external.bbb will be updated automatically,
along with the conference configuration in BCFG4.
In the badecho-section, one line defines one criteria in the following format
(items in curly brackets are optional):
uplink area {aka_list} {in_char out_char origin} group {area_prefix} export
uplink is the nodenumber of your uplink the echomail area must originate.
area is a regular expression matching the names of the areas that can be
created.
aka_list is a list of your akas that should be added to the messages in this
echomail area. The first aka is used in BCFG4, the rest in the echomail-section
of external.bbb.
in_char is the name of the character set that should be used when importing
messages.
out_char is the name of the character set that should be used when exporting
messages. This must be specified if you have specified also the in_char-field.
origin is the number of the origin line that should be used on the area. This
must be given if you have specified inbound and outbound character sets.
group is the single character group ID that should be applied to the area. If
the group is '-', then the area will NOT be created.
area_prefix is the prefix that should be applied to the area name. If there is
a '!' character in the prefix, then the area will be created as a passthrough
area.
export is a list of akas that the area should be exported to. The uplink is
automatically added to this list, so you do not need to list it.
Example:
[badecho]
; For areas that originate from 2:210/27: do not generate areas starting
; with the string "BBBS". Generate all the rest, with the aka 2:222/0,
; origin line 0, group F, prefix "INT.". Export the area to 2:22/10 and
; 2:222/151.666:
;
2:210/27 ^BBBS -
2:210/27 . 2:222/0 IBM IBM 0 F INT. 2:22/10 2:222/151.666
;
; All areas originating from 2:22/222, beginning with "FOO" should be
; created as passthrough areas, export them to 2:22/10:
;
2:22/222 ^FOO P ! 2:22/10
;
; For all areas from 2:22/222, beginning with "BAR" use the akas 50:123/5
; and 69:100/12, export to 2:222/151.666, using origin line 5:
;
2:22/222 ^BAR 50:123/5 69:100/12 IBM IBM 5 B 2:222/151.666
;
; For all areas from 2:22/222, beginning with "BUZ" use the akas 50:123/5
; and 69:100/12, export to 2:222/151.666, using origin line 0 and the ISO
; charset for inbound messages, and the MAC charset for outbound:
;
2:22/222 ^BUZ 50:123/5 69:100/12 ISO MAC 0 Z 2:222/151.666
BCFG4 can autocreate file directories for such fileecho areas that have inbound
files, but have no fileecho configured. This can be accomplished by running the
BCFG4 program with the bad-parameter.
The badtick-section can be used to control the behaviour of the automatic
directory creator of BCFG4. If the section does not exist then no area will be
created (default).
Note that when you run BCFG4 with the "bad" parameter, you are also updating
external.bbb and filedirg.000 with any badecho-entries you might have as
defined in the badecho and "badtick" -sections of external.bbb
In the badtick-section, one line defines one criteria in the following format
(items in curly brackets are optional):
uplink area aka_list group {flags} virtdir_root {export} {/desc}
uplink is the node number of your uplink the fileecho must originate from.
area is a regular expression matching the names of the areas that can be
created.
aka_list is a list of your akas that should be added to the seen-bys of .tic
files in this fileecho area. The first is the primary aka to use as originator
to downlinks.
group is the single character group ID that should be applied to the area. If
the group is '-', then the area will NOT be created.
flags is the flags to apply to the area. See the file-echo section of
external.bbb for a list of the flags.
virtdir_root is the name of the virtual directory root that already exists in
filedirg.000. If this virtual root directory does not exist, the new area will
not be created. If the new file-echo is called "test" and virtdir_root is
"/ticks" then the new directory created will be called "/ticks/test". If a
file-echo is called something like "foo/bar/junk" then the directory will be
called "/ticks/foo_bar_junk", and this would require a filesystem supporting
long filenames (HPFS, EXT2, NTFS, etc.).
export is a list of akas that the area should be exported to. The uplink is
automatically added to this list, so you do not need to list it.
/desc is the default description to give each of these areas. You might want to
call the new file-echos by default "New Fido Ticks" so would write "/New Fido
Ticks".
Example:
[badtick]
; For areas that originate from 2:210/27: do not generate areas starting with
; the string "BBBS". Generate all the rest, with the origin aka 2:222/0,
; assign to file-echo group C and add the V (visible) flag. Make the root
; directory /newtic and export files to 2:22/10 and 2:222/151.666, then give
; echos the default description of "New Fido Echo":
2:210/27 ^BBBS -
2:210/27 . 2:222/0 C V newtic 2:22/10 2:222/151.666 /New Fido Echo
You can restrict directories of AllFix FileFind responses in this section.
Quite simply, you define the echomail area that responds to FileFind requests,
and give a regexp of which directories to search, with an optional different
reply conference. If no reply conference is given, replies are made in the
conference that is searched.
Example:
[archie]
; areaname_of_allfix_message{,replyarea}:regexp_of_dirs_to_search
; Search all file directories for the echomail area STN.FILEFIND but only
; search file directories begining with "linux." for the echo
; FILEFIND-LINUX and reply in FILEFOUND-LINUX:
STN.FILEFIND:.
FILEFIND-LINUX,FILEFOUND-LINUX:linux..
You can use following meta chars when configuring archivers and protocols in
the external.bbb-file. They are replaced with corresponding string or number.
%e Character 27, ESC, ^[.
%r Character 13, CR, ^M.
%% Character 37, "%".
%p Packet name to/from which files should be (un)packed.
%f File that should be sent/received or file to be
(un)packed to/from a packet.
%F Filename (%f), but with "*.*" converted to "*".
%d Filename (%f) without its path.
%D Filename (%d), but with "*.* "converted to "*".
%c In PC-DOS, OS/2 and NT-versions this is the
value of either COMSPEC or SHELL variables, checked
in that order. If neither is defined, then it will be
"c:\os2\cmd.exe" (under OS/2) or "c:\command.com".
Under UNIX versions, the order is SHELL, COMSPEC.
If neither is defined, then "/bin/sh" is used.
%n Value of the "cfgl.newdir" (bl_newdir) variable.
%N User's name.
%L The current node number.
%o Comport number.
%b Comport base address (in hex).
%i Comport IRQ.
%s Comport real baud rate.
%l Comport baud rate.
%a Comport handle.
%A Comport device.
%h"text" If RTS/CTS handshake is enabled, text "text",
otherwise nothing.
The file alias.bbb is used for two purposes. Firstly, you can create mailing
lists so that you can easily send the same message to multiple receivers. The
format of a mailing list entry in alias.bbb is as follows:
listname:fidonet_number1, user_name1,
fidonet_number2, user_name2,
fidonet_number3, user_name3
...
Everything should be typed on a single line in the alias.bbb-file. You can also
create aliases for users in this way: just create a mailing list with just one
user. For email-aliases, the FidoNet number should be your own FidoNet number.
The second purpose of alias.bbb is to define the receivers for comments users
write with the global command "com". They are defined in a very similar manner
to mailing lists; to define a comment receiver, use the string COM_* as the
mailing list name. Replace * with the corresponding key the user should press
when asked for a comment receiver. After the colon, you should write the user
name or mailing list that the comment should be sent to. If the first character
after the colon is a '<'-character, then the file specified after the '<' is
shown when the choice is selected.
When you define comment receivers, remember also to correctly list the comment
receivers in the precom-file in the menus-directory.
Example:
; An example alias.bbb-file
; This one defines aliases 'B' and 'Z' for the users Kim Heino and
; Tapani Salmi at FidoNet address 2:22/222, a mailinglist called BZ,
; including the same users and three comment receivers:
;
B: 2:22/222, Kim Heino
Z: 2:22/222, Tapani Salmi
BZ: 2:22/222, Kim Heino, 2:22/222, Tapani Salmi
COM_B:Kim Heino
COM_Z:bz
COM_F:<c:/bbbs/menus/access
BBBS allows for login aliases for direct logins (telnet/dialup, not HTTP or
FTP). The format of this file is simple. Everything should be typed on a
single file in the format alias:realname.
Example:
; An example login.bbb-file
B:Kim Heino
wulfheart:Vincent Danen
All Internet access is configured in the file inet.bbb. Like the
external.bbb-file, it is divided into different sections. The sections used
are:
[telnet]
[finger]
[rlogin]
[hunt]
[ftp]
[url]
These five sections are used to configure the limitations for outgoing
connections. The telnet-section is used for limitations concerning outgoing
telnet-targets, the finger-section for finger targets and so on. Connections
can only be made to the destinations specified in the appropriate
inet.bbb-section. The syntax for an entry is:
destination:group1{,group2{,group3...}}
Before any user can use any Internet services, he must first be a member of the
group with the name of the service: the group telnet for telnet-connections,
the group ftp for ftp-connections and so on. Also, the user's destination must
be listed in that service's inet.bbb-section, and be a member of one of the
groups defined for that destination.
Only the groups listed can use the service specified in the section, and only
to targets matching the regular expression destination.
For example, to allow only members of the group blood_men to make an ftp
connection to the site ftp.pirasat.org, but allow everyone to ftp into sites
with the .fi domain suffix, you would write into inet.bbb:
[ftp]
^ftp\.pirasat\.org$:blood_men
\.fi$:all
Other configurable internet-related options in inet.bbb are:
[aka]
This section is used to define shortcuts for destinations for other Internet
services. The syntax is simple:
alias1:real1
alias2:real2
...
For example, the definition b:Kim.Heino@utu.fi would mean that the simple
destination b would be expanded into Kim.Heino@utu.fi.
[aliasout]
This section is used to define outgoing Internet-aliases for SMTP and NNTP mail
transfer and BOGUS import, when the gating option is enabled. The syntax is:
inet-address:original
@domain:@original
The first form is used to alias one local or remote user to a different
inet-name. The second is used to alias a whole domain to a different name. The
remote domain from BCFG4 is implied before checking for the entries in the
aliasout-section.
An example:
; To define the address "b@bbbs.net" be an alias for the local user
; "Kim Heino":
b@bbbs.net:Kim Heino
; To direct all mail going to domain bcgbox.bbbs.eu.org to
; p0.f222.n22.z2.fidonet.org:
@bcgbox.bbbs.eu.org:@p0.f222.n22.z2.fidonet.org
[aliasin]
The aliasin-section works like the aliasout-section, but defines incoming
Internet-aliases. For example:
; To define all mail sent to postmaster@bbbs.net to end up to the user
; Kim Heino:
postmaster@bbbs.net:Kim Heino
; To alias the whole domain bcgbox.bbbs.eu.org:
@bcgbox.bbbs.eu.org:@p0.f222.n22.z2.fidonet.org
[fingerin]
This section is used by the BBBS finger program, bbbsd. In it the remote finger
shortcuts are defined. The syntax is simple:
name:user name
name:<filename
The first form is a normal user alias, the second one can be used to show any
text file to the person fingering the name.
An example:
; To make fingering of the user "b" to display the info of Kim Heino:
b:Kim Heino
; To display the file "c:/manual" to the person fingering the
; user "rtfm":
rtfm:<c:/manual
[popalias]
This section is used by the BBBS POP3 daemon, bbbsd. It defines incoming
POP3-names to real names:
alias:user name
An example:
; Allow Kim Heino to use POP3-alias b in addition to "Kim.Heino":
b:Kim Heino
[ftpalias]
Just like popalias, this defines incoming ftp-names to real names:
alias:user name
An example:
; Allow Kim Heino to use FTP-alias b in addition to "Kim.Heino":
b:Kim Heino
[emailforward]
This defines email forwarding. If email comes in to a defined name, it will
be forwarded to the specified email address recipient.
An example:
; forward all email for b@bbs.freezer-burn.org to b@bbbs.net:
b@bbs.freezer-burn.org:b@bbbs.net
[emailcopy]
This defines email copying (or email cc'ing). This will take the message
sent to the destination email address and send a copy to the specified email
address. This function will delete the original email to the original
destination address, so if you want to keep the original of that email, you
must specify it as a recipient email address as well. These entries are
parsed after bounce/accept entries, but before alias/forward/list entries.
An example:
; copy email to sorssu@sorssu.org to bcg, torsh, ranger, and fopaman and
; keep a copy for sorssu as well:
sorssu@sorssu.org:bcg@sorssu.org
sorssu@sorssu.org:torsh@sorssu.org
sorssu@sorssu.org:ranger@sorssu.org
sorssu@sorssu.org:fopaman@sorssu.org
sorssu@sorssu.org:sorssu@sorssu.org
NOTE: This only works for local users. The above example assumes the BBS
domain name to be sorssu.org and all of the email names to be local user names
or email aliases. If you wish to copy email to someone outside of your local
domain (ie. users on your BBS) then see the [emailforward] section.
[listin]
This section can be used to allow remote users to send email directly to a
conference (like a mailing list). The syntax is:
from,sender,to:conference
All mail sent to to by from and sender sender will be written to the conference
named conference. Either of the fields can be empty, so just the other fields
are checked. For example, to write all mail sent to bbbs-chat-list@bbbs.net to
the conference BBBS.Chat, you would write:
,,bbbs-chat-list@bbbs.net:bbbs.chat
And, to write all mail coming from listserv@foo.edu to the conference foolist,
you would write:
listserv@foo.edu,,:foolist
These aliases are used when incoming SMTP messages are received and after the
aliases in the aliasin-section have been processed. Remember that both aliases
have to be full Internet addresses!
The difference between the from and sender fields are subtle. When it comes
to importing mail from mailing lists, from is usally the email address of
the mailing list itself while sender is the email address of the original
person who sent the message to the list in the first place.
[listout]
This is the opposite of listin-section. The syntax is:
conference:from,to
An example:
; Export bbbs.chat conference to scain and mollo as email mailinglist.
bbbs.chat:bbbs-chat-list@bbbs.net,scain@min.net
bbbs.chat:bbbs-chat-list@bbbs.net,mollo@iut-bm.univ-fcomte.fr
[bounce_from]
[bounce_to]
These two sections define the addresses that mail from/to should be bounced
back to the sender. Under both sections, one entry can be either a full
Internet address or just @domain. For example, to bounce all mail from
coolcorp.com and all mail sent to nomail@mysite.net, you would write into
inet.bbb:
[bounce_from]
@coolcorp.com
[bounce_to]
nomail@mysite.net
[accept_from]
[accept_to]
These are the opposite of the bounce statements. BBBS will accept only email
coming from/to these addresses. Under both sections, one entry can be either
a full Internet address or just @domain.
[bbbsd]
This section allows you to define which IP's and netmasks to deny and allow
for bbbsd. The syntax is simple:
[deny]service ip/netmask
Where [deny] is an exclamation mark ('!') to deny a service and ip/netmask
statement, and nothing to allow it. Serice can be any of the standard
protocols bbbsd supports: Telnet, raw, POP3, SMTP, FTP, finger, ident, HTTP,
MRTG, or TP. The IP/Netmask is a statement of IP ranges to allow/deny.
An example:
telnet 10.0.0.1/8
!telnet 0.0.0.0/0
The first line allows incoming telnet from 10.* while the second line denies
telnet from * (which effectively limits telnet to a typical Class A
network).
BBBS has a very powerful menuing system. The menu system is composed of
many parts. The bbbstxt-files, the commands.bbb file and the error-script
are all a part of the menuing system. It is extremely flexible and
versatile. Almost anything you want to do, you can do through these
extensions of modifying the language files and scripts, whether they be BZ,
Perl, Java or REXX.
Due to the high configurability, there is no easy way to change and
customize menus. Some users may find this daunting and may do no more than
change the help screens, while others may dive right in and customize their
BBBS to the extent that the menuing system allows. There is no right or
wrong way to customize your system, nor is there too little or too much
customization. The BBBS package was intended to give sysops as much
flexibility as they require, and the menuing system is one way of
accomplishing this.
Using the commands.bbb file is a common way of customizing menus and adding
commands to your system. The commands.bbb file resides in your main BBBS
directory and is a simple text file. The error.bz script must exist and be
compiled before this configuration file can be used because BBBS reads the
error.bz script whenever an unknown (or bad) command is typed, and the
script is what parses and acts upon the information of this file. The content
of the file is simple:
Command Menu Script, *bbbs_command or !os_command
Command is the menu command you want to add (ie. a "cd.." command in the file
menu).
Menu is a numeric value corresponding to the menu you want your command to
appear on. The following values represent menus:
1 The Read menu
2 The Main menu
3 The Utility menu
4 The File menu
5 The Chat menu
6 The Outbound menu
7 The FTP menu
128 Join No Access (user tries to join a conference they do not have
access to)
129 File CD No Access (user tries to CD to a file directory they do not
have access to)
130 bz::bfile4() (user enters the bfile4() BZ command)
[This can be used to access file areas without logging in]
131 Feelings menu
* Any menu (Global)
Script, *bbbs_command or !os_command is exactly what it says it is. This is
where you associate what action you want with your new command. You can
alias commands to other commands, call specific scripts, or run a specific
command for your operating system. To run a BBBS command, begin this field
with the asterix ('*') character, and to run an operating system command, begin
this field with the exclamation mark ('!') character.
Example config.bbb file:
;Command Menu Script, *bbbs_command or !os_command
;==================================================================
;
; alias "cd" commands:
;
cd.. 4 *cd ..
cd\ 4 *cd /
cd/ 4 *cd /
;
; other BBBS commands:
;
ACCess !,fsysop, 1 *>b You have access!
;
; scripts:
;
Who 2 e!who
Join * strjoin
BNMSG 6 bnmsg
Optionally, you can also add !regexp_of_groups before the menu parameter.
This will restrict commands to members of the specified group. In the above
example, only members of the group "fsysop" would be able to execute the
command ACCess.
When writing commands, remember to use upper case for the minimum letters
you want to use to access the command, while the lower case letters are
optional (ie. in the above example both "acc" and "access" would accomplish
the same command).
You may want to replace some internal commands with a script you have
written or downloaded. This takes a little more work, but is still quite
easy. Edit your bbbstxt-files and locate the original command and rename it
(ie. rename the /Who/ command to /XWho/). Then you place your own Who
command in commands.bbb and you have effectively replaced the internal
command. If, for some reason, you want to access the old command via
another script, you can still do so by calling "xw" or "xwho".
Another method of changing menus is by a script called error.bz. This
script is called everytime a user types in a command that BBBS does not
recognize and thinks it is a bad command. The way BBBS checks for valid
commands is by the bbbstxt-files first, then the error.bz script. This
script is what parses the commands.bbb file for information.
BBBS comes with a default error.bz in your /bbbs/scripts directory. It has
a few default commands already written, as well as the main ability to parse
and use commands.bbb. The commands internal to error.bz are:
REGEXP This displays a help topic on regular expressions (Global Menu)
CLS This clears the screen (Global Menu)
ADDON Shows the files usermenu.gr and usermens.gr, which must exist in
one of your menu directories (Global Menu
FILT MBBS-Compatability dummy command (Util Menu)
GR MBBS-Compatability dummy command (Util Menu)
RUN Runs an external script (Sysop-only command)
By looking at error.bz, and with a little understanding of the BZ language,
you can easily adapt the script to suit your needs. For more simplistic
commands, commands.bbb should be enough, but for more advanced commands that
do not warrant a whole new script, errors.bz is a great place to put them.
The script relies heavily on the parsecom() command, so you should have a
good understanding of how to use it.
Also, BBBS passes to error.bz two parameters: the command and the current
menu number. The command is what the user typed on the BBBS menu prompt and
the menu number is the corresponding number of the menu the user is in (see
commands.bbb-section for a list of menus and their menu numbers).
Remember to compile your error.bz script everytime you make changes to it.
The bbbstxt-files are the "meat" of your system. These language files are
used not only to print strings to the screen based upon user input, but they
also provide the core menu structure of your BBBS menu system.
The format of the menu lines in bbbstxt-files are simple... it is a single
line full of commands for a specific menu, with each command seperated by a
forward slash ('/') character. BBBS interprets these lines to link them to
its internal commands. WARNING: do not remove menu lines or change command
orders! If you do so, your menus will no longer work and can have
unpredictable results!
If you want to rename a command (let's say you have a better "who listing"
script and you want to use it instead of the internal Who command), change
the name of the command to something more obscure. Do not remove it or
change the order of the commands! Changing /Who/ to /XWho/ would be
appropriate.
The lines associated with menu commands are as follows in bbbstxt-files:
Line# Menu name
===== =========
9 Utility menu
10 Global menu
42 Vote menu
73 User->Alias menu
86 Grab-format selection menu
133 Read menu
191 Help menu
222 Main menu
223 File menu
331 Terminal emulation selection menu
334 Editor selection menu
357 Character-set selection menu
358 Protocol selection menu
359 Archive selection menu
360 Language selection menu
361 MG text editor menu
362 Read->Search menu
363 Read->Mode menu
364 Read->Add Msgs to Scratchpad menu
366 Chat menu
367 Logoff menu
369 Goodbye menu
371 Read->Mark menu
374 Bulletin menu
375 CTRL-K menu in the FullScreen Editor
421 Chat Window menu
427 Extended Chat menu
538 Process Grab Packet Anyway? menu
557 Outbound menu
560 Outbound menu flavour types
580 FTP menu
Not all of the above menus can be changed with commands.bbb or error.bz
because they do not have associated known menu types, however they can be
manipulated and renamed by editing the bbbstxt-files.
This section must be completed yet.
BBBS has a very powerful, channel-based chat system with feelings, familiar
from conversation systems like IRC and different MUDs. Basically, chat channels
are "discussion rooms". In every channel there can be a number of users
chatting at the same time. All messages that are sent to a channel by a person
are seen by all other members of the channel the message was sent to.
The channels can be either static or temporary. Static channels always exist,
even if there aren't be any members on them. Temporary channels exist only as
long as they have members. Static channels are defined in the file
channels.bbb, residing in the feelings-directory specified in BCFG4.
Definitions for temporary channels reside in the file channel2.bbb, but you
needn't worry about it, as BBBS will automatically update it when necessary.
Each line of the channels.bbb-file defines one static channel, in the following
format:
#channel_name channel_description
All channel names begin with the '#'-character. The description should be a
simple description of the topic or topics that should be discussed in the
channel. In the description, you can use some flags to define the behavior of
the channel:
+a Make the channel auto-invite. All users are automatically
made members of a channel with this flag.
+igroup Make the channel inaccessible to all but members of the group
group.
+ogroup The group group is given channel operator access to this
channel. Channel operators can use the /kick command to
remove unwanted users from a channel and change the topic of
channels that don't have a static topic.
+t The topic of the channel is "locked" and can only be changed
by channel operators. You don't need to specify this flag for
static channels, as topic is always locked for them.
For example:
#chat +osysops +a General public chat
#simka +isimka Private simka channel
The bans for different channels are defined in the file banned.bbb in the
feelings directory. The format of this file is simple: one line defines one ban
in the following format:
#channel_name:user_name
So, for example, to ban the user "Samuli Suominen" from the channel
#vanessa_rulez, you would write into banned.bbb:
#vanessa_rulez:Samuli Suominen
You can also have word bans for different channels. These are specified in the
file wordban.bbb. In this file, each line is a regular expression that defines
one word ban. Every time a user sends a chat message to a channel, a string in
the form #channel:message is created, with channel being the channel the
message is sent to and message the actual message. The string is then matched
against all the definitions in the wordban.bbb-file. If any of the expressions
in the file match the string, then the user sending the message is
automatically banned from the channel the message was sent to.
For example, specifying ^#chat:Call.*BBS in wordban.bbb would autoban everybody
sending a message starting with "Call" and containing the string "BBS" to
channel #chat.
The BBBS chat has also the possibility to use various feelings, familiar from
different MUDs. They can be used to give some "flavor" to the chat. There are a
lot of feelings in the BBBS distribution package, but you might want to create
your own as well. The feelings are contained in data files in the
feelings-directory specified in BCFG4. They are sorted into files by their
first character, so that the feeling abduct is in the file a.dat, the feeling
teleport in t.dat, and so on. Note that the data files are case sensitive!
There are three types of feelings: ones that require a focus (another user) for
them to be used, ones that work without a focus and ones that can be used
either with or without a focus. They are defined with the keywords wfocus,
wofocus and wwofocus, respectively.
In the data files, the feelings are listed in blocks. Each block begins with a
keyword, specifying what kind of a feeling will be defined next. Then a colon
and the name that should be used to activate this feeling. In the name, the
necessary part should be written in upper case. That is, if you define a
feeling called REMind, then it can be used by writing just "rem". The feeling
definition block consists of a starting curly bracket '{', one or more sockets
and a closing curly bracket '}'. Note that there has to be at least one space
before the closing bracket. Empty lines are ignored, as well as lines beginning
with the pipe character '|'.
There are many sockets that can be used. Which ones are required vary with the
type of the feeling. The generally required sockets are the message sockets:
selfwf: Message displayed to the person emitting the feeling, with
focused feeling.
allwf: Message displayed to all, except the person emitting the
feeling and the focus, with focused feeling.
focus: Message displayed to the focus.
selfof: Message displayed to the person emitting the feeling, without
focus.
allof: Message displayed to all, except the person emitting the
feeling, without focus.
The message sockets contain the actual feeling message to be displayed. It can
be up to 250 characters long and it will be wordwrapped automatically when
printed to screen. You can use ansi-codes in the message to override the
color-socket (see below), but it will screw up the wordwrapping.
Following variables can be used in the message string:
Var Expands to:
=========================================================================
$N The nick of the user emitting the feeling.
$F The nick of the focus.
$A The grade of the feeling. See below for more about
grades. This should follow the verb to get "correct" English.
$B The extension of the feeling. This should normally be at the end
of the feeling.
The following depend on the user's sex:
$G "his" or "her"
$P "him" or "her"
$E "he" or "she"
In lower case ($g, $p, $e), they depend on the focus' sex.
Other sockets that are not required in any feelings, but can still be defined,
are:
author: Name of the person who added this feeling.
classes: The classes this feeling belongs to, see below for a list.
color: The default color of this feeling: yellow, green, blue,
red, cyan or white. First letter is sufficient.
ext: The default extension of this feeling.
grade: The default grade of this feeling. See below for more on
grades.
group: A regexp groupname, defaults to "all". Only members of the
group specified here can use this feeling.
karma: "Karma" value of this feeling, from -10 (very evil) to +10.
standing: The political value of this feeling from -10 (extreme left)
to +10 (extreme right).
List of feeling classes:
affectionate (compassionate)
aggressive
audible (generates sound)
burgeois (capitalistic)
friendly
funny
inferior (the user of the feeling is inferior to others)
malignant (evil (towards the focus), in other words)
negative
positive
red (communist, remember also the standing-socket)
superior (the user of the feeling is superior to others)
tactile (physical, touching)
vulgar
white (monarchist or bourgoise, remember also "standing")
Grades
The grade of the feeling describes manner in which the feeling is executed.
Such as shamelessly, gracefully etc. The users can add any grade they like to a
feeling, but you can specify shortcuts for grades in the *.gra-files in the
feelings-directory. Like the feeling data files, the grades are separated into
files by their first letter: shamelessly goes into s.gra, gracefully into g.gra
and so on.
The syntax of grade files is simple, first the name of the grade (with the
necessary part written in upper case), then a colon and then what it should be
expanded to. See below for an example.
Examples:
| Some example feelings.
|
wfocus: ABDuct
{
selfwf: You $A abduct $F $B.
allwf: $N $A abducts $F $B.
focus: $N $A abducts you $B.
grade: shame
group: sysops
karma: -3
}
wwofocus: AGRee
{
selfof: You $A agree $B.
allof: $N $A agrees $B.
selfwf: You agree $A with $F $B.
allwf: $N agrees $A with $F $B.
focus: $N agrees $A with you $B.
grade: whole | wholeheartedly...
}
wofocus: BLInk
{
selfof: You $A blink $B.
allof: $N $A blinks $B.
}
| An example f.gra:
|
FATherly:in a fatherly manner
FAIthfully:faithfully
FOOlishly:foolishly
FRUstration:in frustration
FONdly:fondly
FEVerently:feverently
FINally:finally
The color schemes for the u pal-command are set up in the colors.bbb-file in
the BBBS-directory. In addition to the schemes defined here, users can create
their own customized schemes with the palette editor.
Each defined color section also has an associated color code (like \3ca)
which can be used in the bbbstxt-files. The codes for each color position has
it's own color code.
The syntax of the file is simple: first the scheme name, then a colon and then
51 characters defining the colors to be used. The characters represent
different items as follows:
Position Code Defines the color of...
==========================================================================
1. \3ca message: normal text in the header.
2. \3cb message: user names in the header.
3. \3cc message: subject lines in the header.
4. \3cd message: normal text in body.
5. \3ce message: quoted text in body.
6. \3cf message: double-quoted text in body.
7. \3cg message: net information (origin/tear/kludge lines).
8. \3ch file: the directory line in listing.
9. \3ci file: the topmost header lines in listing.
10. \3cj file: sub-directories in listing.
11. \3ck file: normal files in listing.
12. \3cl file: free files in listing.
13. \3cm file: file links in listing.
14. \3cn file: the first line of the file description in listing.
15. \3co file: the rest of the file description lines.
16. \3cp file: the numeric data (amount of downloads etc.) in listing.
17. \3cq nodemsg: chat messages sent by the user him/herself.
18. \3cr nodemsg: incoming public chat messages.
19. \3cs nodemsg: incoming private messages.
20. \3ct nodemsg: informative messages (login/logout, entered
message...) in chat.
21. \3cu nodemsg: the chat prefix string (the string displayed before
the message).
22. \3cv nodemsg: incoming public chat messages addressed to the user.
23. \3cw join: the header help lines in.
24. \3cx join: the highlighted characters.
25. \3cy join: a selected option.
26. \3cz join: an unselected option.
27. \3cA join: local public area names.
28. \3cB join: public network area names.
29. \3cC join: local private area names.
30. \3cD join: network mail area names.
31. \3cE join: area descriptions.
32. \3cF show: header lines.
33. \3cG show: total separator line.
34. \3cH show: numeric information.
35. \3cI show: number specifying the amount of personal messages.
36. \3cJ util: user info display header.
37. \3cK util: user info display texts.
38. \3cL util: user info display numeric information.
39. \3cM who: header.
40. \3cN who: nodenumber for active nodes.
41. \3cO who: nodenumber for inactive nodes.
42. \3cP who: speed for active nodes.
43. \3cQ who: speed for inactive nodes.
44. \3cR who: status text for active nodes.
45. \3cS who: status text for inactive nodes.
46. \3cT who: "when" time for active nodes.
47. \3cU who: "when" time for inactive nodes.
48. \3cV who: nickname for active nodes.
49. \3cW who: nickname for inactive nodes.
50. \3cX who: name of the caller for active nodes.
51. \3cY who: name of the caller for inactive nodes.
The character can be a number (0-9) or a letter from a to f. The characters
represent different ANSI attributes as follows:
Char Color
================================
0 Black
1 Red
2 Green
3 Yellow
4 Blue
5 Magenta
6 Cyan
7 White
8 Black with bold
9 Red with bold
a Green with bold
b Yellow with bold
c Blue with bold
d Magenta with bold
e Cyan with bold
f White with bold
The different sections represented are:
Abbreviation Menu or Command
===============================
message Message menu
file File menu
nodemsg Inter-node messages
join Message conference "Join"-command
show Message conference "SHow"-command
util Utility menu
who "Who"-command
With BBBS, it is possible to use up to ten different language configurations.
The language configuration is done with the bbbstxt-files in the BBS root
directory. The extension of the file specifies the language number it
describes. An extensionless bbbstxt-file contains the "default" language,
usually English. With the distribution package, four languages are supplied:
English (bbbstxt), Finnish (bbbstxt1), Swedish (bbbstxt2) and Norwegian
(bbbstxt3).
To edit the supplied languages or create new ones, you can use your favorite
ASCII-editor. Each bbbstxt-file should contain 713 lines. Each line describes
one string that is displayed somewhere in the system. These are (of course) the
same in every bbbstxt-file. When the strings are displayed should be pretty
self-explainatory.
When you are editing the bbbstxt-files, note that the lines should always
contain the original amount of modifiers, characters prefixed with a percent
sign ('%'). The modifies are familiar from the C-language, so that '%u'
specifies a number, '%s' a string and so on.
Other special characters in bbbstxt-files are 2 which represents a CTRL-B
character, and 1 which represents a CTRL-A character.
You can also use colors based on the color palette, using the appropriate
color codes within the bbbstxt-files. See the color palette reference for a
list of the codes you can use.
The bbbstxt-files also contain the names of the commands for the different
menus. If you want to, for example, use the error-script to replace a command,
then you should remove the original command from all your bbbstxt-files. The
error.bz-script that came with the distribution package also offers an easier
way to create new commands and replace old ones, the commands.bbb-file.
Remember that if you really want to have multiple languages, you should code
also your scripts so that they support all your languages!
Besides the most obivious configuration files, BBBS uses and creates a lot of
other files that are used. The directory names given here are not mandatory,
they can be anything you like, but you should have them like this for easier
reference in case of trouble.
By default, BBBS creates the following directories and files to the
BBBS root directory:
bad/ Badecho directory.
feelings/ Directory containing feelings and chat configuration.
grab1/ Grab directory for node one.
hold1/ Filearea "hold" directory for node one.
inbound/ Directory containing inbound FidoNet mail.
mail/ NetMail directory for file attaches.
main/ BBBS main directory, containing the messagebase etc.
menus/ BBBS menus directory, containing all the menus.
misc/ Miscellaneous files.
new1/ Temporary upload directory for node one.
outbound/ Directory containing outbound FidoNet mail.
pub/ Public file directory, used as an example in filedirg.000.
scripts/ Directory containing all the BBBS scripts.
secure/ Directory for storing secure incoming FidoNet messages.
tmpin/ Directory for temporarily storing inbound packets.
tmpout/ Directory for temporarily storing outbound packets.
voice/ Directory for storing voice messages.
work/ BBBS work directory, a general-purpose working directory.
alias.bbb The file holding the BBBS groupmail configuration.
bbbscfg4.000 Global configuration used by all nodes
bbbscfg4.x Local configuration for node x.
bcfg4.exe The configuration program.
external.bbb Configuration file for protocols, archivers and some
FidoNet stuff.
filedirg.000 The global file directories.
filedirn.x The local file directories for node x.
groups The group definition file.
The BBBS configuration files are created and manipulated using BCFG4.
Some special notes about the configuration files which will make creating a
multinode system a little easier:
bbbscfg4.000 is the global configuration file and is used by all nodes.
It's variables are edited in BCFG4 in the Global sections.
bbbscfg4.x are local configuration files for specific nodes (where x is the
node number, for example bbbscfg4.001 would be for node 1). It's variables
are edited in BCFG4 in the Local sections.
bbbscfg4.999 is the "local-global" configuration file. This file is very
unique in that it can be used to reduce similarly-configured nodes to a
single configuration file. In the past, on a 20-line system, you would need
bbbscfg4.001 through bbbscfg4.020, all seperately configured by using BCFG4 x
twenty times to configure each node. This file saves you those many steps.
It is primarily useful for telnet nodes with redundant configurations.
What BBBS does is when loading a particular node, it first searchs for a
corresponding local configuration file (bbbscfg4.x) and if none is found, it
will use bbbscfg4.999 for all the local information.
To create bbbscfg4.999, execute BCFG4 0. You may also want to edit the
Local/General/(logfile|grabdir|uptempdir) options in BCFG4 and use the hash
symbol ('#') to repre