Citadel/UX

a messaging and collaboration platform for BBS and groupware applications

Copyright ©1987-2003 by the Citadel development team:

Steven M. Bellovin	author of public domain 'parsedate' function
Nathan Bryant	build system, security, database access, and others
Art Cancro	overall system design and lead developer
Brian Costello	cosmetics, additional commands
Michael Hampton	client software development
Andru Luvisi	troubleshooting and development assistance
Daniel Malament	string compare function for IMAP server
Stu Mark	additional client features, IGnet protocol design
Ben Mehlman	additional client features
Ari Samson	assistance with project management
John Walker	author of public domain base64 encoder/decoder
Steve Williams	documentation
Ethan Young	IGnet protocol design

The entire package is open source; you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

For more information, visit either of these locations on the web:

• The Citadel home page: http://www.citadel.org
• UNCENSORED! BBS, the home of Citadel: http://uncensored.citadel.org

---

Table of Contents

1. License
2. Installation
3. System Administration
4. Baz
5. Eek

---

GNU General Public License

Copyright (C) 1989, 1991 Free Software Foundation, Inc.  
59 Temple Place - Suite 330, Boston, MA  02111-1307, USA

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

• a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

• b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

• c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

• a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

• b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

• c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

Installation

Overview

Citadel/UX is an advanced, multiuser, client/server, room-based BBS program. It is designed to handle the needs of both small dialup systems and large-scale Internet-connected systems. It was originally developed on an Altos system running Xenix, and has been installed and tested on various Unix and Unix-like platforms. The author's current development environment (and BBS) is an ordinary Linux system. The current distribution includes:

• The Citadel/UX server (this is the back end that does all processing)
• A text-based client program designed with the traditional Citadel "look and feel" (room prompts, dot commands, and the like)
• Setup programs
• A set of utilities for system administration and maintenance
• Documentation

Some knowledge of the Unix system is necessary to install and manage the system. It is mandatory that the sysop have "root" access to the operating system. The following are required to install Citadel/UX:

• A Unix operating system (Linux, BSD, Solaris, Tru64, HP/UX)
• C compiler (such as gcc or egcs) and "make"
• POSIX threads (the "pthreads" library)
• TCP/IP
• Berkeley DB v4.1 or newer (GDBM also works, but its use is officially depracated. If you are building a new system, do not use GDBM. If you have an existing system which uses GDBM, you should migrate it to Berkeley DB as soon as possible.)
• Enough disk space to hold all of the programs and data

If you are running Citadel/UX on a Linux system, it is STRONGLY recommended that you run it on a recent distribution (such as Red Hat 7.3 or newer). A new-ish distribution will have most or all of the prerequisite tools and libraries already integrated for you.

Now available:

• "WebCit", a gateway program to allow full access to Citadel via the World Wide Web. Interactive access through any Web browser.
• Access to Citadel via *any* standards-compliant e-mail program, thanks to Citadel's built-in SMTP, POP, and IMAP services.

Coming soon:

• Newer and better GUI-based clients.

Everything in its place...

Hopefully you've unpacked the distribution archive into its own directory. This is the directory in which all Citadel files are located and in which all activity will take place. Several subdirectories have already been created during the unpacking process, and others may be created by the software if needed. Make sure you have Berkeley DB installed on your system, and that you have all the development libraries and headers in place so that you can compile against them. If you don't, you can get the latest Berkeley DB at http://www.sleepycat.com. If your operating system uses a separate library to support POSIX threads (pthreads), make sure that library is installed as well. This is almost never the case with Linux, but some commercial Unix flavors might need it.

The BBS Login

As with many Unix programs, Citadel wants to run under its own user ID. Unlike other programs, however, this user ID will do double-duty as a public login for your system if you are running a BBS. This account is typically called "bbs" or "citadel" or something to that effect. You will tell Citadel what the user-id of that account is, and when someone logs in under that account, Citadel will prompt for a user name.

The Citadel user should have a unique uid. The home directory should be the one your Citadel installation resides in (in this example we will use /usr/local/citadel) and the shell should be either "citadel" in that directory, or a script that will start up citadel (you may wish to set up an external text editor; see below). Example:

bbs::100:1:BBS Login:/usr/local/citadel:/usr/local/citadel/citadel

When you run setup later, you will be required to tell it what the Citadel user's numeric user ID is, so it knows what user to run as. If you create an account called bbs, guest, or citadel, the setup program will automatically pick up the user ID by default.

For all other users in /etc/passwd, Citadel will automatically set up an account using the full name (or 'gecos' in Unixspeak) of the user. It'll also ignore any password you supply, because it uses the user's password on the host system. This allows a 'single sign on' type of environment. Note that this does have to be enabled at compile time -- it's the configure option called --enable-autologin. Keep in mind that these users can use *either* their Citadel login name or their login name on the host computer, and their password on the host computer.

