© 1996-2003 Jan Wolter, Steve Weiss
Backtalk version 1.4.x uses new formats for most identity databases, which means that users upgrading from Backtalk 1.3.x will need up rebuild their user databases. For more information on how to do this, see the upgrade notes.
Backtalk is an advanced web-based computer conferencing system written and distributed by Jan Wolter and Steve Weiss. For general information about Backtalk, see the Backtalk home page. This document describes the procedure for installing Backtalk on a Unix system. The Backtalk Glossary will help you with some of the terminology used here.
We have expended substantial effort to make the installation process for Backtalk as simple as possible, but it is still more complex than most other packages. There is more to it than just doing "./configure; make install". (Though that might be all it takes in a few cases.)
The complexity of installing Backtalk is partly due to Backtalk's high degree of configurability, and partly due to the necessity of interacting with your http server, which may be configured many different ways. The installation process is not, however, as complex as the bulk of this installation manual would suggest (because we do rather run on, don't we?). However we do recommend reading through this manual as you do the installation. If you have questions or problems, please contact us at contact page, so that we can help you and refine this installation guide.
Backtalk must run on a host running some brand of Unix. Sorry, no Windows or Macintosh OS9 versions are available (or likely to be any time soon). Our objective is to make it work on any flavor of Unix. It has actually been tested on a fair variety of Unixes, including (in decreasing order of thoroughness):
One of the key decisions that you will have to make, and which will impact much of the installation process, is what kind of authentication you wish to use. When Backtalk users connect to your conferencing system, they will give a login name and a password to identify themselves. Backtalk can be configured one of three main ways:
Installation will be a bit more complex than the other option, and you will need to obtain the separately distributed mod_auth_external package, and the "pwauth" program included in that package. This is a free extension to the Apache http server which enables reasonably secure authentication from Unix shadow password files.
Backtalk supports a fairly large number of moderately standard authentication databases, so there is at least a chance that one of the existing configurations will work for you without modification. If your user database is in an SQL database, then it may be fairly easy to make Backtalk work with that database, as Backtalk's SQL interface is pretty easily customizable. Otherwise, you may have to do some C coding to implement a new authentication module for Backtalk. This is a bit more challenging, but it's still probably going to be a lot easier to modify Backtalk to play nicely with your other applications than to modify them to play nicely with Backtalk.
These installation instructions won't tell you too much about how to customize the authentication system beyond the normal array of options built into Backtalk. There is a separate document with advice on how to customize Backtalk's authentication system to work with pre-existing user databases. Aside from that, the installation is probably going to be similar to the standard "backtalk accounts" installation procedure described here.
To set up Backtalk with real Unix accounts, you will need root access on your system. An installation with Backtalk accounts, however, can be done by anyone with enough access to install cgi-bin programs, though it is simpler if you have root access.
Backtalk can be convinced to cooperate nicely with web versions of Yapp, but it's a somewhat finicky process. Getting along with command-line Yapp or Picospan is simpler.
In configuring a new site, I always write a script to run the configure command. For example, the current config script for the Backtalk demo site on unixpapa.com is called UNIXPAPA_CONFIG and looks like this:
env CPPFLAGS=-I/usr/local/include/mysql \ LDFLAGS=-L/usr/local/lib/mysql \ ./configure \ --htmldir=/usr/home/jv/public_html/bt_demo-1.4.6 \ --htmlurl=http://www.unixpapa.com/bt_demo-1.4.6 \ --cgidir=/usr/home/jv/public_html/cgi-bin/bt_demo-1.4.6 \ --cgiurl=http://www.unixpapa.com/cgi-bin/bt_demo-1.4.6 \ --httpd-id=nobody \ --owner-id=jv \ --prefix=/usr/home/jv/jan/bt_demo-1.4.6 \ --login=cookie \ --auth=sql \ --ident=authfile \ --group=sql \ --session=sql \ --with-ispell \ --with-sendmail \ --userlevels=1 \ --with-mysqlNote that I install everything in directories whose names include the version numbers. I keep the script around and when I do an upgrade I edit the script, putting in the new version number, so the new release is installed in a new directory. This way the old system is still runnable by users while I'm updating all the config scripts and testing the new release.
If I'm doing an upgrade where the format of the user database and/or bbs database is not changing, I just move the user and/or bbs directories from the old backtalk directory to the new backtalk directory, putting symlinks into the old directory so the old system continues working. Commands would be something like this, if I was upgrading from Backtalk 1.4.1 to 1.4.6:
cd /usr/home/jv/jan/bt_demo-1.4.6 rm -rf user bbs cd ../bt_demo-1.4.1 mv user ../bt_demo-1.4.6; ln -s ../bt_demo-1.4.6/user user mv bbs ../bt_demo-1.4.6; ln -s ../bt_demo-1.4.6/bbs bbsSo the user and bbs directories now appear to be in both the old and new Backtalk directories, with the real data being in the newest directory (this is important - otherwise you'd lose data when you eventually delete the old directories). I do the mv and ln commands in one line to minimize the time during which the old (active!) system is missing it's user and conference directories. (Perhaps a better procedure would be to keep the real user and bbs directories in a btdemo_data directory, and have all the btdemo-x.x.x directories symlink to that, but the file formats do sometimes change.)
In the cgi-bin directory, I create symbolic links to the subdirectory for the currently active Backtalk version. So the advertized URL for the backtalk demo site is http://www.unixpapa.com/cgi-bin/bt_demo/backtalk, where the bt_demo component of the path name is actually a symlink to bt_demo-1.4.6, or whatever the current release is. When I have finished configuring and testing the new release, I just switch the symlink, and for most users the new version magically appears. This only works if the httpd is configured to follow symlinks.
Usually when there are changes in the format of the databases, then the new release is written so that it can read the old files, but will write them out in the new format. In such cases, you should not leave the old version of Backtalk installed after switching over to the new version as it will eventually stop working.