(1) The documentation says the board’s configuration file can be in the same directory as the data, but my server only allows CGI scripts to be in the CGI-BIN directory! Is this a problem?

No. The configuration file can be located anywhere, so long as the variables are defined correctly to point to the various data files and the message directory. The advantage of having the configuration file outside of your CGI-BIN directory (and renaming it “index.cgi”) is simply that the address of your board’s main page will then be something like “http://www.foo.com/forum/index.cgi” rather than “http://www.foo.com/cgi-bin/forum.config.cgi.” As well, like “index.html” or “welcome.html,” “index.cgi” is recognized on most servers as a “default” page, which means if someone tries to access only the directory name, instead of giving them the directory listing, your server will act as though they’d actually called the default page. The issue is really mostly just a matter of aesthetics, though.

(2) How do I set up multiple boards?

Each board should have its own separate directory (with its own dupecheck file, data number file, address list, and so on). Each should also have a separate config script specifying the correct directory and settings for that particular board. All of the config files can and should reference the same webbbs.pl script, though.

It’s probably easiest to keep the webbbs.pl script in your cgi-bin directory. The individual configuration files can also be there, though if your server allows it, it’s probably better to put them in the various BBS directories, as index.cgi files, so as to make it as easy as possible for your visitors to get to the message indexes!

(3) How can I prevent certain individuals from posting on my BBS?

Unfortunately, you can’t. There is no way to identify visitors to your Web site unless they voluntarily provide you with their identities, so there’s no way to prevent certain specific visitors from posting. The best you could do would be to ban particular IP numbers. However, since most systems use dynamic IP addressing, a given user won’t always have the same number; thus, in order to keep the visitor away, you’d have to ban everyone from his ISP. Obviously, in the case of larger ISPs such as AOL, that’s not even remotely practical. As well, if an individual has more than one access account, even banning an entire ISP won’t necessarily get rid of him.

The only practical way to keep unwanted visitors from posting is to only allow certain visitors to post.

One way to do this is to password-protect your BBS. This can be done by placing the script files within a password-protected directory, and controlling access to that directory via any of the multitude of programs available for the purpose.

A slightly less “secure” but somewhat simpler method of controlling access is to set WebBBS to require profiles and e-mail addresses. No one will be able to post without first creating a profile, and valid e-mail addresses will be required with those profiles. So while you won’t necessarily be able to prevent someone from posting (at least not the first time), you will be able to track down exactly who you’re dealing with.

Short of limiting who can post, your only real alternative — shared by all of us — is to simply ignore the occasional twits and hope they go away quickly.

(4) I’m confused about how the “NEW” message notification works….

First, if you don’t have the script set to utilize cookies, no “new message” notifications will appear. And no messages will appear as “new” on your first visit to the board, or on your first visit after deleting your cookie files.

If you’ve visited the board several times, and the notices still aren’t appearing, or aren’t appearing correctly, you may just need to delete your cookie file and start from scratch.

The script considers a new visit to begin once you’ve been away from the board for at least thirty minutes, so if you return to the board before half an hour has elapsed, the “new” notices will not have updated.

Finally, messages posted since the beginning, rather than the end, of your last visit are flagged as new. So your own messages from your last visit will be so flagged. This may seem a bit confusing at first, but it’s actually handy, as it makes it easier to spot new responses to your messages. As well, any messages posted by others while you were busy posting messages will also be flagged as new on your next visit, so you won’t risk missing them.

(5) The system load seems excessive. What can I do?

The very thing which gives WebBBS its incredible flexibility — the fact that it doesn’t utilize any static HTML pages — also results in its greatest weakness, as every call to the board requires that the script be re-compiled and re-run. The 4.XX and 5.XX versions are much more efficient than earlier versions, but problems can still crop up, especially on very busy sites. The single most helpful thing you can do to reduce server load is make sure that you’re working with the DB_File DBM (database) module, as is discussed in the program’s documentation. Also, use frames! Use of frames will reduce both bandwidth consumption and server resource consumption.

(6) What is LWP::Simple?

WebBBS utilizes the “LWP::Simple” module. This is part of the standard distribution of Perl, and should be available on your system. If, however, for some reason it is not, you should speak with your system administrators about having it installed or about having the version of Perl on your server updated. WebBBS can be run without the module, if you comment out (or simple delete) the use LWP::Simple; $LWPS = 1; line at the top of the “SSI_Functions” subroutine. However, so long as the module is not available, the script will not be able to process “EXEC” SSI tags in your header or footer files.