Next
Previous
Contents
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.
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
'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 :->
- /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
'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.
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 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).
- 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.
Next
Previous
Contents
|