Changes RSS

Synchronet BBS on Debian Lenny

The reason for figuring out my own approach to installing SBBS3, is that I really do not like the “mingle and mangle” approach of build-system that Rob Swindell has set up for Synchronet.

While it works just fine, I am really unconfortable with the way he mixes source files, version-controlled files and production data into one big bowl of soup.

I may be environmentally damaged, but having written code myself, and been working with systems administration, this approach of mixing production data with source is a no-no, and mixing production data with CVS source is a headshot-wound waiting to happen.

Unfinished notes…


Start out with a base Debian Lenny install with “Standard” as the only “tasksel'ed” option. Install the needed packages for compilation of Synchronet.

apt-get install build-essentials
apt-get install cvs
apt-get install libncurses5-dev
apt-get install screen

It is good practice to never work as root, and let as little dynamic data be owned by root. So, add a user for the bbs:

adduser <bbs-owner-username>

Get the sources

Log out from your root session, and log back in with the user you created

I personally fetched the reference doc (I'm trying to work a bit outside of this though, so I get it just for reference)


Next, I created no less than two directories in the bbs user home:

mkdir sbbs
mkdir build

The sbbs dir will be the SBBSDIR, as in, the directory where all the Synchronet files will live. The build directory will be used for, precicely, the build environment and source files.

Pull in the sbbs3 sources and needed libraries from CVS:

cd build
cvs -d co -r HEAD src-sbbs3
cvs -d co -r HEAD lib/mozilla/js/linux.release
cvs -d co -r HEAD lib/mozilla/js/linux.debug
cvs -d co -r HEAD lib/mozilla/nspr/linux.release
cvs -d co -r HEAD lib/mozilla/nspr/linux.debug
cvs -d co -r HEAD lib/cryptlib/linux.release

This gives us a complete kit of sources needed for build. We need a populated SBBSDIR (the directory where Synchronet will be installed) to stop the install from failing. This can be done either by pulling in the stock runtime, or restoring from a backup of a previous base. To do a fresh install of a stock BBS:

cd ~
wget -O sbbs_run-`date +"%Y%m%d"`.tar.gz
cd sbbs
tar zxvf ~/sbbs_run-`date +"%Y%m%d"`.tar.gz

Modified GNUmakefile

The stock GNUmakefile is where the real “magick” I am trying to avoid, so instead of following the install doc, and pulling in that one, I have modified it heavily.

As a reference to my changes, the base file I started with is available here, while a unified diff of the changes is also available.

The resulting GNUmakefile is placed at the root of my 'build' directory.


Before compiling, make sure your SBBSDIR is located correctly. You can add the location as a variable to every invocation of make, or you can set it as an environment variable. I find that to be cleaner:

export SBBSDIR=~/sbbs

To compile the SBBS3 binaries (the Synchronet binaries, plus scfg umonitor uedit and syncview) is now as simple as:


This performs a build with RELEASE configuration, without installing anything! A small, but significant step. To build DEBUG versions of the binaries should be as simple as adding “DEBUG=1” to the make

After building the binaries, and verifying A'OK-ness, installing is done as usual (with the added export):


Naturally, if this is done in sequence of the “make”, the export is not needed…. And if you added DEBUG=1 in the previous step, add the same here.

Some files in the runtime set, those being the external programs and baja sources, need to be compiled. With the export still valid, do:

make externals

Configure and test

If this is a fresh install, you are now ready to configure your setup. Follow the info in sbbsunix.txt for this, basically you need to:

cd ~/sbbs
export SBBSCTRL=/home/bbs/sbbs/ctrl
# Configure needed settings & options
# Change any options related to services and features in the ini files:
vim ctrl/sbbs.ini
vim ctrl/services.ini
# And test the setup. 
# SBBS runs services that use privileged ports, 
# so you'll have to run it as root, unfortunately:
su -c ./exec/sbbs


After doing this modification, I have a build system that I trust a whole lot more, and I am now looking into a way to do a proper “dont-run-as-root” setup for this. There should be code for dropping privileges, but they are still untested by me. Stay tuned for updates :D