Menu ▾ ▴

WWIV 5.0 Install on Linux

Rushfan David Rock

These are some rough details for the steps necessary to get a working linux-based system.
As I get more details about each area, I will be fleshing things out.

NOTE: Unless specifically stated otherwise, assume all linux commands
are run as the wwiv user created in section 1. This ensures the
permissions are correct.

*** Linux things you will need (in no particular order) ***
xinetd - service manager to start telnet. This doc assumes xinetd, but you can also use inetd or systemd. That will be at your own risk, though.
telnetd - telnet service to handle starting the BBS
fetchmail - to pull mail (needed for WWIVnet)
procmail - to drop files in the right places (needed for WWIVnet)
ncurses - any curses library, really. Needed for CLI tools display
dosemu - to run dos-based doors and utilities
dos2unix/unix2dos - for converting file types
uudecode - for processing WWIVnet files

*** Compile things you will need ***
svn (subversion) - to grab the source code for compiling
cmake
make
gcc 4.8 or later

*** (really) Optional Linux Things ***
MTA (eg, postfix) - to process mail
fpc (FreePascal) - for building old Pascal things like WWIVedit

Pre-install steps

DO NOT RUN WWIV AS ROOT. You are just asking to get screwed if you do.
The root account is the linux equivalent of SYSOP. Also, don't run WWIV
as your own user. Anything your user can do, the BBS can do. The best
option is to create a dedicated user to run the BBS.

*** Create WWIV user ***
as root:

  1. create the wwiv group:
    groupadd wwiv
  2. create the wwiv user:
    useradd -g wwiv -c "WWIV BBS Service Account" -d /home/wwiv -s /sbin/nologin -m wwiv
  3. lock wwiv user:
    usermod -L wwiv

This creates a wwiv group and user that has a home directory of
/home/wwiv (change this to whatever you want, but see the note below)
and sets the shell to /sbin/nologin, which makes it impossible to log
in as the wwiv user. The wwiv user should also be locked.

NOTE: If you see something like this:
useradd: cannot create directory /home/wwiv
It's probably because the base directory (/home) does not exist. You will
need to create that separately before running the user command. You should
not run into this unless you decide to use a directory location that's
different than a typical user setup (like a separate /bbs filesystem or something).

Next, use sudo to grant your userid access to run stuff as the wwiv
user, since you can't log in as the wwiv user. This will be important
for manipulating files in the directory, since your userid won't own
them.

As root

  1. visudo
    add the following line to allow access to all commands as the wwiv user:
    youruserid ALL=(wwiv) ALL

To use this, simply run:
sudo -u wwiv -s
it will ask for your password and then will start a shell as the wwiv user.
You are now effectively the wwiv user. You can check this with the id command. For example:
yourid@yourserver ~ $ id
uid=1001(wwiv) gid=1001(wwiv) groups=1001(wwiv)

Steps to install

