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.
.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.
.rpmsave extensions. It was nice,
so I could use them later to update my new-installed
config files.
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.
7plus
operations). Next, its xfbbC console client looks better
than the previous version. But, I still miss
xfbbX client, that I have found not functional.
I hope it will be fixed soon. Finally, Protus
c_filter utility is active too.
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.
.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.
.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.
.703 (for example).
.703 files won't
be unistalled automatically).
xfbb.sh (in my case, that is 7.01f).
.703) to get
their new extensions (in my case, that is .701).
.703 files
should *lose* their previously attached extensions,
in order to become usable.
xfbbC/X server running ...
xfbbd ready and running ...
telnet localhost 6300
passwd.sys file. And, all of
those who are going to telnet 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 'root' abilities to the Linux box.
Notice: Maybe I have already told you that I
use Red Hat 6.2 at home. That's why I usualy look
for .rpm 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.
xfbb-7.04-2.i386.rpm (07 August 2001)
have been downloaded from
www.f6fbb.org/versions.html
/etc/fbb.conf), in order not
to edit usual "defaults" again and again :-)
xfbbC/X server running ...
xfbbd ready and running ...
on the screen, TNC's PTT lamp showed that a beacon was transmitted.
Connecting localhost ... Ok
Authentication in progress ... Ok
Monitoring channel 0 ...
there wasn't any traffic on the screen. In order to really monitor the channel, I had to start another xterm and type:
telnet localhost 6300
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 BBS, /usr/sbin/monitor 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 not. Any suggestion here?
xfbbC -c -f -h localhost -i [callsign] -w [password]
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, xfbbC V3.01 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 while "Monitor ON", it is not confortable to do anything else. Solutions welcomed!
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 also shows this new PID). So, there is a question why it returns that [OK] when it is obvious that daemon is not stopped, but re-started.
Checking, the FBB daemon
xfbbd dead but subsys locked
while "/A" command (Stop BBS) does the same but returns:
Stop-request accepted, no connection.
before shutting down xfbbC itself.
Further tries to re-start either xfbbC or fbbd (using /usr/sbin/fbb start) are not successful, unless /usr/sbin/fbb stop is executed in addition:
Shutting down xfbbd: [FAILED]
Then /usr/sbin/fbb status reports:
Checking, the FBB daemon
xfbbd is stopped
so, daemon might be re-started again. Here it is also mysterious why it returns that [FAILED] when it is obvious that daemon is really stopped.
There are some other commands: "/K" (Reboot BBS with housekeeping), "/M" (Reboot BBS imediatelly) and "/L" (Reboot BBS, waiting users to disconnect) - all of them with slightly different behaviour. Anyway, those three have something in common: they re-start daemon (with different PIDs, of course).