mirror of https://github.com/tLDP/LDP
2323 lines
87 KiB
Plaintext
2323 lines
87 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
|
|
<title>FBB Packet-radio BBS mini-HOWTO
|
|
<author>Miroslav "Misko" Skoric, YT7MPB,
|
|
<tt/m.skoric@eunet.yu/
|
|
<date>v1.20, 2003-06-30
|
|
<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 server
|
|
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 <em>server</em> software for DOS.
|
|
Versions of FBB packet radio BBS <em>server</em>
|
|
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
|
|
December 1999, 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 on a 286/12 box at home.
|
|
Five years ago, when I got better box, Pentium I at 166 MHz with
|
|
32 MB of RAM and VGA color graphics, I switched to a Windows
|
|
version of FBB ("WinFBB"). Author of the software, a 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 great under
|
|
Windows NT 4.0).
|
|
|
|
<p>Update: In late 1999, I upgraded my system to
|
|
Celeron 400 MHz, added more 64 MB of RAM and
|
|
switched to bigger hard disk that will have enough room
|
|
to install Linux and try LinFBB ...
|
|
|
|
<p>Update: 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. Besides that, it is always nice to
|
|
copy some text from another application (for example,
|
|
from an Internet email) and to paste it into a
|
|
packet radio message, or vice versa.
|
|
|
|
<p>Update: In July 2001, I added more 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
|
|
Xwindow 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 channel.
|
|
|
|
4. All three versions must be capable to
|
|
share the same configuration files, i.e.
|
|
to be able, for example, to begin a new
|
|
session from the exact position where the
|
|
other version has finished its own last
|
|
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). I mean of RPM packages. So, there
|
|
are no source (re)compilations here at the
|
|
moment, but in the future we will see :-)
|
|
</verb></tscreen>
|
|
|
|
|
|
<sect>How to install X11 (Xwindow) 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 fine, 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 & swap partitions.
|
|
Well, at 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
|
|
the same system files, it is needed to put these
|
|
files in a place that both operating systems are
|
|
able to "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" one
|
|
installation is able to run properly 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 necessary
|
|
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 that
|
|
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 the "old" WinFBB or
|
|
the "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). If that works, later you may adopt that
|
|
change within your <bf>/etc/fstab</bf> configuration.
|
|
|
|
<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 as functional
|
|
as before this installation).
|
|
|
|
<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 the first time).
|
|
|
|
<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 <em>same</em> 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 "battle field"). 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 fine, 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
|
|
<bf>connection filters</bf> for a long time now.
|
|
At first, it was the 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 automated BBS-to-BBS
|
|
forwarding protection, using MD2 algorithm.
|
|
One of the reasons to cover Protus
|
|
in this document is the fact that its author
|
|
haven't made a manual in English yet. I keep
|
|
trying to translate original manuals
|
|
from Spanish into English, but it is a hard work.
|
|
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
|
|
usual, non-restricted 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 system use,
|
|
|
|
<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> directory, 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
|
|
their 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 may
|
|
be translated because they are originated
|
|
in Spanish (those files are just the parts of
|
|
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. After everything mentioned has
|
|
been 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 the well known line [[FBB-7.00-AB1FHMRX$]. It
|
|
only gives an information that Protus is active on the
|
|
system. Users of your BBS 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 have various kinds
|
|
of passwords: a fixed phrase (similar as those you
|
|
are used to when 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 random 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 algorithms; FBB-to-FBB automatic
|
|
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 32-bit applications).
|
|
|
|
<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
|
|
to implement 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 one 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 by the author to make a new directory
|
|
<bf>/var/ax25/fbb/protus</bf> and put *.PRT files there.
|
|
I <em>didn't move</em> files from <bf>\FBB\PROTUS</bf>
|
|
but rather <em>copied</em> them into the new location,
|
|
because I wanted Protus to continue working under WinFBB
|
|
as before. The utility still didn't want to run, unless I
|
|
<em>also</em> copied additional two *.PRT files from
|
|
<bf>\FBB\SYSTEM</bf> to the same new location
|
|
(<bf>/var/ax25/fbb/protus</bf>). After I did that, Protus
|
|
became 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 algorithm 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 operating
|
|
system and appropriate version of FBB, will have <em>one</em>
|
|
complete log of connection errors, users make when try to
|
|
connect 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
|
|
the "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 have Protus password, that
|
|
means 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 also logged.
|
|
|
|
<p>
|
|
<item>In addition, you may decide to have a "guest"
|
|
access or a "read-only" as <em>default</em> for
|
|
some BBS's access 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,
|
|
in such case a SSID of -0 would be expected).
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
<sect>How to install "xfbbd", a 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
|
|
really requested for LinFBB daemon to work.
|
|
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 the 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. Besides
|
|
that, some hams, including 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 for easy installation.
|
|
|
|
<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 related to <tt>7plus</tt>
|
|
operations). Next, its <tt>xfbbC</tt> console client looks better
|
|
than the previous version. But, I still miss graphical
|
|
<tt>xfbbX</tt> client, that I have found not able to become
|
|
activated. 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). Uninstall? Why? You will
|
|
find out soon, read on ...
|
|
|
|
<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 mostly for sysops, so the other users
|
|
(who might also have access to the local
|
|
keyboard) should rather try something less
|
|
dangerous, like this:
|
|
|
|
<p>
|
|
<tscreen><verb>
|
|
telnet localhost 6300
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
<item>... where 'localhost' and '6300' may vary from
|
|
BBS to BBS. I was pleasantly surprised
|
|
when discovered that <bf>telnet</bf> is much more
|
|
suitable for ordinary BBS users than <em>sysops'</em>
|
|
client <bf>xfbbC</bf>.
|
|
|
|
<p>
|
|
<item>Folks, I also think of writing a chapter about
|
|
FBB's system configuration. Until something
|
|
like that appears in this howto, 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. In addition, all
|
|
of these folks who are going to <bf>telnet</bf>
|
|
the BBS, have to be declared as users with
|
|
the 'M' flag (modem users). It is up to your
|
|
security precautions, if either of them would
|
|
eventually have <em>'root'</em> capabilities
|
|
to that one Linux machine itself.
|
|
<p>
|
|
<item>My next task is to use an old i286/12 MHz box,
|
|
having only 1 MB of RAM, running DOS 5.0, as a
|
|
'telnet client' computer. That box has a network
|
|
card so I would like to 'connect' to the
|
|
BBS from that one 'telnet client' box. If that
|
|
succeeds, it would be a good preparation for
|
|
installing another LinFBB (in the local school
|
|
club), where several old 286 computers will be also
|
|
available. It would be nice to offer more than
|
|
one student-amateur the opportunity to 'connect' the
|
|
BBS simultaneously, using a bunch of vintage
|
|
'telnet client' DOS computers.
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
<sect1>LinFBB v7.04
|
|
|
|
<p>
|
|
<em>Notice: Maybe I have already explained that I
|
|
use Red Hat 6.2 at home. That's why I usually look
|
|
for <tt>.rpm</tt> packages that have been made for
|
|
that particular Linux distribution, but not only that. I have
|
|
also tried to use Red Hat 7.1 but it seemed not to support
|
|
an older Xwindow application, LinFBB 7.00g (04 August 1998).
|
|
When I noticed that issue, I returned back to Red Hat 6.2.</em>
|
|
|
|
<p>
|
|
<itemize>
|
|
|
|
<item>Well, I started by downloading the package
|
|
<tt>xfbb-7.04-2.i386.rpm</tt> (07 August 2001)
|
|
from <url url="http://www.f6fbb.org/versions.html"
|
|
name="www.f6fbb.org/versions.html">
|
|
|
|
<p>
|
|
<item>Folks, this time I finally decided to install
|
|
version 7.04 as a completely "fresh" installation, i.e.
|
|
without some parts of any previously used "daemon"
|
|
on the disk. It means that I have uninstalled the last
|
|
daemon version I was using before, and, in addition,
|
|
I also removed the old 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 to avoid
|
|
editing the same "defaults" once again and again :-)
|
|
|
|
<p>
|
|
<item>The setup procedure has reported some dependency
|
|
issues. I didn't want to get bored with them so I repeated
|
|
the installation once again with "--force" and "--nodeps"
|
|
options.
|
|
|
|
<p>
|
|
<item>So far - so good. Then, I replaced a couple of
|
|
"default" files with the <em>saved</em> ones.
|
|
After that being accomplished, I mounted a
|
|
FAT partition with WinFBB's system files,
|
|
made a pray and started LinFBB's daemon. It was
|
|
also an interesting new experience to try HI8GN's
|
|
script <bf>/usr/sbin/fbb start</bf> (activated in an
|
|
<em>xterm</em>) to start the server. Although there
|
|
were no usual lines:
|
|
<p>
|
|
<tscreen><verb>
|
|
xfbbC/X server running ...
|
|
xfbbd ready and running ...
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
on my screen, TNC's <em>PTT</em> lamp confirmed
|
|
that a <em>beacon</em> was really transmitted.
|
|
|
|
<p>
|
|
<item>Then I wanted to try HI8GN's script
|
|
<bf>/usr/sbin/monitor</bf> to see what's
|
|
going 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 appeared no 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>
|
|
Bingo! From the usual FBB's prompt I entered the gateway
|
|
and typed the familiar "M" ("Monitor") command.
|
|
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 <em>xterm</em> as long as that telnet session
|
|
was closed. I was in doubt if that was OK or not,
|
|
because there I expected to see the traffic from the radio
|
|
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's (or better to say: sysop's)
|
|
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. Instead of that it reported
|
|
that command couldn't be found. Anyway, <em>xfbbC v3.01</em>
|
|
itself appeared to work nice. It is still possible to monitor the
|
|
working channel too (using the "M" command from within the
|
|
gateway), but this is not a valuable solution because
|
|
while "Monitor ON", it is not confortable to do
|
|
anything else within the gateway. Once again, solutions
|
|
are welcomed!
|
|
|
|
<p>
|
|
<item>Although the active <em>xfbbC</em> session can be
|
|
easily terminated using "B" ("Bye") command, a fooled
|
|
<bf>/usr/sbin/monitor</bf> can not. The user has to
|
|
find its <em>process number</em>, (PID), using <bf>ps ax</bf>
|
|
command and then kill that process.
|
|
|
|
<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> can show that new PID). So, there is
|
|
a question why it returns that [OK] when it is
|
|
obvious that daemon is not stopped, but rather re-started.
|
|
|
|
<p>
|
|
<item>Well, if you are like me, you may also want to
|
|
experiment with some special sysop's commands, from
|
|
within an <em>xfbbC</em> session. For example, "/R"
|
|
command ("Re-boot 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") returns:
|
|
|
|
<tscreen><verb>
|
|
Stop-request accepted, no connection.
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
before shutting down <em>xfbbC</em> client itself.
|
|
|
|
<p>
|
|
Further attempts to re-start either <em>xfbbC</em> client
|
|
or <em>xfbbd</em> server (using <bf>/usr/sbin/fbb start</bf>)
|
|
are not successful, unless an additional
|
|
<bf>/usr/sbin/fbb stop</bf> is executed. The result is:
|
|
|
|
<p>
|
|
<tscreen><verb>
|
|
Shutting down xfbbd: [FAILED]
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
Now another <bf>/usr/sbin/fbb status</bf> reports:
|
|
|
|
<p>
|
|
<tscreen><verb>
|
|
Checking, the FBB daemon
|
|
xfbbd is stopped
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
so finally, daemon might be re-started again. Here it is
|
|
also a mystery why it returns that [FAILED]
|
|
when it is obvious that daemon is really
|
|
stopped (maybe it is a "failure" when we try to
|
|
stop the same thing <em>twice</em>).
|
|
|
|
<p>
|
|
There are some other commands: "/K" (Re-boot BBS with
|
|
housekeeping), "/M" (Re-boot BBS immediatelly) and
|
|
"/L" (Re-boot BBS, waiting users to disconnect) -
|
|
all of them with slight different behavior. Anyway, those
|
|
three commands have something in common: they all re-start
|
|
the daemon (with different PIDs, of course).
|
|
|
|
<p>
|
|
<item>Finally, what I would like to have is to
|
|
manage housekeeping and other maintaining
|
|
tasks. Until now, that is not accomplished.
|
|
I suppose that I should make some more fine
|
|
customization in system paths. Any suggestion
|
|
about is welcomed.
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
<sect>How to use LinFBB's "xfbbX", a GUI client for Linux
|
|
|
|
<p>
|
|
2002-10-20
|
|
|
|
<p>
|
|
Well, soon after the installation of LinFBB v7.04
|
|
<em>.rpm</em> package, I noticed
|
|
a new "kid on the block", i.e. a new item within the
|
|
Start menu (under Gnome environment). That was a
|
|
"HamRadio" group, having several "Xfbb version 7.04"
|
|
sub-items and one of them was "xfbbd X Client".
|
|
|
|
<p>
|
|
It seemed that a mouse <em>click</em> on that
|
|
"xfbbd X Client" icon was not likely to return any
|
|
response, although <em>xfbbd</em> daemon has been successfully
|
|
running <em>before</em> invoking the client. That's why I have
|
|
been asking for help (related to that issue) from other LinFBB
|
|
users, but it seemed there was no one capable to solve that
|
|
problem. Anyway, it looks to me that there is a "dead" link
|
|
from this "xfbbd X Client" icon to an existing executable.
|
|
|
|
<p>
|
|
Trying to find a solution, the other day I was browsing the
|
|
<bf>/usr/sbin</bf> directory. I have noticed something that
|
|
I have already seen for several times. That was <bf>xfbbX</bf>
|
|
file. Well, I am sure that I tried to use this <em>executable</em>
|
|
earlier, but without much success. This time, I have entered
|
|
the full path, like this:
|
|
|
|
<p>
|
|
<tscreen><verb>
|
|
/usr/sbin/xfbbX
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
and, finally, the GUI client appeared on the screen.
|
|
|
|
<p>
|
|
So far - so good. Soon after, I realized that 'Monitoring'
|
|
window was capable to monitor the actual traffic on the radio
|
|
frequency, but not only that. Headers of all packets appear
|
|
in green and the actual information is in blue, so it is easy
|
|
to distinguish what is the header and what is the text info
|
|
(comparing to my old X11 LinFBB application where everything
|
|
came in black).
|
|
What I could describe as a disadvantage of the 'Monitoring'
|
|
window, is that the scroll bar does not give you much of the
|
|
previous, already <em>scrolled</em> traffic.
|
|
|
|
<p>
|
|
The 'All channels' screen was even better, so the system
|
|
user correspondents' traffic appeared in green, the local
|
|
user's traffic was in black and the port information was in
|
|
yellow. Unfortunately, there's no easy way (if any) to
|
|
change colors (and that's the standard feature in WinFBB)
|
|
for both 'Monitoring' and 'All channels' windows. Maybe I
|
|
haven't managed yet to find a switch for that, so any
|
|
useful info about is appreciated.
|
|
|
|
<p>
|
|
What I have also found a bit annoying, was that both
|
|
windows mentioned above, appear not arranged side-by-side,
|
|
a form that would be more suitable. Besides that, the
|
|
third window, 'Console', has to be activated with another
|
|
mouse click (instead of being activated automatically
|
|
with the other two windows). Actually, the whole thing of
|
|
<em>xfbbX</em> client seems to be primarily useful for
|
|
sysops looking only for BBS's command line, in order to
|
|
execute some server's commands etc. That's why I have found
|
|
a bit strange why the console window must be activated
|
|
separately (OK, I know that's the same with WinFBB's
|
|
windows, but why not to add some additional feature?)
|
|
|
|
<p>
|
|
Anyway, the 'Console' connection window has almost the same
|
|
functionality as WinFBB's 'Console' window. Here I think
|
|
of the commands given at the BBS's command prompt, because
|
|
they are invoked from the usual language *.TXT files.
|
|
|
|
<p>
|
|
But, the big disadvantage of today's version of
|
|
<em>xfbbX</em> client, I've found here, is the absence of
|
|
several useful icons, that I was very fond of within
|
|
the WinFBB's user interface. For example, there are
|
|
no icons for pending mail, users information,
|
|
disconnect a user, edit a message text or a header
|
|
etc. It looks to me that <em>xfbbX</em> developers are
|
|
not likely to offer the full comfort that we have
|
|
within WinFBB's GUI. It makes me wonder why? There are lots
|
|
of commands that can not be easily activated without the
|
|
proper icons. It drives me crazy whenever I have to
|
|
re-boot to Windows to start WinFBB, in order to perform
|
|
some simple tasks mentioned, using the mouse.
|
|
|
|
<p>
|
|
Besides that, there is no way to activate that nice
|
|
message editor screen, very useful in WinFBB
|
|
(also existed in an old Xwindow LinFBB application
|
|
v7.00g from 1998!) The same goes for replying
|
|
a message, where a sender does not get the text
|
|
of a message to be replied to, within the new
|
|
message body. In short, I don't like absence of
|
|
all those earlier implemented, but now abandoned
|
|
features.
|
|
|
|
<p>
|
|
Well, I can't imagine what Jean-Paul, F6FBB, and
|
|
other developers would do in the future, but I am not
|
|
satisfied with the idea to only keep further development
|
|
of LinFBB server side, but, in the same time, to abandon
|
|
the development of LinFBB's graphical client side. And not
|
|
only that: It looks that MS Windows client for LinFBB server,
|
|
<em>xfbbW</em> has been reported to be much more functional
|
|
that described xfbbX, while, in the same time, WinFBB server
|
|
development has been also stopped. A bit confusing situation,
|
|
isn't it?
|
|
|
|
<p>
|
|
Some amateurs think that it is just a result of "global" IT
|
|
situation: Linux (as well as other Unix-type platforms) is better
|
|
suited for servers, but Windows is better for clients. If so,
|
|
it looks that LinFBB packet-radio system operators, "sysop's",
|
|
seem to be forced to run at least two computers, in order
|
|
to get the same functionality they always had with WinFBB.
|
|
I'd rather suggest to Jean-Paul, F6FBB, and other developers
|
|
to transfer all known WinFBB's GUI features to <em>xfbbX</em>
|
|
GUI environment, in order to avoid using two computers.
|
|
|
|
<p>
|
|
2002-10-30
|
|
|
|
<p>
|
|
A couple of paragraphs ago, I said that "xfbbd X Client" icon
|
|
didn't work under Gnome environment. It did make me wonder
|
|
if it would work under KDE graphical user interface. So, this
|
|
time I started KDE (and I did it as "root" so, in addition, I
|
|
also got a mailbox icon on the desktop, named "fbb X11". When I
|
|
located the mouse pointer over that icon, there appeared some
|
|
more description: "F6FBB bbs Server for Packet Radio").
|
|
|
|
<p>
|
|
Well, when I tried to <em>click</em> on that icon, I got a
|
|
KFM Warning message box explaining that program
|
|
<bf>/root/.xfbbX</bf> could not be executed. Fortunately,
|
|
a "right click" on the icon allowed to enter file's Properties.
|
|
The Execute card gave me a possibility to change the path
|
|
for a program to be used. So, I did some browsing and located
|
|
the new path: <bf>/usr/sbin/xfbbX</bf>. After that, another
|
|
<em>click</em> resulted in running the GUI client.
|
|
|
|
<p>
|
|
Interestingly, there is some slight difference between
|
|
<em>xfbbX</em> appearance under KDE and Gnome. Actually,
|
|
each KDE's <em>xfbbX</em> window has "FBB" logo in the upper
|
|
left corner (Gnome's windows haven't that). That may indicate
|
|
that <em>xfbbX</em> client was produced primarily for KDE
|
|
environment. Besides that, it seems that other features
|
|
are almost the same, regardless being within KDE or Gnome
|
|
environment.
|
|
|
|
<p>
|
|
On the other side, the already mentioned "xfbbd X Client"
|
|
item (within the Start menu, under yhe "HamRadio" group), still
|
|
does not work. I suppose that there should also be some
|
|
modifications, related to program executable paths, but I
|
|
do not know how to manage that. Anyway, it does not matter
|
|
because <em>xfbbX</em> is running here this or that way.
|
|
|
|
<p>
|
|
2003-06-30
|
|
|
|
<p>
|
|
A recent email from Jose, HI8GN, related to the xfbbX GUI client,
|
|
about the RPM package:
|
|
|
|
<p><em>
|
|
"The reason of the why not the xfbbd X Client didn't give you any
|
|
answer is for several causes. 1) if the xfbbd daemon is not running
|
|
the xfbbd X client won't run. 2) if the xfbbd is dead in its process.
|
|
3) if the xfbbd was not shutoff correctly, but delete the xfbbd lock file
|
|
as this:</em>
|
|
|
|
<p><em>
|
|
. /etc/init.d/rc.fbb stop or service rc.fbb stop, and then it was run
|
|
and didn't create the xfbbd lock file, the shell script looks for the
|
|
existence the /var/lock/subsys/xfbbd or /var/lock/subsys/xfbbX lock file
|
|
and 4) if the xfbb X11 Server it is running it create a xfbbX lock file
|
|
by that the xfbbd X client won't neither run</em>
|
|
|
|
<p><em>
|
|
the same thing makes the X11 Client the one it verifies that the xfbbd is
|
|
not running</em>
|
|
|
|
<p><em>
|
|
if you make a click on the Icon that says fbb X11 Client and it doesn't run
|
|
it is because the one is seeing that there is a process of the xfbbd
|
|
running like as daemon.
|
|
the script rc.fbb I have also modified it so that it can not be executed
|
|
twice.</em>
|
|
|
|
<p><em>
|
|
if exist xfbbX lock file the xfbbd X client won't run
|
|
if exist xfbbd lock file the fbb X11 won't run.</em>
|
|
|
|
<p><em>
|
|
Lastly if you execute the command fbb in the console or in xterminal in
|
|
the desktop, you will see what I mean that simple."</em>
|
|
|
|
<p>
|
|
Thanks Jose!
|
|
|
|
<p>
|
|
<sect>How to use LinFBB's "xfbbW", a GUI client for Windows
|
|
|
|
<p>
|
|
2002-11-17
|
|
|
|
<p>
|
|
<em>Notice: Well, folks, I couldn't try to install and use
|
|
LinFBB client for Windows, because I have not had
|
|
a second computer for that purpose. The only way to
|
|
check how this client works, was to borrow a laptop machine
|
|
and give it a try.</em>
|
|
|
|
<p>
|
|
The first task was to link that Windows laptop to a Linux
|
|
desktop. I had some difficulties with the network card on
|
|
the desktop box, because it seemed not to be likely to start
|
|
the appropriate <bf>eth0</bf> interface. I'll give you some
|
|
more details about the equipment here: Linux is Red Hat 6.2
|
|
and my ISA network card has UMC UM9008 chip. Long ago, I
|
|
used some utilities that should "recognize" ISA cards (if
|
|
I remember their names, that were isapnptools, pnpdump etc).
|
|
|
|
<p>
|
|
What I do know, is that such tools should have add some new
|
|
lines into the existing files, like <bf>/etc/conf.modules</bf>
|
|
or, to create some new files, like <bf>/etc/isapnp*</bf>.
|
|
Well, I have forgotten what exactly should be done, so I
|
|
went to look for the right tools. The one that was looking
|
|
suitable was <bf>/sbin/isapnp</bf>. Although I got its
|
|
response on the screen, telling that the UM9008 chip was
|
|
recognized, there was nothing added to the system files,
|
|
nor new files seemed to be created.
|
|
|
|
<p>
|
|
What I also tried to use, was the old good <em>Linuxconf</em> tool, that
|
|
was already installed per default within RH 6.2 Linux. I
|
|
found the right place to add the information related to NIC's
|
|
IRQ and I/O address. There I seemed to make a little mistake,
|
|
so I put the value of <em>220</em> (for the I/O address), instead
|
|
of <em>0x220</em> that would better fit. The result was as one
|
|
may expect: the interface <bf>eth0</bf> continued to
|
|
report that a <em>ne</em> module had not found a card
|
|
at that one address. Then I checked the actual I/O address
|
|
the card uses under Windows OS (was the same) and
|
|
tried to fix the parameters (Thanks goes to a UK ham who advised
|
|
me to have to let Linux know the proper IRQ and I/O
|
|
addresses).
|
|
|
|
<p>
|
|
Interestingly, <em>Linuxconf</em> added a couple of new lines
|
|
into <bf>/etc/conf.modules</bf> too. In short, the next time
|
|
during the system boot, the interface <bf>eth0</bf>
|
|
reported a green <em>[OK]</em>, so I could
|
|
establish the link. So far - so good.
|
|
|
|
<p>
|
|
The next task was to download the client package from the
|
|
FBB's main site. I did it from the <em>"Newest version"</em>
|
|
web page and the number of the version was 1.12 (it
|
|
seems that was not a pretty much new version, or maybe the
|
|
content on that <em>"newest"</em> page has not been updated
|
|
recently - another task for Jean-Paul?). Anyway, I installed it
|
|
without any problem, configured its part related to the LinFBB
|
|
server it was about to access, changed the console font to my
|
|
favorite one (Tahoma) and started the utility.
|
|
|
|
<p>
|
|
At the first sight, the client looked great, because
|
|
Linux clients still prefer so small letters, that are
|
|
hard to read (compared to characters on a Windows screen).
|
|
Now I tried the most used commands like List, Read, Send Reply
|
|
etc. All of them worked great. What I have found a bit
|
|
strange, was that the <em>message justification</em> did
|
|
not work in its message editor window. You see, I like
|
|
my messages to be justified on both sides. I hope a solution
|
|
for that problem will be found soon.
|
|
|
|
<p>
|
|
Another issue with <em>xfbbW</em> client is that seems not to
|
|
allow a multiple click onto more than one
|
|
BBS callsign within <em>pending forward</em> list,
|
|
comparing to WinFBB's behavior. You know, I am not very fond of
|
|
opening the same <em>pending forward</em> window repeatedly
|
|
again and again, in order to start (or to stop) more than
|
|
one forwarding action.
|
|
|
|
<p>
|
|
In general, I like <em>xfbbW</em> client. I hope to
|
|
install some newer version(s) soon, and I hope some of
|
|
its features will be upgraded and some new ones will be added
|
|
in the future. What I would also like to have, is to
|
|
activate the maintenance of the BBS (a "housekeeping" task)
|
|
from that client's menu. Another thing I miss at the moment, is the
|
|
absence of the <em>xfbbW</em>'s help system. I mean
|
|
of a <em>real</em> Windows help, because there's not
|
|
much use of a <em>Help</em> menu, having only
|
|
<em>Copyright</em> and <em>About</em> information :-))
|
|
|
|
<p>
|
|
<sect>How to compile LinFBB's <em>executable</em> files
|
|
|
|
<p>
|
|
2003-01-01
|
|
|
|
<p>
|
|
<em>Notice: Until recently, I preferred to download "factory-made"
|
|
executables in RPM format (something like ZIP in MS Windows world).
|
|
After getting a RPM package, a click on it activates the program
|
|
that unpack and install its content. Well, it is great whenever
|
|
your RPM has been "manufactured" for the very similar distribution
|
|
of Linux you have. If not ...</em>
|
|
|
|
<p>
|
|
<itemize>
|
|
|
|
<item>Well, I have already had the package
|
|
<tt>xfbb-7.04-2.i386.rpm</tt> (07 August 2001), that was
|
|
running OK under RH 6.2 distro. And not only that. Its
|
|
"packager", Jose HI8GN, has explained that this package
|
|
was actually compiled and linked with utilities that came
|
|
with RH 6.2 - so under that distribution should be no
|
|
problems at all.
|
|
|
|
<p>
|
|
<item>The other day, I finally decided to abandon that 4-5 year
|
|
old version of X11 LinFBB <em>application</em> that I knew it would
|
|
not run under something newer than RH 6.2 distro. In short,
|
|
I decided to stay with daemon LinFBB's only, so it was the
|
|
right time to upgrade the Linux system itself. Another handy
|
|
installation that I had, was RH 7.1 and I used it. After
|
|
finishing that task, I rushed to re-install the RPM package
|
|
above, but it just didn't want to run.
|
|
|
|
<p>
|
|
<item>I had no choice but to browse fbb web sites in order to find
|
|
a RPM package that would fit RH 7.1 distribution. Unfortunately,
|
|
it looked that there were no LinFBB precompiled RPMs for 7.1
|
|
version of RedHat. The only solution was to try with <em>tarballs</em>.
|
|
So, what I have downloaded from <url url="http://www.f6fbb.org/versions.html"
|
|
name="www.f6fbb.org/versions.html">, was <tt>xd704h-src.tgz</tt>
|
|
archive.
|
|
|
|
<p>
|
|
<item>So far - so good. Well, folks, I am not very good in "deepest"
|
|
secrets of Linux, so I was not sure where might be the best
|
|
location to unpack the archive. According a <em>readme</em>
|
|
file, it should be "fbbsrc" directory, so I considered that
|
|
<bf>/usr/src</bf> would be the best place to copy archive's
|
|
<bf>fbbsrc.704h</bf> directory.
|
|
|
|
<p>
|
|
<item><bf>fbbsrc.704h</bf> directory has been made of 12 files and 7
|
|
subdirectories, one of which is <bf>src</bf> subdirectory. As
|
|
I said, the <em>readme</em> suggests a user to "goto fbbsrc/src"
|
|
directory, and I concluded that <bf>/usr/src/fbbsrc.704h/src</bf>
|
|
was the right place.
|
|
|
|
<p>
|
|
<item>The <em>readme</em> also suggests to "update the variables" at
|
|
the beginning of <em>Makefile</em> files, but I did not do that
|
|
because I was not sure what should be replaced there. I have
|
|
just left the file(s) intact.
|
|
|
|
<p>
|
|
<item>The next task was to run <em>make</em> command from the shell
|
|
and it took half a minute to be finished. The result were few new
|
|
<em>xfbb</em> executable files that I quickly moved to
|
|
<bf>/usr/sbin</bf> directory. BTW, some people rather suggest to run
|
|
<em>make install</em>, in order to avoid multiple copying of
|
|
compiled executables, but I found that way as not functional.
|
|
|
|
<p>
|
|
<item>Soon after, I tried to activate LinFBB's <em>daemon</em> and
|
|
it seemed to work without visible difficulties (using a temporary home
|
|
LAN with a laptop, I also started <bf>fbbW</bf>, a LinFBB Windows client.
|
|
It recognized the <em>daemon</em> in a second and I've only
|
|
noticed that there was no Protus password utility running).
|
|
|
|
<p>
|
|
<item>According the <em>readme</em>, the next task should be to "compile
|
|
the xfbbC client". That operation is to be performed from a place
|
|
called "fbbsrc/client" but the only directory available under
|
|
<bf>/usr/src/fbbsrc.704h/src</bf> was <bf>X11</bf> subdir.
|
|
|
|
<p>
|
|
<item>After clicking on its icon, I recognized the second one file
|
|
with a name <em>Makefile</em> (they have mentioned "updating"
|
|
of <em>both</em> Makefile files, so I hoped to reach the proper
|
|
place once again, regardless of two unknown paths). Besides that,
|
|
they have suggested to use "at least the version 2.1.37b of
|
|
ax25-utils" and I found <em>not</em> to have something like that
|
|
installed (case they mean of a <em>suit</em> of libax25, ax25apps
|
|
and ax25tool - than it is OK). Anyway, one more time I activated
|
|
<em>make</em> command from the shell and the result was in
|
|
getting <em>xfbbC</em> executable.
|
|
|
|
<p>
|
|
<item>As usual, <bf>xfbbC</bf> client is invoked from within an
|
|
<em>xterm</em> (or similar) window and it seemed that it was
|
|
also fully functional. So far - so good.
|
|
|
|
<p>
|
|
<item>The next issue is to "compile the xfbbX client", but this time
|
|
a user is requested to have a version of Motif installed. Well,
|
|
what I knew was that I had no Motif in the box, but a couple of Lesstif
|
|
RPM packages were somewhere around. Anyway, I installed them
|
|
with <tt>--force</tt> and <tt>--nodeps</tt> options to avoid
|
|
several <em>dependency</em> obstacles. In sum, Lestiff has come
|
|
to its place on the disk.
|
|
|
|
<p>
|
|
<item>This time, I did make some "updates" related to <em>Makefile</em>
|
|
paths and tried to run <em>make</em> command from the shell (for
|
|
the 3rd time now). Seems that I got no answer, because there appeared
|
|
neither <bf>xfbbX</bf> nor <bf>xfbbX_cl</bf> new executable files.
|
|
In order to "solve" that issue, I just applied the executables
|
|
from the earlier version I have backup-ed on the system.
|
|
|
|
<p>
|
|
<item>Finally, I managed to activate <bf>xfbbX</bf> client without
|
|
problems, although I knew it was not an updated version (compared
|
|
to the daemon itself). Regardless of that fact, a GUI client
|
|
works properly.
|
|
|
|
<p>
|
|
<item>As I just mentioned, I noticed that the first console connections
|
|
were without familiar <bf>{PROTUS-4.1b7}</bf> designation. So, I had
|
|
to check and double-check all the paths and system directories,
|
|
described in the Protus section of this mini-HOWTO. At the first
|
|
sight, it looked to me that everything was fine, but the utility
|
|
was not likely to start. Finally, I copied its main executable
|
|
into the yet another system location: <bf>/usr/lib/fbb/filter</bf>,
|
|
re-started the system and Protus returned back to its function.
|
|
|
|
<p>
|
|
<item>What I have to do in the future, is to check if the procedure
|
|
described in this section was the right one, although most of the
|
|
BBS's main features seem to be active - like they were with RH 6.2
|
|
distribution and mentioned LinFBB packages in RPM format.
|
|
|
|
</itemize>
|
|
|
|
<p>
|
|
<sect>How to access the "xfbbd" server from a DOS client?
|
|
|
|
<p>
|
|
2003-06-30
|
|
|
|
<p>
|
|
<em>Notice: In some of the previous chapters, I announced
|
|
my plans to use an old i286/12 MHz box,
|
|
having only 1 MB of RAM, running DOS 5.0, as a
|
|
'telnet client' computer. That box has a network
|
|
card so I would like to 'connect' to the
|
|
BBS from that one 'telnet client' box. If that
|
|
succeeds, it would be a good preparation for
|
|
installing another LinFBB (in the local school
|
|
club), where several old 286 computers will be also
|
|
available. It would be nice to offer more than
|
|
one student-amateur the opportunity to 'connect' the
|
|
BBS simultaneously, using a bunch of vintage
|
|
'telnet client' DOS computers.</em>
|
|
|
|
<p>
|
|
First of all, I have been looking for networking software that
|
|
does not require much of hardware resources. Several hams
|
|
keep advising me to try this or that way, but Jose, CO2JA,
|
|
sent me his distribution copy of <bf>NCSA Telnet</bf> utility.
|
|
According to its own <em>howto</em> document, that is
|
|
actually a <bf>"NCSA Telbin DOS client"</bf>, being <bf>"used
|
|
at The University of Port Elizabeth (Sep '94)"</bf>. So far
|
|
about software's earlier "official" usage.
|
|
|
|
<p>
|
|
Well, it seems that NCSA TCP/IP kernel only runs on packet
|
|
drivers now. That's why I looked for appropriate packet drivers
|
|
for my old ISA network card, equipped with the UMC's UM9003AF
|
|
chip. <bf>CZ20000.COM</bf> packet driver seemed to be the
|
|
most suitable one.
|
|
|
|
<p>
|
|
Before implementing the driver I also needed the proper diagnostic
|
|
utility to check and/or modify NIC's IRQ and I/O address in order to avoid
|
|
possible hardware conflicts (you know, under DOS it is less easier
|
|
to resolve interrupt hardware conflicts case a user has several ISA
|
|
cards that are not of P'n'P type /as PCI cards are/). It seemed that
|
|
<bf>DIAG.EXE</bf> ("The Ethernet Adapter Diagnostic Program,
|
|
Ver. 2.13" - that comes with E1000 and E2000 series Etherent cards)
|
|
was fully capable to handle my card's parameters, so I choose the
|
|
values of IRQ 5 and I/O 320 that weren't occupied by other resources.
|
|
|
|
<p>
|
|
Then I could execute the following DOS command:
|
|
|
|
<tscreen><verb>
|
|
cz2000 0x60 5 0x320
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
in order to activate the NIC.
|
|
|
|
<p>
|
|
Now the configuration file CONFIG.TEL should be modified
|
|
in order to satisfy my particular needs, including local (DOS client) and
|
|
remote (Linux server) IP addresses etc. In a couple of minutes
|
|
that was finished so the main executable <bf>TELBIN.EXE</bf>
|
|
successfully started running on my old 286 DOS box.
|
|
|
|
<p>
|
|
If you want, you may put <bf>cz2000 0x60 5 0x320</bf> and
|
|
<bf>telbin</bf> commands into a dedicated <em>TELNET.BAT</em>
|
|
file in order to make your telnet utility easier to activate. Should
|
|
you plan to use your old DOS box for only accessing the
|
|
Linux FBB server, both lines may be added to the
|
|
<em>AUTOEXEC.BAT</em> startup file.
|
|
|
|
|
|
<p>
|
|
<sect>How to make better ham radio rules?
|
|
|
|
<p>
|
|
2002-10-27
|
|
|
|
<p>
|
|
<em>Notice: Folks, here I am going to discuss some
|
|
rule'n'regulation issues that we, radio amateurs, every day
|
|
face to. These problems make rather significant obstacles
|
|
for this nice way of communication to be more developed
|
|
and widely used.</em>
|
|
|
|
<p>
|
|
First of all, anybody who might be interested in
|
|
running Linux amateur radio software, as a way of
|
|
using radio amateur stations on the international
|
|
HF waves, in a <em>digital</em> manner, has to learn
|
|
<bf>manual <em>analog</em></bf> Morse telegraphy and
|
|
pass the similar <bf>manual</bf> Morse skill test. For a long
|
|
time now, I have been trying to explain myself, why manual
|
|
Morse telegraphy is still being kept as the requirement
|
|
without an amateur is not allowed to use HF radio frequencies
|
|
under 30 MHz, in order to contact other Linux and remaining
|
|
<bf><em>digital</em></bf> radio amateurs world-wide. I still
|
|
have no answer, except that all of those who have wasted lots
|
|
of time learning Morse, now don't want to allow newcomers to
|
|
use the same capabilities - without the same (useless) tests!
|
|
|
|
<p>
|
|
You all know, there are so many Linux enthusiasts world-wide
|
|
(including myself) who have been fighting against all types
|
|
of <bf>monopols</bf> (like a company from Redmond, USA).
|
|
The Morse obligatory test is the same: just another type of a
|
|
<bf>monopoly!</bf>
|
|
|
|
<p>
|
|
That's why I have been trying to persuade all relevant
|
|
authorities to <bf>remove</bf> such outdated regulatory
|
|
principles, that make more and more obstacles for not
|
|
only Linux users, but for other kinds of computer users
|
|
- when it comes to the modern ICT technologies. I hope,
|
|
all of you, readers of this mini-HOWTO, can now
|
|
understand what does it mean to endlessly use outdated
|
|
rules and regulations. For example, I often contact
|
|
people from the academic world, students and scientists,
|
|
in order to motivate them to join amateur radio wireless
|
|
activities. They mostly refuse to start with amateur
|
|
(also called <em>"ham"</em>) radio, as soon as they hear they
|
|
have to pass the Morse test, as the legal requirement
|
|
<em>before</em> they become allowed to connect to
|
|
remote computing radio users world-wide, using the HF
|
|
radio bands and devices. I am sure, the absence of
|
|
those high educated people in the ham radio is one
|
|
of the most negative consequences in ICT areas we face to.
|
|
|
|
<p>
|
|
I have been thinking what to do, since early ninetees
|
|
when I was the secretary of <em>YU7</em> (Vojvodina
|
|
province in Serbia) amateur radio union. It seemed to
|
|
me that it was a very hard task to persuade the people who govern
|
|
the amateur radio organizations, to remove such outdated rule.
|
|
When I realized that the removing the mandatory manual Morse
|
|
test is almost impossible to be expected in a short period of time,
|
|
I decided to suggest the implementation of
|
|
another regulatory principle: To adopt a new type
|
|
of amateur radio licenses, a <bf>H</bf>am <bf>D</bf>igital
|
|
<bf>L</bf>icence (the <bf>HDL</bf> in short). The HDL licensees
|
|
would be allowed to use ALL amateur radio frequencies,
|
|
including ALL international HF bands
|
|
under 30 MHz. But, they rather should be allowed to use ONLY
|
|
digital types of amateur activities, including the use of
|
|
computers with LinFBB packet radio software. The HDL holders
|
|
might use some dedicated radio transmitters, without
|
|
the capability for both voice microphone and Morse key
|
|
connections, in order to avoid possible misuse of
|
|
unwanted amateur activities (like voice SSB operations).
|
|
|
|
<p>
|
|
All HDL candidates would have to learn various topics like
|
|
computer hardware and software in general (operating systems and
|
|
system software configuration, amateur radio software setup etc),
|
|
connecting amateur radio stations to the computers (connecting radio
|
|
modems to the transmitters etc), building simple antennas (like 1/2 wave
|
|
wire dipole for 20m I used long ago), English language (or German etc)
|
|
in the written exam etc. The Morse requirement would not be used anymore,
|
|
as well as some other obsolete tests, like highly complicated radio
|
|
circuits or skills needed for building home-brew radios from the scratch
|
|
(instead of buying modern factory manufactured devices) etc. Of course,
|
|
regulatory issues should also be tested (like band plans - in particular
|
|
recognizing the sub-bands dedicated for <bf>digital</bf> ham radio),
|
|
RFI issues and how to avoid them etc.
|
|
|
|
<p>
|
|
I believe that amateur radio <em>digital</em>
|
|
activities have their future only if we all do
|
|
our best to improve the regulatory principles that
|
|
govern this fine hobby. You should also know that,
|
|
besides the telegraphy skill requirement for HF access,
|
|
here in Serbia we have some further restrictions: we
|
|
have all to be the members of the national amateur radio
|
|
unions (SRV in YU7 province and SRS in Serbia in whole),
|
|
as the legal requirement, <bf>before</bf> we become allowed
|
|
to use <em>any</em> type of the amateur radio activities.
|
|
Such a stupid rule does not exist elsewhere!
|
|
|
|
<p>
|
|
Should you want helping us to adopt internationally known
|
|
principles, that do NOT require to join <em>any</em>
|
|
type of an amateur radio organizational system, i.e. an
|
|
amateur radio society (that only wants to get our membership
|
|
money), you are invited to lobby for that. Our outdated
|
|
amateur society leadership has their email address:
|
|
yu0srj@eunet.yu (I suppose they may have more than
|
|
one email address, but you may try to use this one).
|
|
You may also use an Internet search engine and scan for
|
|
more info related to "Savez radio amatera Jugoslavije",
|
|
"Savez radio amatera Srbije", etc). Your valuable help would
|
|
be highly appreciated. Case you need more info regarding
|
|
these legal issues, do not hesitate to contact me too.
|
|
|
|
<p>
|
|
If you find yourself interested enough in making
|
|
amateur radio rules and regulations better and
|
|
updated (say to spread the idea of liberalize the
|
|
ICT areas and make them free of any kind of monopols),
|
|
I would suggest you to look for your national radio
|
|
amateur society and/or national telecommunication
|
|
regulatory agency (like FCC in the USA). Lobby to them
|
|
in order to remove the obsolete manual Morse proficiency
|
|
test. In addition, should you have some opportunities to
|
|
attend to some ICT related science conferences or
|
|
something like that, you are also invited to let me know of.
|
|
|
|
<p>
|
|
Case we all do our best to remove obstacles mentioned above
|
|
and allow the new people who may wish to enjoy the amateur
|
|
radio digital and Linux-related operations to do so, the
|
|
technology would become the part of more homes. I hope you,
|
|
the readers, may help. So I look forward to hear from you soon!
|
|
|
|
<p>
|
|
<sect>Bibliography
|
|
|
|
<p>
|
|
2003-06-17
|
|
|
|
<em>Notice: Folks, I often visit some (inter)national
|
|
ICT conferences all around Serbia and Montenegro,
|
|
submitting papers and having presentations. What I want
|
|
to do is to spread - as wide as possible - the basic idea
|
|
and the useful mission of the amateur radio hobby. You bet,
|
|
whenever possible I want my readers to make it with Linux.
|
|
Besides that, I have been writing various articles for a variety
|
|
of scientific and other magazines. Here you have a list of the
|
|
articles I have written, and the papers submitted to the
|
|
conferences until now.</em>
|
|
|
|
<p>
|
|
Case you want to re-publish or forward my volunteer paper
|
|
works to some journals or other public media around, you are
|
|
free to contact me. Some of my papers are written in Serbian
|
|
Cyrillic, some of them in English and some of them even
|
|
combined!
|
|
|
|
<p>
|
|
<tscreen><verb>
|
|
- "U prilog I.A.C.", MI (the youth scientists' organization
|
|
newspaper), No. 69, 1990.
|
|
|
|
- "U prilog I.A.C. (2)", MI (the youth scientists' organization
|
|
newspaper), No. 70, 1990.
|
|
|
|
- "Vise od radio-amaterskog hobija", Vojska, No. 163, 1995.
|
|
|
|
- "Korak ka zvezdama", Vojska, No. 200, 1996.
|
|
|
|
- "Die Gefahr von Innen - Internet gegen Amateurfunk",
|
|
AMSAT-DL Journal, No. 4, Dez./Feb. 96/97.
|
|
|
|
- "Kakva nam organizacija (ne) treba?", Radioamater,
|
|
Feb. 1997.
|
|
|
|
- "Kakva nam organizacija (ne) treba? (2)", Radioamater,
|
|
Apr./May. 1997.
|
|
|
|
- "Sateliti umiru padajuci", Vojska, No. 235, 1997.
|
|
|
|
- "The Internet is not the Enemy", QST, Aug. 1998.
|
|
|
|
- "Novi radio-amateri za novi vek", Antena, June 2000.
|
|
|
|
- "Racunarske komunikacije putem radio-veza i
|
|
zastita pristupa", Bezbednost, No. 3, 2000.
|
|
|
|
- "Paket-radio - Racunarske komunikacije putem radio-veza",
|
|
proceedings, "Info-Teh", Vrnjacka Banja, Serbia, 2001.
|
|
|
|
- "Racunarske komunikacije putem radio-amaterskih veza",
|
|
proceedings, "YU-Info", Kopaonik, Serbia, 2002.
|
|
|
|
- "Computer Communications over radio", presentation,
|
|
"Linux FEST", Belgrade, Serbia, 2002.
|
|
|
|
- "Paket-radio - Radio-amaterske digitalne veze",
|
|
proceedings, "Kongres JISA", Herceg Novi, Montenegro, 2002.
|
|
|
|
- "Paket-radio (2) - Modemi za radio-veze",
|
|
proceedings, "Info-Teh", Vrnjacka Banja, Serbia, 2002.
|
|
|
|
- "Alternativne racunarske mreze", festival catalog,
|
|
"INFOFEST", Budva, Montenegro, 2002.
|
|
|
|
- "Alternative computer networks", proceedings, "TELFOR",
|
|
Belgrade, Serbia, 2002.
|
|
|
|
- "With rule and regulation improvements to the progress"
|
|
proceedings, "TELFOR", Belgrade, Serbia, 2002.
|
|
|
|
- "Paket-radio (3) - Programske mogucnosti na strani servera",
|
|
proceedings, "Info-Teh", Vrnjacka Banja, Serbia, 2003.
|
|
|
|
- "Paket-radio (4) - Legal rules and regulations in the amateur
|
|
computer networks", proceedings, "Info-Teh", Vrnjacka Banja,
|
|
Serbia, 2003.
|
|
|
|
- "Packet-radio (2) - With rule and regulation improvements to the progress",
|
|
proceedings, "Kongres JISA", Herceg Novi, Montenegro, 2003.
|
|
</verb></tscreen>
|
|
|
|
<sect>Further information
|
|
|
|
<p>
|
|
<sect1>Copyright
|
|
<p>
|
|
Copyright (c) 2003 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
|
|
also look for AX.25 (mini-)HOWTO at the same
|
|
location where you get this 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 or this one: <url
|
|
url="http://www.tldp.org/"
|
|
name="Linux Documentation Project">.
|
|
</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,
|
|
and a variety of helpful radio amateurs world-wide.
|
|
</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/ etc.
|
|
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, or this one: <url
|
|
url="http://www.tldp.org/"
|
|
name="Linux Documentation Project">,
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|