NOTE run all commands from WWIV install directory as the wwiv user unless stated otherwise
NOTE All references to init refer to the WWIV init program in the WWIVBASE, NOT the linux init command.

  1. Make WWIV directory (this should be the same as the home directory of the wwiv user above)
  2. download the latest WWIV 5.0 to your wwiv directory
  3. Extract wwiv-build-number-number.zip into your wwiv directory
  4. Copy the compiled binaries to your WWIV base directory
    • NOTE Do these steps as a non-root user; your BBS user would be the easiest from a file permissions perspective later on.
    • pull down the code from svn (svn checkout svn://svn.code.sf.net/p/wwiv/svn/trunk wwiv-svn) There are currently no pre-built binaries for linux.
    • In the svn directory (e.g., /home/wwiv/wwiv-svn), run cmake . && make (don't forget the ".")
    • assuming you built in /home/wwiv/wwiv-svn, the binaries you will have as a result are:
      • /home/wwiv/wwiv-svn/bbs/bbs
      • /home/wwiv/wwiv-svn/init/init
      • /home/wwiv/wwiv-svn/nodemgr/nodemgr
      • /home/wwiv/wwiv-svn/fix/fix
      • /home/wwiv/wwiv-svn/networkb/networkb
    • These should all be placed in your base WWIV directory. For example, if your WWIV base is /home/wwiv and your svn base is /home/wwiv/wwiv-svn, the following will copy all the compiled binaries to your base wwiv directory
      • cd /home/wwiv
      • cp /home/wwiv/wwiv-svn/fix/fix /home/wwiv/wwiv-svn/bbs/bbs /home/wwiv/wwiv-svn/init/init /home/wwiv/wwiv-svn/nodemgr/nodemgr /home/wwiv/wwiv-svn/networkb/networkb . (don't forget the ".")
  5. run sh install.sh It will run init at the end; say Yes to initializing and log out of init. init takes care of the remaining WWIV-specific config files (e.g., config.dat)
  6. Your BBS basic local setup is complete. Run ./bbs and set up a new user to be the sysop (#1) account (ie, type NEW for the user and fill in the user info). Once you are done, log out.
  7. Run ./init and set up all the details
    • select (G) "General System Configuration" to set up the BBS name, etc
    • select (U) for the User editor. Set user #1 SL and DSL permissions to 255 to set it up as your sysop user.
    • select (P) "System Paths". You will want to set up relative pathing, not absolute paths, as tools that run under DOSEMU will conflict and get confused.
      • ** example of relative pathing **
      • Messages : msgs/
      • GFiles : gfiles/
      • Menus : gfiles/menus/
      • Data : data/
      • Downloads : dloads/

*** Setting up multiple instances ***
Managing your instance nodes is a setting in the wwiv.ini file. Find the following values and configure to your liking. The default setup gives you four nodes:

NUM_INSTANCES        = 4
TEMP_DIRECTORY       = temp%n
BATCH_DIRECTORY      = batch%n

*** Set up xinetd to handle telnet requests and run nodemgr ***

Move ${WWIVBASE}/wwiv-service to /etc/xinetd.d/wwiv, change disable=yes to disable=no, and restart xinetd. Depending on how xinetd is configured, you may also need to adjust access settings in /etc/xinetd.conf. The no_access or only_from directives for example often are set up to not allow remote connections by default.

If your system is using inetd instead, you will need to translate the wwiv-service file to an inetd.conf compatible format.

NOTE this will need to be created as the root user, since you are writing in the /etc/xinetd.d directory. Note we are using the user that we created above. Change the port, user and server_args values as appropriate (ie, to match where you installed things, etc).

After the install

If you've gotten this far, Your BBS should be up and running. Everything below this point is details about more in-depth configuration (DOORs, WWIVnet, etc) and some of the current warts that linux has that you need to be aware of. If you come across anything that is not detailed here, please let us know.

*** DOSEMU config ***
DOSEMU is used for a number of things that can't be handled directly. Here are some config details
[DOSEMU common settings] - general settings for DOSEMU
[DOSEMU for system scripts] - specific settings for system scripts (wwivnet, etc)
[DOSEMU for doors] - specific settings for different doors

*** Configuring WWIVnet ***
See [WWIVnet Config on Linux] for details on configuring WWIVnet and subscribing to subs

*** Things that are "hinky" ***
Filename Case mismatches
The biggest issues right now are problems with filename case mismatching.

One way to get around this is to use hard linking.

Hard linking only works if the files are on the same filesystem (which shouldn't be a problem since everything is in the same directory anyway). hard links also don't work for directories. hard links are preferred over symlinks (soft links) where possible because they are actually references to the same inode (ie, they are the same file with different names), so any change to one is actually a change to both. You can verify they are the same inode by using the ls command with a -i:

wwiv@wdfs ~/msgs $ ls -li .dat
173185 -rw-r--r-- 1 wwiv wwiv 200 May 11 23:50 GENERAL.dat
173234 -rw-r--r-- 1 wwiv wwiv 100 May 11 23:48 TESTSUB.dat
173387 -rw-r--r-- 1 wwiv wwiv 100 May 30 14:59 W4LINUX.dat
173239 -rw-r--r-- 2 wwiv wwiv 1000 May 30 15:14 wwivsys.dat
173239 -rw-r--r-- 2* wwiv wwiv 1000 May 30 15:14 WWIVSYS.dat

note the inodes are the same in the first column, and the number of references to that inode is 2, rather than the usual 1.

To create a hard link, use the ln command. For example:
ln -P wwivsys.dat WWIVSYS.dat

List of known filename case mismatches

Data
subs msgs files: msgs/*.dat should be UPPER.lower

Display Files
gfiles/

TERM settings
The Curses library being used for init gets confused on some terminal settings, and results in a borked display on exit. You may have to type a "reset" command to get it to behave normally again. In general, it appears that using a TERM setting in the xterm family works best (xterm, xterm-color, etc).

Troubleshooting

*** Hung bbs process ***

There have been some cases where the connection to the bbs will die for unknown reasons and it doesn't clean up properly. This leaves nodes hung up as in use and if a normal user was connected, they won't be able to reconnect. An easy way to simulate this is to connect with syncTERM and just close the syncTERM window instead of logging off.

To clean up disconnected processes, use the ps command to find them and kill them. Let's look at an example:

wwiv@wdfs ~ $ ps axu | head -n 1
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

wwiv@wdfs ~ $ ps axu | grep "\./bbs\s" | grep -v grep
wwiv     21546  6.1  0.4   5820  2508 ?        R    11:52   1:08 ./bbs /N1 /I1
wwiv     21611  0.2  0.4   5820  2252 pts/10   S+   12:09   0:00 ./bbs /N2 /I2

If you look at the TTY column, you will see that one of the active nodes has "pts/10" while the other has "?". The one with the "?" is the disconnected one. Active terminal sessions have a TTY for user interaction. When the TTY goes away, it becomes an unusable node. So, the one we are interested in killing off is the one with "?" in the TTY column.

so, we can use a shell script to clean these up:

for pid in `ps axu | grep "\./bbs\s" | grep -v grep | awk '{if($7 == "?") print $2}'`
do
    kill $pid
done

This will find all the ps lines that match ./bbs and have "?" in column #7, loop through them and run a kill command on the process id in column #2. You can put this in a shell script and schedule it via cron if this is a big issue, otherwise, it's available for occasional cleanup.

NOTE: You may need to change the field value references for your awk command to match your specific ps output.

Related

Wiki: DOSEMU common settings
Wiki: DOSEMU for system scripts
Wiki: Install
Wiki: WWIVnet Config on Linux

MongoDB Logo MongoDB