Home Download FAQ / Knowledge Base Screenshots Documentation Support

Manual installation of Citadel using source code and the command line client

Intended audience

This manual is intended for well-seasoned Unix/Linux system administrators who are comfortable building software from source code and administering it from the command line. It is not the typical installation method. If you are not part of the intended audience then you are encouraged to make use of the Easy Install deployment system, or packages built specifically for your Linux distribution.

Please review the credits and license for this software before continuing.

Installation Overview

Citadel is an advanced, multiuser, client/server messaging system suitable for email, collaboration, message boards, content management, and other "groupware" applications. It is designed to handle the needs of both small organizations and large-scale public access systems. It runs on all modern Linux systems and many legacy Unix systems. The current distribution includes:

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

It is STRONGLY recommended that you run it on a recent Linux distribution. Many of the prerequisite tools and libraries will either be preinstalled for you or will be readily available in the repositories.

Other pieces which complete the Citadel system:

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.oracle.com/technetwork/database/berkeleydb/downloads/index.html

Creating a system account for Citadel

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 guest login if you are running a public system. 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 the citadel text-based client in that directory, or a script that will start up the citadel client. Example:

  citadel::100:1:Citadel Login:/usr/local/citadel:/usr/local/citadel/citadel

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

For all other users in /etc/passwd (or in some other name service such as LDAP), Citadel can automatically set up an account using the display 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 setup time -- it's the option called "host based authentication mode". 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 into Citadel, instead of displaying the "login:" prompt first. You can do this by having telnetd start citadel directly instead of "/bin/login". The "setup" program will offer to configure this automatically for you if it sees a configuration it understands. If you would prefer to configure it manually, 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 making changes to telnet, because if you accidentally break telnet and don't have SSH running, you'll have effectively locked yourself out of your system until you can get physical access to the console.

Compiling the programs

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

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.

Non-Linux systems such as FreeBSD and macOS tend to break and fix from release to release. On a Mac you will need 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, Citadel Server 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

Keep in mind that if you're using Berkeley DB from a non-standard location, you'll have to make sure that location is available at runtime.

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 Citadel user in order to avoid security holes.


Any existing Citadel installation may be upgraded in place without the need to discard your existing data files.

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 upgrade" 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.

After doing make upgrade, you should run setup again to bring your data files up to date. Please see the setup section below for more information on this.

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:

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

Using an external editor for message composition

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


The above example would make Citadel call the vi editor when using the ".Enter Editor" command, or when a user selects the "Always compose messages with the full-screen editor" option. 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 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="a2ps -o - |lpr -Plocal"

...that would convert the printed text to PostScript, 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=xdg-open "%s" >/dev/null 2>&1

In the above example, it would open the selected URL in the system's default browser, if one is running.

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

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.

You will then be prompted for the name and password of the system administrator. By default, it is admin with password citadel -- but you can change it here if you want to or if you have become locked out of the system.

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.

setup will then ask you about authentication mode. Please understand this question thoroughly before answering it. You have a choice of several authentication modes:

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 system configuration files 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 SysV style init files) -- 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 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] [-lLogFacility] [-d] [-f]

The options are as follows:

"-hHomeDir" - the directory your Citadel 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. When -x is used, it will suppress
messages sent to syslog (see below). In other words, syslog will never see certain messages if
-x is used. Normally you should configure logging through syslog, but -x may still be useful
in some circumstances. The available debugging levels are:

  * 0 - Emergency condition; Citadel will exit immediately
  * 1 - Severe errors; Citadel may be unable to continue without attention
  * 2 - Critical errors; Citadel will continue with degraded functionality
  * 3 - Error conditions; Citadel will recover and continue normally
  * 4 - Warning messages; Citadel will continue normally
  * 5 - Normal operational messages
  * 6 - Informational messages, progress reports, etc.
  * 7 - Debugging messages; extremely verbose

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

