FBB Packet-radio BBS mini-HOWTO
Miroslav "Misko" Skoric, YT7MPB, m.skoric@eunet.yu
v1.18, 2003-06-01
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 bul
letin board system (BBS), a mailbox for personal messages, a database
for various texts, documents and binary files, a server for small use
ful calculations etc. Packet radio is a way of connecting computers
via amateur radio stations.
1. Introduction
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 server software for DOS. Versions of FBB packet
radio BBS server software for DOS, today are known as "DosFBB".
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.
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).
New: Since Spring 2001, I run WinFBB v7.00i (17 March 2001) under
Windows 2000 Professional.
The main difference between DosFBB and WinFBB is that the second one
offers you to do other jobs with your computer, while FBB is running
as just any other application. Beside that, it is always nice to copy
a text from another application (for example, from an Internet email)
and to paste it into a packet radio message, or vice versa.
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 ...
New: In July 2001, I added more 128 MB of RAM so my home system is
very confortable now.
Finally, you should be aware what I want to have here:
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 :-)
2. How to install X11 (Xwindow) version of LinFBB
· 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).
· Download or copy LinFBB (the main ftp site is ftp.f6fbb.org
but there are many mirror sites too). For
example, if you get a file like
x700e_full.tgz
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
xd700g_full.tgz
means that it is not X11 but daemon version 7.00g and it is also com
plete to unpack. Further,
x700f01.tgz
and
x700g.tgz
are "upgrades" to any previous "full" package. For example, after I
have upgraded to x700g.tgz 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.
· Copy the archive file in /tmp directory.
· You have to make a "base" directory where your FBB will be
installed. For example you may type: mkdir /usr/local/fbb if you
want FBB to be there. You have to be logged as
· Then, you should locate yourself in that directory: cd
/usr/local/fbb.
· Now, you should unpack the archive: tar xvzf /tmp/x700b25.tgz (<--
use the right name of the archive here).
· When you finished unpacking the archive, you may continue
installing the software: ./install.sh is the command for that. The
setup will ask you for the 'base' directory where FBB will be
installed. If you chose /usr/local/fbb 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 /usr/local/fbb/init.srv file.
· After that, you MUST check this file again manually in order to fix
some other details needed (because installation script does not fix
all parts within that file).
· Well, so far - so good. After you have checked all configuration
files, you may start the software: ./xfbb.sh (<-- 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.
3. How to install LinFBB in addition to existing WinFBB
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).
· 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").
· 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.
· 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.
· Some files can't be used as they are under both 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):
init.srv -> init_w.srv
forward.sys -> forw_w.sys
port.sys -> port_w.sys
protect.sys -> prot_w.sys
FBB is able to recognize and accept those renamed files.
· Make a backup of the actual WinFBB (I do that by copying the whole
WinFBB file structure into the other Windows partition that won't
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?).
· Now, you should restart your machine and boot into Linux. Log on as
'root' or make 'su' from a user's account.
· Mount a shared FAT directory (where FBB files are): mount -t vfat
/dev/hda2 /mnt/win (for example). If that works, later you may
adopt that change within your /etc/fstab configuration.
· Copy LinFBB archive to /tmp directory.
· Position yourself to the 'base' directory: cd /usr/local/fbb (for
example).
· Unpack the archive: tar xvzf /tmp/filename.
· Start the installation script ./install.sh and, after asked for the
'base' installation directory, chose /usr/local/fbb. 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).
· Copy /usr/local/fbb to /mnt/win/fbb but do *not* rewrite existing
files with the new files having the same names.
· Copy /mnt/win/fbb/init_w.srv to /mnt/win/fbb/init_l.srv file.
· Edit /mnt/win/fbb/init_l.srv to what is needed for Linux. You may
use the existing file /mnt/win/fbb/init.srv as an example.
· Copy newly edited /mnt/win/fbb/init_l.srv over the
/mnt/win/fbb/init.srv (if you do not do that, maybe you wouldn't be
able to start LinFBB using ./xfbb.sh, like me at the first time).
· Copy /mnt/win/fbb/system/port_w.sys to
/mnt/win/fbb/system/port_l.sys file.
· Edit /mnt/win/fbb/system/port_l.sys to what is needed for Linux and
LinFBB. You may use the existing file /mnt/win/fbb/system/port.sys
as an example.
· Edit /mnt/win/fbb/xfbb.sh in order to fix the right path.
· Ensure that you are in FBB's main directory: cd /mnt/win/fbb (for
example).
· Start the script ./xfbb.sh to run LinFBB. If everything is OK,
your LinFBB under Linux should run with the same configuration as
your "old" WinFBB under Windows. From this point, both FBB's should
behave very similar (actually, I must admit that WinFBB has much
better visual quality than X11 LinFBB, but probably the reasons for
that you may find in Windows-vs.-Linux-GUI quality "battle field").
FYI, my actual WinFBB is v7.00g25 (05 January 2000) and X11 LinFBB
is v7.00g (04 August 1998).
· Although this combination WinFBB/X11 LinFBB works fine, I have
noticed some problems. For example, LinFBB was not able to use
amsat forward_to_file routine (located in /mnt/win/fbb/system/fwd
directory), because that file was composed like this (for example):
A AMSAT
*
P @
*
C D:\FBB\SYSTEM\SAT\AMSAT.TXT <-- looks familiar to DOS/Windows only
*
G AMSAT
*
--------
On the other side, LinFBB's amsat.sys (located in /etc/ax25/fbb/fwd
directory) has suggested something like this:
A AMSAT
*
P @
*
C /var/ax25/fbb/sat/amsat.txt <-- looks familiar to Linux only
*
G AMSAT
*
--------
Well, then I copied LinFBB's amsat.sys into /mnt/win/fbb/system/fwd
directory so it could become functional. As a result, I got two
amsat.txt files, one of them for each of WinFBB/LinFBB, and of course,
both files appeared on different locations: the first one was
/mnt/win/fbb/system/sat/amsat.txt and it was filled by WinFBB; the
other one was in /var/ax25/fbb/sat/amsat.txt and was filled by LinFBB.
I didn't like it that way.
In order to have only one result, regardless of FBB version, the newly
copied amsat.sys had to be slightly changed:
A AMSAT
*
P @
*
*C /var/ax25/fbb/sat/amsat.txt
C /mnt/win/fbb/system/sat/amsat.txt
*
G AMSAT
*
--------
As you can see now, when LinFBB is active, its amsat.sys will not
forward into its "native" location of amsat.txt. Instead of that, it
will go to the location of the WinFBB's amsat.txt and just add some
new materials into it, ok?
Well now it's up to you to decide what to do with your growing
amsat.txt. An old DosFBB manual says that the 'batch' file (I suppose,
the old good APPEL.BAT) should be adopted in order for SATUPDAT.EXE
can update sat 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?
4. How to install Protus password utility
Notice: Well, I have been using Protus connection filters 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: m.skoric@eunet.yu.
Protus offers several interesting features:
· It can send a presentation message to all users, informing about
possibility to make users' access more safe,
· It can send messages to users who have usual, non-restricted
access, informing about utility's existence,
· It can send messages to users who have no valid access (before
disconnecting them),
· It can send messages to new users who have connected the BBS for
the first time, informing them about the password utility.
· It can send messages to users who have entered wrong password
(before disconnecting them),
· It can inform sysop about almost everything related to users'
connections (new user on the system, unsuccessful connections etc),
· Messages mentioned above could be translated into various languages
and used similarly as various language files that FBB system use,
· Messages mentioned above could be different for different BBS
ports,
· Protus could be activated/deactivated at various intervals of time
using CRON.SYS system file,
· Passwords could be managed remotely, using an external server,
developed by Jose EB5IVB,
· ...
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,
c_filter:
· Users of Dos/WinFBB versions of Protus already know that it is
needed to create a new directory \FBB\PROTUS where several *.PRT
files should be placed. In addition, the main C_FILT*.DLL files
should be copied into \FBB\BIN directory, as well as a couple of
"system", (i.e. config) *.PRT files that are going to be within
\FBB\SYSTEM directory.
· 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: CONFIG.PRT and USERS.PRT 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 all users in the same way as they worked before
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.
· 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: {PROTUS-4.0} 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. roman }
· 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).
· 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.
· I have already told you that I have been running here both WinFBB
under Windows NT and LinFBB under Linux (see also Linux+WinNT mini-
HOWTO and Lilo mini-HOWTO). That means all Protus stuff has already
been installed in a way WinFBB has required, except Linux
executable of c_filter file. I put that one file into /fbb/bin
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
/var/ax25/fbb/protus and put *.PRT files there. I didn't move
files from \FBB\PROTUS but rather copied 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 also
copied additional two *.PRT files from \FBB\SYSTEM to the same new
location (/var/ax25/fbb/protus). After I did that, Protus became
functional.
· 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 /var/ax25/fbb/protus where all *.prt files should
be placed. Only c_filter executable should go to /fbb/bin and
that's it.
· 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).
· One of the interesting features of Protus is to log unsuccessful
connections. Due to the different 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 one complete log of connection errors,
users make when try to connect your BBS.
· As it was told earlier, if you implemented password protection for
only some 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 only 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.
· In addition, you may decide to have a "guest" access or a "read-
only" as default 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!
· 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).
}
5. How to install "xfbbd", a daemon version of LinFBB
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!
· 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 before the
installation of LinFBB itself:
libax25.rpm
ax25apps.rpm
ax25tool.rpm
· Now it is the right time to install fbbsrv.rpm 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 .rpm package, was 7.01f Release 4 (09 December 1999).
· A file called fbb.conf, serving as the replacement for init.srv, is
placed in the location: /etc/ax25/fbb.conf
· Unless you are going to install daemon-only system, you should make
a backup of the following existing files:
dirmes.sys
etat.sys
heard.bin
inf.sys
statis.dat
tpstat.sys
· Now you have to edit /etc/ax25/fbb.conf and change some paths in
case you already have X11 LinFBB installed on a different path.
Here you have some examples that cover my particular situation...
· Directory of data files, instead of /var/ax25/fbb, should be
/mnt/win/fbb/system
· Directory of config files, instead of /etc/ax25/fbb, should be
/mnt/win/fbb/system
· Directory of message files, instead of /var/ax25/fbb/mail, should
be /mnt/win/fbb/mail
· Directory of compressed files, instead of /var/ax25/fbb/binmail,
should be /mnt/win/fbb/binmail
· Directory of users, instead of .../home/fbbdos/..., should be
.../mnt/win/fbb/users... (case you don't mind that both your WinFBB
and LinFBB users handle the same location for users' files)
· Directory of YAPP files, instead of /home/fbbdos/yapp, should be
/mnt/win/fbb/users/yapp (the same reason as above)
· Directory of documentation files, instead of /var/ax25/fbb/docs,
should be /mnt/win/fbb/docs
· Directory of pg programs, instead of /usr/local/pg, should be
/mnt/win/fbb/pg
· Path and filename for import file, instead of C:\FBB\MAIL.IN should
be /mnt/win/fbb/mail.in
· Now you have to edit /usr/sbin/xfbb.sh and change some paths in
case you already have running X11 version of LinFBB on a different
path. Here you have an example that cover my particular
situation...
· Base directory of XFBB software, instead of /var/ax25/fbb, should
be /mnt/win/fbb
· So far - so good. Now it is the time to start LinFBB daemon. The
command for that is in the location: /usr/sbin/xfbb.sh and it may
be executed within an xterm. If everything is OK, you should get
several system messages on your screen, ending with something like:
xfbbC/X server running ...
xfbbd ready and running ...
· Well, daemon itself can't be used to access the BBS so it is needed
to activate a client that is /usr/sbin/xfbbC. It has a couple of
parameters (a callsign/password pairs that are stored in
/fbb/passwd.sys). Note that xfbbC can also be activated within
another xterm.
· If you are like me, you would like to activate one more xterm with
xfbbC in a way to monitor your radio frequency. If you have enough
room on your screen, you may place all three xterm windows side by
side.
· When you finish your xfbbC console session, it is suitable to use
the same xterm to eventually stop the daemon. First of all, with
the command ps ax you should locate PIDs of xfbb.sh shell and
daemon itself, that you may kill after that.
6. How to install an upgrade to a daemon version of LinFBB
6.1. LinFBB v7.02g
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.
· I also noticed that my version of Protus was newer 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.
· Jose, HI8GN, has offered daemon LinFBB v7.02g as a .rpm package (18
September 2000). I got it from his site:
http://hi8gn.dynip.com/indice.html
. But, when I tried to install
it over the previous version 7.01f, it complained about some
existing LinFBB files.
· Then I had to uninstall the old package, after what some config
files remained in their locations, but with new .rpmsave
extensions. It was nice, so I could use them later to update my
new-installed config files.
· 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 xfbbd and xfbbC
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 .rpm, in order to install the previous version of
LinFBB once again - the version that I was satisfied with.
· 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...?
· Well, the new daemon is likely to check for some more directories
than the older version (mostly related to 7plus operations). Next,
its xfbbC console client looks better than the previous version.
But, I still miss graphical xfbbX client, that I have found not
able to become activated. I hope it will be fixed soon. Finally,
Protus c_filter utility is active too.
· An interesting question might be: is that now a really upgraded
LinFBB daemon or not? Actually, I haven't changed the "old" script
xfbbd.sh 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 xfbbd.sh. After I returned to xfbbd.sh
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 m_filter has not been found or
something like that. The next tasks are to solve these issues.
6.2. LinFBB v7.03
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.
· Well, it was needed to get 7.03 package (09 December 2000) as an
.rpm package from www.f6fbb.org/versions.html
, that was suggested by Jean-
Paul, F6FBB. Anyway, soon after there appeared several mirror
sites, offering 7.03 too.
· If you use GnomeRPM, it is easy to uninstall your actual LinFBB (If
you just try to install new .rpm 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 .rpmsave files, so you could use
them later again.
· Installation of 7.03 package will give you new executables in
/usr/sbin directory. Those new executables should be temporary
given extensions like .703 (for example).
· So far - so good. Now you should *uninstall* the 7.03 package (of
course, .703 files won't be unistalled automatically). Uninstall?
Why? You will find out soon, read on ...
· Once again, you should *install* the last one version of LinFBB
daemon, that works OK with its own xfbb.sh (in my case, that is
7.01f).
· For sure, many of you might find it odd, but now it is the right
time for the executables from /usr/sbin (I mean of all fbb
executables, except those who were renamed to .703) to get their
new extensions (in my case, that is .701).
· Well, after that is performed, .703 files should *lose* their
previously attached extensions, in order to become usable.
· Folks, on that point I usually hold my breath, cd to /usr/sbin and
type: xfbb.sh following with an Enter. If everything is fine,
several lines should scroll on the screen, ending with something
like:
xfbbC/X server running ...
xfbbd ready and running ...
· If you don't get something similar on your xterm 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 :->
· /usr/sbin/xfbbC 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 not 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.
· Recently, I was informed that xfbbC 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:
telnet localhost 6300
· ... where 'localhost' and '6300' may vary from BBS to BBS. I was
pleasantly surprised when discovered that telnet is much more
suitable for ordinary BBS users than sysops' client xfbbC.
· 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 xfbbC
have to be added into your passwd.sys file. In addition, all of
these folks who are going to telnet 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 'root'
capabilities to that one Linux machine itself.
· My next task is to use an old i286/12 MHz box, having only 1 MB of
RAM, running DOS 5.0, as a 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 also be
available. It would be nice to offer more than one student-amateur
the opportunity to 'connect' the BBS simultaneously, using a bunch
of vintage
6.3. LinFBB v7.04
Notice: Maybe I have already explained that I use Red Hat 6.2 at home.
That's why I usually look for .rpm 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.
· Well, I started by downloading the package xfbb-7.04-2.i386.rpm (07
August 2001) from www.f6fbb.org/versions.html
· 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 /etc/fbb.conf), in order to avoid editing
the same "defaults" once again and again :-)
· 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.
· So far - so good. Then, I replaced a couple of "default" files with
the saved 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 /usr/sbin/fbb start (activated in an xterm) to start
the server. Although there were no usual lines:
xfbbC/X server running ...
xfbbd ready and running ...
on my screen, TNC's PTT lamp confirmed that a beacon was really
transmitted.
· Then I wanted to try HI8GN's script /usr/sbin/monitor to see what's
going on the frequency. Although I got something like:
Connecting localhost ... Ok
Authentication in progress ... Ok
Monitoring channel 0 ...
there appeared no traffic on the screen. In order to really monitor
the channel, I had to start another xterm and type:
telnet localhost 6300
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, /usr/sbin/monitor window, mentioned above,
started to copy whatever was going on the telnet xterm 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?
· Well, then I wanted to use /usr/sbin/bbs, in order to connect to
the client's (or better to say: sysop's) console (xfbbC). Looks
that there was a line in HI8GN's script:
xfbbC -c -f -h localhost -i [callsign] -w [password]
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, xfbbC v3.01 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!
· Although the active xfbbC session can be easily terminated using
"B" ("Bye") command, a fooled /usr/sbin/monitor can not. The user
has to find its process number, (PID), using ps ax command and then
kill that process.
· At the end of the game, daemon itself should be stopped. HI8GN's
script /usr/sbin/fbb stop returns:
Shutting down xfbbd: [OK]
but /usr/sbin/fbb status reports:
Checking, the FBB daemon
xfbbd (pid) is running...
Looks that /usr/sbin/fbb stop 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 ps ax 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.
· Well, if you are like me, you may also want to experiment with some
special sysop's commands, from within an xfbbC session. For
example, "/R" command ("Re-boot PC") shuts down xfbbC and
/usr/sbin/fbb status reports:
Checking, the FBB daemon
xfbbd dead but subsys locked
while "/A" command ("Stop BBS") returns:
Stop-request accepted, no connection.
before shutting down xfbbC client itself.
Further attempts to re-start either xfbbC client or xfbbd server
(using /usr/sbin/fbb start) are not successful, unless an additional
/usr/sbin/fbb stop is executed. The result is:
Shutting down xfbbd: [FAILED]
Now another /usr/sbin/fbb status reports:
Checking, the FBB daemon
xfbbd is stopped
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 twice).
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).
· 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.
7. How to use LinFBB's "xfbbX", a GUI client for Linux
2002-10-20
Well, soon after the installation of LinFBB v7.04 .rpm 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".
It seemed that a mouse click on that "xfbbd X Client" icon was not
likely to return any response, although xfbbd daemon has been
successfully running before 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.
Trying to find a solution, the other day I was browsing the /usr/sbin
directory. I have noticed something that I have already seen for
several times. That was xfbbX file. Well, I am sure that I tried to
use this executable earlier, but without much success. This time, I
have entered the full path, like this:
/usr/sbin/xfbbX
and, finally, the GUI client appeared on the screen.
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 scrolled traffic.
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.
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 xfbbX 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?)
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.
But, the big disadvantage of today's version of xfbbX 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 xfbbX 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.
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.
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, xfbbW
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?
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
xfbbX GUI environment, in order to avoid using two computers.
2002-10-30
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").
Well, when I tried to click on that icon, I got a KFM Warning message
box explaining that program /root/.xfbbX 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: /usr/sbin/xfbbX. After that, another click resulted in running
the GUI client.
Interestingly, there is some slight difference between xfbbX
appearance under KDE and Gnome. Actually, each KDE's xfbbX window has
"FBB" logo in the upper left corner (Gnome's windows haven't that).
That may indicate that xfbbX 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.
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 xfbbX is running here this or that
way.
8. How to use LinFBB's "xfbbW", a GUI client for Windows
2002-11-17
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.
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 eth0
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).
What I do know, is that such tools should have add some new lines into
the existing files, like /etc/conf.modules or, to create some new
files, like /etc/isapnp*. 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 /sbin/isapnp. 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.
What I also tried to use, was the old good Linuxconf 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 220
(for the I/O address), instead of 0x220 that would better fit. The
result was as one may expect: the interface eth0 continued to report
that a ne 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).
Interestingly, Linuxconf added a couple of new lines into
/etc/conf.modules too. In short, the next time during the system boot,
the interface eth0 reported a green [OK], so I could establish the
link. So far - so good.
The next task was to download the client package from the FBB's main
site. I did it from the "Newest version" 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 "newest" 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.
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 message justification 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.
Another issue with xfbbW client is that seems not to allow a multiple
click onto more than one BBS callsign within pending forward list,
comparing to WinFBB's behavior. You know, I am not very fond of
opening the same pending forward window repeatedly again and again, in
order to start (or to stop) more than one forwarding action.
In general, I like xfbbW 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 xfbbW's help system. I mean of a real Windows help,
because there's not much use of a Help menu, having only Copyright and
About information :-))
9. How to compile LinFBB's executable files
2003-01-01
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 ...
· Well, I have already had the package xfbb-7.04-2.i386.rpm (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.
· The other day, I finally decided to abandon that 4-5 year old
version of X11 LinFBB application 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.
· 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 tarballs. So, what I
have downloaded from www.f6fbb.org/versions.html
, was xd704h-src.tgz archive.
· 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 readme file, it should
be "fbbsrc" directory, so I considered that /usr/src would be the
best place to copy archive's fbbsrc.704h directory.
· fbbsrc.704h directory has been made of 12 files and 7
subdirectories, one of which is src subdirectory. As I said, the
readme suggests a user to "goto fbbsrc/src" directory, and I
concluded that /usr/src/fbbsrc.704h/src was the right place.
· The readme also suggests to "update the variables" at the beginning
of Makefile 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.
· The next task was to run make command from the shell and it took
half a minute to be finished. The result were few new xfbb
executable files that I quickly moved to /usr/sbin directory. BTW,
some people rather suggest to run make install, in order to avoid
multiple copying of compiled executables, but I found that way as
not functional.
· Soon after, I tried to activate LinFBB's daemon and it seemed to
work without visible difficulties (using a temporary home LAN with
a laptop, I also started fbbW, a LinFBB Windows client. It
recognized the daemon in a second and I've only noticed that there
was no Protus password utility running).
· According the readme, 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
/usr/src/fbbsrc.704h/src was X11 subdir.
· After clicking on its icon, I recognized the second one file with a
name Makefile (they have mentioned "updating" of both 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 not to have
something like that installed (case they mean of a suit of libax25,
ax25apps and ax25tool - than it is OK). Anyway, one more time I
activated make command from the shell and the result was in getting
xfbbC executable.
· As usual, xfbbC client is invoked from within an xterm (or similar)
window and it seemed that it was also fully functional. So far - so
good.
· 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
--force and --nodeps options to avoid several dependency obstacles.
In sum, Lestiff has come to its place on the disk.
· This time, I did make some "updates" related to Makefile paths and
tried to run make command from the shell (for the 3rd time now).
Seems that I got no answer, because there appeared neither xfbbX
nor xfbbX_cl 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.
· Finally, I managed to activate xfbbX 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.
· As I just mentioned, I noticed that the first console connections
were without familiar {PROTUS-4.1b7} 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: /usr/lib/fbb/filter, re-started
the system and Protus returned back to its function.
· 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.
10. How to make better ham radio rules?
2002-10-27
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.
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 digital manner, has to learn manual
analog Morse telegraphy and pass the similar manual 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 digital 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!
You all know, there are so many Linux enthusiasts world-wide
(including myself) who have been fighting against all types of
monopols (like a company from Redmond, USA). The Morse obligatory
test is the same: just another type of a monopoly!
That's why I have been trying to persuade all relevant authorities to
remove 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 "ham") radio, as soon
as they hear they have to pass the Morse test, as the legal
requirement before 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.
I have been thinking what to do, since early ninetees when I was the
secretary of YU7 (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 Ham Digital Licence
(the HDL 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).
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 digital ham
radio), RFI issues and how to avoid them etc.
I believe that amateur radio digital 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, before we become allowed to use any type of the
amateur radio activities. Such a stupid rule does not exist
elsewhere!
Should you want helping us to adopt internationally known principles,
that do NOT require to join any 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.
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.
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!
11. Bibliography
2003-06-01
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.
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!
- "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.
12. Further information
12.1. Copyright
Copyright (c) 2003 by Miroslav "Misko" Skoric, YT7MPB.
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
http://www.fsf.org/licenses/fdl.html.
12.2. Disclaimer
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.
12.3. News
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.
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 Linux Documentation Project homepage
or this one: Linux Documentation Project .
12.4. Credits
This version of mini-HOWTO can thanks to:
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.
Any comments or suggestions can be mailed to my email address:
m.skoric@eunet.yu.
12.5. HOWTO
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 Bootdisk, Installation, SCSI and
UMSDOS. The main site for these is the LDP archive
at Metalab (formerly known as Sunsite).
12.6. Mini-HOWTO
These are the smaller free text relatives to the HOWTOs. Some
relevant mini-HOWTOs are Backup-With-MSDOS, Diskless, LILO, Large
Disk, Linux+DOS+Win95+OS2, Linux+OS2+DOS, Linux+Win95,
Linux+WindowsNT, Linux+NT-Loader, NFS-Root, Win95+Win+Linux, ZIP
Drive, FBB packet-radio BBS etc. You can find these at the same place
as the HOWTOs, usually in a sub directory called mini. Note that these
are scheduled to be converted into SGML and become proper HOWTOs in
the near future.
12.7. Local Resources
In most distributions of Linux there is a document directory
installed, have a look in the /usr/doc directory. where most packages
store their main documentation and README files etc. Also you will
here find the HOWTO archive ( /usr/doc/HOWTO) of ready formatted
HOWTOs and also the mini-HOWTO archive ( /usr/doc/HOWTO/mini
) of plain text documents.
Many of the configuration files mentioned earlier can be found in the
/etc directory. In particular you will want to work with the
/etc/fstab file that sets up the mounting of partitions and possibly
also /etc/mdtab file that is used for the md system to set up RAID.
The kernel source in /usr/src/linux is, of
course, the ultimate documentation. In other words, use the source,
Luke. 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 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 ( /var/log/messages) to see
what is going on and in particular how the booting went if too much
scrolled off your screen. Using tail -f /var/log/messages 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 /proc file system that is a window
into the inner workings of your system. Use cat rather than more to
view the files as they are reported as being zero length. Reports are
that less works well here.
12.8. Web Pages
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 Linux Documentation Project
home page, or this one: 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.
13. Getting help
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 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:
Hardware
· Processor
· DMA
· IRQ
· Chip set (LX, BX etc)
· Bus (ISA, VESA, PCI etc)
· Expansion cards used (Disk controllers, video, IO etc)
Software
· BIOS (On motherboard and possibly SCSI host adapters)
· LILO, if used
· Linux kernel version as well as possible modifications and
patches
· Kernel parameters, if any
· Software that shows the error (with version number or date)
Peripherals
· Type of disk drives with manufacturer name, version and type
· Other relevant peripherals connected to the same busses
Remember that booting text is logged to /var/log/messages 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 SHIFT and 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 brief as a complete log file dumped to
Usenet News is more than a little annoying.