519 lines
16 KiB
HTML
519 lines
16 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE>FBB Packet-radio BBS mini-HOWTO: How to install an upgrade to a daemon version of LinFBB</TITLE>
|
|
<LINK HREF="FBB-7.html" REL=next>
|
|
<LINK HREF="FBB-5.html" REL=previous>
|
|
<LINK HREF="FBB.html#toc6" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="FBB-7.html">Next</A>
|
|
<A HREF="FBB-5.html">Previous</A>
|
|
<A HREF="FBB.html#toc6">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s6">6.</A> <A HREF="FBB.html#toc6">How to install an <EM>upgrade</EM> to a daemon version of LinFBB</A></H2>
|
|
|
|
|
|
<H2><A NAME="ss6.1">6.1</A> <A HREF="FBB.html#toc6.1">LinFBB v7.02g</A>
|
|
</H2>
|
|
|
|
<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>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI>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.
|
|
|
|
|
|
</LI>
|
|
<LI>Jose, HI8GN, has offered daemon LinFBB v7.02g as a
|
|
<CODE>.rpm</CODE> package (18 September 2000). I got it
|
|
from his site:
|
|
<A HREF="http://hi8gn.dynip.com/indice.html">http://hi8gn.dynip.com/indice.html</A>. But, when I tried
|
|
to install it <EM>over</EM> the previous version 7.01f, it
|
|
complained about some existing LinFBB files.
|
|
|
|
|
|
</LI>
|
|
<LI>Then I had to uninstall the old package, after what
|
|
some config files remained in their locations, but
|
|
with new <CODE>.rpmsave</CODE> extensions. It was nice,
|
|
so I could use them later to update my new-installed
|
|
config files.
|
|
|
|
|
|
</LI>
|
|
<LI>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
|
|
<CODE>xfbbd</CODE> and <CODE>xfbbC</CODE> 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 <CODE>.rpm</CODE>, in order to install the previous
|
|
version of LinFBB once again - the version that I was
|
|
satisfied with.
|
|
|
|
|
|
</LI>
|
|
<LI>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...?
|
|
|
|
|
|
</LI>
|
|
<LI>Well, the new daemon is likely to check for some more directories
|
|
than the older version (mostly related to <CODE>7plus</CODE>
|
|
operations). Next, its <CODE>xfbbC</CODE> console client looks better
|
|
than the previous version. But, I still miss graphical
|
|
<CODE>xfbbX</CODE> client, that I have found not able to become
|
|
activated. I hope it will be fixed soon. Finally, Protus
|
|
<CODE>c_filter</CODE> utility is active too.
|
|
|
|
|
|
</LI>
|
|
<LI>An interesting question might be: is that now a really upgraded
|
|
LinFBB daemon or not? Actually, I haven't changed the "old"
|
|
script <CODE>xfbbd.sh</CODE> 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 <CODE>xfbbd.sh</CODE>.
|
|
After I returned to <CODE>xfbbd.sh</CODE> 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 <CODE>m_filter</CODE> has not been found or something like that.
|
|
The next tasks are to solve these issues.
|
|
</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="ss6.2">6.2</A> <A HREF="FBB.html#toc6.2">LinFBB v7.03</A>
|
|
</H2>
|
|
|
|
<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>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI>Well, it was needed to get 7.03 package (09 December 2000)
|
|
as an <CODE>.rpm</CODE> package from
|
|
<A HREF="http://www.f6fbb.org/versions.html">www.f6fbb.org/versions.html</A>,
|
|
that was suggested by Jean-Paul, F6FBB. Anyway,
|
|
soon after there appeared several mirror sites,
|
|
offering 7.03 too.
|
|
|
|
|
|
</LI>
|
|
<LI>If you use <EM>GnomeRPM</EM>, it is easy to uninstall
|
|
your actual LinFBB (If you just try to install new
|
|
<CODE>.rpm</CODE> 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 <CODE>.rpmsave</CODE> files, so you could use
|
|
them later again.
|
|
|
|
|
|
</LI>
|
|
<LI>Installation of 7.03 package will give you
|
|
new executables in <B>/usr/sbin</B> directory.
|
|
Those new executables should be temporary given
|
|
extensions like <CODE>.703</CODE> (for example).
|
|
|
|
|
|
</LI>
|
|
<LI>So far - so good. Now you should *uninstall* the
|
|
7.03 package (of course, <CODE>.703</CODE> files won't
|
|
be unistalled automatically). Uninstall? Why? You will
|
|
find out soon, read on ...
|
|
|
|
|
|
</LI>
|
|
<LI>Once again, you should *install* the <EM>last</EM>
|
|
one version of LinFBB daemon, that works OK with its
|
|
own <CODE>xfbb.sh</CODE> (in my case, that is 7.01f).
|
|
|
|
|
|
</LI>
|
|
<LI>For sure, many of you might find it odd, but
|
|
now it is the right time for the executables from
|
|
<B>/usr/sbin</B> (I mean of all fbb executables,
|
|
except those who were renamed to <CODE>.703</CODE>) to get
|
|
their new extensions (in my case, that is <CODE>.701</CODE>).
|
|
|
|
|
|
</LI>
|
|
<LI>Well, after that is performed, <CODE>.703</CODE> files
|
|
should *lose* their previously attached extensions,
|
|
in order to become usable.
|
|
|
|
|
|
</LI>
|
|
<LI>Folks, on that point I usually hold my breath, <B>cd</B>
|
|
to <B>/usr/sbin</B> and type: <B>xfbb.sh</B>
|
|
following with an Enter. If everything is fine, several
|
|
lines should scroll on the screen, ending with
|
|
something like:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
xfbbC/X server running ...
|
|
xfbbd ready and running ...
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
</LI>
|
|
<LI>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
|
|
through the procedure once again in order to be
|
|
sure you did all what was needed to be done :->
|
|
|
|
|
|
</LI>
|
|
<LI><B>/usr/sbin/xfbbC</B> 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.
|
|
|
|
|
|
</LI>
|
|
<LI>Recently, I was informed that <B>xfbbC</B>
|
|
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>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
telnet localhost 6300
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
</LI>
|
|
<LI>... where 'localhost' and '6300' may vary from
|
|
BBS to BBS. I was pleasantly surprised
|
|
when discovered that <B>telnet</B> is much more
|
|
suitable for ordinary BBS users than <EM>sysops'</EM>
|
|
client <B>xfbbC</B>.
|
|
|
|
|
|
</LI>
|
|
<LI>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 <B>xfbbC</B> have to be added into
|
|
your <CODE>passwd.sys</CODE> file. In addition, all
|
|
of these folks who are going to <B>telnet</B>
|
|
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.
|
|
|
|
</LI>
|
|
<LI>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.
|
|
</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="ss6.3">6.3</A> <A HREF="FBB.html#toc6.3">LinFBB v7.04</A>
|
|
</H2>
|
|
|
|
<P><EM>Notice: Maybe I have already explained that I
|
|
use Red Hat 6.2 at home. That's why I usually look
|
|
for <CODE>.rpm</CODE> 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>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI>Well, I started by downloading the package
|
|
<CODE>xfbb-7.04-2.i386.rpm</CODE> (07 August 2001)
|
|
from
|
|
<A HREF="http://www.f6fbb.org/versions.html">www.f6fbb.org/versions.html</A>
|
|
|
|
|
|
</LI>
|
|
<LI>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 <CODE>/etc/fbb.conf</CODE>), in order to avoid
|
|
editing the same "defaults" once again and again :-)
|
|
|
|
|
|
</LI>
|
|
<LI>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.
|
|
|
|
|
|
</LI>
|
|
<LI>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 <B>/usr/sbin/fbb start</B> (activated in an
|
|
<EM>xterm</EM>) to start the server. Although there
|
|
were no usual lines:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
xfbbC/X server running ...
|
|
xfbbd ready and running ...
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>on my screen, TNC's <EM>PTT</EM> lamp confirmed
|
|
that a <EM>beacon</EM> was really transmitted.</P>
|
|
|
|
|
|
</LI>
|
|
<LI>Then I wanted to try HI8GN's script
|
|
<B>/usr/sbin/monitor</B> to see what's
|
|
going on the frequency. Although
|
|
I got something like:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Connecting localhost ... Ok
|
|
Authentication in progress ... Ok
|
|
Monitoring channel 0 ...
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<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>
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
telnet localhost 6300
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<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, <B>/usr/sbin/monitor</B> 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>
|
|
|
|
|
|
</LI>
|
|
<LI>Well, then I wanted to use <B>/usr/sbin/bbs</B>,
|
|
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>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
xfbbC -c -f -h localhost -i [callsign] -w [password]
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<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>
|
|
|
|
|
|
</LI>
|
|
<LI>Although the active <EM>xfbbC</EM> session can be
|
|
easily terminated using "B" ("Bye") command, a fooled
|
|
<B>/usr/sbin/monitor</B> can not. The user has to
|
|
find its <EM>process number</EM>, (PID), using <B>ps ax</B>
|
|
command and then kill that process.
|
|
|
|
|
|
</LI>
|
|
<LI>At the end of the game, daemon itself should
|
|
be stopped. HI8GN's script <B>/usr/sbin/fbb stop</B>
|
|
returns:
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Shutting down xfbbd: [OK]
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>but <B>/usr/sbin/fbb status</B>
|
|
reports:</P>
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Checking, the FBB daemon
|
|
xfbbd (pid) is running...
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>Looks that <B>/usr/sbin/fbb stop</B> 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
|
|
<B>ps ax</B> 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>
|
|
|
|
|
|
</LI>
|
|
<LI>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 <B>/usr/sbin/fbb status</B> reports:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Checking, the FBB daemon
|
|
xfbbd dead but subsys locked
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>while "/A" command ("Stop BBS") returns:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Stop-request accepted, no connection.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>before shutting down <EM>xfbbC</EM> client itself.</P>
|
|
|
|
<P>Further attempts to re-start either <EM>xfbbC</EM> client
|
|
or <EM>xfbbd</EM> server (using <B>/usr/sbin/fbb start</B>)
|
|
are not successful, unless an additional
|
|
<B>/usr/sbin/fbb stop</B> is executed. The result is:</P>
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Shutting down xfbbd: [FAILED]
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<P>Now another <B>/usr/sbin/fbb status</B> reports:</P>
|
|
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Checking, the FBB daemon
|
|
xfbbd is stopped
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<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>
|
|
|
|
<P>There are some other commands: "/K" (Re-boot BBS with
|
|
housekeeping), "/M" (Re-boot BBS immediately) 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>
|
|
|
|
|
|
</LI>
|
|
<LI>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.
|
|
</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
|
|
|
|
<HR>
|
|
<A HREF="FBB-7.html">Next</A>
|
|
<A HREF="FBB-5.html">Previous</A>
|
|
<A HREF="FBB.html#toc6">Contents</A>
|
|
</BODY>
|
|
</HTML>
|