"-lLogFacility" - Tell the server to send its debug/trace output to the "syslog" service on
the host system //instead of// to a trace file. "LogFacility" must be one of: "//kern, user,
mail, daemon, auth, syslog, lpr, news, uucp, local0, local1, local2, local3, local4, local5,
local6, local7//". Please note that use of the "-l" option will cancel any use of the "-t"
option; that is, if you specify a trace file //and// a syslog facility, log output will only
go to the syslog facility.

"-d" - Run as a daemon; i.e. in the background.

"-f" - Defragment all the databases upon startup.  (No longer used; this is still here only
for backwards compatibility.)

The preferred method of starting the Citadel server is to use the init scripts that are generated when you run the setup program.

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 (Admin). This overcomes some obvious logistical problems - normally, Admin access is given by another Admin, 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.

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:

To report a problem, you can log on to UNCENSORED! and locate the "Citadel Support" 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 (remember stderr; do >/tmp/logfile 2>&1 at the end of
  easy install / configure etc.)
  * 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


Citadel, 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. Admins are selected people who have special access within the Citadel program. Room Admins only have this access in a certain room. Preferred users can be selected by Admins 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.

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

(In the early days of Citadel, from 1981 until around the turn of the century, the software referred to system administrators as "aides" and the lead administrator as the "sysop". You may still see this terminology used from time to time for historical reasons.)

Admin commands

Admins have the following commands available to them that are not available to normal users.

(Enter a dot (.) followed by the Capital letters of each word shown below to enter the commands.)

.Admin Kill-this-room		Deletes the current room from the system.
.Admin Edit-this-room		Allows editing of the properties of the current room. This is
				explained in greater detail below.
.Admin 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.
.Admin edit-User		Allows editing of the properties of any user account on the system.
.Admin 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).
.Admin 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.
.Admin Room Invite-user		Access control command to grant any specific user access to a private room.
.Admin 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.
.Admin File Delete		If the current room has an associated file directory, this
				command may be used to delete files from it.
.Admin 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.
.Admin 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.
.Admin 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.
.Admin System-config 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.
.Admin System-config Internet	This command allows configuration of settings
				which affect how your Citadel system sends and receives messages on the Internet.
.Admin System-config 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.
.Admin Terminate-server Now	Immediately shut down the Citadel service, disconnecting any users who are logged in.
				Note that depending on how you installed Citadel, the server might automatically restart.
.Admin 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.
.Admin 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.
.Admin 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.

Editing rooms

This command allows any admin to change the parameters of a room. Go to the room you wish to edit and enter the .Admin 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 Admin explicitly invites them to the room using the .Admin 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 Admins 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 Administrators. 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_Citadel_directory/files/room_directory_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>", "Admin>", 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 Admin for this room, as well as any system-wide Admins.

  Room admin [Joe Responsible]:

...on larger systems, it helps to designate a person to be responsible for a room. Room Admins have access to a restricted set of Admin 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 admin 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.

When a new Citadel system is first installed, the default system-wide expire policy is set to 'manual' -- no automatic purging of messages takes place anywhere. For public message boards, you will probably want to set some sort of automatic expire policy, in order to prevent your message base from growing forever.

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 ;Admin Edit-floor command. The default setting for the floor default, in turn, is the system default setting, which can be changed using the .Admin 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 Admin level access may use the .Admin edit-User command to create and/or edit user accounts. There are several parameters which can be set here.

To create a user:

Lobby> . Admin 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> . Admin edit User
User name: person of significance
User #70 - Person of Significance  PW:
Current access level: 4 (Normal 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:

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 login 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 login' 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

Admins and Room Admins 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 ->

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

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 .Admin 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> . Admin System configuration General
Node name [uncnsrd]:
Fully qualified domain name [uncensored.citadel.org]:
Human readable node name [Uncensored]:
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. 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.

'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 Admin privileges. This is one of two ways for the system administrator to grant himself/herself Admin 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: