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.
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.
Access to Citadel's calendar and address book functions using any PIM client that supports Webcal or GroupDAV (requires WebCit).
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
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.
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.
You can easily compile the Citadel server 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.
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 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.
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:
editor=/usr/bin/vi
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.
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.
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.
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.
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:
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.
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.
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.
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).
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.)
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.
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.
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.
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.
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.
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:
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 admin 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 Admins to Zap (forget) rooms [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 Admin.
'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 .Admin Validate-new-users command. If you do not require registration, you should set the initial access level to 4 (Normal 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:
'Access level required to create rooms' is up to you. You might wish to restrict the creation of new rooms only to Admins, 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 admin 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 admin, and will have access to a subset of the .Admin command set while in that room. If you would rather grant this permission manually, answer No.
Citadel also has the ability to suspend problem user accounts instead of deleting them. This can be done by reducing 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 message forum it might be appropriate.
Normally, Admins have access to every room, public or private. They are also forbidden from Zap-ping 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 Admins to Zap (forget) rooms', in which case they may use the Zap command just like any other user. Admins may also .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 [10000000]: Minimum number of worker threads [5]: Maximum number of worker threads [256]: Automatically delete committed database logs [Yes]:
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.
'Automatically delete committed database logs' is a crucial setting which affects your system's disk utilization and backup recoverability. Please refer to the documentation on backups and recoverability to learn how the presence or absence of database logs affect your ability to reliably backup your Citadel system.
The next set of options affect how Citadel behaves on a network.
Server IP address (0.0.0.0 for 'any') [0.0.0.0]: POP3 server port (-1 to disable) [110]: POP3S server port (-1 to disable) [995]: IMAP server port (-1 to disable) [143]: IMAPS server port (-1 to disable) [993]: SMTP MTA server port (-1 to disable) [25]: SMTP MSA server port (-1 to disable) [587]: SMTPS server port (-1 to disable) [465]: Correct forged From: lines during authenticated SMTP [Yes]: Allow unauthenticated SMTP clients to spoof my domains [No]: No Instantly expunge deleted IMAP messages [No]: Yes
"Server IP address" refers to the IP address on your server to which Citadel's protocol services should be bound. Normally you will leave this set to * or 0.0.0.0, which will cause Citadel to listen on all of your server's interfaces. However, if you are running multiple Citadels on a server with multiple IP addresses, this is where you would specify which one to bind this instance of Citadel to.
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.
You'll also notice that you can specify two port numbers for SMTP: one for MTA (Mail Transport Agent) and one for MSA (Mail Submission Agent). The traditional ports to use for these purposes are 25 and 587. If you are running an external MTA, such as Postfix (which submits mail to Citadel using LMTP) or Sendmail (which submits mail to Citadel using the citmail delivery agent), that external MTA will be running on port 25, and you should specify "-1" for the Citadel MTA port to disable it. The MSA port (again, usually 587) would be the port used by end-user mail client programs such as Thunderbird or Outlook, to submit mail into the system. All connections to the MSA port must use Authenticated SMTP.
The protocols ending in "S" (POP3S, IMAPS, and SMTPS) are SSL-encrypted. Although all of these protocols support the STARTTLS command, older client software sometimes requires connecting to "always encrypted" server ports. Usually when you are looking at a client program that gives you a choice of "SSL or TLS," the SSL option will connect to one of these dedicated ports, while the TLS option will connect to the unencrypted port and then issue a STARTTLS command to begin encryption. (It is worth noting that this is //not// the proper use of the acronyms SSL and TLS, but that's how they're usually used in many client programs.)
All of the default port numbers, including the encrypted ones, are the standard ones.
The question about correcting forged From: lines affects how Citadel behaves with authenticated SMTP clients. Citadel does not ever allow third-party SMTP relaying from unauthenticated clients -- any incoming messages must be addressed to a user on the system or somewhere in a Citadel network. To use Citadel with SMTP client software such as Thunderbird, Outlook, or whatever, users must log in with a username and password. In order to prevent message forgeries, Citadel discards the "From:" line in any message entered by an authenticated user, and replaces it with a "From:" line containing the user's genuine name and e-mail address. Technically, this violates RFC822, because headers are never supposed to be altered, but common sense dictates that this is a good idea. Nevertheless, if you want to suppress this behavior, answer 'No' at the prompt (the default is 'Yes') and the headers will never be altered.
"Instant expunge" affects what happens when IMAP users delete messages. As you may already know, messages are not truly deleted when an IMAP client sends a delete command; they are only marked for deletion. The IMAP client must also send an "expunge" command to actually delete the message. The Citadel server automatically expunges messages when the client logs out or selects a different folder, but if you select the Instant Expunge option, an expunge operation will automatically follow any delete operation (and the client will be notified, preventing any mailbox state problems). This is a good option to select, for example, if you have users who leave their IMAP client software open all the time and are wondering why their deleted messages show up again when they log in from a different location (such as WebCit).
"Allow spoofing" refers to the security level applied to non-authenticated SMTP clients. Normally, when another host connects to Citadel via SMTP to deliver mail, Citadel will reject any attempt to send mail whose sender (From) address matches one of your host's own domains. This forces your legitimate users to authenticate properly, and prevents foreign hosts (such as spammers) from forging mail from your domains. If, however, this behavior is creating a problem for you, you can select this option to bypass this particular security check.
Connect this Citadel to an LDAP directory [No]: No
The LDAP configuration options are discussed elsewhere in this document.
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) [0]: Keep how many messages online? [150]: Mailbox default message expire policy (? for list) [0]: How often to run network jobs (in seconds) [1800]: Default frequency to run POP3 collection (in seconds) [3600]: Fastest frequency to run POP3 collection (in seconds) [0]: Enable full text search index (warning: resource intensive) [Yes]: Yes Hour to run purges (0-23) [4]:
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:
Again, this setting may be overridden on a per-floor basis, and the floor setting may be overridden on a per-room basis. You'll also notice that you can set a different default for mailbox rooms if you want to. This can allow you, for example, to set a policy under which old messages scroll out of public rooms, but private mail stays online indefinitely until deleted by the mailbox owners.
"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.
"Default frequency to run POP3 collection". If not overriden by a rooms own setting this determines how often POP3 mail will be collected for each configured room.
"Fastest frequency to run POP3 collection" is the fastest frequency that POP3 collection will be performed for any room. If a rooms frequency is set faster it will only be collected at this frequency.
"Hour to run purges" determines when expired and/or deleted objects are purged from the database. These purge operations are typically run overnight and automatically, sometime during whatever hour you specify. If your site is much busier at night than during the day, you may choose to have the auto-purger run during the day.
"Enable full text search index," if enabled, instructs the server to build and maintain a searchable index of all messages on the system. This is a time and resource intensive process -- it could take days to build the index if you enable it on a large database. It is also fairly memory intensive, so you may choose to disable this function if your server is short on memory. Once enabled, however, it will be updated incrementally and will not have any noticeable impact on the interactive response time of your system. The full text index is currently only searchable when using IMAP clients; other search facilities will be made available in the near future.
Perform journaling of email messages [No]: Perform journaling of non-email messages [No]: Email destination of journalized messages [example@example.com]:
The "Perform journaling..." options allow you to configure your Citadel server to send an extra copy of every message, along with recipient information if applicable, to the email address of your choice. The journaling destination address may be an account on the local Citadel server, an account on another Citadel server on your network, or an Internet email address. These options, used in conjunction with an archiving service, allow you to build an archive of all messages which flow through your Citadel system. This is typically used for regulatory compliance in industries which require such things. Please refer to the journaling guide for more details on this subject.
Save this configuration? No
When you're done, enter 'Yes' to confirm the changes, or 'No' to discard the changes.
As you know by now, Citadel is a completely self-contained, full-featured Internet e-mail system. When you run Citadel you do not need any other mail software on your host system. This eliminates the need for tedious mucking about with sendmail, qmail, postfix, Cyrus, the UW IMAP server, or any of countless other needlessly complex programs that lead some people to the false assumption that Unix systems are difficult to administer.
Some of the many features supported by Citadel are:
This section of the documentation will demonstrate how to configure these features.
Basic configuration of your Citadel system for Internet e-mail begins with the .Admin System-config Internet command:
Lobby> .Admin System-configuration Internet ### Host or domain Record type --- ------------------------- -------------------- 1 <A>dd <D>elete <S>ave <Q>uit ->
This is a "clean" setup. For a simple, standalone e-mail system you simply have to enter the Add command:
<A>dd <D>elete <S>ave <Q>uit -> Add Enter host name: schmeep.splorph.com (1) localhost (Alias for this computer) (2) smart host (Forward all outbound mail to this host) (3) fallback host (Send mail to this host only if direct delivery fails) (4) SpamAssassin (Address of SpamAssassin server) (5) RBL (domain suffix of spam hunting RBL) (6) masq domains (Domains as which users are allowed to masquerade) (7) ClamAV (Address of ClamAV clamd server) Which one [1]:
localhost: Basically what you're doing here is telling Citadel what any aliases for your machine are. If your machine were schmeep.splorph.com and you also had a DNS entry set up for "blah.com", you might want to enter '1' and enter blah.com as your alias, so that e-mail sent to that address won't bounce.
Important tip: if your system is known by one name and only one domain, you might not even need to do this at all. You will recall that you entered your system's fully qualified domain name earlier when you went through the .Admin System-configuration General command. The domain name you entered there is automatically considered by Citadel to be a 'localhost' entry in your Internet mail configuration. It does not hurt to enter it in both locations, though.
smart-host: Normally, Citadel sends outbound Internet e-mail directly to its destination. This may not be appropriate for some sites; you may require (due to local convention, security policy, or whatever) that all outbound mail be sent to an SMTP relay or forwarder. To configure this functionality, simply enter the domain name or IP address of your relay as a 'smart-host' entry.
If your relay server is running on a port other than the standard SMTP port 25, you can also specify the port number using "host:port" syntax; i.e. relay99.myisp.com:2525
Furthermore, if your relay server requires authentication, you can specify it using username:password@host or username:password@host:port syntax; for example, jsmith:pass123@relay99.myisp.com:25
A fallback host is a smart-host that is only used if mail cannot be delievered directly to its destination. This is useful if you prefer direct delivery but do not want your server queue filling up with deferred deliveries.
spamassassin: if you are running a SpamAssassin service anywhere on your local network, enter its name or IP address as a 'spamassassin' entry. This may be (and, in fact, will usually be) "127.0.0.1" to specify that the service is running on the same host computer as the Citadel server.
smw @ pixel % telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 pixel.citadel.org ESMTP Sendmail 8.9.3/8.9.3; Wed, 15 Mar 2000 19:00:53 -0500
smw @ pixel % ./citserver Init Starting params = 0xbfc2d020 Adding thread 0xb77366d0 (MasterThread) 2009/01/18 22:44:12.425673 2009/01/18 22:44:12.428991 2009/01/18 22:44:12.431528 * Citadel server engine v7.39 (build 6804M) * 2009/01/18 22:44:12.434108 Copyright (C) 1987-2008 by the Citadel development team. 2009/01/18 22:44:12.436836 This program is distributed under the terms 2009/01/18 22:44:12.438987 of the GNU General Public License. 2009/01/18 22:44:12.439376 Called as: ./citserver 2009/01/18 22:44:12.439433 $Id: libcitadel.c 5941 2008-01-16 14:42:41Z ajc $ 2009/01/18 22:44:12.439450 Loading citadel.config 2009/01/18 22:44:12.439768 Acquiring control record 2009/01/18 22:44:12.544350 Registered server command STLS (Start SSL/TLS session) 2009/01/18 22:44:12.544418 Registered server command GTLS (Get SSL/TLS session status) 2009/01/18 22:44:12.544439 Registered a new session function (type 0) 2009/01/18 22:44:12.544509 master_startup() started 2009/01/18 22:44:12.544537 Opening databases 2009/01/18 22:44:12.544564 cdb_*: open_databases() starting 2009/01/18 22:44:12.544585 Compiled db: Sleepycat Software: Berkeley DB 4.4.20: (February 24, 2006) 2009/01/18 22:44:12.544615 Linked db: Sleepycat Software: Berkeley DB 4.4.20: (February 24, 2006) 2009/01/18 22:44:12.544636 Calculated dbversion: 4004020 2009/01/18 22:44:12.544652 Previous dbversion: 4004020 2009/01/18 22:44:12.544774 cdb_*: Setting up DB environment 2009/01/18 22:44:12.544889 dbenv->open(dbenv, /var/lib/citadel//data/, 1392737, 0) 2009/01/18 22:44:12.703400 BDB: Finding last valid log LSN: file: 4 offset 6682554 2009/01/18 22:44:12.710590 BDB: Recovery starting from [4][6680296] 2009/01/18 22:44:12.715256 BDB: Recovery complete at Sun Jan 18 22:44:12 2009 2009/01/18 22:44:12.718080 BDB: Maximum transaction ID 80000061 Recovery checkpoint [4][6682554] 2009/01/18 22:44:12.720728 Starting up DB 2009/01/18 22:44:12.725381 Checking floor reference counts 2009/01/18 22:44:12.759949 Floor 0: 59 rooms 2009/01/18 22:44:12.882510 Floor 1: 0 rooms 2009/01/18 22:44:12.983090 Creating base rooms (if necessary) 2009/01/18 22:44:12.983126 create_room(name=Lobby, type=0, view=0) 2009/01/18 22:44:12.983320 Lobby already exists. 2009/01/18 22:44:12.983355 create_room(name=Aide, type=3, view=0) 2009/01/18 22:44:12.983403 Aide already exists. 2009/01/18 22:44:12.983425 create_room(name=Local System Configuration, type=3, view=0) 2009/01/18 22:44:12.983466 Local System Configuration already exists. 2009/01/18 22:44:12.983488 create_room(name=Trashcan, type=0, view=0) 2009/01/18 22:44:12.983528 Trashcan already exists. 2009/01/18 22:44:12.987894 Seeding the pseudo-random number generator... 2009/01/18 22:44:12.991851 Initializing ipgm secret 2009/01/18 22:44:12.992022 master_startup() finished 2009/01/18 22:44:12.992048 Checking/re-building control record 2009/01/18 22:44:12.999411 Upgrading modules. 2009/01/18 22:44:12.999472 Upgrade modules. 2009/01/18 22:44:12.999493 Server-hosted upgrade level is 7.39 2009/01/18 22:44:12.999512 $Id: serv_upgrade.c 6351 2008-05-30 22:10:27Z ajc $ 2009/01/18 22:44:12.999775 Unix domain socket '/var/run/citadel//citadel.socket': registered. 2009/01/18 22:44:12.999919 TCP port 0.0.0.0:504: (citadel-TCP) registered. 2009/01/18 22:44:12.999942 Initializing server extensions 2009/01/18 22:44:12.999962 Initialise modules, CtdlThreads not yet enabled. 2009/01/18 22:44:12.999983 Registered server command AUTO (Do recipient autocompletion) 2009/01/18 22:44:13.000003 $Id: serv_autocompletion.c 5777 2007-11-25 22:15:18Z davew $ 2009/01/18 22:44:13.000019 Registered server command EBIO (Enter your bio) 2009/01/18 22:44:13.000036 Registered server command RBIO (Read a user's bio) 2009/01/18 22:44:13.000052 Registered server command LBIO (List users with bios) 2009/01/18 22:44:13.000067 $Id: serv_bio.c 6159 2008-03-29 01:15:32Z davew $ 2009/01/18 22:44:13.000089 Registered a new message function (type 201) 2009/01/18 22:44:13.000105 Registered a new message function (type 202) 2009/01/18 22:44:13.000121 Registered a new session function (type 2) 2009/01/18 22:44:13.000136 Registered server command ICAL (Citadel iCal commands) 2009/01/18 22:44:13.000152 Registered a new session function (type 1) 2009/01/18 22:44:13.000166 Registered a new session function (type 0)
The lines emphasized in boldface in the above log output tell you that Citadel "can't bind" to various ports. The error 'address already in use' generally means that something else is already running on the requested port. Make SURE you've followed the above steps to remove sendmail/pop and start your Citadel server again.
Occationally it is not practical to remove a non-Citadel MTA on your host system. For example, you might have multiple groups of users, some of which are using Citadel and some of which are using a legacy Unix mail spool. This type of configuration is discouraged, but two tools are provided to allow it.
The tool is called "citmail" and it is, quite simply, a local MDA (Mail Delivery Agent) which you can configure into your MTA for final delivery of incoming messages to Citadel users. A full discussion of the finer points of complex Sendmail configurations is beyond the scope of this document; however, you might consider asking about it in the Citadel Support room on Uncensored.
local_transport = lmtp:unix:/usr/local/citadel/lmtp.socket
CitaNews} . Admin Edit this room
Room name [CitaNews]:
//(lots of other stuff omitted for brevity...)//
Self-service list subscribe/unsubscribe [No]: Yes
- Shut down the Citadel server. - Back up all files (database files, log files, etc.) to tape or some other backup media. - Start the Citadel server.
- Back up all files. Make sure the database files (cdb.*) are backed up //before// the log files (log.*). This will usually be the case, because the database files tend to appear first in both alphabetical and on-disk ordering of the data/ directory. - After verifying that your backup completed successfully, delete the committed log files with a command like this:
/usr/local/citadel/sendcommand "CULL"
- Stop the Citadel service with a command like "/etc/init.d/citadel stop" - Make a backup of your data. Either write it out to tape or copy it to another directory, or a tarball. - "cd" to your Citadel directory and type "./database_cleanup.sh" - Let the cleanup script run. Do not interrupt this process for any reason. - Restart the Citadel service with a command like "/etc/init.d/citadel start"
- This should be obvious, but it's still worth mentioning: Make sure you have a backup of everything before you start this! You're performing a major operation here. Don't risk it. - First, get all the users logged off from your system. Disconnect it from the network if possible. You don't want anyone logging in while you're doing this. - Log on as root, or some other user that has read/write access to all relevant files. - Go to the directory that Citadel is installed in. For example, issue a command like "cd /usr/local/citadel" - Export the databases with the following command:
./sendcommand "MIGR export" >exported.xml
-This command may run for a while. On a very large system it could take an hour or more. Please be patient! - When the export completes, check to make sure that "exported.dat" exists and has some data in it. (Type "ls -l exported.dat") - Shut down the Citadel server. If you have a line in "/etc/inittab" that reads like this:
c1:2345:respawn:/usr/local/citadel/citserver -h/usr/local/citadel
- ...then you should change the "respawn" to "off" and then type "/sbin/init q" to make the changes take effect. - Now it's time to delete your current binary databases. Type:
rm -f citadel.config citadel.control data/*
- If you're moving Citadel to another computer, you should move the //entire// directory over at this time. "exported.dat" only contains the information that was in the binary databases. Information which was stored in portable formats doesn't need to be exported/imported, so you must bring it all over in its current form. - Now get Citadel running on the new computer (or whatever). Run "setup" and turn the service back on (from "/etc/inittab") but DO NOT log in. - As root, run the import command:
./sendcommand "MIGR import"
- This will import your databases. Again, it may run for a long time.
- If you get watchdog time out messages during the import you will need to use the -w switch
to sendcommand like this:
./sendcommand -w60 "MIGR import"
- Restart the Citadel server. You can do this any way you like. From the command line, you
can do it with a command like:
./sendcommand "DOWN"
- Now you're finished. Log in and test everything. You may delete exported.dat at this time,
or you might want to save it somewhere as a sort of pseudo-backup.
Cryptography support (TLS/SSL)
Overview
Citadel provides built-in support for encryption using Transport Layer Security (TLS) for ESMTP,
IMAP, POP3, and the Citadel client protocol. A simple cryptographic configuration is installed
automatically when you bring the system online. The remainder of this section describes how
this configuration is built, and what you can do to make changes to it.
Encryption files are kept in the "keys/" directory. The three files used by Citadel are:
* "citadel.key" - Contains your system's RSA private key. Citadel generates a new key
automatically if one is not found.
* "citadel.csr" - Contains a Certificate Signing Request (CSR) for your system. Citadel
generates a new CSR automatically, using your private key, if one is not found.
* "citadel.cer" - Contains the public certificate for your system. The public key in the
certificate must correspond with the private key in "citadel.key", otherwise encryption
will not function properly. Citadel will generate a self-signed certificate, again using your
private key, if a certificate is not found.
Generating and installing a Trusted Certificate
If you wish to interact with 3rd party clients that have hard coded lists of acceptable Certificate
Authorities, and you do not want annoying dialog boxes popping up for the user on the first
(or all) connections, then you will have to have your key signed by a valid Certificate Authority.
It is beyond the scope of this document to provide a complete tutorial on SSL certificates. Here
are the general rules to follow:
* Generally, the Certificate Signing Requeste which is automatically generated by Citadel
will not contain enough information for any Certificate Authority to sign it. Generate a new
CSR with the following commands:
cd keys
openssl req -new -key citadel.key -out citadel.csr
Answer all questions (your geographic location, organization name, etc.) and then send the new
"citadel.csr" to your Certificate Authority when you order the certificate.
* When the certificate is received, simply save it as "citadel.cer" and restart the Citadel
server.
* If your certificate authority delivers a 'chained' certificate (one with intermediate
certificate authorities), simply append the intermediate certificate after your server's own
certificate in the "citadel.cer" file.
----
LDAP (Directory) Support
Introduction
Citadel is capable of authenticating users against an external LDAP service instead of
maintaining its own username/password database. This is useful if you are installing Citadel
in an organization that already uses LDAP for "single sign on" purposes.
Citadel supports both the standard LDAP schema (RFC 2307) as well as the most popular non-standard
schema (Microsoft Active Directory).
Preparing your LDAP server for Citadel connections
Your LDAP service must be up and running before you attempt to connect Citadel to it.
It must also be able to accept TCP client connections.
Configuring the LDAP Connector for Citadel
Once you've located or installed your LDAP server, connecting Citadel to it is easily completed
with the .Admin System-configuration General command:
Lobby> . Admin System configuration General
//(lots of other stuff omitted for brevity...)//
Connect this Citadel to an LDAP directory [Yes]: Yes
Host name of LDAP server []: 127.0.0.1
Port number of LDAP service [389]: 389
Base DN []: dc=servername,dc=domain,dc=org
Bind DN []: cn=manager,dc=servername,dc=domain,dc=org
Password for bind DN []: secret
//(more questions omitted...)//
Save this configuration? Yes
* sendcommand - Send a server command
It is up to you to decide which utilities should be made accessible only to system administrators. It is important that you set the file permissions correctly. All utilities should have access to the Citadel data files. We will attempt to address each program individually.
sendcommand will interpret its arguments (except for -hDIRNAME) as a server command, which is sent to the server. Commands which require textual input will read it from stdin. Commands which generate textual output will be sent to stdout.
This utility is intended to be used to enable Citadel server commands to be executed from shell scripts.
NOTE: be sure that this utility is not world-executable. It connects to the server in privileged mode, and therefore could present a security hole if not properly restricted.