<!doctype linuxdoc system>
<article>
<title>FBB Packet-radio BBS mini-HOWTO
<author>Miroslav "Misko" Skoric, YT7MPB,
<tt/m.skoric@eunet.yu/
<date>v1.11, 2001-11-27
<abstract>
<nidx>linux windows nt amateur packet radio</nidx>
This mini-HOWTO covers the installation and use of
the most popular amateur packet-radio BBS
software "FBB". That software works under Linux,
DOS and Windows operating systems. It serves as a
bulletin board system (BBS), a mailbox for
personal messages, a database for various texts,
documents and binary files, a server for small
useful calculations etc. Packet radio is a way of
connecting computers via amateur radio stations.
</abstract>
<sect>Introduction
<p>
I have been using FBB amateur radio software since
early nineties. It was the time of DOS operating
system, so most of us, system administrators (or, so
called system operators - sysop's), used various
packet radio software for DOS. Versions of FBB
packet radio BBS software for DOS, today are
known as "DosFBB".
<p>
I still administer one DosFBB database in the SRV
(Amateur Radio Union of Vojvodina, a part of SRJ).
It is DosFBB v7.00g23 that runs on a 486DX computer
with 16 MB of RAM and Hercules b/w graphics. Since
last December, it runs without any re-boot (excepting
some power failures). Before that, it was a bit
tricky to set up all memory management properly, in
order to avoid "frozen" system. Although this server
runs under DOS, its "radio clients" don't depend
on that. In fact, users of that DosFBB might run
their client software under DOS, Windows, Linux
or any other operating system that offer amateur
packet radio abilities.
<p>I have also used DosFBB v5.15c at home. Three years
ago, when I got my new box, Pentium 166 with 32 MB of
RAM and VGA color graphics, I switched to a Windows
version of FBB ("WinFBB"). Author of the software, an
radio amateur from France, Jean-Paul F6FBB, has made many
versions of WinFBB, including 16 bit variant for
Windows 3.x and Windows 9x as well as 32 bit variant for
Windows NT. I have run both variants until now
(at the moment it is 16 bit WinFBB v7.00g25 that runs
ok under Windows NT 4.0).
<p>New: Since Spring 2001, I run WinFBB v7.00i
(17 March 2001) under Windows 2000 Professional.
<p>The main
difference between DosFBB and WinFBB is that the
second one offers you to do other jobs with your
computer, while FBB is running as just any other
application. Beside that, it is always nice to
copy a text from another application (for example,
from an Internet email) and to paste it into a
packet radio message, or vice versa.
<p>In the mean time, I upgraded my system to the
Celeron 400 MHz with 96 MB of RAM and a big hard
disk that has enough room to install Linux and try
LinFBB ...
<p>New: In July 2001, I added 128 MB of RAM so my
home system is very confortable now.
<p>Finally, you should be aware what I want to
have here:
<tscreen><verb>
1. WinFBB when I run Windows.
2. LinFBB when I run Linux. It should be an
Xwindows application that may be
started/stopped similarly to WinFBB.
That's why X11 LinFBB package is used.
3. LinFBB when I run Linux, but as a daemon
that runs in the background. In addition,
an interface for a local user (myself)
is needed, as well as an interface to
monitor the radio chanell.
4. All three versions must be capable to
use the same configuration files, i.e.
to be able, for example, to begin from
the exact position where the other
version finished its previous session.
5. I am not an expert in Linux, so I am
only able to install "factory-made"
packages for Linux (just like to install
self executing software packages under
Windows). So, no (re)compilations here :-)
</verb></tscreen>
<sect>How to install X11 (Xwindows) version of LinFBB
<p>
<itemize>
<item>First of all, you should have running Linux
with a GUI installed. I am fully satisfied
with Gnome GUI but I suppose that KDE will
be ok too (or any other GUI available).
<p>
<item>Download or copy LinFBB (the main ftp site
is <url url="http://ftp.f6fbb.org/" name=
"ftp.f6fbb.org"> but there are many mirror
sites too). For example, if you get a file
like <tscreen><verb>x700e_full.tgz</verb></tscreen>
it means that it is X11 version 7.00e and it
contains all you need in tgz archive to install
the BBS. On the other hand, a name like
<tscreen><verb>xd700g_full.tgz</verb></tscreen>
means that it is not X11 but daemon version 7.00g
and it is also complete to unpack. Further,
<tscreen><verb>x700f01.tgz</verb></tscreen>
and <tscreen><verb>x700g.tgz</verb></tscreen>
are "upgrades" to any previous "full" package.
For example, after I have upgraded to <tt>x700g.tgz</tt>
I started to run X11 LinFBB 7.00g (04 August 1998).
Btw, X11 versions are not maintained anymore, but
I still run it here. It has some bugs but I like it.
<p>
<item>Copy the archive file in <bf>/tmp</bf> directory.
<p>
<item>You have to make a "base" directory where
your FBB will be installed. For example you
may type: <bf>mkdir /usr/local/fbb</bf> if you want
FBB to be there. You have to be logged as
'root' or 'superuser' to install FBB.
<p>
<item>Then, you should locate yourself in that
directory: <bf>cd /usr/local/fbb</bf>.
<p>
<item>Now, you should unpack the archive:
<bf>tar xvzf /tmp/x700b25.tgz</bf> (<-- use the right
name of the archive here).
<p>
<item>When you finished unpacking the archive,
you may continue installing the software:
<bf>./install.sh</bf> is the command for that. The
setup will ask you for the 'base' directory
where FBB will be installed. If you chose
<bf>/usr/local/fbb</bf> again, you will be told that
such directory already exists and all files
will be overwritten. It is ok, so you should
answer yes. If everything is ok, you should
see on the screen that fbb system
directories are created. At the beginning
of that procedure, program will ask you for
bbs's callsign, name of the city, QTH
locator, your name etc. That details will
become a part of <bf>/usr/local/fbb/init.srv</bf>
file.
<p>
<item>After that, you MUST check this file
<bf>again</bf> manually in order to fix some other
details needed (because installation script does
not fix all parts within that file).
<p>
<item>Well, so far - so good. After you have checked
all configuration files, you may start the
software: <bf>./xfbb.sh</bf> (<-- type this within
an xterm or something similar). When you
start your BBS for the first time, it will ask
you to create some files it needs, so you
should answer "yes" to the questions.
</itemize>
<p>
<sect>How to install LinFBB in addition to existing WinFBB
<p>
<em>Notice: Folks, you see, at my place, I have a
dual-boot system, consisting of Windows NT and
Linux (each of them having their own partition(s)
and file system). I wanted to have 'independent'
operating systems that won't see each other. So I
made two NT's partitions as NTFS partitions and
rest of the space used Linux as ext2 partitions.
Well, first I have installed WinFBB under NT and X11
LinFBB under Linux. Both of them worked, but there
was a big "problem": I could not share their
system files. You might say: So, what a big deal.
But, my FBB's should serve as packet-radio forwarding
stations (regardless of which one I boot at the
moment), so it was really needed for new LinFBB
to "know", for example, the position where WinFBB
has stopped the mail exchange last time (and vice
versa, of course).</em>
<p>
<itemize>
<item>Well, in order to allow both WinFBB under
Windows NT and LinFBB under Linux to use
some common files, it is needed to put these
files in a place where both operating systems can
"see". So I do that by re-installing
WinFBB onto a FAT (FAT16) partition that is
recognized by NT and Linux too. The best way to do
that is to install a "fresh" copy of WinFBB on
a FAT partition and to copy complete "old"
WinFBB from NTFS partition over the fresh
installation (whenever you are asked to
rewrite existing files, you should answer
"yes").
<p>
<item>When that is finished, you should have a "clone"
of the existing old WinFBB, but this time on
the FAT partition that is visible from under
Linux. Anyway, you should check if the "new"
installation is able to run as the "old" one.
<p>
<item>I could also recommend you to check the file
tree of WinFBB in order to become more
familiar with it. The file tree of LinFBB
is a bit different so it is advisable to
note various details here and there.
<p>
<item>Some files can't be used as they are under <em>both</em>
operating systems (without some neccesary
changes). That's why some file names should
be renamed (or, at least, you should make
appropriate copies of some files):
<p>
<tscreen><verb>
init.srv -> init_w.srv
forward.sys -> forw_w.sys
port.sys -> port_w.sys
protect.sys -> prot_w.sys
</verb></tscreen>
<p>
FBB is able to recognize and accept those renamed files.
<p>
<item>Make a backup of the actual WinFBB (I do this
by copying the whole WinFBB file structure into
the other Windows partition that <em>won't</em> be
shared with Linux, like NTFS one). You'll never
know when a catastrophe may happen, so as a result,
you won't be able to start neither of WinFBB or new
LinFBB. As a precaution, the backup might be the
easiest way to recover at least the old WinFBB for
a while (until you configure your new LinFBB, ok?).
<p>
<item>Now, you should restart your machine and boot
into Linux. Log on as 'root' or make 'su' from a
user's account.
<p>
<item>Mount a shared FAT directory (where FBB files are):
<bf>mount -t vfat /dev/hda2 /mnt/win</bf>
(for example).
<p>
<item>Copy LinFBB archive to <bf>/tmp</bf> directory.
<p>
<item>Position yourself to the 'base' directory:
<bf>cd /usr/local/fbb</bf> (for example).
<p>
<item>Unpack the archive: <bf>tar xvzf /tmp/filename</bf>.
<p>
<item>Start the installation script <bf>./install.sh</bf>
and, after asked for the 'base' installation
directory, chose <bf>/usr/local/fbb</bf>. It doesn't
matter if the program warns you that such
directory already exists so existing files
will be overwritten (by the way, if you
choose a mounted directory shared with NT,
many original WinFBB files, located there, would be
over-written by LinFBB files, so after returning
to Windows, WinFBB might not be functional
like before).
<p>
<item>Copy <bf>/usr/local/fbb</bf> to <bf>/mnt/win/fbb</bf> but do
*not* rewrite existing files with the new files
having the same names.
<p>
<item>Copy <bf>/mnt/win/fbb/init_w.srv</bf> to
<bf>/mnt/win/fbb/init_l.srv</bf> file.
<p>
<item>Edit <bf>/mnt/win/fbb/init_l.srv</bf> to what is
needed for Linux. You may use the existing
file <bf>/mnt/win/fbb/init.srv</bf> as an example.
<p>
<item>Copy newly edited <bf>/mnt/win/fbb/init_l.srv</bf>
over the <bf>/mnt/win/fbb/init.srv</bf> (if you do
not do that, maybe you wouldn't be able to start LinFBB
using <bf>./xfbb.sh</bf>, like me at first).
<p>
<item>Copy <bf>/mnt/win/fbb/system/port_w.sys</bf> to
<bf>/mnt/win/fbb/system/port_l.sys</bf> file.
<p>
<item>Edit <bf>/mnt/win/fbb/system/port_l.sys</bf> to
what is needed for Linux and LinFBB. You may use the
existing file <bf>/mnt/win/fbb/system/port.sys</bf>
as an example.
<p>
<item>Edit <bf>/mnt/win/fbb/xfbb.sh</bf> in order to fix
the right path.
<p>
<item>Ensure that you are in FBB's main directory:
<bf>cd /mnt/win/fbb</bf> (for example).
<p>
<item>Start the script <bf>./xfbb.sh</bf> to run LinFBB.
If everything is ok, your LinFBB under Linux
should run with the same configuration as
your "old" WinFBB under Windows. From this point,
both FBB's should behave very similar (actually,
I must admit that WinFBB has much better visual
quality than X11 LinFBB, but probably the reasons
for that you may find in Windows-vs.-Linux-GUI
quality battles). FYI, my actual WinFBB is v7.00g25
(05 January 2000) and X11 LinFBB is v7.00g (04 August
1998).
<p>
<item>Although this combination WinFBB/X11 LinFBB works ok, I
have noticed some problems. For example, LinFBB
was not able to use <tt>amsat</tt> forward_to_file routine
(located in <bf>/mnt/win/fbb/system/fwd</bf> directory),
because that file was composed like this (for example):
<p>
<tscreen><verb>
A AMSAT
*
P @
*
C D:\FBB\SYSTEM\SAT\AMSAT.TXT <-- looks familiar to DOS/Windows only
*
G AMSAT
*
--------
</verb></tscreen>
<p>
On the other side, LinFBB's <tt>amsat.sys</tt> (located
in <bf>/etc/ax25/fbb/fwd</bf> directory) has suggested
something like this:
<p>
<tscreen><verb>
A AMSAT
*
P @
*
C /var/ax25/fbb/sat/amsat.txt <-- looks familiar to Linux only
*
G AMSAT
*
--------
</verb></tscreen>
<p>
Well, then I copied LinFBB's <tt>amsat.sys</tt>
into <bf>/mnt/win/fbb/system/fwd</bf> directory so
it could become functional. As a result, I got
<em>two</em> <tt>amsat.txt</tt> files, one of them
for each of WinFBB/LinFBB, and of course, both files
appeared on different locations: the first one was
<bf>/mnt/win/fbb/system/sat/amsat.txt</bf> and it
was filled by WinFBB; the other one was in
<bf>/var/ax25/fbb/sat/amsat.txt</bf> and was filled by
LinFBB. I didn't like it that way.
<p>
In order to have only <em>one</em> result,
regardless of FBB version, the newly copied
<tt>amsat.sys</tt> had to be slightly changed:
<p>
<tscreen><verb>
A AMSAT
*
P @
*
*C /var/ax25/fbb/sat/amsat.txt
C /mnt/win/fbb/system/sat/amsat.txt
*
G AMSAT
*
--------
</verb></tscreen>
<p>
As you can see now, when LinFBB is active, its
<tt>amsat.sys</tt> will not forward into
its "native" location of <tt>amsat.txt</tt>.
Instead of that, it will go to the location
of the WinFBB's <tt>amsat.txt</tt> and just
add some new materials into it, ok?
<p>
Well, now it's up to you to decide what to do
with your growing <tt>amsat.txt</tt>. An old
DosFBB manual says that the 'batch' file
(I suppose, the old good <tt>APPEL.BAT</tt>)
should be adopted in order for <bf>SATUPDAT.EXE</bf>
can update <em>sat</em> tracking data and, after
that, to erase AMSAT.TXT because it is not
needed anymore. Well, I haven't found a way to
manage that in both WinFBB and LinFBB. Actually,
whenever I perform housekeeping from either of them,
it seems that AMSAT.TXT remains intact. Happily,
it doesn't grow too much, so it's not a big problem.
Any suggestion here?
</itemize>
<p>
<sect>How to install Protus password utility
<p>
<em>Notice: Well, I have been using Protus
connection filters for a long time now. At
first, it was version 3.1/1.2 for DosFBB515c
and, later, version 3.3 for Dos/WinFBB700.
I have found Protus as very useful utility
because of its implementation of BBS-to-BBS
forwarding protection using MD2 algorythm.
One of the reasons I am going to cover Protus
in this document is a fact that its author
haven't made a manual in english yet. I keep
trying to translate the original manuals
from spanish into english, but it is a hard
process. Any good 'spanish-to-english'
translator is welcomed to contact me:
<htmlurl url="mailto:m.skoric@eunet.yu"
name="m.skoric@eunet.yu">.</em>
<p>
Protus offers several interesting features:
<p>
<itemize>
<item>It can send a presentation message to
all users, informing about possibility
to make users' access more safe,
<p>
<item>It can send messages to users who have
normal access, informing about utility's
existence,
<p>
<item>It can send messages to users who have no
valid access (before disconnecting them),
<p>
<item>It can send messages to new users who have
connected the BBS for the first time, informing
them about the password utility.
<p>
<item>It can send messages to users who have entered
wrong password (before disconnecting them),
<p>
<item>It can inform sysop about almost everything
related to users' connections (new user on
the system, unsuccessful connections etc),
<p>
<item>Messages mentioned above could be translated
into various languages and used similarly as various
language files that FBB uses,
<p>
<item>Messages mentioned above could be different
for different BBS ports,
<p>
<item>Protus could be activated/deactivated at various
intervals of time using CRON.SYS system file,
<p>
<item>Passwords could be managed remotely, using an
external server, developed by Jose EB5IVB,
<p>
<item>...
</itemize>
<p>
Well, let's see what should be done in order to
implement secure access to the FBB packet
radio BBS, using Protus type of, so called, <em>c_filter</em>:
<p>
<itemize>
<item>Users of Dos/WinFBB versions of Protus
already know that it is needed to create a new
directory <bf>\FBB\PROTUS</bf> where several *.PRT
files should be placed. In addition, the
main C_FILT*.DLL files should be copied
into <bf>\FBB\BIN</bf> as well as a couple of "system",
(i.e. config) *.PRT files that are going to be
within <bf>\FBB\SYSTEM</bf> directory.
<p>
<item>After the sysop has copied all files into
the proper locations, it is needed to make
some configuration. The most important files
are two "system" ones: <tt>CONFIG.PRT</tt> and <tt>USERS.PRT</tt>
that should be carefully adopted to any
particular situation. Other *.PRT files will
work as they are in original, but they might
be translated because they are originated
in spanish (those files are just textual
information that are sent to users who
connect to the BBS). For your information,
I usualy don't care much about, because my
BBS's are so called "open systems". It means
they work quite normal for <em>all</em> users in the
same way as they worked <em>before</em> implementing Protus.
Only a couple of callsigns have password
installed and, when connecting, they know
what they are doing, so, they don't need
any additional info. Your mileage may vary.
<p>
<item>So far - so good. When everything mentioned is
done, you have to restart your FBB in order
for Protus utility to be activated. In all
connections to your BBS (including console),
you should see a line like this: <bf>{PROTUS-4.0}</bf>
just after a line [[FBB-7.00-AB1FHMRX$]. It
only gives an information that Protus is active on the
system. Users of your system who don't have
their passwords, connect just normally as before.
Users who's callsigns have password implemented,
are prompted for password just after their connections.
<p>
<item>The author of Protus, Jesus EB5AGF, has made
several working "modes" of its utility. It
is possible for users to get various kinds
of security: a fixed phrase as a password
(similar when you connect to the Internet
via telephone line, but this way the phrase
can be masqueraded within the longer answer);
a changeable answer to the 5 numbers (just
like usual FBB sysop's password); a mode
that uses automatic answer from user's client
packet programs; implementation of MD2 and
MD5 algorythms; FBB-to-FBB automatic forward
protection etc. FYI, my WinFBB is equipped
with 16-bit Protus 4.0 (13. August 1999).
There is also a 32-bit module of the same date
that would be called from within 32-bit WinFBB
(I haven't tested those two).
<p>
<item>Well, the situation regarding working location
of Protus files under LinFBB is somewhat different.
I have become familiar to the directory structure
that DosFBB and WinFBB versions of Protus have
been using, so I considered that it was enough
just to copy the same directory structure when
I started the installation of Protus under LinFBB.
It was wrong. After having pulled out the
remaining hair, the things started to work, so,
now I am going to tell you what to do.
<p>
<item>I have already told you that I have
been running here both WinFBB under Windows NT
and LinFBB under Linux (see also <tt>Linux+WinNT
mini-HOWTO</tt> and <tt>Lilo mini-HOWTO</tt>). That means
all Protus stuff has already been installed in
a way WinFBB has required, except <em>Linux</em>
executable of <em>c_filter</em> file. I
put that file into <bf>/fbb/bin</bf> directory and,
after the next restart of LinFBB, I got the
info mentioned above: {PROTUS-4.0}. But the
password protection was not likely to work.
I was told to make a new directory <bf>/var/ax25/fbb/protus</bf>
and put *.prt files there. I <em>didn't move</em> *.PRT
files from <bf>\FBB\PROTUS</bf> but <em>copied</em> them into
the new location, because I wanted Protus to
run further under WinFBB as before. The utility
still didn't want to run, unless I copied
<em>also</em> *.PRT files from <bf>\FBB\SYSTEM</bf> to the
new location (<bf>/var/ax25/fbb/protus</bf>). After I
did that, Protus became fully functional.
<p>
<item>Well, I suppose, the above info would be
useful for those of you who intend to run
*both* Windows and Linux FBB's on the same machine.
For the majority of LinFBB-only users, it is just
important to make <bf>/var/ax25/fbb/protus</bf>
where <em>all</em> *.prt files should be placed. <em>Only</em>
c_filter executable should go to <bf>/fbb/bin</bf>
and that's it.
<p>
<item>About FBB-to-FBB protection: *both* partners
have to install Protus. Password for the
forwarding partner's callsign must be the
same at *both* sides of the link. The versions
of Protus don't need to be the same (neither
the versions of FBB, neither the operating
systems, HI!). Anyway, MD5 algorythm will only
work if both parties have Protus 4.x and
above (I still don't use that, but it is not
a problem, because my two boxes, DosFBB/Protus3.3 and
WinFBB/LinFBB/Protus4.0, make all things ok with MD2).
<p>
<item>One of the interesting features of Protus is to
log unsuccessful connections. Due to the
<em>different</em> locations of *.prt files here, I have
separate logs for WinFBB and LinFBB c_filtering.
Those of you who are going to run only one version of
FBB, will have <em>one</em> complete log of connection
errors, your users make when they try
connecting your BBS.
<p>
<item>As it was told earlier, if you implemented
password protection for only <em>some</em> of your
users (but not for all of them who connect
normally) - your system is considered as
an "open" one. It means that will be logged
only unsuccessful tries to enter the system
by "protected" callsigns. But, if you decided
that your BBS can be accessed by <em>only</em> those
callsigns who are protected with Protus, it
means that your system is the "closed" one.
Then, there is no way a user could enter your
FBB unless its callsign has given a password
within your Protus. Any unauthorized try to
connect your BBS is logged.
<p>
<item>In addition,
you may decide to have a "guest" access or
a "read-only" as <em>default</em> for some ports
and/or for users who enter the wrong password.
Many combinations are possible. You could
even password protect your own FBB console!
<p>
<item>To finish with this topic for now, just to
inform you that my X11 LinFBB is equipped
with Protus v4.1b7 (15. February 2000). It
has some minor bugs, for example, it logs
incoming connections with a SSID of -48 if
a user doesn't have a SSID at all (of
course, a SSID of -0 would be expectible
in such case).
</itemize>
<p>
<sect>How to install daemon version of LinFBB
<p>
<em>Notice: You see, folks, that I keep trying to get
as many as possible versions of this great
software (Jean-Paul, F6FBB, must be very proud after
reading these words now). What I think when mention
"as many as possible versions" means that we have
learned how to get both WinFBB and X11 LinFBB on
the same computer. But, that's not all. There is a
variety of daemon versions of LinFBB. In this section
we are going to discuss how to *add* a daemon LinFBB
to the existing two: X11 LinFBB and WinFBB!</em>
<p>
<itemize>
<item>Well, many amateurs have suggested me to install
a couple of packages that weren't look to me as
too much needed for LinFBB daemon - to be run.
Anyway, I installed those packages <em>before</em>
the installation of LinFBB itself:
<p>
<tscreen><verb>
libax25.rpm
ax25apps.rpm
ax25tool.rpm
</verb></tscreen>
<p>
<item>Now it is the right time to install <tt>fbbsrv.rpm</tt>
package. The archive was composed to make its
own directories, as "base" directories. The last new
version to start with, that I have managed to find as
a <tt>.rpm</tt> package, was 7.01f Release 4 (09. December
1999).
<p>
<item>A file called <bf>fbb.conf</bf>, serving as the
replacement for <bf>init.srv</bf>, is placed in the
location: <bf>/etc/ax25/fbb.conf</bf>
<p>
<item><em>Unless</em> you are going to install daemon-<em>only</em>
system, you should make a backup of the
following existing files:
<p>
<tscreen><verb>
dirmes.sys
etat.sys
heard.bin
inf.sys
statis.dat
tpstat.sys
</verb></tscreen>
<p>
<item>Now you have to edit <bf>/etc/ax25/fbb.conf</bf>
and change some paths in case you already
have X11 LinFBB installed on a <em>different</em>
path. Here you have some examples that cover
my particular situation...
<p>
<item>Directory of data files, instead of /var/ax25/fbb,
should be <bf>/mnt/win/fbb/system</bf>
<p>
<item>Directory of config files, instead of /etc/ax25/fbb,
should be <bf>/mnt/win/fbb/system</bf>
<p>
<item>Directory of message files, instead of /var/ax25/fbb/mail,
should be <bf>/mnt/win/fbb/mail</bf>
<p>
<item>Directory of compressed files, instead of /var/ax25/fbb/binmail,
should be <bf>/mnt/win/fbb/binmail</bf>
<p>
<item>Directory of users, instead of .../home/fbbdos/...,
should be ...<bf>/mnt/win/fbb/users</bf>... (case you
don't mind that both your WinFBB and LinFBB users handle
the same location for users' files)
<p>
<item>Directory of YAPP files, instead of /home/fbbdos/yapp,
should be <bf>/mnt/win/fbb/users/yapp</bf> (the same
reason as above)
<p>
<item>Directory of documentation files, instead of
/var/ax25/fbb/docs, should be <bf>/mnt/win/fbb/docs</bf>
<p>
<item>Directory of pg programs, instead of /usr/local/pg,
should be <bf>/mnt/win/fbb/pg</bf>
<p>
<item>Path and filename for import file, instead of
C:\FBB\MAIL.IN should be <bf>/mnt/win/fbb/mail.in</bf>
<p>
<item>Now you have to edit <bf>/usr/sbin/xfbb.sh</bf>
and change some paths in case you already
have running X11 version of LinFBB on a <em>different</em>
path. Here you have an example that cover
my particular situation...
<p>
<item>Base directory of XFBB software, instead of
/var/ax25/fbb, should be <bf>/mnt/win/fbb</bf>
<p>
<item>So far - so good. Now it is the time to start
LinFBB daemon. The command for that is in the
location: <bf>/usr/sbin/xfbb.sh</bf> and it may
be executed within an <em>xterm</em>. If
everything is OK, you should get several
system messages on your screen, ending with
something like:
<p>
<tscreen><verb>
xfbbC/X server running ...
xfbbd ready and running ...
</verb></tscreen>
<p>
<item>Well, daemon itself can't be used to access the
BBS so it is needed to activate a <em>client</em>
that is <bf>/usr/sbin/xfbbC</bf>. It has a couple
of parameters (a callsign/password pairs that are
stored in <bf>/fbb/passwd.sys</bf>). Note that xfbbC can
also be activated within another <em>xterm</em>.
<p>
<item>If you are like me, you would like to activate one
more <em>xterm</em> with xfbbC in a way to monitor
your radio frequency. If you have enough room on
your screen, you may place all three <em>xterm</em>
windows side by side.
<p>
<item>When you finish your xfbbC console session, it is suitable
to use the same <em>xterm</em> to eventually stop the
daemon. First of all, with the command <bf>ps ax</bf>
you should locate PIDs of xfbb.sh shell and daemon itself,
that you may <bf>kill</bf> after that.
</itemize>
<p>
<sect>How to install an "upgrade" to daemon version of LinFBB
<p>
<sect1>LinFBB v7.02g
<p>
<em>Notice: Well, the main trouble I have discovered with 7.01f
daemon was the absence of Protus c_filter protection. As I told you
before, Protus is a "third-party" product, so it might have
some problems with the compatibility to LinFBB itself. Anyway,
it is also possible that a daemon version of LinFBB has some
special requirements over some "third-party" software.</em>
<p>
<itemize>
<item>I also noticed that my version of Protus was <em>newer</em>
than the version of daemon LinFBB I had at first. Beside
that, some hams, as well as F6FBB himself, have suggested me
to upgrade LinFBB. I have also found a "problem" that I am
still new in compiling Linux software, so, I'd rather
look for pre-compiled packages to install easily.
<p>
<item>Jose, HI8GN, has offered daemon LinFBB v7.02g as a
<tt>.rpm</tt> package (18 September 2000). I got it
from his site:
<url url="http://hi8gn.dynip.com/indice.html" name=
"http://hi8gn.dynip.com/indice.html">. But, when I tried
to install it <em>over</em> the previous version 7.01f, it
complained about some existing LinFBB files.
<p>
<item>Then I had to uninstall the old package, after what
some config files remained in their locations, but
with new <tt>.rpmsave</tt> extensions. It was nice,
so I could use them later to update my new-installed
config files.
<p>
<item>Btw, the installation of Jose's package was performed
without problems, but the new daemon was not likely to run
as I expected, although I tried to configure it as best
as I could. Not quite sure, but it looked to me that F6FBB
is likely to implement some changes not only to the main
executables but to shell files too. So, I have decided to
save copies of these new
<tt>xfbbd</tt> and <tt>xfbbC</tt> executables from 7.02g
package (I have made it with adding extensions like
.702 to the files). After that, I *uninstalled* the rest
of that 7.02 <tt>.rpm</tt>, in order to install the previous
version of LinFBB once again - the version that I was
satisfied with.
<p>
<item>So far - so good. The "old" 7.01f version was installed again
and tested one more time to be sure it was ok. Then, I just
copied the previously saved executables from the new package,
over the "old" executables. In a couple of minutes, the new
daemon LinFBB v7.02g has come in place and function. Comments...?
<p>
<item>Well, the new daemon is likely to check for some more directories
than the older version (mostly regarding <tt>7plus</tt>
operations). Next, its <tt>xfbbC</tt> console client looks better
than the previous version. But, I still miss
<tt>xfbbX</tt> client, that I have found not functional.
I hope it will be fixed soon. Finally, Protus
<tt>c_filter</tt> utility is active too.
<p>
<item>An interesting question might be: is that now a really upgraded
LinFBB daemon or not? Actually, I haven't changed the "old"
script <tt>xfbbd.sh</tt> with the new one, because during the
first tests with the new 7.02 I was getting lots of error messages.
Looks that the directory structure was a bit complicated for me
to set properly within the new version of <tt>xfbbd.sh</tt>.
After I returned to <tt>xfbbd.sh</tt> from 7.01 package, the
BBS finally started to be run, though without some functions
like over-night maintaining (that one problem I solve in a way
to boot the BBS as WinFBB under Windows NT where that task is ok).
In addition, there are still some mysterious messages telling
that <tt>m_filter</tt> has not been found or something like that.
The next tasks are to solve these issues.
</itemize>
<p>
<sect1>LinFBB v7.03
<p>
<em>Notice: As I have said in the previous section,
I haven't found an easy way to upgrade FBB's (its main
executables), without temporary uninstalling an
older version, then to install the new version - in
order to get new executables. After that is done, a
reverse procedure must be put in place.</em>
<p>
<itemize>
<item>Well, it was needed to get 7.03 package (09 December 2000)
as an <tt>.rpm</tt> package from
<url url="http://www.f6fbb.org/versions.html"
name="www.f6fbb.org/versions.html">,
that was suggested by Jean-Paul, F6FBB. Anyway,
soon after there appeared several mirror sites,
offering 7.03 too.
<p>
<item>If you use <em>GnomeRPM</em>, it is easy to uninstall
your actual LinFBB (If you just try to install new
<tt>.rpm</tt> over the existing LinFBB you will get
some error messages complaining that you already have
FBB installed on the computer). Anyway, after
the uninstallation, there you will find some config
files as <tt>.rpmsave</tt> files, so you could use
them later again.
<p>
<item>Installation of 7.03 package will give you
new executables in <bf>/usr/sbin</bf> directory.
Those new executables should be temporary given
extensions like <tt>.703</tt> (for example).
<p>
<item>So far - so good. Now you should *uninstall* the
7.03 package (of course, <tt>.703</tt> files won't
be unistalled automatically).
<p>
<item>Once again, you should *install* the <em>last</em>
one version of LinFBB daemon, that works ok with its
own <tt>xfbb.sh</tt> (in my case, that is 7.01f).
<p>
<item>For sure, many of you might find it odd, but
now it is the right time for the executables from
<bf>/usr/sbin</bf> (I mean of all fbb executables,
except those who were renamed to <tt>.703</tt>) to get
their new extensions (in my case, that is <tt>.701</tt>).
<p>
<item>Well, after that is performed, <tt>.703</tt> files
should *lose* their previously attached extensions,
in order to become usable.
<p>
<item>Folks, on that point I usually hold my breath, <bf>cd</bf>
to <bf>/usr/sbin</bf> and type: <bf>xfbb.sh</bf>
following with an Enter. If everything is fine, several
lines should scroll on the screen, ending with
something like:
<p>
<tscreen><verb>
xfbbC/X server running ...
xfbbd ready and running ...
</verb></tscreen>
<p>
<item>If you don't get something similar on your <em>xterm</em>
'window' (or on other appropriate terminal
utility), you're out of luck, so you might go
thru the procedure once again in order to be
sure you did all what was needed to be done :->
<p>
<item><bf>/usr/sbin/xfbbC</bf> is the easiest way to
check if your new 7.03 is in the game
or not. When I mention xfbbC it is good to let
you know, that I kept living in a belief that
xfbbC is also useful for regular telnet users
(who are also supposed to 'connect' to the BBS via
the same computer's console, where LinFBB is
running from). But, I have discovered that my
users, who were <em>not</em> declared as sysops,
are allowed to read all messages (including all
private messages), as well as to have some
other sysop's abilities. I did think it was
a matter of probably wrong declared security flags.
But, it was not.
<p>
<item>Recently, I was informed that <bf>xfbbC</bf>
is suitable only for sysops, but other users
(who also might have local keyboard access)
should rather try:
<p>
<tscreen><verb>
telnet localhost 6300
</verb></tscreen>
<p>
<item>... where 'localhost' and '6300' may vary from
system to system. I was pleasently surprised
when discovered that <bf>telnet</bf> is much more
useful for regular users than <bf>xfbbC</bf>.
<p>
<item>Folks, I think of making a section about the
FBB's system configuration. Until something
like that appear on the net, you should know
that all of those callsigns who are going to
use <bf>xfbbC</bf> have to be added into
your <tt>passwd.sys</tt> file. And, all of
those who are going to <bf>telnet</bf> into
the BBS have to be declared as users with
a 'M' flag (modem users). It is up to your
security precautions, if either of them will
have <em>'root'</em> abilities to the Linux box.
<p>
<item>My next issue is to use an old 286/12 MHz box,
having 1 MB of RAM and running DOS 5.0 as a
'telnet client' computer. That box also has
a NIC and I would like to 'connect' to the
BBS computer from that 'telnet client' box.
Due to my preparation for starting another
LinFBB in the local school club, where I
should have several old 286 boxes, would
be nice to offer more than one kid to
'connect' the BBS simultanously, using
a bunch of 'telnet client' computers.
</itemize>
<p>
<sect1>LinFBB v7.04
<p>
<em>Notice: Maybe I have already told you that I
use Red Hat 6.2 at home. That's why I usualy look
for <tt>.rpm</tt> packages that have been made for
that Linux distribution. And not only that. I have
also tried Red Hat 7.1 but it seemed not to support
Xwindows LinFBB 7.00g (04 August 1998). When I saw
that, I switched back to Red Hat 6.2.</em>
<p>
<itemize>
<item>Well, <tt>xfbb-7.04-2.i386.rpm</tt> (07 August 2001)
have been downloaded from
<url url="http://www.f6fbb.org/versions.html"
name="www.f6fbb.org/versions.html">
<p>
<item>Folks, this time I decided to install v7.04
as a completely "fresh" installation, i.e.
without parts of a previous daemon on the disk.
It means that I have uninstalled previous
daemon version of LinFBB and, in addition,
removed all older executables (of course, before
the uninstalation, I made the backup of some
config files that are not version depending
(like <tt>/etc/fbb.conf</tt>), in order not
to edit usual "defaults" again and again :-)
<p>
<item>The setup procedure has reported some dependency
issues. I didn't want to get bored with them
so I did install the package once again with
"--force" and "--nodeps" options.
<p>
<item>So far - so good. Then I replaced a couple of
default files with the saved ones, then mounted
WinFBB's FAT partition, made a pray and started
LinFBB's daemon. In order to accomplish that, it
was a new experience to try HI8GN's
script <bf>/usr/sbin/fbb start</bf> within an
<em>xterm</em> to start the thing. Although there
was no usual
<p>
<tscreen><verb>
xfbbC/X server running ...
xfbbd ready and running ...
</verb></tscreen>
<p>
on the screen, TNC's <em>PTT</em> lamp showed
that a beacon was transmitted.
<p>
<item>Then I wanted to use HI8GN's <bf>/usr/sbin/monitor</bf>
to see what's going on on the frequency. Although
I got something like
<p>
<tscreen><verb>
Connecting localhost ... Ok
Authentication in progress ... Ok
Monitoring channel 0 ...
</verb></tscreen>
<p>
there wasn't any traffic on the screen. In order to really
monitor the channel, I had to start another <em>xterm</em>
and type:
<p>
<tscreen><verb>
telnet localhost 6300
</verb></tscreen>
<p>
and from FBB's prompt enter the gateway, type
the "M" command you are familiar with etc. But,
interestingly, as soon as I telnet'ed to the
BBS, <bf>/usr/sbin/monitor</bf> window, mentioned
above, started
to copy whatever was going on the telnet xterm
(until that telnet session was closed). I wondered
if that was ok or not because I expected to see
the traffic passing thru the channel -
regardless being connected to the system or
not. Any suggestion here?
<p>
<item>Well, then I wanted to use
<bf>/usr/sbin/bbs</bf> in order to connect
to the client_console (<em>xfbbC</em>). Looks
that there was a line in HI8GN's script:
<p>
<tscreen><verb>
xfbbC -c -f -h localhost -i [callsign] -w [password]
</verb></tscreen>
<p>
with missing ./ (dot+slash) before xfbbC, so the script
was not likely to be executed, but reported that a
command couldn't be found. Anyway, <em>xfbbC V3.01</em>
itself seemed to work Ok. It *is* possible to monitor the
channel from here too (using the "M" command under the
gateway), but this is also a bad solution because
while "Monitor ON", it is not confortable to do
anything else. Solutions welcomed!
<p>
<item>Though <em>xfbbC</em> session can be easily
terminated with "B" ("bye") command, a fooled
<bf>/usr/sbin/monitor</bf> can not. Its
process have to be found with <bf>ps ax</bf>
and then killed.
<p>
<item>At the end of the game, daemon itself should
be stopped. HI8GN's script <bf>/usr/sbin/fbb stop</bf>
returns:
<p>
<tscreen><verb>
Shutting down xfbbd: [OK]
</verb></tscreen>
<p>
but <bf>/usr/sbin/fbb status</bf>
reports:
<p>
<tscreen><verb>
Checking, the FBB daemon
xfbbd (pid) is running...
</verb></tscreen>
<p>
Looks that <bf>/usr/sbin/fbb stop</bf> does not terminate
daemon *every* time the command is executed, but re-start it
(the only difference is the new PID of the process and
<bf>ps ax</bf> also shows this new PID). So, there is
a question why it returns that [OK] when it is
obvious that daemon is not stopped, but re-started.
<p>
<item>Well, if you are like me, you may also want to experiment
with sysop's commands under <em>xfbbC</em> session.
For example, "/R" command (Reboot PC) shuts down
<em>xfbbC</em> and <bf>/usr/sbin/fbb status</bf>
reports:
<p>
<tscreen><verb>
Checking, the FBB daemon
xfbbd dead but subsys locked
</verb></tscreen>
<p>
while "/A" command (Stop BBS) does the same but returns:
<tscreen><verb>
Stop-request accepted, no connection.
</verb></tscreen>
<p>
before shutting down <em>xfbbC</em> itself.
<p>
Further tries to re-start either <em>xfbbC</em>
or fbbd (using <bf>/usr/sbin/fbb start</bf>) are not
successful, unless <bf>/usr/sbin/fbb stop</bf> is
executed in addition:
<p>
<tscreen><verb>
Shutting down xfbbd: [FAILED]
</verb></tscreen>
<p>
Then <bf>/usr/sbin/fbb status</bf> reports:
<p>
<tscreen><verb>
Checking, the FBB daemon
xfbbd is stopped
</verb></tscreen>
<p>
so, daemon might be re-started again. Here it is
also mysterious why it returns that [FAILED]
when it is obvious that daemon is really
stopped.
<p>
There are some other commands: "/K" (Reboot BBS with
housekeeping), "/M" (Reboot BBS imediatelly) and
"/L" (Reboot BBS, waiting users to disconnect) -
all of them with slightly different behaviour.
Anyway, those three have something in common: they
re-start daemon (with different PIDs, of course).
<p>
<item>Finally, what I would like to have is to
manage housekeeping and other maintaining
tasks. 'Till now, that is not accomplished.
I suppose that I should make some more
customization of system paths. Any suggestion
is welcomed.
</itemize>
<sect>Further information
<p>
<sect1>Copyright
<p>
Copyright (c) 2001 by Miroslav "Misko" Skoric, YT7MPB.
<P>
Permission is granted to copy, distribute and/or modify
this document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by the
Free Software Foundation; with no Invariant Sections,
with no Front-Cover Texts, and with no Back-Cover Texts.
A copy of the license is available from
<a href="http://www.fsf.org/licenses/fdl.html">http://www.fsf.org/licenses/fdl.html</a>.
<sect1>Disclaimer
<p>
Use the information in this document at your own
risk. I disavow any potential liability of this
document. Use of the concepts, examples, and/or
other content of this document is entirely at
your own risk.
All copyrights are owned by their owners, unless
specifically noted otherwise. Use of a term in
this document should not be regarded as
affecting the validity of any trademark or service
mark.
Naming of particular products or brands should not
be seen as endorsements.
You are strongly recommended to take a backup of
your system before major installation and backups
at regular intervals.
<sect1>News
<p>
This is not the first release of this mini-HOWTO. I
hope to improve it whenever possible. Beside that,
there are other documents that may help you to
use amateur radio stuff on your computer. You may
look for AX.25 (mini-)HOWTO at the same location
where you get FBB mini-HOWTO.
<em>This mini-HOWTO would be improved from time
to time. If you think that the HOWTO on your
Linux installation CD is some out-of-date, you
may check for newest release on the Internet. It
could be found within the main <url
url="http://www.linuxdoc.org/"
name="Linux Documentation Project">
homepage.
</em>
<sect1>Credits
<p>
<em>This version of mini-HOWTO can thanks to:</em>
<tscreen><verb>
Jean-Paul Roubelat, F6FBB, the author of FBB.
Per Olsen, LA6CU, the author of FBB documentation.
Jesus R., EB5AGF, the author of Protus.
Jose Marte, HI8GN, the packager of 7.02g package.
</verb></tscreen>
Any comments or suggestions can be mailed to my
email address:
<htmlurl url="mailto:m.skoric@eunet.yu"
name="m.skoric@eunet.yu">.
<sect1>HOWTO
<p>
<nidx>disk!information resources!HOWTOs</nidx>
These are intended as the primary starting points to
get the background information as well as show you how to solve
a specific problem.
Some relevant HOWTOs are <tt/Bootdisk/, <tt/Installation/, <tt/SCSI/ and <tt/UMSDOS/.
The main site for these is the
<url url="http://metalab.unc.edu/LDP/"
name="LDP archive">
at Metalab (formerly known as Sunsite).
<sect1>Mini-HOWTO
<p>
<nidx>disk!information resources!mini-HOWTOs</nidx>
These are the smaller free text relatives to the HOWTOs.
Some relevant mini-HOWTOs are
<tt/Backup-With-MSDOS/, <tt/Diskless/, <tt/LILO/, <tt/Large Disk/,
<tt/Linux+DOS+Win95+OS2/, <tt/Linux+OS2+DOS/, <tt/Linux+Win95/,
<tt/Linux+WindowsNT/, <tt/Linux+NT-Loader/, <tt/NFS-Root/,
<tt/Win95+Win+Linux/, <tt/ZIP Drive/, <tt/FBB packet-radio BBS/.
You can find these at the same place as the HOWTOs, usually in a sub directory
called <tt/mini/. Note that these are scheduled to be converted into SGML and
become proper HOWTOs in the near future.
<sect1>Local Resources
<p>
<nidx>disk!information resources!local</nidx>
In most distributions of Linux there is a document directory installed,
have a look in the
<htmlurl url="file:///usr/doc"
name="/usr/doc"> directory.
where most packages store their main documentation and README files etc.
Also you will here find the HOWTO archive (
<htmlurl url="file:///usr/doc/HOWTO"
name="/usr/doc/HOWTO">)
of ready formatted HOWTOs
and also the mini-HOWTO archive (
<url url="file:///usr/doc/HOWTO/mini"
name="/usr/doc/HOWTO/mini">)
of plain text documents.
Many of the configuration files mentioned earlier can be found in the
<htmlurl url="file:///etc"
name="/etc">
directory. In particular you will want to work with the
<htmlurl url="file:///etc/fstab"
name="/etc/fstab">
file that sets up the mounting of partitions
and possibly also
<htmlurl url="file:///etc/mdtab"
name="/etc/mdtab">
file that is used for the <tt/md/ system to set up RAID.
The kernel source in
<url url="file:///usr/src/linux"
name="/usr/src/linux">
is, of course, the ultimate documentation. In other
words, <em>use the source, Luke</em>.
It should also be pointed out that the kernel comes not only with
source code which is even commented (well, partially at least)
but also an informative
<url url="file:///usr/src/linux/Documentation"
name="documentation directory">.
If you are about to ask any questions about the kernel you should
read this first, it will save you and many others a lot of time
and possibly embarrassment.
Also have a look in your system log file (
<htmlurl url="file:///var/log/messages"
name="/var/log/messages">)
to see what is going on and in particular how the booting went if
too much scrolled off your screen. Using <tt>tail -f /var/log/messages</tt>
in a separate window or screen will give you a continuous update of what is
going on in your system.
You can also take advantage of the
<htmlurl url="file:///proc"
name="/proc">
file system that is a window into the inner workings of your system.
Use <tt/cat/ rather than <tt/more/ to view the files as they are
reported as being zero length. Reports are that <tt/less/ works well here.
<sect1>Web Pages
<p>
<nidx>disk!information resources!WWW</nidx>
<nidx>disk!information resources!web pages</nidx>
There is a huge number of informative web pages out there and by their very
nature they change quickly so don't be too surprised if these links become
quickly outdated.
A good starting point is of course the
<url url="http://www.linuxdoc.org/"
name="Linux Documentation Project"> home page,
an information central for documentation, project pages and much, much more.
Please let me know if you have any other leads that can be of interest.
<sect>Getting help
<p>
<nidx>(your index root)!assistance, obtaining</nidx>
In the end you might find yourself unable to solve your problems and need
help from someone else. The most efficient way is either to ask someone
local or in your nearest Linux user group, search the web for the nearest
one.
Another possibility is to ask on Usenet News in one of the many, many
newsgroups available. The problem is that these have such a high
volume and noise (called low signal-to-noise ratio) that your question
can easily fall through unanswered.
No matter where you ask it is important to ask well or you will not be
taken seriously. Saying just <it/my disk does not work/ is not going
to help you and instead the noise level is increased even further and if
you are lucky someone will ask you to clarify.
Instead describe your problems in some detail that
will enable people to help you. The problem could lie somewhere you did
not expect. Therefore you are advised to list up the following information
on your system:
<descrip>
<tag/Hardware/
<itemize>
<item>Processor
<item>DMA
<item>IRQ
<item>Chip set (LX, BX etc)
<item>Bus (ISA, VESA, PCI etc)
<item>Expansion cards used (Disk controllers, video, IO etc)
</itemize>
<tag/Software/
<itemize>
<item>BIOS (On motherboard and possibly SCSI host adapters)
<item>LILO, if used
<item>Linux kernel version as well as possible modifications and patches
<item>Kernel parameters, if any
<item>Software that shows the error (with version number or date)
</itemize>
<tag/Peripherals/
<itemize>
<item>Type of disk drives with manufacturer name, version and type
<item>Other relevant peripherals connected to the same busses
</itemize>
</descrip>
Remember that booting text is logged to <tt>/var/log/messages</tt> which can
answer most of the questions above. Obviously if the drives fail you might not
be able to get the log saved to disk but you can at least scroll back up the
screen using the <tt/SHIFT/ and <tt/PAGE UP/ keys. It may also be useful to
include part of this in your request for help but do not go overboard, keep
it <em/brief/ as a complete log file dumped to Usenet News is more than a
little annoying.
</article>
