Whole document tree

6. How to install an "upgrade" to 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. Beside that, some hams, as well as 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 to install easily.

• 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 regarding 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.

• 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).

• 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 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 only for sysops, but other users (who also might have local keyboard access) should rather try:

        telnet localhost 6300
  

• ... where 'localhost' and '6300' may vary from system to system. I was pleasently surprised when discovered that telnet is much more useful for regular users than xfbbC.

• Folks, I think of making a section about the FBB's system configuration. Until something like that appear on the net, you should know that all of those callsigns who are going to use xfbbC have to be added into your 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.

• 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.

6.3 LinFBB v7.04

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.

• Well, xfbb-7.04-2.i386.rpm (07 August 2001) have been downloaded from www.f6fbb.org/versions.html

• Folks, this time I decided to install v7.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 config files that are not version depending (like /etc/fbb.conf), in order not to edit usual "defaults" again and again :-)

• 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 "--force" and "--nodeps" options.

• 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 /usr/sbin/fbb start within an xterm to start the thing. Although there was no usual

        xfbbC/X server running ...
        xfbbd ready and running ...
  

  on the screen, TNC's PTT lamp showed that a beacon was transmitted.

• Then I wanted to use HI8GN's /usr/sbin/monitor to see what's going on on the frequency. Although I got something like

        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?

• Well, then I wanted to use /usr/sbin/bbs in order to connect to the client_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, 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!

• Though xfbbC session can be easily terminated with "B" ("bye") command, a fooled /usr/sbin/monitor can not. Its process have to be found with ps ax and then killed.

• 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 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.

• Well, if you are like me, you may also want to experiment with sysop's commands under xfbbC session. For example, "/R" command (Reboot PC) shuts down xfbbC and /usr/sbin/fbb status reports:

        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).

• 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 is welcomed.