1. Create a directory in your CGI-BIN called "rpgboard".
2. Put all of the scripts (*.cgi) and include files (*.h) into this directory.  UPLOAD IN ASCII!!!
3. Make the scripts (*.cgi) executable by chmoding them 755 in your RPGBoard directory.
4. Make rpgvariables.h writable by chmoding it 666.  (If you know how your server's security works, you might want to chmod it to 600 or 644 and change ownership accordingly.)
5. Apache users: Edit (or create) your .htaccess file and add xbithack on to it.  The option forces the server to check any HTML file for server-side includes, if the exec bit is set (not just *.shtml files).  Put this file in your root WWW directory (or message directory, if you want).
6. Create a directory where the message board will go.  (Let's say "/mb".)  Do not put this directory in your CGI-BIN!  (BTW, this is considered to be your base directory.)
7. Create a directory called "messages" in your MB directory (like "/mb/messages").
8. Chmod both of these directories to 777.
9. Put the *.html and *.gif files into a "docs" directory (like "/mb/docs")
10. Throw the dictionary file in your MB directory, if you are going to use it.
11. Fire up your favorite browser and go to the config.cgi on your site.
12. Enter in password on the password prompt.
13. Configure the basic information.  (Don't forget to change your password!)
14. After you submit the information, a bunch of warnings will get displayed.  This is normal.  Be sure to read through them all and check the indented actions, too.
15. Go to the main screen and configure all of the sections.  Don't stop until you don't see any more warnings.  (For now, only configure one forum.)
16. Special note when creating forums: Use small names for your forums.  Don't name everything "[insert topic here] Discussion Board".  It's repetive, esp. when your MB's collective name is "[something] Discussion Board".  Instead, just call it your topic.  Not only does it look nicer, but the default directory name isn't nearly as long.  ("Foobar Discussion Board" turns into "foobardiscussionboard/".)
17. Go to defaults.html on your MB directory and use !!default as the name and password as the password.
18. This is the default defaults for people who aren't registered.  Change everything that you want to, including the password.
19. Now, test the board by going to http://www.yoursite.com/yourmb/yourforum/.  If you see the "Display messages from" option on the page, you're OK.  If not, you may not be running Apache and/or your SSIs may not be working.
20. Try posting a message and see if it shows up.  Test all of the other functions, too.
21. You'll need to make a index.html in your MB directory as a entrance page.  Also, changing the pre-made HTML files ([defaults/backgrounds/index/post].html) would be nice, too.  (Please don't remove the SSI comments, ok?)

However, as a program originally intented for UNIX systems, RPGBoard has a few features which will not work on NT.  These are the auto-compression system (no GZip), e-mail functions (no sendmail), and using nslookup to check an IP name (no nslookup).  You should disable the first two in the toggle menu of the configurator.  (RPGBoard won't use nslookup if it can't find it.)

(BTW, unzip the dictionary since you can't use GZip.)

1. Using telnet and running the command on the files (like "chmod 755 *.cgi").
2. Using an FTP client that supports a "change permissions" or "CHMOD" function.  Usually, this is accessible by right-clicking on the file.
3. Using the QUOTE command from a FTP client (like "QUOTE SITE CHMOD 755 post.cgi")

• 0 = no permissions
• 1 = execute only
• 2 = write only
• 3 = write/execute
• 4 = read only
• 5 = read/execute
• 6 = read/write
• 7 = read/write/execute (full permissions)

If you are on an NT system, you don't need to worry about it.  NT systems don't have a way of remotely changing the permissions of a file or directory, so your WHS has made sure there is no way of encountering permission problems.

Basically, a CGI-BIN is the place where you put your WWW progams.  Anything that interacts with the internet on the server end goes there.  If you don't have one, you can't run any *.cgi, *.pl, *.py, etc. scripts/programs via a browser, including this script.  (Sorry!)

More information on user moderation can be found on question 3.6 in the Posters' FAQ.

When the first post of the new day hits the script, it starts the auto maintenance processes: deleting, archiving, and compression.  The daily maintenance routine will first delete any old data files from the forum directory.  Then it will run the archiving.

The archive process involves taking all of the yyyymmdd (daily) files and merging them into a yyyymm (monthly) file, and taking all of the yyyymm (monthly) files and putting them into yyyy (yearly) file.  While it's doing this, it will purge any messages marked for deletion, and fix any corruption in the data files (as best as it can).  There is no change in the readability of the messages, merely the way the files are organized.

After the archiving is completed, it will compress any data files with gzip or bzip2, if you have either.  Note that messages can still be read from a compressed database, though it might be slightly slower, due to uncompression overhead.

Setting up the bridge is somewhat easy, but it requires several steps.  First of all, you'll need to reserve a forum for this purpose.  The bridge works on both threaded and non-threaded/flat modes.  (Hybrid and semi-threaded modes might work, but it's not recommended, due to its strange results.)

Go into the directory/file locations and set your ML mailbox file, such as "/var/spool/mail/foobar", or /home/foobar/mailbox".  This is the mailbox file that the bridge will scan for ML messages.  If you leave it blank, the bridge will look for standard input for messages.  This is useful if you're going to use something like procmail to activate the bridge.  (On a side note, the bridge automatically dumps the contents of standard input to standard output for easy piping.)

After this is done, you have to setup the ML forum variables.  First, turn on the switch next to the ML subject search option to turn on the bridge for that forum.  The ML subject search is the phrase usually found on the beginning of all messages like "(foobar)" or "[Foo Bar]".  This phrase is important because RPGBoard will extracted it out of the subjectline, as well as use it for e-mail posts for that forum.  (If you don't have such a phrase, leave it blank.)  The ML to/cc/bcc search is the list of addresses that can be used to post a ML message.  It will search both this list and the subjectline (logical OR) for messages to post.  (If both are blank, it will accept all messages.)  If you want all forum messages to get sent to the ML, fill in the "E-Mail all posts to" option.

Now, you need to setup your system to run the ml2forum.pl program every time you get e-mail.  Recommendations would be either a crontab entry or something in your procmail file.  (No, I'm not going to give you help on either of these details.  Read a man page.)  One thing to note: the ml2forum.pl MUST be in the RPGBoard directory.  Also, the bridge will NOT delete mail for you.  You have to do that yourself to prevent dupes.

1. All of the files have been renamed.  As such, you'll have to hand edit your index.html and post.html files, as well as your defaults.html.  The following are the name changes you should fix:

   rpgadmin.cgi --> admin.cgi
   rpgbio.cgi --> bio.cgi
   rpgboard.cgi --> post.cgi
   rpgconfig.cgi --> config.cgi
   rpgdefaults.cgi --> defaults.cgi
   rpgheaders.cgi --> viewer.cgi
   rpgmessage.cgi --> viewer.cgi
   rpgsearch.cgi --> search.cgi
   rpgstats.cgi --> stats.cgi

   Remove the following files from your /cgi-bin/rpgboard directory:

   rpg*.cgi
   rpgerrors.h
   rpgglobal.h
   rpgheaders.h
   rpglanguage.h
   rpgmessage.h

   Rename your rpgvariables.h to variables.h.  After all this is done, go into your configurator and change the locations of all of the CGI files.

2. The post.html SSIs are slightly different.  Change the following:

   <form method=POST action="/cgi-bin/rpgboard/post.cgi?forum">
   <!--#include virtual="/cgi-bin/rpgboard/post.cgi"-->

   to:

   <!--#include virtual="/cgi-bin/rpgboard/post.cgi?forum"-->

3. RPGBoard now uses CSS for its fonts.  As such, you'll need to change a few things in your index.html and post.html files.  For both of them, you'll need to add the following SSI in-between the ending HEAD tag and beginning BODY tag:

   UNIX systems: <!--#include virtual="/cgi-bin/rpgboard/post.cgi?@@CSS@@"-->
   Windows systems: <!--#exec cgi="/cgi-bin/rpgboard/post.cgi?@@CSS@@"-->

• Normal Users can:
• Post messages
• Change his/her message defaults
• Delete his/her messages
• Forum Administrators can:
• Do anything a normal user can
• Delete or undelete anybody's messages (including multiple deletions), on the forum s/he's limited to
• Change the score on a message to anything (between -X and X*2; where X is the default score)
• Spoof as another user on protected boards, on the forum s/he's limited to (not very useful, but...)
• MB Administrators can:
• Do anything a forum admin can, except on all of the forums
• Change anybody's message defaults (including passwords)
• Change the default message defaults (using the name "!!default"), including the MB admin password
• Superusers can:
• Do anything an MB admin can
• Change the configuration of the MB, including the forum and superuser passwords
• Edit the ban list
• Add new forums/backgrounds/etc.

*.foobar.com          Some loser spamming the board
192.168.*             Mr. Flamer
ip*.anytown.*.us

• Normal passwords:
• Changable though the defaults
• Normal users, MB admins, and superusers can change the password
• Used to grant normal access for a registered nick
• Forum passwords (optional):
• Changable though the Forum section of the configurator
• Only superusers can change these passwords
• Used to grant admin access for a specific forum
• MB admin (or master default) password:
• Changable though the defaults by using the name "!!default"
• Only superusers and MB admins can change the password
• Used to grant admin access for an entire MB
• Superuser (or configurator) password:
• Changable though the Basic Information section of the configurator
• Only superusers can change the password
• Used to grant superuser access for an entire MB

Except for the normal passwords, none of the passwords have any username attached to them.  So, if you want to grant admin access to somebody, all you have to do is give them the password, and tell them to test it somewhere.  (Deleting and undeleting a message is a good test.)  This will store the password cookie, so that they can be reconized as an admin on future visits.

If you're using forum passwords, you might end up with a lot of passwords to deal with.  As the passwords themselves are encrypted, you can't use them as a reference.  The best thing to do is to keep record (in a safe and secure place, mind you) of the passwords and who uses them, because while this script makes managing large MBs much easier, there's still a few things you need to keep track of.

• Very small (small group of friends, etc.):
Definately only one forum, possibly even a forum set to flat mode.  Administration shouldn't be much of a problem.

• Small (start-up MB):
You should only start with one forum and one admin.  If you start with too many forums, the message population hits the floor and nobody visits the MB.  Instead, start with a "General" forum, and work from there.  Eventually, you'll see the need for a forum split, and your MB will become popular at its own rate.

• Medium (3-5 forums):
Here is where message scanning might become a problem for one user.  The best solution is to find another trusted regular that tends to visit different forums that you do, and give him MB admin access.  Forum admins might be another option, but they aren't really required at this point.

• Large (7-10 forums, start-up MB for popular sites):
Forum admins tend to be helpful at this point, as there are certain people that favor a peticular forum.  Find these people out (through the stats program, if you have to), and figure out which ones should be forum admins.  Generally, one person will handle one or two forums, and they'll do it without really trying, because they frequent that forum anyway.

A second MB admin might be a good idea, too.  Thus, you would have yourself (a superuser), two MB admins, and your forum admins.  At this point, keeping track of admin/forum passwords is a good idea.

• Very large (12+ forums):
While forum admins can potentially protect an infinate number of forums, you might run the risk of too much power given to too many people, and having too much to keep track of.  For a MB of this scale, you could either ditch the forum administration system entirely in favor of user moderation, or add user moderation as an alternative administration tool for the regulars to use.  The configuration options for moderation are important: about 25% of your regulars should be moderators, and the default score should reflect the total number of moderators.  (Again, use your stats program.)

Forum splits are a tricky thing.  They can make or break the life of a forum.  However, they are basically the only way to create new forums.  The general rule is this: if a forum gets overpopulated with messages of a certain type, it's time for a forum split.  Overpopulation depends on the forum subject, but it's generally when the expire time hits the "2 days ago" mark consistantly (if the forum expire time is set to automatic).  Of course, a chatty forum might have a bunch of small threads, while a more intellectual forum would contain three or four dense threads at a time (this is called "thread density"), so use your best judgment.  Overall, don't be afraid to kill off a new forum if it's not working out, especially if both forums are too slow because of the split.

Enforcement of forum topics should be somewhat strict, especially right after a forum split.  Yes, people may complain, but if you don't do your job, the forums might become unbalanced and cluttered with off-topic messages.  (If it becomes too bad, some people may stop visiting the forums, due to an overabundance of off-topic subjects that they don't care about.)

You should also consider the audience of your forums.  Don't rely on one forum having the same audience as another forum, even if they were the product of a forum split.  Some people might visit your MB exclusively for one forum.  Others might visit one forum for different reasons than you might think.  Therefore, when you split a forum, remember that you may be dealing with a slightly different audience on both forums.

Another cause of this problem is that your Perl program may be located in a different location than "/usr/bin/perl".  Try telnetting into the site and type "which perl".  Jot that path down and change the first line of all of the script files (*.cgi) to match it.  For example, if your Perl is located at "/usr/local/bin/perl", you would change the first line to say:

#!/usr/local/bin/perl

Also, did you forget to chmod your config.cgi?

If you have root access to your web server, you may want to check a few Apache config options make your that your SSIs are turned on.  Check your httpd.conf (or other config files, if you have an older version of Apache) for:

AddHandler server-parsed .shtml
AddType text/html shtml

(Of course, this is not a requirement for people using the XBitHack option.)

Also, you should check for Options Include in your <Directory /www/foo/bar/myweb> section.  After all, it isn't going to do anything if the SSIs aren't turned on :)

This behavior is both good and bad.  It's good because it cuts down on bandwidth by a lot.  It's bad because your users might get a stale copy and would usually have to do a reload to get a fresh one.  If you want to fix this, remove those META tags.  However, doing this would raise your bandwidth usage because people will never use a cached copy of the page.

The CGI scripts (specifically, viewer.cgi) will cache all messages for 15 minutes.  After that period, the browser will re-request the message again.  I feel that 15 minutes is an good period of time to prevent reloads on already-fresh messages, but if you want a way to change this time frame or disable it altogether, let me know and I'll add that as an option on the next RPGBoard.

$cl_archive = 1;
$ENV{'QUERY_STRING'} = "[forum id here]";
do "post.cgi";

Fill in the correct forum ID on the second line.  Save this file (say, "archive.pl") and put it in the cgi-bin/rpgboard directory.  Telnet into your box, enter the cgi-bin/rpgboard directory, and type "perl [filename]" (like "perl archive.pl").  (As a precaution, you may want to disable the exec bit on all of the RPGBoard files temporarily to prevent any damage from users.)

However, the password cookies make things easier so you don't have to enter in your password every time.  Yes, you're more likely to forgot your password because of that, but hey...nobody's perfect!