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

updated

This commit is contained in:
gferg 2002-10-22 22:43:01 +00:00
parent f6b52c6011
commit 7a4b054306
3 changed files with 226 additions and 101 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml
View File

@ -472,7 +472,7 @@ FBB</ULink>, <CiteTitle>
FBB Packet-radio BBS mini-HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>
Updated: November 2001</CiteTitle>.
Updated: October 2002</CiteTitle>.
Covers the installation and use of the most popular amateur packet-radio
BBS software FBB. </Para>
</ListItem>

2
LDP/howto/docbook/HOWTO-INDEX/miscSect.sgml
View File

@ -351,7 +351,7 @@ FBB</ULink>, <CiteTitle>
FBB Packet-radio BBS mini-HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>
Updated: November 2001</CiteTitle>.
Updated: October 2002</CiteTitle>.
Covers the installation and use of the most popular amateur packet-radio
BBS software FBB. </Para>
</ListItem>

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

@ -6,7 +6,7 @@
<title>FBB Packet-radio BBS mini-HOWTO
<author>Miroslav "Misko" Skoric, YT7MPB,
<tt/m.skoric@eunet.yu/
<date>v1.11, 2001-11-27
<date>v1.12, 2002-10-22
<abstract>
<nidx>linux windows nt amateur packet radio</nidx>
This mini-HOWTO covers the installation and use of
@ -95,16 +95,18 @@ have here:
monitor the radio chanell.
4. All three versions must be capable to
use the same configuration files, i.e.
to be able, for example, to begin from
the exact position where the other
version finished its previous session.
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). So, no (re)compilations here :-)
Windows). I mean of RPM packages. So, there
are no source (re)compilations here :-)
</verb></tscreen>
@ -859,6 +861,7 @@ to the existing two: X11 LinFBB and WinFBB!</em>
that you may <bf>kill</bf> after that.
</itemize>
<p>
<sect>How to install an "upgrade" to daemon version of LinFBB
@ -1044,9 +1047,9 @@ reverse procedure must be put in place.</em>
<p>
<item>Recently, I was informed that <bf>xfbbC</bf>
is suitable only for sysops, but other users
(who also might have local keyboard access)
should rather try:
is suitable mostly for sysops, so the other users
(who might also have access to the local
keyboard) should rather try something like this:
<p>
<tscreen><verb>
@ -1055,34 +1058,36 @@ reverse procedure must be put in place.</em>
<p>
<item>... where 'localhost' and '6300' may vary from
system to system. I was pleasently surprised
bbs to bbs. I was pleasently surprised
when discovered that <bf>telnet</bf> is much more
useful for regular users than <bf>xfbbC</bf>.
practical for ordinary bbs users than <bf>xfbbC</bf>.
<p>
<item>Folks, I think of making a section about the
<item>Folks, I also think of writing a chapter about
FBB's system configuration. Until something
like that appear on the net, you should know
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. And, all of
those who are going to <bf>telnet</bf> into
the BBS have to be declared as users with
a 'M' flag (modem users). It is up to your
security precautions, if either of them will
have <em>'root'</em> abilities to the Linux box.
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 Linux box itself.
<p>
<item>My next issue is to use an old 286/12 MHz box,
having 1 MB of RAM and running DOS 5.0 as a
'telnet client' computer. That box also has
a NIC and I would like to 'connect' to the
BBS computer from that 'telnet client' box.
Due to my preparation for starting another
LinFBB in the local school club, where I
should have several old 286 boxes, would
be nice to offer more than one kid to
'connect' the BBS simultanously, using
a bunch of 'telnet client' computers.
<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
succeedes, it would be a good preparation for
installing another LinFBB (in the local school
club), where I would have several similar 286
computers. It would be nice to offer more than
one school kid the opportunity to 'connect' the
BBS simultanously, using a bunch of vintage
'telnet client' computers.
</itemize>
@ -1090,49 +1095,53 @@ reverse procedure must be put in place.</em>
<sect1>LinFBB v7.04
<p>
<em>Notice: Maybe I have already told you that I
<em>Notice: Maybe I have already explained that I
use Red Hat 6.2 at home. That's why I usualy look
for <tt>.rpm</tt> packages that have been made for
that Linux distribution. And not only that. I have
also tried Red Hat 7.1 but it seemed not to support
Xwindows LinFBB 7.00g (04 August 1998). When I saw
that, I switched back to Red Hat 6.2.</em>
that particular Linux distribution. And not only that. I have
also tried to use Red Hat 7.1 but it seemed not to support
an older Xwindows application, LinFBB 7.00g (04 August 1998).
When I noticed that, I returned back to Red Hat 6.2.</em>
<p>
<itemize>
<item>Well, <tt>xfbb-7.04-2.i386.rpm</tt> (07 August 2001)
have been downloaded from
<item>Well, I started with 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 decided to install v7.04
<item>Folks, this time I finally decided to install
version 7.04
as a completely "fresh" installation, i.e.
without parts of a previous daemon on the disk.
It means that I have uninstalled previous
daemon version of LinFBB and, in addition,
removed all older executables (of course, before
the uninstalation, I made the backup of some
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 not
to edit usual "defaults" again and again :-)
(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 did install the package once again with
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 saved ones, then mounted
WinFBB's FAT partition, made a pray and started
LinFBB's daemon. In order to accomplish that, it
was a new experience to try HI8GN's
script <bf>/usr/sbin/fbb start</bf> within an
<em>xterm</em> to start the thing. Although there
was no usual
<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
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 ...
@ -1140,13 +1149,14 @@ that, I switched back to Red Hat 6.2.</em>
</verb></tscreen>
<p>
on the screen, TNC's <em>PTT</em> lamp showed
that a beacon was transmitted.
on the screen, TNC's <em>PTT</em> lamp confirmed
that a <em>beacon</em> was really transmitted.
<p>
<item>Then I wanted to use HI8GN's <bf>/usr/sbin/monitor</bf>
to see what's going on on the frequency. Although
I got something like
<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
@ -1155,7 +1165,7 @@ that a beacon was transmitted.
</verb></tscreen>
<p>
there wasn't any traffic on the screen. In order to really
there appeared no traffic on the screen. In order to really
monitor the channel, I had to start another <em>xterm</em>
and type:
@ -1165,21 +1175,20 @@ and type:
</verb></tscreen>
<p>
and from FBB's prompt enter the gateway, type
the "M" command you are familiar with etc. But,
interestingly, as soon as I telnet'ed to the
Bingo! From FBB's prompt I have entered the gateway
and typed the familiar "M" ("Monitor") command.
Interestingly, as soon as I "telneted" to the
BBS, <bf>/usr/sbin/monitor</bf> window, mentioned
above, started
to copy whatever was going on the telnet xterm
(until that telnet session was closed). I wondered
if that was ok or not because I expected to see
the traffic passing thru the channel -
regardless being connected to the system or
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 I expected to see the traffic on 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
<bf>/usr/sbin/bbs</bf>, in order to connect
to the client_console (<em>xfbbC</em>). Looks
that there was a line in HI8GN's script:
<p>
@ -1188,21 +1197,22 @@ not. Any suggestion here?
</verb></tscreen>
<p>
with missing ./ (dot+slash) before xfbbC, so the script
was not likely to be executed, but reported that a
command couldn't be found. Anyway, <em>xfbbC V3.01</em>
itself seemed to work Ok. It *is* possible to monitor the
channel from here too (using the "M" command under the
gateway), but this is also a bad solution because
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 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. Solutions welcomed!
anything else within the gateway. Once again, solutions
are welcomed!
<p>
<item>Though <em>xfbbC</em> session can be easily
terminated with "B" ("bye") command, a fooled
<bf>/usr/sbin/monitor</bf> can not. Its
process have to be found with <bf>ps ax</bf>
and then killed.
<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> using <bf>ps ax</bf>
command and then kill that process.
<p>
<item>At the end of the game, daemon itself should
@ -1228,16 +1238,16 @@ but <bf>/usr/sbin/fbb status</bf>
Looks that <bf>/usr/sbin/fbb stop</bf> does not terminate
daemon *every* time the command is executed, but re-start it
(the only difference is the new PID of the process and
<bf>ps ax</bf> also shows this new PID). So, there is
<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 re-started.
<p>
<item>Well, if you are like me, you may also want to experiment
with sysop's commands under <em>xfbbC</em> session.
For example, "/R" command (Reboot PC) shuts down
<em>xfbbC</em> and <bf>/usr/sbin/fbb status</bf>
reports:
<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 ("Reboot PC") shuts down <em>xfbbC</em>
and <bf>/usr/sbin/fbb status</bf> reports:
<p>
<tscreen><verb>
Checking, the FBB daemon
@ -1245,20 +1255,20 @@ obvious that daemon is not stopped, but re-started.
</verb></tscreen>
<p>
while "/A" command (Stop BBS) does the same but returns:
while "/A" command ("Stop BBS") returns:
<tscreen><verb>
Stop-request accepted, no connection.
</verb></tscreen>
<p>
before shutting down <em>xfbbC</em> itself.
before shutting down <em>xfbbC</em> client itself.
<p>
Further tries to re-start either <em>xfbbC</em>
or fbbd (using <bf>/usr/sbin/fbb start</bf>) are not
successful, unless <bf>/usr/sbin/fbb stop</bf> is
executed in addition:
Further tries 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>
@ -1276,9 +1286,10 @@ Then <bf>/usr/sbin/fbb status</bf> reports:
<p>
so, daemon might be re-started again. Here it is
also mysterious why it returns that [FAILED]
also a mystery why it returns that [FAILED]
when it is obvious that daemon is really
stopped.
stopped (maybe it is a "failure" if somebody tries to
stop the same thing <em>twice</em>).
<p>
There are some other commands: "/K" (Reboot BBS with
@ -1291,13 +1302,127 @@ re-start daemon (with different PIDs, of course).
<p>
<item>Finally, what I would like to have is to
manage housekeeping and other maintaining
tasks. 'Till now, that is not accomplished.
I suppose that I should make some more
customization of system paths. Any suggestion
tasks. Untill now, that is not accomplished.
I suppose that I should make some more fine
customization in system paths. Any suggestion
is welcomed.
</itemize>
<p>
<sect>How to use "xfbbX" - a GUI client
<p>
2002-10-20
<p>
Well, soon after the installation of LinFBB v7.04
<em>.rpm</em> package, I noticed
the 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
respond, although <em>xfbbd</em> daemon has been successfully
running <em>before</em> invoking the client. That's why I have
been asking for help from other LinFBB users, but it seemed
there was no one capable to solve the problem.
<p>
The other day I was browsing the <bf>/usr/sbin</bf> directory
and 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 that file 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 showed the actual radio traffic on the frequency,
but not only that. Headers of packets appeared in green
and the actual information was in blue, so it was easily
to distinguish what was the header and what was the
real text info. What I could describe 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
partners' traffic appeared in green, the local user's
traffic was in black and port information was in yellow.
Unfortunatelly, there's no easy way (if any) to change
the colors (an usual feature in WinFBB) for both
'Monitoring' and 'All channels' windows. Maybe I
haven't managed to find a switch for that, so any
useful info will be welcomed.
<p>
What I have found a bit annoying, was that both windows
mentioned above, appeared not arranged side-by-side,
a form that would be more suitable. Besides that, the
third window, 'Console', has to be activated with a
mouse click (instead of being activated automaticaly
with the other two windows). Actually, the whole thing of
<em>xfbbX</em> client seems to be primarily useful for
sysops looking for a command line, maintain the server
etc. So it is strange why the console window must be activated
separately (ok, I know that's the same with WinFBB's
windows, but...)
<p>
Anyway, the 'Console' connection window is almost the same
functional as WinFBB's 'Console' window. Actually,
the commands are the same, because they are invoked
from the <language>.TXT files.
<p>
The big disadvantage of the <em>xfbbX</em>
client, I have found here, is the absence of
several useful icons, that I was 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 and WinFBB in order to perform
some simple tasks, using the mouse.
<p>
Besides that, there is no way to activate that nice
message editor screen, very useful in WinFBB
(also in the old Xwindows 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
so many, already implemented but 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 keep further development of LinFBB server side,
but, in the same time, to abandon the development
of LinFBB's GUI client side. And not only that. It
looks that Windows client for LinFBB server, <em>xfbbW</em>
has been reported to be much more functional that xfbbX,
while, in the same time, WinFBB server development is
also stopped. A bit confusing situation, isn't it?
<sect>Further information