LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2001-10-31 14:16:11 +00:00
parent fc55af89c4
commit 1ca8b858b9
1 changed files with 386 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

431
LDP/howto/linuxdoc/FBB.sgml
View File

@ -6,18 +6,18 @@
<title>FBB Packet-radio BBS mini-HOWTO
<author>Miroslav "Misko" Skoric, YT7MPB,
<tt/m.skoric@eunet.yu/
<date>v1.9, 07 October 2001
<date>v1.10, 30 October 2001
<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
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.
connecting computers via amateur radio stations.
</abstract>
@ -30,34 +30,36 @@ 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.
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
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.
packet radio abilities.
<p>Two years ago, after I got my new box, Pentium 166
with 32 MB of RAM and VGA color graphics, I
switched to a Windows version of FBB (so called
WinFBB). Author of the software, an radio amateur
from France, Jean-Paul F6FBB, has made many
<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).
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
@ -66,13 +68,45 @@ 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.
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
@ -100,8 +134,8 @@ LinFBB ...
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, so
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>
@ -321,9 +355,104 @@ versa, of course).</em>
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
(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>
@ -585,7 +714,7 @@ 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 LinFBB for X11 on
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
@ -594,11 +723,11 @@ to the existing two: X11 LinFBB and WinFBB!</em>
<p>
<itemize>
<item>Well, many amateurs suggested me to install some
packages that looked to me as not too much needed
for LinFBB itself - to be run. Anyway, I have installed
those packages <em>before</em> the installation
of LinFBB daemon version itself:
<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>
@ -609,21 +738,21 @@ to the existing two: X11 LinFBB and WinFBB!</em>
<p>
<item>Now it is the right time to install <tt>fbbsrv.rpm</tt>
package. The archive is composed to make its
package. The archive was composed to make its
own directories, as "base" directories. The last new
daemon version to start with, that I managed to find as
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 <bf>fbb.conf</bf>, that serves as the
replacement for <bf>init.srv</bf>, is located in the
following location: <bf>/etc/ax25/fbb.conf</bf>
<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
existing following files:
following existing files:
<p>
<tscreen><verb>
@ -660,13 +789,13 @@ to the existing two: X11 LinFBB and WinFBB!</em>
<p>
<item>Directory of users, instead of .../home/fbbdos/...,
should be ...<bf>/mnt/win/fbb/users</bf>... (<-- case you
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
should be <bf>/mnt/win/fbb/users/yapp</bf> (the same
reason as above)
<p>
@ -756,7 +885,7 @@ special requirements over some "third-party" software.</em>
<p>
<item>Jose, HI8GN, has offered daemon LinFBB v7.02g as a
<tt>.rpm</tt> package (18. September 2000). I got it
<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
@ -824,15 +953,15 @@ special requirements over some "third-party" software.</em>
<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 of an
older version, then to install a newer version in
order to get new executables. After that, a reverse
procedure must be put in place.</em>
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)
<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">,
@ -957,6 +1086,218 @@ procedure must be put in place.</em>
</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