Bypassing the login: prompt

If you normally log in to your host system using some method other than telnet (such as ssh), you might want the telnet service to go straight to the Citadel BBS, instead of displaying the login: prompt first. You can do this by having telnetd start citadel directly instead of /bin/login. This is actually very simple to implement; all you need to do is make a simple change to your inetd or xinetd configuration. Here are some configuration examples.

An example for inetd (put the following line in /etc/inetd.conf, replacing any existing telnet configuration line already there):

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd -L /usr/local/citadel/citadel

An example for xinetd (if you have a file called /etc/xinetd.d/telnet then simply replace that file with this one):

service telnet
{
	flags           = REUSE
	socket_type     = stream
	wait            = no
	user            = root
	server          = /usr/sbin/in.telnetd
	server_args     = -L /usr/local/citadel/citadel
	log_on_failure  += USERID
	disable         = no
}

Please make sure you know what you're doing before you install this! If you are going to put Citadel somewhere other than /usr/local/citadel then change the directory name accordingly. If you know of any other local peculiarities which need to be observed, edit the above configuration accordingly as well. And, of course, if you're working remotely, make sure you can successfully log in using SSH before you start changing your telnet configuration, otherwise you could lock yourself out of your system (ask any networking specialist about the dangers of "working inline" -- then pull up a chair and get a fresh cup of coffee, because you're going to hear some war stories).

Compiling the programs

You can easily compile the Citadel system with the following commands:

./configure
make
make install

The 'configure' script will generate a Makefile from the Makefile.in, and it will also write the file "sysdep.h" to your Citadel directory. Please do not edit sysdep.h or Makefile.in yourself. The configure script will figure out your system dependencies and set everything correctly.

Mac OS X 10.1 and later are now supported. (Sorry, 10.0 cannot be supported, now or in the future.) You need to install the Developer Tools CD, which you can purchase or download for free from http://developer.apple.com. Then run configure like this:

env CC=/usr/bin/cc ./configure (options - see below)

By default, the Citadel system will install in /usr/local/citadel. If you wish to place it in a different directory, you can instead do:

./configure --prefix=/export/home/citadel      (or whatever)

If you've got Berkeley DB installed in a non-standard location, you can help the configure script find it by doing something like this:

./configure --with-db=/usr/local/BerkeleyDB-4.1

The configure script prefers Berkeley DB if it is available, but will fall back to GDBM if it has to.

File permissions are always a bother to work with. You don't want Citadel to crash because someone couldn't access a file, but you also don't want shell users peeking into the binaries to do things like reading others' mail, finding private rooms, etc. The Citadel server needs to be started as root in order to bind to privileged ports, but as soon as its initialization is finished, it changes its user ID to your BBS user ID in order to avoid security holes.

Upgrading

Upgrading to a new version uses the same build procedure as compiling the program for a fresh install, except that you want to do make install-exec instead of make install. This will overwrite the programs but not your data. Be sure to shut down citserver during this process! If Citadel is running while you upgrade, you may face data corruption issues.

The citadel.rc file

The text-based client included with Citadel is suitable for BBS applications. Much of its command set and other behavior is configurable through a Run Control (RC) file. The standard client looks for this file in the following locations:

• $HOME/.citadelrc
• /usr/local/lib/citadel.rc
• your-Citadel-directory/citadel.rc

The next couple of sections deal with client-side configuration.

Using an external editor for message composition

Citadel/UX has a built-in message editor. However, you can also use your favorite text editor to write messages. To do this you simply put a line in your citadel.rc file like this:

editor=/usr/bin/vi

The above example would make Citadel call the vi editor when using the .Enter Editor command. You can also make it the default editor for the Enter command by editing the citadel.rc file. But be warned: external editors on public systems can be a security hole, because they usually provide users with the ability to drop into a shell on the host system, or save files using names other than the name of the temporary file they are editing. If you intend to use an external editor on a public BBS, make sure you use one that has been hardened for such a purpose -- one which has had the 'shell' and 'save as' commands disabled, as well as any other functions which a destructive user could use to gain unauthorized access to your host system.

Printing messages

Citadel/UX can send messages to a printer, or just about anywhere else in your system. The variable PRINTCMD in citadel.rc specifies what command you use to print. Text is sent to the standard input (stdin) of the print command.

So if you did this:

printcmd="nl|pr|lpr -Plocal"

...that would add line numbers, then paginate, then print on the printer named "local". There's tons of stuff you can do with this feature. For example, you could use a command like cat <<$HOME/archive to save copies of important messages in a textfile. Again, this is probably something you don't want to configure for a public BBS host -- most system administrators don't want remote users sending arbitrary things to local printers.

URL viewing

This is one more feature which is appropriate for local users. While reading a message that has Internet URL's in it, you can select the URL-view command, and it will perform some pre-defined action (usually, this is to open up the URL in a web browser). For example:

urlcmd=netscape -remote "openURL(%s)"

In the above example, it would open up the URL in an open Netscape window.

Setup and login

Before logging in for the first time, you must run the setup program. To begin this procedure, enter the following commands:

cd /usr/local/citadel
./setup

The setup program will guide you through a simple configuration procedure. It will ask you what directory to place your data files in -- the default is the current directory, which is usually the sensible thing to select. If you want to run more than one instance of Citadel on the same host, however, you can specify a different directory here -- just remember to specify the directory name again when you start up the server later on.

setup will then shut down the Citadel service if it is found to be running.

You will then be prompted for the name of the system administrator. This is not merely a cosmetic option -- when you log in to your system a little while from now, you'll log in with this name, and it will automatically assign your account the highest access level.

Next, you will be prompted for the User ID of the Citadel account on your host system. If you have an account called bbs, guest, or citadel, that account's UID will be the default. If you are upgrading or reconfiguring an existing system, the existing value will be preserved.

Then you will be prompted for a server port number. This is the TCP port which Citadel clients use to connect to your Citadel server. In almost all cases, you want to use the default -- port 504, which is the official port number assigned by the IANA for Citadel implementations.

The Citadel service will then be started, and you will see the following message:

Setup is finished.  You may now log in.

Setup is now complete, on most systems, anyway. Please see below to find out if you need to do anything else:

Configuring your host system to start the service

Please note: this topic involves modifications made to /etc/services and /etc/inittab in order to configure your host system to automatically start the Citadel service. setup will automatically perform these steps if it can, and if you allow it to -- just answer 'Yes' when prompted, and everything will be taken care of for you. If you answer 'No' -- or if your system is a little bit odd (for example, BSD systems don't have /etc/inittab) -- read this section and do what you need to in order to get things configured.

Before you can use Citadel, you must define the "citadel" service to your system. This is accomplished by adding a line to your /etc/services file that looks something like this:

citadel		504/tcp			# Citadel/UX Server

504 is the port number officially designated by the IANA for use by Citadel. There should not be any need to use a different port number, unless you are running multiple Citadels on the same computer and therefore need a different port for each one.

The next step is to arrange for the server to start. The citserver program is the main Citadel server. Before we cover the recommended method of starting the server, let's examine its usage options:

citserver [-hHomeDir] [-xDebugLevel] [-tTraceFile] [-d] [-f]

The options are as follows:

-hHomeDir - the directory your BBS data files live in. This should, of course, be a directory that you've run the setup program against to set up some data files. If a directory is not specified, the directory name which was specified in the Makefile will be used.

-xDebugLevel - Set the verbosity of trace messages printed. The available debugging levels are:

• 1 - Internal errors (failed thread creation, malloc problems, etc.)
• 2 - Network errors (broken sockets, failed socket creation)
• 3 - Begin and end of sessions, startup/shutdown of server
• 5 - Server commands being sent from clients
• 7 - Entry and exit of various functions
• 8 - Entry and exit of critical sections
• 9 - Various debugging checkpoints (insanely verbose)

-tTraceFile - Tell the server where to send its debug/trace output. Normally it is sent to stdout.

-d - Run as a daemon; i.e. in the background. This switch would be necessary if you were starting the Citadel server, for example, from an rc.local script (which is not recommended, because this won't allow the server to automatically restart when it is shut down).

-f - Defragment all the databases upon startup. This isn't normally necessary due to the nature of the data stored in Citadel, but the option is provided in case you need it. (Note that this only applies to GDBM installations; if you are using Berkeley DB it has no effect.)

The preferred method of starting the Citadel server is to place an entry in your /etc/inittab file. This will conveniently bring the server up when your system is up, and terminate it gracefully when your system is shutting down. The exact syntax for your system may vary, but here's an entry that could be used on a Linux system:

cit:2345:respawn:/usr/local/citadel/citserver -h/usr/local/citadel -t/dev/tty9 -x3

In this example, we've chosen debugging level 3, and have the trace stuff output to one of the virtual consoles. It's important to remember to turn off any getty that is set up on that virtual console, if you do this. After making this change, the command init q works on most systems to tell init to re-read the file. If in doubt, just reboot the computer.

Logging in for the first time

At this point, your system is ready to run. Run the citadel program from the shell and log in as a new user. NOTE: the first user account to be created will automatically be set to access level 6 (Aide). This overcomes some obvious logistical problems - normally, Aide access is given by another Aide, but since there aren't any on your system yet, this isn't possible.

Welcoming new users

Sometimes you might decide that you want a welcome message (or several different messages) automatically mailed to new users upon their first login. Now there is a way to do this. If you create a room called New User Greetings, and it is a private room (invitation-only probably makes the most sense), any messages you enter into that room will automatically be delivered to all new users upon registration.

You can put anything you want there: a welcome message, system policies, special information, etc. You can also put as many messages there as you want to (although it really doesn't make sense to clutter new users' mailboxes with lots of junk).

Don't worry about wasting disk space, either. Citadel has a single-instance message store, so all the new users are actually looking at the same copy of the message on disk.

Space for adding your own client features (doors)

Please take note! This function really represents the "old" way of doing things, and it doesn't fit in well with the client/server paradigm. Please consider it "deprecated" because it may be removed someday.

The "doorway" feature is just a generic way to add features to the system. I called it "Doorway" to make it resemble the doors on non-Unix boards, but as we all know, us Unix types don't have to write special code to access the modem. :-) Anyway, when a user hits the * (doorway) command, Citadel does...

USERNAME=(username); export USERNAME
./subsystem (user-number) (screen-width) (access level)

...so you can put whatever you want in there. I suggest putting in a menu program to allow the users to pick one of a number of programs, etc. Do be aware that door programs will only be available when the client and server programs are running on the same computer, and when the user is running the text-mode client. Because of these restrictions, Door programs are being utilized less and less every day.

Troubleshooting and getting help

That's just about all the information you need to install the system. But if you get stuck, you can visit UNCENSORED! BBS and report a problem or ask for help. But if you intend to report a problem getting the Citadel server to run, please double-check the following things first:

• Did you do ./configure && make && make install ??
• Did you run setup?
• Did you start the server?

To report a problem, you can log on to UNCENSORED! or any other BBS on the Citadel network which carries the Citadel/UX> room. Please DO NOT e-mail the developers directly. Post a request for help on the BBS, with all of the following information:

• The exact nature of your difficulty
• A transcript of the error message(s) if possible
• The version of Citadel you are running
• The version of Berkeley DB present on your system
• Which operating system you are running, and what version
• If you are running a Linux system, we need to know which distribution, and the version of the kernel, libc, and pthreads you are using (it would help to post the output of a ldd ./citserver command).

---

System Administration

Overview

Citadel/UX, when installed properly, will do most of its maintenance by itself. It is intended to be run unattended for extended periods of time, and most installations do just that without any software failures.

The system has seven access levels. Most users are at the bottom and have no special privileges. Aides are selected people who have special access within the Citadel program. Room Aides only have this access in a certain room. Preferred users can be selected by Aides for access to preferred only rooms. A sysop is anyone who has access to the various sysop utilities - these are in their own executable files, which should have their permissions set to allow only sysops to run them. You should either create a sysops group in /etc/group, or use some other existing group for this purpose.

Aides have access to EVERY room on the system, public and private (all types). They also have access to commands starting with .Aide in addition to being able to delete and move messages. The system room, Aide>, is accessible only by those users designated as Aides.

Aide commands

Aides have the following commands available to them that are not available to normal users. They are:

.Aide Kill this room	Deletes the current room from the system.
.Aide Edit this room	Allows editing of the properties of the current room. This is explained in greater detail below.
.Aide Who knows room	For private rooms with access controls, or mailbox rooms, this command displays a list of users who have access to the current room.
.Aide edit User	Allows editing of the properties of any user account on the system.
.Aide Validate new users	For public access systems, this command reviews all new user registrations and allows you to set each new user's access level (or simply delete the accounts).
.Aide enter Info file	Each room may contain a short textual description of its purpose, which is displayed to users upon entering the room for the first time (or in the room banner, for users of the Web client). This command allows you to enter or edit that description.
.Aide Room Invite user	Access control command to grant any specific user access to a private room.
.Aide Room Kick out user	Access control command to revoke any specifc user's access to the current room. This works regardless of whether the room is public or private.
.Aide File Delete	If the current room has an associated file directory, this command may be used to delete files from it.
.Aide File Send over net	If the current room has an associated file directory, this command may be used to transmit a copy of any file in that directory to another node on a Citadel network.
.Aide File Move	If the current room has an associated file directory, this command may be used to move any file in that directory to another room. The target room must also have an associated file directory.
.Aide Message edit	This command allows editing of any of the various system banners and messages which are displayed to users. Type the name of the banner or message you wish to edit.
.Aide Post	This is the functional equivalent of the Enter message command available to all users, except that it allows you to post using any user name.
.Aide System configuration General	This command allows configuration of a large number of global settings for your Citadel system. These settings will be explained in greater detail below.
.Aide System configuration Internet	This command allows configuration of settings which affect how your Citadel system sends and receives messages on the Internet.
.Aide System configuration check Message base	Perform a consistency check on your message store. This is a very time-consuming operation which should not be performed unless you have reason to believe there is trouble with your database.
.Aide System configuration Network	Configure networking (e-mail, room sharing, etc.) with other Citadel nodes.
.Aide System configuration network Filter list	If you are on a large public or semi-public network of Citadel nodes and you find content from certain systems or individuals objectionable, you can use this command to define a rule set to automatically reject those messages when they arrive on your system.
.Aide Terminate server Now	Immediately shut down the Citadel service, disconnecting any users who are logged in. Please keep in mind that it will start right back up again if you are running the service from /etc/inittab, so in practice this command will probably not get much use.
.Aide Terminate server Scheduled	Shut down the Citadel service the next time there are zero users connected. This allows you to automatically wait until all users are logged out.
.Aide mailing List recipients	Any room may be made into a mailing list. Enter this command to open an editor window containing the list of Internet e-mail addresses to which every message posted in the room will be sent.
.Aide mailing list Digest recipients	Similar to the regular mailing list command, except the messages will be sent out in 'digest' form -- recipients will see messages from the address of the room itself rather than the address of the author of each message, and a digest may contain more than one message. Each room may have any combination of List and Digest recipients.
.Aide Network room sharing	Configures the sharing of the current room's contents with other Citadel nodes. Messages posted in this room on any Citadel system will automatically be replicated to other Citadel systems carrying the room.

Editing rooms

This command allows any aide to change the parameters of a room. Go to the room you wish to edit and enter the .Aide Edit room command. A series of prompts will be displayed. The existing parameters will be displayed in brackets; simply press return if you want to leave any or all of them unchanged.

 
Room name [IG's Fun Room]:

...the name of the room.

Private room [Yes]? 

...enter Yes if you wish to restrict access to the room, or no if the room is to be accessible by all users. Note that Citadel doesn't bother users about access to rooms every time they need to access the room. Once a user gains access to a private room, it then behaves like a public room to them. The following four questions will only be asked if you selected Private...

Accessible by guessing room name [No]?

...if you enter Yes, the room will not show up in users' Known rooms listing, but if they .Goto the room (typing the room's full name), they will gain access to the room.

Accessible by entering a password [No]?
Room password [mypasswd]:  

...this adds an additional layer of security to the room, prompting users for a password before they can gain access to the room.

If you did not select guessname or passworded, then the only way users can access the room is if an Aide explicitly invites them to the room using the .Aide Room Invite user command.

Cause current users to forget room [No] ? No

Enter Yes if you wish to kick out anyone who currently has access to the room.

Preferred users only [No]? No

Enter Yes if you wish to restrict the room to only users who have level 5 (Preferred User) status (and Aides too, of course). You should make the room public if you intend to do this, otherwise the two restrictions will be COMBINED.

Read-only room [No]? No

If you set a room to Read-Only, then normal users will not be allowed to post messages in it. Messages may only be posted by Aides, and by utility programs such as the networker and the "aidepost" utility. This is useful in situations where a room is used exclusively for important announcements, or if you've set up a room to receive an Internet mailing list and posting wouldn't make sense. Other uses will, of course, become apparent as the need arises.

Now for a few other attributes...

Directory room [Yes]? Yes

...enter Yes if you wish to associate a directory with this room. This can be used as a small file repository for files relevant to the topic of the room. If you enter Yes, you will also be prompted with the following four questions:

Directory name [mydirname]: 

...the name of the subdirectory to put this room's files in. The name of the directory created will be <your BBS directory>/files/<room dir name>.

Uploading allowed [Yes]? Yes

...enter Yes if users are allowed to upload to this room.

Downloading allowed [Yes]? Yes

...enter Yes if users are allowed to download from this room.

Visible directory [Yes]? Yes

...enter Yes if users can read the directory of this room.

Network shared room [No]? No

...you can share a room over a network without setting this flag, and vice versa, but what this flag does is twofold:

• It prevents people with no network access from entering messages here
• Messages are displayed with the name of their originating system in the header.

Permanent room [No]? No

Citadel contains an 'auto purger' which is capable of removing rooms which have not been posted in for a pre-defined period of time (by default this is set to two weeks). If you wish to keep this from happening to a particular room, you can set this option. (Keep in mind that Lobby>, Aide>, any private mailbox rooms, any network shared rooms, and any rooms with a file directory are automatically permanent.)

Anonymous messages [No]? No
Ask users whether to make messages anonymous [No]? No

...you can have rooms in which all messages are automatically anonymous, and you can have rooms in which users are prompted whether to make a message anonymous when they enter it. The real identity of the author of each message is still revealed to the Room Aide for this room, as well as any system-wide Aides.

Room aide [Joe Responsible]: 

...on larger systems, it helps to designate a person to be responsible for a room. Room Aides have access to a restricted set of Aide commands, ONLY when they are in the room in which they have this privilege. They can edit the room, delete the room, delete and move messages, and invite or kick out users (if it is a private room), but they cannot perform aide commands that are not room-related (such as changing users access levels).

Listing order [64]: 

This is just a simple way to try to control the order rooms are listed in when users call up a Known Rooms listing. Rooms with a lower listing order are displayed prior to rooms with a higher listing order. It has no other effect. For users who list rooms in floor order, the display will sort first by floor, then by listing order.

Message expire policy (? for list) [0]:

This provides you with the opportunity to select how long each message will remain in a room before automatically being deleted. Press ? for a list of options. You can choose to keep messages around forever (or until they are manually deleted), until they become a certain number of days old, or until a certain number of additional messages are posted in the room, at which time the oldest ones will scroll out.

You will notice that you can also fall back to the default expire policy for the floor upon which the room resides. This is the default setting. You can change the floor's default with the ;Aide Edit floor command. The default setting for the floor default, in turn, is the system default setting, which can be changed using the .Aide System configuration General command.

Save changes (y/n)? Yes

...this gives you an opportunity to back out, if you feel you really messed things up while editing.

File directories

If you have created any directory rooms, you can attach file descriptions to the filenames through a special file called filedir. Each line contains the name of a file in the directory, followed by a space and then a description of the file, such as:

myfile.txt This is a description of my file.
phluff A phile phull of phluff!

...this would create file descriptions for the files myfile.txt and phluff which would be displayed along with the directory. It should also be noted that when users upload files to your system, they will be prompted for file descriptions, which will be added to the filedir file. If one does not exist, it will be created.

Creating and editing user accounts

Anyone with Aide level access may use the .Aide edit User command to create and/or edit user accounts. There are several parameters which can be set here.

To create a user:

Lobby> . Aide edit User 
User name: New User Name
No such user.
Do you want to create this user? Yes

At this point, the new user account has been created, and the command will continue as if you were editing an existing account. Therefore the remainder of this procedure is the same for creating and editing:

Lobby> . Aide edit User 
User name: person of significance
User #70 - Person of Significance  PW: 
 

,  
 
 

Current access level: 4 (Network User)

The blank lines are the user's 'registration' information -- personal information such as full name, address, telephone number, etc. This information will comprise the user's vCard in both their user profile and in the Global Address Book.

Change password [No]: No

...answer Yes to set or change the password for this account.

Access level [4]: 

...this allows you to set or change the access level for this account. The access levels available are as follows:

• 0 - Deleted. (This immediately deletes the account.)
• 1 - New, unvalidated user
• 2 - Problem user (severely restricts account - use for probationary access)
• 3 - User with no network privileges. Same access as a normal user except cannot post messages in rooms shared on a network.
• 4 - Normal user
• 5 - Preferred user (access is granted to privileged rooms)
• 6 - Aide (administrative access to the whole system)

Permission to send/receive Internet mail [ No]? No

If your system is configured to only allow Internet mail privileges to certain users, this is where you can grant or revoke that privilege.

Ask user to register again [Yes]: Yes

If you answer Yes to this question, the user will be presented with a 'registration' screen or set of prompts, the next time they log in using a Citadel client. This will prompt them for their full name, address, telephone number, etc.

Times called [0]: 
Messages posted [0]: 

These statistics are available for informational purposes only, so there is normally no need to change them.

Set last call to now [No]: No
Purge time (in days, 0 for system default [0]: 

Citadel contains an auto-purger which is capable of automatically deleting accounts which have not been accessed in a predefined period of time. If you choose to perform this operation, you can 'touch' the account of a wayward user by setting their 'last call' time to 'now'. You can also adjust, on a per-user basis, the amount of time which must pass before their account is purged by the system. This time is set in days. You can also specify 0 days to indicate that you wish to use the system default setting.

Deleting and moving messages

Aides and Room Aides have the ability to delete and move messages. After each message, the normal prompt appears:

(8) <B>ack <A>gain <Q>uote <R>eply <N>ext <S>top m<Y> next <?>help ->

Entering Delete will delete the message. A (y/n) prompt will appear to confirm that you really want to delete the message. Entering Move will prompt for a room to which the message should be moved.

Customizing the help files

The subdirectory called help contains your system's help files. There's nothing hard-coded into the system that dictates what files should be there. Whenever a user types the command .Help followed by the name of a help file, it displays the contents of that help file.

The help files that come with the system, of course, are enough to guide a user through its operation. But you can add, change, or remove help files to suit whatever is appropriate for your system.

There are several strings that you can put in help files that will be automatically substituted with other strings. They are:

 
 ^nodename    = The node name of your system on a Citadel/UX network
 ^humannode   = Human-readable node name (also your node name on C86Net)
 ^fqdn        = Your system's fully-qualified domain name
 ^username    = The name of the user reading the help file
 ^usernum     = The user number of the user reading the help file
 ^sysadm      = The name of the system administraor (i.e., you)
 ^variantname = The name of the BBS software you're running
 ^bbsdir      = The directory on the host system in which you have
                installed the Citadel system.

So, for example, you could create a help file which looked like:

  "Lots of help, of course, is available right here on ^humannode.  Of
course, if you still have trouble, you could always bug ^sysadm about it!"

Site configuration

Once your Citadel server is up and running, the first thing you'll want to do is customize and tune it. This can be done from the text-based client with the .Aide System configuration General command, or from WebCit (if you have it installed) by clicking 'Advanced Options' followed by 'Edit site-wide configuration.' Either method will offer the same configuration options. This document shows the text mode client being used.

The first set of options deal with the identification of your system.

Lobby> . Aide System configuration General
Node name [uncnsrd]: 
Fully qualified domain name [uncensored.citadel.org]: 
Human readable node name [Uncensored]: 
Modem dialup number [US 914 999 9999]: 
Geographic location of this system [Mount Kisco, NY]: 
Name of system administrator [IGnatius T Foobar]: 
Paginator prompt []: 

'Node name' refers to the short, unqualified node name by which your system is known on a Citadel network. Generally it will be the same as the unqualified host name of your computer; this is, in fact, the default setting.

Then enter the fully-qualified domain name (FQDN) of your system. If you are not on the Internet, you can simply set it to the same as your unqualified host name. Otherwise you should set this value to the host name by which your system is most commonly known.

The field called 'Human-readable node name' (also known as the 'node title' or 'organization name' in other software) is used solely for display purposes. Set it to the actual name of your system as you want it to appear in banners, messages, etc.

If you have a modem or bank of modems answering data calls for your system, enter it in the field marked 'Modem dialup number.' Otherwise you may leave it blank.

'Geographic location of this system' is another display field. Enter a city and state, or city and country.

'Name of system administrator' is important! Any user who logs on with the name you enter here will automatically be granted Aide privileges. This is one of two ways for the system administrator to grant himself/herself Aide access to the system when initially setting it up. (The other is simply to have the first account created on a new installation.)

The next set of options are your system's security settings. Before delving into the actual options, we should review the various access levels available on the system. Citadel has seven access levels:

• 0 (Deleted). A user whose access level is set to 0 will automatically be deleted by the system.
• 1 (New User). Users at this level may only read messages. Entering messages is prohibited, except in the Mail> room, where a message to 'sysop' may be entered.
• 2 (Problem User). Also known as 'Twit.'
• 3 (Local User). May enter messages, except in rooms shared on a Citadel network.
• 4 (Network User). May enter messages in every accessible room.
• 5 (Preferred User). Use of this level is up to the whim of the system administrator.
• 6 (Aide). Access is granted to the administrative functions of the system. (This access level may also be granted to a user only for a specific room, please see 'Room Aide' for more information.)

Require registration for new users [No]: No
Disable self-service user account creation [No]: No
Initial access level for new users [4]:
Access level required to create rooms [4]: 
Automatically give room aide privs to a user who creates a private room [No]: No

Automatically move problem user messages to twit room [Yes]: Yes
Name of twit room [Trashcan]: 
Restrict Internet mail to only those with that privilege [No]: No
Allow Aides to Zap (forget) rooms [Yes]: Yes
Allow system Aides access to user mailboxes [Yes]: Yes
Log all pages [No]: No

'Registration' refers to the process of a user entering various personal contact information (real name, address, telephone number, etc.) into the system. When enabled, this information is stored as a vCard object on the system in two places: the user's My Citadel Config> room, and in the Global Address Book> room. (Note: the latter should be made private on publicly-accessible systems, for obvious reasons.)

If you answer Yes to 'Require registration for new users' then each new user, upon creating a new account, will immediately be entered into the registration process. On the other hand, if you answer Yes to 'Disable self-service user account creation' then new users will not be able to log in at all -- all accounts must be created by an Aide.

'Initial access level for new users' should be set to 1 (New User) if you would like to review each new user's registration info before granting them higher access. This would be done periodically with the .Aide Validate new users command. If you do not require registration, you should set the initial access level to 4 (Network User).

Given the above options, it then becomes clear that there are generally two ways you can set up your Citadel system, depending on its purpose:

• A public access BBS or message board - since you do not know who might want to log in, self-service account creation needs to stay enabled. If you want to be strict about users identifying themselves, then you should also require users to register (just remember to post a privacy policy if you're going to collect personal information) -- then set the initial access level to 1 (New User), so new users cannot post messages until after you've validated them. For a more lax environment, you can remove the registration requirement and grant new accounts level 4 (Normal User) access on the first visit.
• A private email/groupware system for your organization - in this case, disable self-service account creation; you don't want strangers welcoming themselves to your system. You'll probably also want to disable registration, because you or some other site administrator will be entering users' contact info when you create their accounts. Since this is also how you assign their Internet e-mail addresses, it's probably a good idea to do it yourself instead of expecting them to do it.

'Access level required to create rooms' is up to you. You might wish to restrict the creation of new rooms only to Aides, or you might wish to allow anyone to create a room. The latter is one of the Citadel culture's most long-standing traditions; the former may be appropriate if users are abusing this privilege.

You have the ability to 'Automatically give room aide privs to a user who creates a private room.' If you answer Yes, then any user who creates a guess-name, passworded, or invitation-only room will automatically become the room aide, and will have access to a subset of the .Aide command set while in that room. If you would rather grant this permission manually, answer No.

Another tradition in the Citadel culture is to refrain from deleting problem users, but instead to 'twit' them (reduce their access level to 2 [Problem User]). You can then 'Automatically move problem user messages to twit room' (answer Yes, then specify 'Name of twit room' and remember to create that room). If you employ this logic, any user with level 2 (Problem User) access will continue to have access to the same set of rooms, but all messages posted will automatically be routed to the Trashcan (or whatever you call your twit room).

If you have Internet mail configured, you have the option of restricting its use on a user-by-user basis. If you wish to do this, answer Yes to 'Restrict Internet mail to only those with that privilege.' Obviously this makes no sense for an internal e-mail system, but for a public BBS it might be appropriate.

Normally, Aides have access to every room, public or private, except for user mailboxes. They are also forbidden from Zapping rooms, because the review of content is considered one of their roles. If you wish to change these policies, the next two options allow you to. You may 'Allow Aides to Zap (forget) rooms', in which case they may use the Zap command just like any other user. Furthermore, if you 'Allow system Aides access to user mailboxes', then they may .Goto any private mailbox belonging to any user, using a special room name format.

If your local security and/or privacy policy dictates that you keep a log of all pages (instant messages) that go through the system, then answer Yes to 'Log all pages'. If you answer Yes, you will be prompted for the name of a room to which all pages will be logged. If you answer No, then only the sender and recipient of each individual message will receive a copy.

The next set of options deals with the tuning of your system. It is usually safe to leave these untouched.

Server connection idle timeout (in seconds) [900]: 
Maximum concurrent sessions [20]: 
Maximum message length [2147483647]: 
Minimum number of worker threads [5]: 
Maximum number of worker threads [256]: 

The 'Server connection idle timeout' is for the connection between client and server software. It is not an idle timer for the user interface. 900 seconds (15 minutes) is the default and a sane setting.

'Maximum concurrent sessions' is the highest number of user sessions you wish to allow on your system at any given time. Citadel can scale to hundreds of concurrent users, but if you have limited hardware or (more likely) limited bandwidth, you might wish to set a maximum. You can also set it to zero for no limit.

'Maximum message length' is just that. This could be a good way to prevent enormous multimedia files from finding their way into your message base. This maximum is enforced in all protocols and is also advertised by the ESMTP service.

The minimum and maximum number of worker threads can be tuned to your liking. Citadel will attempt to keep one worker thread running per session, within these constraints. You should be aware that due to the use of the worker thread model, Citadel can handle a large number of concurrent sessions with a much smaller thread pool. If you don't know the programming theory behind multithreaded servers, you should leave these parameters alone.

The next set of options affect how Citadel behaves on a network.

How often to run network jobs (in seconds) [3600]: 
SMTP server port (-1 to disable) [25]: 
POP3 server port (-1 to disable) [110]:
IMAP server port (-1 to disable) [143]:

'How often to run network jobs' refers to the sharing of content on a Citadel network. If your system is on a Citadel network, this configuration item dictates how often the Citadel server will contact other Citadel servers to send and receive messages. In reality, this will happen more frequently than you specify, because other Citadel servers will be contacting yours at regular intervals as well.

Then you can specify TCP port numbers for the SMTP, POP3, and IMAP services. For a system being used primarily for Internet e-mail, these are essential, so you'll want to specify the standard port numbers: 25, 110, and 143. If Citadel is running alongside some other mail system, though, then you might want to choose other, unused port numbers, or enter -1 for any protocol to disable it entirely.

The final set of options configures system-wide defaults for the auto-purger:

Default user purge time (days) [120]: 
Default room purge time (days) [30]: 
System default message expire policy (? for list) [2]: 
Keep how many messages online? [150]:

Any user who does not log in for the period specified in 'Default user purge time' will be deleted the next time a purge is run. This setting may be modified on a per-user basis.

'Default room purge time' behaves the same way, and may also be modified on a per-room basis.

'System default message expire policy' defines the way in which old messages are expired (purged) off the system. You can specify any of:

• Purge by age (specify in days)
• Purge by message count in the room (specify number of messages)
• Do not purge at all

Again, this setting may be overridden on a per-floor basis, and the floor setting may be overridden on a per-room basis.

Save this configuration? No

When you're done, enter 'Yes' to confirm the changes, or 'No' to discard the changes.