Backtalk Installation Guide

Version 1.4.9

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

Linux
OpenBSD
FreeBSD
SunOS 4.1
NetBSD
Solaris
Mach (NeXTStep)
Ultrix

It probably works on almost any other Unix as well, probably including Macintosh OSX.

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:

Authenticate with Backtalk accounts. The login/password gives access to Backtalk, but does not let users log onto your system via telnet, rlogin, or ftp. The Backtalk accounts are not real Unix accounts, instead the authentication database is maintained directly by Backtalk. Tools to create and manage such accounts are included in the Backtalk system. This is the simplest and most common way to set up Backtalk. (Note that Backtalk will maintain a directory for each user's files that it calls a "home directory" and it will assign a unique ID number to each user that it calls a "uid number" - but these values are not real Unix "home directories" or "uid numbers".)
Authenticate with real Unix accounts. The host system's /etc/passwd database will be used to authenticate Backtalk users. This way any user that can telnet to the system can use the same login and password to run Backtalk. Backtalk's files will be kept in the user's actual Unix home directory, and will be owned by the user instead of Backtalk, so they can be shared with Picospan or command-line Yapp. That is the primary reason you might prefer this configuration - if you want to allow your users a choice between conferencing with a telnet-based interface like Picospan or Yapp, or with a web-based interface like Backtalk. None of the account creation and administration tools included in Backtalk will work in this configuration (you should use the standard Unix account administration tools to create, destroy and edit accounts).
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.
Some Other Existing Authentication System. If you already have some kind of authentication system running on your web site that lets users log in with password and login ID, then you might want those logins to work for Backtalk too instead of making your users login separately to use Backtalk.
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.

Recommended Installation and Upgrade Procedure

Over the years, my standard method of installing Backtalk has evolved considerably. Someday I mean to update the configure scripts to more effectively support them. For now, I'd just like to make some recommendations.

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-mysql

Note 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 bbs

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

Getting Started

Once you've decided which of these major variations you want, you are ready to start the installation process. Separate pages describe each part of the installation process:

Backtalk Configuration.
Compilation.
SQL Server Configuration.
Installation with Backtalk accounts or Unix accounts.
Apache Configuration for Backtalk accounts or Unix accounts.
Crontab Configuration.
Customization.