Add files via upload

data/Makefile

@@ -0,0 +1,22 @@
+# Makefile for data directory.
+#
+# IRC Services is copyright (c) 1996-2009 Andrew Church.
+#     E-mail: <achurch@achurch.org>
+# Parts written by Andrew Kempe and others.
+# This program is free but copyrighted software; see the file GPL.txt for
+# details.
+
+include ../Makefile.inc
+TOPDIR=..
+
+all: example-ircservices.conf example-modules.conf
+
+%.conf: %.conf.in Makefile ../Makefile.inc
+	sed 's/@PROGRAM@/$(PROGRAM)/g' <$< >$@
+
+install: all $(DATDEST)/helpfiles
+	$(INSTALL_DAT) example-ircservices.conf "$(INSTALL_PREFIX)$(DATDEST)/example-$(PROGRAM).conf"
+	$(INSTALL_DAT) example-modules.conf "$(INSTALL_PREFIX)$(DATDEST)/example-modules.conf"
+
+$(DATDEST)/helpfiles:
+	$(CP_ALL) helpfiles "$(DATDEST)"

data/example-ircservices.conf

@@ -0,0 +1,873 @@
+# Example configuration file for Services.  After making the appropriate
+# changes to this file, place it in the Services data directory (as
+# specified in the "configure" script, default /usr/local/lib/ircservices)
+# with the name "ircservices.conf".
+#
+# The format of this file is fairly simple: a line beginning with a # is a
+# comment, and any other non-blank line is expected to be a directive and
+# parameters, separated by spaces or tabs.  For example:
+#
+#	Directive Parameter-1 Parameter-2 ...
+#
+# Directives are case-insensitive.  Note that some directives do not take
+# any parameters; these are typically "on-off" directives, for which simply
+# including the directive in this file (or removing it) has an effect on
+# Services' functionality.
+#
+# If a parameter's value is a string which includes spaces, enclose the
+# string in double quotation marks, like the example below.  Quotes may be
+# used around any string at all for clarity.
+#
+#	"This is a parameter string with spaces in it"
+#
+# If you need to include a double quote inside a quoted string, precede it
+# by a backslash:
+#
+#	"This string has \"double quotes\" in it"
+#
+# A backslash can likewise be included by preceding it with another
+# backslash.
+#
+# Time parameters can be specified either as an integer representing a
+# number of seconds (e.g. "3600" = 1 hour), or as an integer with a unit
+# specifier: "s" = seconds, "m" = minutes, "h" = hours, "d" = days.
+# Combinations (such as "1h30m") are also permitted.  Examples (all of which
+# represent the same length of time, one day):
+#
+#	"86400", "86400s", "1440m", "24h", "1d", "23h60m", "23h59m60s"
+#
+# In the documentation for each directive, one of the following will be
+# included to indicate whether an option is required:
+#
+# [REQUIRED]
+#     Indicates a directive which must be given.  Without it, Services will
+#     not start.
+#
+# [RECOMMENDED]
+#     Indicates a directive which may be omitted, but omitting it may cause
+#     undesirable side effects.
+#
+# [OPTIONAL]
+#     Indicates a directive which is optional.  If not given, the feature
+#     will typically be disabled.  If this is not the case, more
+#     information will be given in the documentation.
+#
+# [DISCOURAGED]
+#     Indicates a directive which may cause undesirable side effects if
+#     specified.
+# 
+
+###########################################################################
+#
+# Configuration file control
+#
+###########################################################################
+
+# IncludeFile <filename>  [OPTIONAL]
+#     Specifies another file from which to read configuration directives.
+#     The file is processed as if its contents were included in place of
+#     the IncludeFile directive.  If a relative pathname is given, it is
+#     relative to the Services data directory.  This directive may be used
+#     in both ircservices.conf and modules.conf.
+#
+#     Note that IncludeFile directives may only be nested to a depth of
+#     100 levels, in order to prevent infinite loops.
+
+#IncludeFile     "local.conf"
+
+###########################################################################
+#
+# Remote server configuration
+#
+###########################################################################
+
+# RemoteServer <hostname> <port> <password>  [REQUIRED]
+#     Specifies the remote server hostname and port.  The hostname may be
+#     either a standard Internet hostname or dotted-quad numeric address;
+#     the port number must be an integer between 1 and 65535 inclusive.
+#     The password is a string which should be enclosed in double quotes
+#     if it contains any spaces (or just for clarity).  Make sure to
+#     uncomment the directive (remove the leading "#") before running
+#     Services.
+#
+#     The remote server and port may be overridden at runtime with the
+#     -remote command-line option.  The password may not be set at runtime.
+
+#RemoteServer    127.0.0.1 6667 "password"
+
+# LocalAddress <hostname> [<port>]  [OPTIONAL]
+#     Specifies the local address to bind to before connecting to the
+#     remote server.  This may be useful on multihomed hosts.  The hostname
+#     and port number are specified the same way as with the RemoteServer
+#     directive.  If this is not specified, Services will let the operating
+#     system choose the local address.  If only a hostname is specified,
+#     Services will bind to that address but let the operating system
+#     choose the local port number.
+#
+#     If you don't know what this means or don't need to use it, just leave
+#     the directive commented out.
+
+#LocalAddress    host.name.here
+#LocalAddress    host.name.here 6677
+
+###########################################################################
+#
+# Services identification
+#
+###########################################################################
+
+# ServerName <name>  [REQUIRED]
+#     Specifies the IRC server name which Services should use when it
+#     connects to the network.
+
+ServerName      "services.example.net"
+
+# ServerDesc <text>  [REQUIRED]
+#     Specifies the text which should appear as the server's information in
+#     /whois and similar queries.
+
+ServerDesc      "Services for IRC Networks"
+
+# ServiceUser <usermask>  [REQUIRED]
+#     Specifies the user@host mask which should be used by the Services
+#     pseudoclients.
+
+ServiceUser     "services@example.net"
+
+###########################################################################
+#
+# Unix group and umask to use
+#
+###########################################################################
+
+# RunGroup <group>  [OPTIONAL]
+#     Specify the group which Services should run as.  <group> can be
+#     either a group name or an equals sign ("=") followed by a group ID.
+#     If not specified, Services will use the group ID it is started with.
+#     Note that Unix setgid permission on the executable file will do the
+#     same thing, but the setgid permission bit is cleared whenever the
+#     file is modified, while this setting will always be used (if the
+#     system permits it) when Services is started.
+
+#RunGroup        services
+#RunGroup        =65534    # A common value for the "nogroup" group
+
+# Umask <umask>  [RECOMMENDED]
+#     Sets the umask (file creation mask) for Services.  This mask is
+#     applied to all data files created by Services, including database
+#     files (which are recreated on every database update) and the process
+#     ID file (PIDFilename, below), and indicates which file permission
+#     bits are NOT to be set on those files as an octal value.  Common
+#     values are given in the examples below.  If not specified, the umask
+#     in place when Services is started will be used.
+
+Umask           077     # Disallows access to all but file owner
+                        #    (recommended when RunGroup is not set)
+#Umask           007    # Allows access to members of file group as well
+                        #    (recommended when RunGroup is set)
+
+###########################################################################
+#
+# Services data filenames
+#
+###########################################################################
+
+# NOTE: All filenames are relative to the Services data directory.
+
+# LogFilename <filename>  [REQUIRED]
+#     Specifies the name of the file into which Services will log data.
+#     May be overridden by the -log command-line option.  If this name
+#     contains "%y", "%m", or "%d", they will be replaced by the current
+#     year, month, or day, respectively, and the logfile will be
+#     automatically rotated as needed when the date changes.
+
+LogFilename     ircservices.log
+
+# PIDFilename <filename>  [REQUIRED]
+#     Specifies the name of the file containing Services' process ID.
+#     Note that if you change this filename, and you are using the
+#     "ircservices-chk" crontab script provided with Services, you will
+#     need to change the filename in that file as well.
+
+PIDFilename     ircservices.pid
+
+# MOTDFilename <filename>  [REQUIRED]
+#     Specifies the name of the Message of the Day file.
+
+MOTDFilename    ircservices.motd
+
+# LockFilename <filename>  [REQUIRED]
+#     Specifies the name of the data directory lock file.  This file is
+#     created in the data directory when Services begins updating
+#     databases, and is removed after the databases are updated.  If the
+#     file already exists when Services tries to update the databases,
+#     Services sends a warning (via wallops) and does not write any data.
+
+LockFilename    .lock
+
+###########################################################################
+#
+# Basic functionality
+#
+###########################################################################
+
+# NoBouncyModes  [OPTIONAL]
+#     Normally, Services will check for the remote IRC server reversing its
+#     mode changes, and issue a warning (and stop changing modes) if it
+#     detects such a problem.  However, the detection will sometimes
+#     trigger even when there is no problem, thus preventing channel
+#     mode-locks and other features from working.  If you specify this
+#     directive, Services will not check for mode bouncing, which can avoid
+#     this problem if you know your servers are set up correctly.
+#
+#     WARNING: setting this option when your servers are incorrectly
+#     configured can result in flooding!
+
+#NoBouncyModes
+
+# NoSplitRecovery  [OPTIONAL]
+#     Disables Services' recognition of users returning from netsplits.
+#     Normally (on networks with some sort of timestamp support in the IRC
+#     server), Services will check via the timestamp field whether a user
+#     is the same as the last user who identified for the nick, and allow
+#     the user access to that nick without requiring identification again
+#     if the timestamps match.  Enabling this directive will force all
+#     users to re-identify after a netsplit.
+#
+#     It's generally easier on users to leave this disabled, but if you
+#     suspect one of your servers has been hacked to send false timestamps
+#     (or you suspect a bug in Services itself) enabling this directive
+#     will eliminate the possibility of one user "stealing" another's nick
+#     by pretending to have the same timestamp.
+#
+#     You may also want to uncomment this directive if your servers' clocks
+#     are very far apart; the less synchronized the servers' clocks are,
+#     the greater the possibility of someone "taking over" another person's
+#     nick when a server with a fast clock splits.
+#
+#     NOTE: On DALnet 4.4.15+, Dreamforge, Bahamut, Unreal, and compatible
+#     networks, Services takes advantage of an IRC server feature to assign
+#     each user a permanent ID number, which significantly enhances the
+#     security of this check.  On such networks, you should almost always
+#     leave this directive commented out.  See section 3-1-2 of the manual
+#     for details.
+
+#NoSplitRecovery
+
+# StrictPasswords  [RECOMMENDED]
+#     When enabled, causes Services to perform more stringent checks on
+#     passwords.  If this is disabled, Services will only disallow a
+#     password if it is the same as the entity (nickname or channel name)
+#     with which it is associated.  When enabled, however, Services will
+#     also check that the password is at least five characters long, and
+#     disallow it if not.
+
+StrictPasswords
+
+# NoAdminPasswordCheck  [OPTIONAL]
+#     When enabled, allows Services administrators to set any password
+#     for a nickname or channel (including their own), bypassing all of
+#     the password checks.  When disabled, Services administrators are
+#     subject to the same password checks as ordinary users.
+
+#NoAdminPasswordCheck
+
+# BadPassLimit <count>  [RECOMMENDED]
+#     Sets the number of invalid password tries before Services removes a
+#     user from the network.  If a user enters <count> invalid passwords
+#     for any Services function or combination of functions during a
+#     single IRC session (subject to BadPassTimeout, below), Services will
+#     issue a /KILL for the user.  If not given, Services will ignore
+#     failed password attempts (though they will be logged in any case).
+#     Note that entering a correct password will _not_ reset this count.
+
+BadPassLimit    5
+
+# BadPassTimeout <time>  [OPTIONAL]
+#     Sets the time after which invalid passwords are forgotten about.  If
+#     a user does not enter any incorrect passwords in this amount of time,
+#     the incorrect password count will reset to zero.  If not given, the
+#     timeout will be disabled, and the incorrect password count will never
+#     be reset until the user disconnects.
+
+BadPassTimeout  1h
+
+# BadPassWarning <count>  [RECOMMENDED]
+#     Sets the number of bad passwords _for a single nick or channel_ that
+#     will be accepted before a warning is sent using WALLOPS/GLOBOPS.  If
+#     not given, no warnings will be sent.
+
+BadPassWarning  5
+
+# IgnoreDecay <rate>  [RECOMMENDED]
+#     Services keeps track of an "ignore level" for each user, based on how
+#     often the user sends commands to Services and how long those commands
+#     take to execute; this directive specifies how quickly that level
+#     returns to zero when the user idles.  The parameter is the number of
+#     seconds (possibly including a fractional part, like "0.5") it takes
+#     for the ignore level to drop by half.
+#
+#     If either this directive or IgnoreThreshold is not given, the ignore
+#     code is disabled.
+
+IgnoreDecay     5
+
+# IgnoreThreshold <level>  [RECOMMENDED]
+#     This directive specifies the ignore level at which Services decides
+#     that a user is flooding Services and ignores that user.
+#
+#     If either this directive or IgnoreDecay is not given, the ignore code
+#     is disabled.
+
+IgnoreThreshold 0.1
+
+# UpdateTimeout <time>  [REQUIRED]
+#     Sets the delay between automatic database updates.  This timer is
+#     reset by the OperServ UPDATE command.
+
+UpdateTimeout   5m
+
+# WarningTimeout <time>  [REQUIRED]
+#     Sets the interval between sending warning messages for program
+#     errors via WALLOPS/GLOBOPS.
+
+WarningTimeout  4h
+
+# ReadTimeout <seconds>  [REQUIRED]
+#     Sets the timeout period for reading from the network; this is the
+#     length of time Services will wait to receive data from an external
+#     source if none is available before proceeding with other actions,
+#     such as timeout checking.  Note that the parameter is a number of
+#     seconds, not a "time"; it may also include a fractional part, such as
+#     "0.5".
+#
+#     This value also influences the period between timeout checks; see the
+#     TimeoutCheck directive below.
+
+ReadTimeout     3
+
+# TimeoutCheck <seconds>  [REQUIRED]
+#     Sets the (maximum) frequency at which the timeout list is checked.
+#     This, combined with ReadTimeout above, determine how accurately timed
+#     events, such as nick kills, occur; it also determines how much CPU
+#     time Services will use doing this.  Higher values will cause less
+#     accurate timing but less CPU usage.  Note that the parameter is a
+#     number of seconds, not a "time", and may include a fractional part.
+#
+#     This shouldn't be set any higher than 10 seconds, and 1 second or
+#     less is best if your system is powerful enough (or your network small
+#     enough) to handle it.  0 will cause the timeout list to be checked
+#     every time through the main loop, which provides the most accurate
+#     timeout response but may require too much processing on large
+#     networks.
+#
+#     Note that if this value is smaller than ReadTimeout (above), then the
+#     delay between checks of the timeout list may exceed the value given
+#     here during periods of little or no network activity.
+
+TimeoutCheck    1.0
+
+# PingFrequency <time>  [OPTIONAL]
+#     Sets the time after which Services sends a PING message to its uplink
+#     if no other network activity has occurred.  This can be useful if you
+#     have a low-activity network and your server keeps dropping Services'
+#     connection with "Ping timeout".  If not set, Services will not send
+#     PING messages.
+
+#PingFrequency   30s
+
+# MergeChannelModes <seconds>  [OPTIONAL]
+#     WARNING:  This directive can have security implications; read
+#     carefully before enabling.
+#
+#     If this directive is given, it causes Services to not send out
+#     channel mode changes immediately, but to wait for the given number of
+#     seconds (which may be fractional) and collect all channel modes to
+#     send in a single command.  For example, if two users enter a channel
+#     at nearly the same time and both of them are to be opped, instead of
+#     sending two MODE +o commands, Services will send a single MODE +oo
+#     command.  This option can help with large channels in reducing mode
+#     floods, particularly when Services first connects or a server
+#     reconnects after a split; however, the sending of the mode command
+#     will be slightly delayed, so that the users will have to wait a short
+#     time before getting chanop privileges.  Furthermore, since this
+#     increases the time before deops, etc. occur, users can take advantage
+#     of netsplits to "steal ops" for a short time before Services responds.
+#
+#     Services will never send out more than six parameters with each MODE
+#     command (this limit is part of the IRC protocol specification).  If
+#     more than six +o, +v, etc. modes are to be sent, Services will send
+#     them out six at a time without waiting for the timeout given with
+#     this directive.  Also, if more than MERGE_CHANMODE_SLOTS (defined in
+#     defs.h; default 3) channels receive modes before the timeout expires,
+#     those modes will similarly be sent out at that time.
+#
+#     Note that the actual sending of the MODE command may be delayed by as
+#     much as the TimeoutCheck value; if you use this option, then in
+#     general you should set TimeoutCheck to the same (or a smaller) value.
+#     Also, on networks with little traffic there may be an additional
+#     delay up to the value of ReadTimeout before the modes are sent.
+#
+#     If this option is not set, Services will still collect all mode changes
+#     resulting from a single event (such as a user joining a channel) and
+#     send them in a single message as soon as the event processing finishes.
+
+#MergeChannelModes 0.5
+
+# NetBufferSize <total-size> [<per-connection-size>]  [RECOMMENDED]
+#     Sets the maximum amount of memory used by network connection buffers.
+#     If a second parameter is given, it sets the maximum amount of memory
+#     used by a single connection; if not given, this defaults to the same
+#     as the total limit.
+
+NetBufferSize   4194304 1048576  # 4MB and 1MB
+
+# NetBufferLimit <inactive-limit> [<ignore-limit>]  [RECOMMENDED]
+#     Sets the threshold at which Services sends a "busy" reply to PRIVMSGs
+#     (<inactive-limit>) and at which Services ignores PRIVMSGs entirely
+#     (<ignore-limit>).  Both thresholds apply to non-operator users only;
+#     PRIVMSGs from IRC operators will always be processed normally.  A
+#     WALLOPS/GLOBOPS message will be sent when Services exceeds or drops
+#     below either of the thresholds.  If the thresholds are set to the
+#     same value, "busy" messages will never be sent.
+#
+#     The thresholds are expressed as percentages of the value(s) given for
+#     NetBufferSize above.  If both a total size limit and a per-connection
+#     size limit are specified, the higher of the two percentages is
+#     checked against these thresholds.
+#
+#     If NetBufferSize is not specified, NetBufferLimit has no effect.
+
+NetBufferLimit  80 95
+
+###########################################################################
+#
+# Miscellaneous settings
+#
+###########################################################################
+
+# These are settings which don't belong anywhere else, or which would
+# be module settings but apply to multiple modules.
+
+# EncryptionType <type>  [OPTIONAL]
+#     Specifies the type of encryption to be used when storing new
+#     passwords.  Changing this has no effect on passwords previously set.
+#     If not specified, new passwords will not be encrypted.
+
+#EncryptionType  md5
+
+# GuestNickPrefix <value>  [REQUIRED]
+#     Sets the nickname prefix used when Services changes a user's
+#     nickname (for example, from the "NSForceNickChange" NickServ option).
+#     A unique series of digits will be appended to this string to form the
+#     new nickname.  This option is ignored for IRC servers which do not
+#     allow remote clients' nicknames to be forcibly changed, but it must
+#     be set to something anyway.
+
+GuestNickPrefix "Guest"
+
+# RejectEmail  [OPTIONAL]
+#     Specifies E-mail addresses (which may include wildcards) which are
+#     not allowed to be used in nickname or channel registration.  This
+#     directive can be given multiple times to disallow multiple addresses
+#     or address masks.
+
+#RejectEmail     *@example.com
+
+# DefTimeZone <time-zone>  [OPTIONAL]
+#     Sets the time zone to be used for displaying the time of day with
+#     certain commands, such as NickServ INFO.  If not given, the system's
+#     default time zone (the value of the TZ environment variable) is used.
+#     <time-zone> is the name of the time zone to be used; consult your
+#     system manual for how time zone names are specified on your system.
+#     Note that users can set time zones for their own nicknames
+#     independently; this setting is only used as a default.  The
+#     following example will cause Services to use United States Pacific
+#     time on most systems:
+
+#DefTimeZone     PST8PDT
+
+# ListMax <count>  [REQUIRED]
+#     Specifies the maximum number of nicks to be returned for commands
+#     that return a list of items, such as NickServ LIST and LISTEMAIL
+#     or OperServ AKILL LIST.
+
+ListMax         50
+
+# LogMaxUsers  [OPTIONAL]
+#     Causes Services to write a message to the log every time a new
+#     user maximum is reached.
+
+LogMaxUsers
+
+# EnableGetpass  [OPTIONAL]
+#     Allows use of the NickServ and ChanServ GETPASS commands.
+
+EnableGetpass
+
+# WallAdminPrivs  [OPTIONAL]
+#     Causes Services to send a WALLOPS/GLOBOPS whenever a Services
+#     administrator uses those privileges to perform a NickServ or
+#     ChanServ operation (such as setting a nickname or channel
+#     password).
+
+#WallAdminPrivs
+
+# LoadLanguageText  [OPTIONAL]
+#     Loads replacement text for language-specific strings from the given
+#     file.  Relative pathnames are relative to the Services data
+#     directory.  See section 3-9 of the manual for the file format.
+
+#LoadLanguageText mytext.l
+
+###########################################################################
+#
+# Modules to load
+#
+###########################################################################
+
+# The remainder of this file lists which modules should be loaded by
+# Services at startup.  Note that modules are loaded in the order they are
+# listed in this file; some modules depend on others, and if they are given
+# in the wrong order, Services may not be able to start!
+#
+# Modules are loaded using the LoadModule directive, which has the format:
+#	LoadModule <module name>
+# Available module names are listed below.
+
+###########################################################################
+
+# Base IRC protocol module  [REQUIRED]
+#     These modules provide the base functionality for communicating with
+#     the remote IRC server, and MUST be loaded before any other module.
+#     Select the module which matches the IRC server you are using:
+#         protocol/bahamut      DALnet Bahamut server, versions 1.4.25+
+#         protocol/dalnet       DALnet server, version 4.4.13 and earlier
+#         protocol/dreamforge   DALnet Dreamforge server, versions 4.4.15+
+#         protocol/hybrid       Hybrid server, version 7.0
+#         protocol/inspircd     InspIRCd server, version 1.1 and later
+#         protocol/monkey       Chunky Monkey IRCD, version 1.0 and later
+#         protocol/ptlink       PTlink IRC server, version 6.0 and later
+#         protocol/ratbox       ircd-ratbox server, all versions
+#         protocol/rfc1459      RFC1459-compliant servers
+#         protocol/solidircd    solid-ircd server, all versions
+#         protocol/trircd       Trircd server, version 5.5 and later
+#         protocol/ts8          RFC1459 with TS8 extensions
+#         protocol/undernet-p9  Undernet server, version 2.9.x only
+#         protocol/unreal       Unreal server, version 3.1.1 and later
+
+#LoadModule protocol/(insert protocol name here)
+
+###########################################################################
+
+# Encryption modules  [OPTIONAL]
+#     These modules enable encryption of passwords used in Services.
+#     Encryption provides a measure of safety against having passwords
+#     stolen even if someone gains access to the Services databases.
+#     Encryption modules MUST be loaded before database modules (below).
+#
+#     Loading encryption modules makes them available for use in decrypting
+#     previously set passwords, but unless you set the EncryptionType
+#     directive as well, new passwords will not be encrypted.
+#
+#     WARNING: Depending on the encryption type used, you may not be able
+#     to recover the original passwords once they are encrypted!  Modules
+#     with this behavior are marked "(ONE-WAY)" below.
+#
+#     Encryption modules available:
+#         encryption/md5         Encryption using the MD5 message-digest
+#                                    algorithm (ONE-WAY)
+#         encryption/unix-crypt  Encryption using the DES-based Unix
+#                                    crypt() function (ONE-WAY)
+
+LoadModule encryption/md5
+LoadModule encryption/unix-crypt
+
+###########################################################################
+
+# Database access module  [RECOMMENDED]
+#     These modules provide access to permanent storage for data used by
+#     various Services modules.  You can run Services without a database
+#     module loaded, but (except for testing and experimentation) you
+#     probably won't find it very useful!  Select the module corresponding
+#     to the type of database you want to use:
+#         database/standard     Standard database module (file-based)
+#         database/version4     Database files compatible with version
+#                                   4.5.x and 5.0.x of Services
+
+LoadModule database/standard
+#LoadModule database/version4
+
+###########################################################################
+
+# Mail-sending modules  [OPTIONAL]
+#     This set of modules allows Services to send E-mail.  This feature is
+#     currently used to forward memos via E-mail and implement E-mail
+#     address confirmation.  Two modules must be loaded to use mail, the
+#     main module (mail/main) and one of the following low-level modules:
+#         mail/smtp  [RECOMMENDED]
+#             Sends mail via the SMTP protocol.
+#         mail/sendmail  [DISCOURAGED]
+#             Sends mail via a "sendmail" program.  This module should
+#             not be used unless you cannot send mail via SMTP.
+
+LoadModule mail/main
+LoadModule mail/smtp
+#LoadModule mail/sendmail
+
+###########################################################################
+
+# OperServ modules  [RECOMMENDED]
+#     These modules provide functionality for IRC operators, and allow
+#     overall management of Services and the IRC network.  The base module,
+#     "operserv/main", contains basic functions, such as channel mode
+#     changing via Services, juping (banning from the network) of servers,
+#     management of Services operator/administrator lists, and control of
+#     Services itself (settings and shutdown/restart).  Additionally, the
+#     following add-on modules are available:
+#
+#         operserv/akill  [RECOMMENDED]
+#             Allows the use of autokills, which prevent users matching
+#             certain masks from connecting to the network.
+#
+#         operserv/news  [OPTIONAL]
+#             Adds a "news" system, which can be used to send automated
+#             messages to users when they log onto the network, or to IRC
+#             operators when they gain operator privileges.
+#
+#         operserv/sessions  [OPTIONAL]
+#             Monitors connections to the network, and sends a warning when
+#             a large number of connections (often a sign of "cloning") are
+#             initiated from the same host, optionally killing the users as
+#             well.  However, this module consumes a good deal of CPU time,
+#             and may slow down Services too much to be usable on large
+#             networks.
+#
+#         operserv/sline  [OPTIONAL]
+#             Allows the use of S-lines, alternative types of autokills
+#             which can be used to match against users' nicknames, "real
+#             names" or IP addresses.  (Note that matching against IP
+#             addresses will not work unless your IRC server supports this
+#             feature; currently, only the Bahamut server is known to
+#             support this.)
+
+LoadModule operserv/main
+LoadModule operserv/akill
+LoadModule operserv/news
+LoadModule operserv/sessions
+LoadModule operserv/sline
+
+###########################################################################
+
+# NickServ modules  [RECOMMENDED]
+#     These modules provide for the registration of nicknames and
+#     associated functions.  The base module, "nickserv/main", provides the
+#     core registration functionality, as well as commands to set nickname
+#     options and maintain the nickname's access list.  Additionally, the
+#     following add-on modules are available:
+#
+#         nickserv/access  [OPTIONAL]
+#             Allows users to be recognized for their nickname based on an
+#             access list of user@host masks.  Note that if the SECURE
+#             option is set for the nick (which is the default), users will
+#             still need to identify for their nicks, but if their address
+#             is on the access list, Services will not issue nick kills or
+#             change their nick.
+#
+#         nickserv/autojoin  [OPTIONAL]
+#             Allows users to request that Services automatically make
+#             them join certain channels upon identifying.  This module
+#             requires an IRC server which supports the SVSJOIN command;
+#             currently, Unreal and trircd are known to support this.
+#
+#         nickserv/link  [OPTIONAL]
+#             Allows users to create and remove links (aliases) to their
+#             nickname using the LINK and UNLINK commands, and provides a
+#             LISTLINKS command to list all links in a group of linked
+#             nicks.
+#
+#         nickserv/mail-auth  [OPTIONAL; RECOMMENDED for large networks]
+#             Allows verification of E-mail addresses for nicknames by
+#             sending an authentication code to the address given in the
+#             REGISTER or SET EMAIL command and disallowing identification
+#             for the nick until the user sends the authentication code to
+#             NickServ with the AUTH command.
+#
+#     The "operserv/main" module is REQUIRED for all NickServ modules.
+
+LoadModule nickserv/main
+LoadModule nickserv/access
+#LoadModule nickserv/autojoin
+LoadModule nickserv/link
+LoadModule nickserv/mail-auth
+
+###########################################################################
+
+# ChanServ modules  [RECOMMENDED]
+#     These modules provide for the registration of channels and associated
+#     functions.  The base module, "chanserv/main", provides the core
+#     registration functionality, as well as commands to set channel
+#     options and maintain access and autokick lists for the channel.
+#     Additionally, the following add-on modules are also available:
+#
+#         chanserv/access-levels  [OPTIONAL]
+#             Allows modification of channels' access lists using the
+#             ACCESS command, as well as modification of channel feature
+#             access levels (such as auto-op or auto-voice) with the LEVELS
+#             command.
+#
+#         chanserv/access-xop  [OPTIONAL]
+#             Allows modification of channels' access lists using the SOP,
+#             AOP, and VOP (as well as HOP on servers supporting halfops)
+#             commands.  This module may be used along with the
+#             "chanserv/access-levels" module, but use of the LEVELS
+#             command may cause unexpected behavior with respect to these
+#             commands.
+#
+#     The "operserv/main" and "nickserv/main" modules are REQUIRED for all
+#     ChanServ modules.
+
+LoadModule chanserv/main
+LoadModule chanserv/access-levels
+#LoadModule chanserv/access-xop
+
+###########################################################################
+
+# MemoServ modules  [RECOMMENDED]
+#     These modules provide the ability to send "memos" (short messages) to
+#     users who are offline, which the user can then read at a later time.
+#     Memos may be sent to channels as well, and will be readable by anyone
+#     who has the proper access in the channel.  The base module,
+#     "memoserv/main", provides this functionality.  The following add-on
+#     modules are also available:
+#
+#         memoserv/forward  [OPTIONAL]
+#             Allows users to have their memos mailed to them instead of
+#             storing them in Services' databases.
+#             NOTE: This module requires the "nickserv/mail-auth" module.
+#
+#         memoserv/ignore  [RECOMMENDED]
+#             Allows users to create a list of other users (by nickname or
+#             user@host mask) who are not permitted to send them memos.
+#
+#     The "operserv/main" and "nickserv/main" modules are REQUIRED for all
+#     MemoServ modules.
+
+LoadModule memoserv/main
+LoadModule memoserv/forward
+LoadModule memoserv/ignore
+
+###########################################################################
+
+# StatServ modules  [OPTIONAL]
+#     These modules provide a system to keep track of detailed network
+#     statistics.  Services normally tracks the highest number of users
+#     seen on the network, but StatServ can report on number of servers
+#     online, number of users per server, and other information.  The base
+#     module is "statserv/main"; no add-on modules are currently available.
+
+LoadModule statserv/main
+
+###########################################################################
+
+# HelpServ module  [OPTIONAL]
+#     This module provides an online help system that can serve user-
+#     configurable data.  This is separate from the help messages used by
+#     NickServ, ChanServ, and so on, and simply displays text files from a
+#     directory (specified in modules.conf).  This can be used, for example,
+#     to provide network policy information, contact addresses and the like
+#     in a central location.
+
+LoadModule misc/helpserv
+
+###########################################################################
+
+# DevNull module  [OPTIONAL]
+#     This module creates a pseudoclient which, like its Unix namesake
+#     /dev/null, simply discards all messages sent to it.  This module
+#     serves little purpose other than being a toy of sorts, but the author
+#     has found it occasionally useful as a /query target in ircII to avoid
+#     sending /msg's to the wrong person.
+
+#LoadModule misc/devnull
+
+###########################################################################
+
+# HTTP server modules  [OPTIONAL]
+#     These modules add an HTTP server to Services, which can be used to
+#     report on Services status, perform nickname and channel queries and
+#     maintenance, and so on.  The main module ("httpd/main") provides the
+#     core server functionality; queries and such are handled by
+#     sub-modules, as listed below:
+#
+#         httpd/dbaccess  [OPTIONAL]
+#             Allows access to the Services database (nickname and channel
+#             information, autokill list, ec.) via a web browser.
+#
+#         httpd/debug  [OPTIONAL]
+#             Displays a "debug page" showing the data for the request
+#             received by the server.  Enabling this module does not allow
+#             access to any internal Services data or otherwise cause
+#             security problems, but as it does take up memory and have a
+#             minor impact on performance, it should generally not be
+#             enabled on production systems.
+#
+#         httpd/redirect  [OPTIONAL]
+#             Redirects browsers to URLs associated with nicknames and
+#             channels.  For example, if a nick "SomeNick" had the URL
+#             "http://somenick.org/" registered with NickServ, then
+#             "http://services.example.net/~SomeNick/" would be redirected
+#             to "http://somenick.org/".
+#
+#         http/top-page  [OPTIONAL]
+#             Allows a file or redirect to be served for access to the top
+#             page of the server (http://servername/).
+#
+#     In addition, "authorization modules" are available to limit access
+#     to certain resources.  The following authorization modules are
+#     available:
+#
+#         httpd/auth-ip  [OPTIONAL]
+#             Restricts access to resources based on the client's IP
+#             address.
+#
+#         httpd/auth-password  [OPTIONAL]
+#             Restricts access to resources based on a username and
+#             password.
+#
+#     NOTE: Authorization modules are checked in the order in which they
+#           are loaded, as are ordinary (request handler) modules.
+
+LoadModule httpd/main
+LoadModule httpd/auth-ip
+LoadModule httpd/auth-password
+#LoadModule httpd/dbaccess
+#LoadModule httpd/debug
+#LoadModule httpd/redirect
+#LoadModule httpd/top-page
+
+###########################################################################
+
+# Miscellaneous modules  [OPTIONAL]
+#     These are modules which do not fit easily into any other category:
+#
+#         misc/xml-export
+#             Provides the ability to export the Services database in XML
+#             format.  If this module is loaded, the httpd/dbaccess module
+#             will use it to provide an XML download link.
+#
+#         misc/xml-import
+#             Provides the ability to import data in XML format (such as
+#             another Services database).  If this module is loaded, the
+#             httpd/dbaccess module will use it to provide an XML
+#             download link; note that XML importing via this link may
+#             require the httpd/main RequestBufferSize setting in
+#             modules.conf to be increased.  This module requires the
+#             chanserv/main module to be loaded.
+
+LoadModule misc/xml-export
+LoadModule misc/xml-import
+
+###########################################################################
+
+# End of example-ircservices.conf

data/helpfiles/help

@@ -0,0 +1,13 @@
+HelpServ is a service designed to give out information on
+IRC and Services.  Detailed help for Services can be accessed
+via the HELP commands of the other Services clients:
+
+   /msg NickServ HELP
+        for information on registering nicknames
+
+   /msg ChanServ HELP
+        for information on registering and controlling
+        channels
+
+   /msg MemoServ HELP
+        for information on sending messages to off-line users

docs/1.html

@@ -0,0 +1,348 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual - 1. About IRC Services</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>1. About IRC Services</h2>
+
+<p>1-1. <a href="#1">Introduction</a>
+<br>1-2. <a href="#2">Overview of IRC Services clients</a>
+<br>1-3. <a href="#3">IRC Services download site</a>
+<br>1-4. <a href="#4">IRC Services discussion forums</a>
+<br>1-5. <a href="#5">Credits and acknowledgements</a>
+<br>1-6. <a href="#6">Contacting the author</a>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a> |
+<a href=2.html>Next section: About IRC Services</a></font>
+
+<p><hr>
+
+<a name=1></a>
+<h3>1-1. Introduction</h3>
+
+<p>IRC Services (also called just "Services" for short) is a system of
+services to be used with Internet Relay Chat networks.  Services provides
+for definitive nickname and channel ownership, as well as the ability to
+send messages ("memos") to offline users, and gives IRC operators
+considerably more control over the network.
+
+<p>In particular, Services provides the following features to an IRC
+network:
+
+<p><ul>
+<li><b>Nickname management.</b>  Services allows users to "register"
+nicknames, and will prevent users other than the registrant from using
+them.  Services also maintains information about each registered nickname,
+including the last time the nick's owner was online as well as a URL and
+E-mail address that can be set by the user.
+
+<li><b>Channel management.</b>  Like nicknames, Services allows users to
+register channels as well.  A channel's owner can give privileges to other
+users of the channel, such as auto-opping or the ability to set various
+channel options, or conversely deny other users the ability to obtain
+channel operator privileges or even enter the channel altogether.  Services
+will remember the topic on the channel even after the last user leaves, and
+can automatically set modes on the channel whenever a user joins it.
+
+<li><b>Messages to offline users.</b>  Probably every IRC user has gone
+through the experience of waiting and waiting for someone to come online in
+order to pass a message along or ask a question.  Services alleviates this
+with a "memo" system, allowing users to leave messages for other users even
+if the recipient is not online at the time; the recipient will be notified
+of the memo the next time they log on.
+
+<li><b>Centralized network control.</b>  Services includes features which
+allow IRC operators greater control over the IRC network through a single
+point, and also defines multiple privilege levels for IRC operators with
+respect to Services itself.  For example, IRC operators with sufficient
+privileges can use Services to set modes on any channel; it is also
+possible to ban users or groups of users from connecting to the network
+entirely, and such bans ("autokills" in Services terminology) will remain
+active even if a server, or Services itself, splits from the network.
+</ul>
+
+<p>Furthermore, each of these sets of features can be configured or
+disabled to match individual networks' policies.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=2></a>
+<h3>1-2. Overview of Services clients</h3>
+
+<p>Each of the major feature groups mentioned in <a href="#1">section
+1-1</a> above is controlled through a Services <i>client</i>, a nickname
+associated with that particular set of features.  (These are often called
+"pseudoclients", since they are not true clients, like IRC programs used by
+humans, but conveniences to simplify access to Services' features.)  These
+clients, as well as others which handle smaller areas of network control,
+are briefly described below; a more detailed discussion of each feature is
+presented in <a href=3.html>section 3</a>, while complete information on
+each of the commands used to control each client can be found in
+<a href=4.html>section 4</a>.
+
+<p><b>NickServ</b> handles registration and maintenance of nicknames.  Its
+primary functions include:
+<p>
+<ul><li>registration and de-registration (dropping) of nicknames;
+    <li>verification of nickname users, including password authentication,
+	and removal (either automatically or upon request) of unauthorized
+	users;
+    <li>creation and deletion of nickname aliases (links), which allow a
+	single user to own and switch between multiple nicknames which
+	share settings;
+    <li>control of nickname options, including security level (whether to
+	require a password or simply check the user's username and
+	hostname), associated URL and E-mail address, and what information
+	to show or not show to other users;
+    <li>recording of nickname usage information, including the nickname's
+	last used time and the username and hostname of the nickname's last
+	user; and
+    <li>expiration of nicknames that have not been used in a certain period
+	of time.</ul>
+
+<p>Services has the ability to send messages to users in multiple
+languages; a user who has registered their nickname can select from any of
+the supported languages (English, Dutch, French, German, Hungarian,
+Japanese, Russian, Spanish, and Turkish).  A default language can also be
+configured for users who have not registered their nicknames or have not
+selected a specific language.
+
+<p>Furthermore, NickServ has the ability to verify E-mail addresses
+associated with nicknames, by sending an "authentication code" to the
+E-mail address and not allowing the owner any privileges associated with
+the nickname until the owner sends that authentication code back to
+NickServ.  This feature can help maintain accountability of users for their
+actions on IRC by requiring a valid E-mail address at which the user of a
+nickname can be contacted if problems arise.
+
+<p><b>ChanServ</b> is to channels what NickServ is to nicknames; it handles
+registration and maintenance of channels on the IRC network.  Its functions
+in large part mirror those of NickServ, and include:
+<p>
+<ul><li>registration and dropping of channels (a user who registers a
+	channel is known as the channel's <i>founder</i>);
+    <li>verification of channel users, through either direct password
+	authentication or NickServ verification;
+    <li>control of channel access and autokick lists (see below);
+    <li>monitoring and adjustment of channel modes, including automatically
+	giving channel-operator or voice privileges or "inviting"
+	authorized users into invite-only channels;
+    <li>control of channel options, such as preventing users from changing
+	the topic or controlling the strictness with which channel modes
+	and privileges are enforced, and setting a URL or E-mail address
+	for the channel;
+    <li>recording of channel usage information, including the last time a
+	verified user was in the channel; and
+    <li>expiration of channels that have not been used in a certain period
+	of time.
+</ul>
+
+<p>One major difference between nicknames and channels is the <i>access
+list</i>.  While nicknames may have an "access list" that lists addresses
+which NickServ will recognize as "allowed to use the nickname"&mdash;a
+feature that has little value if passwords are used as the primary means of
+verification&mdash;channel access lists play a much greater role, in that
+they control which users (nicknames) have what degree of access to
+(privileges in) the channel.  The founder of a channel will always have
+full access to the channel, but the founder can, via the access list,
+designate other users who will receive a certain subset of channel
+privileges.  For example, the founder might give privileges to some users
+to automatically receive channel operator (<tt>+o</tt>) status when they
+enter the channel; those users might then, in turn, designate other users
+to automatically receive voice (<tt>+v</tt>) status if the channel is
+moderated.  Certain levels of access also allow users to use privileged
+ChanServ features, such as management of the "autokick list", explained
+below, or commands which remove channel bans on a user or invite the user
+into a channel.
+
+<p>Conversely, the <i>autokick list</i> (often referred to as the "AKICK
+list", from the name of the command&mdash;<tt>AKICK</tt>&mdash;which
+controls it) specifies users which are not to be allowed access to the
+channel at all.  If a user joins a channel whose autokick list they are
+listed on, ChanServ will kick them out of the channel and set a channel ban
+which prevents them from entering again.  Since a malicious user could
+easily enter using an unregistered nickname, channel founders (or other
+privileged users) can enter username/hostname masks as well as nicknames in
+the autokick list.
+
+<p>As channels are complex beasts, ChanServ features many options which
+control how the channel is managed; for example, ChanServ can be set to
+disallow any changes to the channel topic (if a user changes the topic,
+ChanServ will cancel the change by restoring the previous topic), or to
+prevent any users not explicitly entered in the access list from using the
+channel.  ChanServ can also enforce a certain set of modes on a channel;
+for example, a channel which wants to stay hidden from casual users could
+use ChanServ to ensure that the <tt>+s</tt> (secret) mode is always set on
+the channel.
+
+<p>If the founder of a channel loses his nickname, whether by explicitly
+dropping it or by letting it expire, the channel will be dropped as well.
+If this should happen by accident, it can be difficult to restore all of
+the channel settings.  To help avoid this problem, ChanServ allows channel
+founders to designate a <i>successor</i> for the channel.  If the founder's
+nickname should ever be dropped or expire, then ChanServ will give the
+channel to the successor&mdash;making them the new founder of the
+channel&mdash;rather than dropping the channel.
+
+<p><b>MemoServ</b> handles storage and notification of <i>memos</i>, short
+messages between IRC users.  Memos can be thought of as an intermediate
+stage between realtime chat and E-mail; they are sent and read in the same
+way as ordinary chatting, but can be sent even if the recipient is not
+online at the time, and the recipient can read the memos at his or her
+leisure.  Memos are particularly useful for short messages for which it
+would not be worth the time to start up an E-mail client and type out a
+complete message, or for cases where the nickname of the recipient is known
+but the recipient's E-mail address is not (or the recipient does not have
+an E-mail address at all).
+
+<p>MemoServ's four main functions are <i>sending</i> memos, <i>listing</i>
+memos which have been received, <i>reading</i> memos, and <i>deleting</i>
+memos after they have been read.  Users can also set memo options, which
+include whether to notify them of new memos when they log on and whether
+they should be able to receive memos at all, and can have memos
+automatically forwarded to an authenticated E-mail address.
+
+<p>In addition to memos between users, memos can also be sent to channels;
+such memos will be sent to all users with sufficient privileges on the
+channel.  This type of memo can be used, for example, to inform channel
+operators about a problem user, or as a way for users to ask questions
+about the channel.
+
+<p><b>OperServ</b> provides access to the "network control" functionality
+of Services.  Available only to IRC operators, OperServ allows:
+<p>
+<ul><li>broadcasts of messages to the entire network (global notices), as
+	well as recording of news messages to be sent to users when they
+	connect to the network;
+    <li>control of modes in any channel, as well as the ability to kick any
+	user from any channel;
+    <li>banning certain users from the entire network (autokill list and
+	S-lines, described below);
+    <li>limiting the number of users which can connect from a single IP
+	address, useful for preventing "cloning" (sessions), as well as
+	making exceptions to those limits;
+    <li>disconnecting all users from a given IP address;
+    <li>preventing certain servers from connecting to the network
+	("juping");
+    <li>setting global Services options; and
+    <li>restarting or shutting down Services itself.
+</ul>
+
+<p>Many of these functions can, if misused, have disastrous effects for the
+entire network; thus, OperServ implements a privilege system to limit which
+IRC operators can use which functions.  Four different privilege levels are
+defined: normal IRC operator, Services operator, Services administrator,
+and Services super-user (also known as "Services root", from the Unix
+tradition of using the username "root" for the system super-user).  Normal
+IRC operators can use very few of the functions above, while the Services
+super-user has absolute control over Services and the IRC network.
+
+<p>Of particular note are the <i>autokill list</i> and <i>S-line</i>
+features, which are to the network as autokick lists are to channels; users
+in these lists will be prohibited from connecting to any server on the
+network, and will be disconnected immediately if they do connect.  The
+difference between the two is what they prohibit; the autokill list
+prohibits certain combinations of username and hostname, much like autokick
+lists do, while S-lines, named after the commands used by a certain IRC
+server to implement them, prohibit nicknames, "real names", or IP addresses
+(IP address checking is only available with a few IRC servers).
+
+<p>OperServ also includes a separate client, by default called
+<b>Global</b>, which is used to send global (network-wide) notices and news
+messages to users.  Many networks rename this client to the same name as
+their network; the name of the client (as well as all other Services
+clients) can be changed by editing the configuration file, as described in
+<a href="2.html#4">section 2-4</a>.
+
+<p><b>StatServ</b> is an additional client which monitors and keeps basic
+statistical information regarding network usage.  It can be useful to
+check, for example, which servers are getting the most use, or whether
+certain servers have a tendency to split from the network frequently.
+
+<p><b>In addition</b> to the clients above, Services also has a built-in
+HTTP (web) server, which allows access to Services information (such as
+registered nickname and channel information and network statistics) without
+having to connect to the IRC network.  See <a href="3.html#6">section
+3-6</a> for more information about the HTTP server.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=3></a>
+<h3>1-3. IRC Services download site</h3>
+
+<p>Development and maintenance of IRC Services has been discontinued.
+As of the writing of this manual, historical information can be found at
+<a href="http://achurch.org/services/"><tt>http://achurch.org/services/</tt></a>.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=4></a>
+<h3>1-4. IRC Services discussion forums</h3>
+
+<p>Two mailing lists were previously provided for discussion of Services:
+<i>ircservices</i>, for general discussion, and <i>ircservices-coding</i>,
+for technical issues.  These mailing lists were disabled on January 1, 2010,
+but archives of the lists are available at the historical information site
+listed in <a href="#3">section 1-3</a> above.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=5></a>
+<h3>1-5. Credits and acknowledgements</h3>
+
+<p>Services is primarily the work of <a href="http://achurch.org/"><b>Andrew
+Church</b></a>, and was developed from early 1996 through 2009; a somewhat
+more detailed history can be found in <a href="tech/1.html#s3">section 1-3
+of the technical manual</a>.  However, many people have contributed ideas,
+bug reports, or other help to the project as well.  Some of the more
+noteworthy contributors include:
+<ul>
+<li><b>Andrew Kempe</b> (session limiting and news systems, as well as
+	maintenance and development of Services for versions 4.3 and 4.4)
+<li><b>Yusuf Iskenderoglu</b> (Turkish translation and many feature suggestions)
+<li><b>Martin Pels</b> (Dutch translation)
+<li><b>Elijah</b> (French translation)
+<li><b>Jacek Margos</b> and <b>Holger Baust</b> (German translation)
+<li><b>Janos Kapitany</b> and <b>Krisztian Romek</b> (Hungarian translation)
+<li><b>Alexander Zverev</b> (Russian translation)
+<li><b>&lt;RealCFC@chatfirst.com&gt;</b> (Spanish translation)
+</ul>
+Credit is given to all contributions in the
+<tt><a href="Changes">Changes</a></tt> and
+<tt><a href="Changes.old">Changes.old</a></tt> files in this directory,
+which detail all changes made in each version of Services.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=6></a>
+<h3>1-6. Contacting the author</h3>
+
+<p>The author may be contacted via E-mail at
+<tt><a href="mailto:achurch@achurch.org">achurch@achurch.org</a></tt>
+as of the writing of this manual.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a> |
+<a href=2.html>Next section: About IRC Services</a></font>
+
+</body>
+</html>

docs/2.html

@@ -0,0 +1,682 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual - 2. Installing and using Services</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>2. Installing and using Services</h2>
+
+<br>2-1. <a href="#1">System and network requirements</a>
+<br>2-2. <a href="#2">Installing Services from a binary distribution</a>
+<br>2-3. <a href="#3">Installing Services from source code</a>
+<br>2-4. <a href="#4">Configuring Services</a>
+<br>2-5. <a href="#5">Configuring your IRC server</a>
+<br>2-6. <a href="#6">Starting, stopping and controlling Services</a>
+
+<p align=right><font size=-1><a href="1.html">Previous section: About IRC Services</a> |
+<a href="index.html">Table of Contents</a> |
+<a href="3.html">Next section: Overview of Services features</a></font>
+
+<p><hr>
+
+<a name=1></a>
+<h3>2-1. System and network requirements</h3>
+
+<p>In order to run Services, you will need the following:</p>
+
+<p><ul>
+<li><b>A POSIX-compliant operating system.</b>  Services is designed
+for the Linux operating system, but should function on any POSIX-compliant
+(or nearly so) operating system; it is known to work on FreeBSD, OpenBSD,
+and Solaris, and has been reported to work on MacOS X and AmigaOS as well.
+(On AmigaOS, you will need to increase the program stack size using the
+CLI command <tt>STACK</tt>; a stack size of 512k, 524288 bytes, should be
+sufficient.  Services is not supported on Windows, but some users have
+reported success in running it; see <a href="faq.html#A3">FAQ A.3</a>.)
+
+<p><li><b>A supported IRC server</b> (IRCD).  Services supports several
+different types of IRC servers, as listed in Table 2-1 below.  Your IRC
+network must be using one of these servers in order to use Services (the
+"Services module" column indicates which protocol module is used with that
+server; see <a href="#4">section 2-4</a> for details).
+</ul>
+
+<p>Additionally, if you plan to compile Services from the source code, you
+will also need the following (note that these are not necessary if you
+install from a binary package):</p>
+
+<p><ul>
+<li><b><a href="http://www.gnu.org/software/gcc/gcc.html">GCC</a>
+<font size=-1>[<tt>www.gnu.org</tt>]</font> (the GNU C compiler),</b>
+version 3.2 or later.  Services uses some extensions to the C language
+provided by GCC, and is unlikely to compile on other compilers; Services
+also takes advantage of recent additions to the C standard (often referred
+to as "C99") which are not supported by older versions of GCC.
+
+<p><i>Notice: (1)</i> Services will not work with the
+<a href="http://www.trl.ibm.com/projects/security/ssp/">SSP (stack-smashing
+protector)</a> <font size=-1>[<tt>www.trl.ibm.com</tt>]</font> patch to GCC,
+due to a bug in SSP triggered by Services that causes crashes.  The
+<tt>configure</tt> script (see below) will automatically detect the
+presence of this patch and deactivate the stack-protection feature, or
+refuse to compile if it cannot be deactivated.
+
+<p><i>(2)</i> Versions of GCC before 3.4 have bugs which cause Services to
+crash.  Services has workarounds for the Intel x86, SPARC, and PowerPC
+platforms, but you will need to use GCC 3.4 or later on other systems.  See
+<a href="faq.html#B1.5">FAQ B.1.5</a> for details.
+
+<p><li><b><a href="http://www.gnu.org/software/make/make.html">GNU
+make</a> [<font size=-1><tt>www.gnu.org</tt></font>], version 3.79 or
+later.</b>  Services uses complex Makefiles which may or may not work with
+other "make" programs, and are known not to work with earlier versions of
+GNU make.  Note that GNU make may be installed on your system as either
+<tt>make</tt> or <tt>gmake</tt>; if you're not sure, type <tt>make -v</tt>
+or <tt>gmake -v</tt> in your shell, and if you get output that looks like
+"<tt>GNU Make version 3.79.1, by Richard Stallman and Roland McGrath</tt>",
+then it's installed.
+
+<p><li><b>The Bourne shell</b> or a compatible shell.  This is installed on
+most Unix-like systems as <tt>/bin/sh</tt>.  If by any chance the
+<tt>configure</tt> script fails (see <a href="#3">section 2-3</a>), try
+installing <a href="http://www.gnu.org/software/bash/bash.html">Bash</a>
+<font size=-1>[<tt>www.gnu.org</tt>]</font> and using it to run the
+<tt>configure</tt> script.
+
+<p><li><b><a href="http://www.perl.com/">Perl</a>
+<font size=-1>[<tt>www.perl.com</tt>]</font></b> may also be needed if you
+modify certain files (the language data files in particular).
+</ul>
+
+<div align=center>
+<a name=table1></a>
+<b>Table 2-1.</b>  Supported IRC server types<br><br>
+<table border=1>
+<tr><th>IRC server (IRCD) name<th>Services module
+<tr><td><a href="http://bahamut.dal.net/">Bahamut</a>
+	<font size=-1>[<tt>bahamut.dal.net</tt>]</font> 1.8.0 and later
+	<font color=red>(*)</font>
+    <td align=center><tt>bahamut</tt>
+<tr><td>Chunky Monkey IRCD 1.0 and later
+    <td align=center><tt>monkey</tt>
+<tr><td>DALnet (ircd.dal) 4.4.13 and earlier
+    <td align=center><tt>dalnet</tt>
+<tr><td>DALnet (ircd.dal) 4.4.15 and latre
+    <td align=center><tt>dreamforge</tt>
+<tr><td>Dreamforge (ircd.dal 4.6.x)
+    <td align=center><tt>dreamforge</tt>
+<tr><td><a href="http://www.inspircd.org/">InspIRCd</a>
+	<font size=-1>[<tt>www.inspircd.org</tt>]</font> 1.1 and later
+    <td align=center><tt>inspircd</tt>
+<tr><td><a href="http://ircd-hybrid.com/">IRCD-Hybrid</a>
+	<font size=-1>[<tt>ircd-hybrid.com</tt>]</font> 7.0 and later
+	<font color=red>(**)</font>
+    <td align=center><tt>hybrid</tt>
+<tr><td>ircd-2.8.x
+    <td align=center><tt>rfc1459</tt>
+<tr><td>ircd-2.8.x+TS8
+    <td align=center><tt>ts8</tt>
+<tr><td><a href="http://coder-com.undernet.org/">ircu (Undernet)</a>
+	<font size=-1>[<tt>coder-com.undernet.org</tt>]</font> 2.9.x
+    <td align=center><tt>undernet-p9</tt>
+<tr><td><a href="http://www.ptlink.net/Coders/">PTlink IRCd</a>
+	<font size=-1>[<tt>www.ptlink.net</tt>]</font> 6.10.0 and later
+    <td align=center><tt>ptlink</tt>
+<tr><td><a href="http://www.ircd-ratbox.org/">ircd-ratbox</a>
+	<font size=-2>[<tt>www.ircd-ratbox.org</tt>]</font>2.1.x and later
+	<font color=red>(***)</font>
+    <td align=center><tt>ratbox</tt>
+<tr><td><a href="http://www.solid-ircd.com/">solid-ircd</a>
+	<font size=-2>[<tt>www.solid-ircd.com</tt>]</font>, all versions
+	<font color=red>(*)</font>
+    <td align=center><tt>ratbox</tt>
+<tr><td><a href="http://tr-ircd.sourceforge.net/">tr-ircd</a>
+	<font size=-1>[<tt>tr-ircd.sourceforge.net</tt>]</font> 5.7 and
+	later<br>
+    <td align=center><tt>trircd</tt>
+<tr><td><i>UltimateIRCD 2.8.1</i>
+    <td align=center><tt>dreamforge</tt>
+<tr><td><i>UltimateIRCD 3.0.0</i>
+    <td align=center><tt>bahamut</tt>
+<tr><td><a href="http://www.unrealircd.com/">UnrealIRCd</a>
+	<font size=-1>[<tt>www.unrealircd.com</tt>]</font> 3.1.1 and later
+    <td align=center><tt>unreal</tt>
+</table>
+(servers listed in <i>italics</i> are listed based on user reports, but are <b>not supported</b>)
+</div>
+
+<p><font color=red>(*)</font> When using Bahamut or solid-ircd, <b>do
+not</b> configure your server as a "services hub" ("<tt>servtype
+serviceshub</tt>" in the <tt>ircd.conf</tt> file); this setting causes
+Bahamut and solid-ircd to not send certain information needed by Services
+to work correctly.  If Services detects that your server is configured as a
+services hub, it will log a message to that effect and abort.
+
+<p><font color=red>(**)</font> To use Hybrid with Services, you must load
+the <tt>m_tburst.so</tt> module in your server's configuration.  In recent
+versions of Hybrid (at least 7.2.3), this module is compiled automatically;
+in earlier versions, you may need to locate and compile it yourself.  If
+the module is not loaded, Services will refuse to connect to the server.
+
+<p><font color=red>(***)</font> When using ircd-ratbox, make sure to
+include the "<tt>topicburst</tt>" server flag in the <tt>connect</tt> block
+for Services on the remote server; if topic burst support is not enabled,
+Services will refuse to connect to the server.  Also, forced nickname
+changing will be unavailable unless all servers are compiled with the
+"<tt>--enable-services</tt>" option.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=2></a>
+<h3>2-2. Installing Services from a binary distribution</h3>
+
+<p>Binary distributions of Services are provided for Linux systems in the
+popular RPM and .deb formats.  See the <a href="1.html#3">Services home
+page</a> to download the latest binary distribution, then install or
+upgrade it the same way you would for any other package.
+
+<p>Note that executable files in the binary distributions are compiled
+statically; this means that they will work on any modern system regardless
+of version, at the cost of requiring slightly more disk space and runtime
+memory, and requiring an upgrade (or recompile from source) if a bug is
+found in any of the system libraries used by Services.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=3></a>
+<h3>2-3. Installing Services from the source code</h3>
+
+<p>If no binary distribution is available for your platform or you prefer to
+compile Services yourself, you will need to install from the source code.
+Once you have <a href="1.html#3">downloaded the source</a>, you need to:
+
+<p><ol>
+   <li><b>Run the <tt>configure</tt> script.</b>  This script checks what
+type of system you are running and determines what adjustments to the base
+source code are necessary in order to compile.  Certain compile-time
+settings can be set by passing command-line options to the script; the most
+common ones are:
+<ul><li><tt>-ignore-cache</tt> (ignore the results of any previous
+	configuration; use this if your system configuration has changed)
+    <li><tt>-prefix <i>pathname</i></tt> (set default installation location)
+    <li><tt>-use-static-modules</tt> (compile using statically-linked
+	modules, even if dynamic linking is available)
+    <li><tt>-[no-]sorted-lists</tt> (select between sorted nickname/channel
+	lists and unsorted ones; <tt>-sorted-lists</tt> is the default, but
+	on large networks, keeping the lists sorted can slow down Services
+	significantly)
+</ul>
+See Table 2-2 below for a full list of options, which can also be obtained
+with <tt>./configure -help</tt>.  (If you prefer the GNU autoconf
+"<tt>--<i>option</i>[=<i>value</i>]</tt>" format, <tt>configure</tt> will
+accept that as well, <i>e.g.</i> "<tt>--prefix=/usr</tt>".)  Note that
+<tt>configure</tt> will ignore environment variables like <tt>CC</tt> and
+<tt>CFLAGS</tt>; use the appropriate command-line options instead if you
+need to set these yourself.
+
+<p><b>Note on using alternate C compilers:</b> If you specify a particular
+C compiler using the <tt>-cc</tt> option, or if GCC is not installed on
+your system, you will also need to specify any necessary options using the
+<tt>-cflags</tt> option.  In particular, Services uses a feature of C known
+as "pointer aliasing", which is technically forbidden by the C standard but
+necessary for clean programming.  Some compilers attempt to optimize based
+on the assumption that pointer aliasing is not used; if your compiler does
+this, you will need to tell it not to.
+
+<a name="table2-2"></a>
+<div align=center>
+<b>Table 2-2.</b>  Options to the <tt>configure</tt> script<br><br>
+<table border=1>
+<tr><th>Option<th>Description
+
+<tr><th colspan=2>Controlling the <tt>configure</tt> script
+<tr><td><tt>-help</tt>
+    <td>Displays a list of command-line options and their meanings, then
+	exits.
+<tr><td><tt>-ignore-cache</tt>
+    <td>Prevents the cache file from being read.  (The cache file,
+	<tt>config.cache</tt>, is created the first time you run the
+	<tt>configure</tt> script, and saves the results of configuration
+	to speed up the script the next time you run it.)
+
+<tr><th colspan=2>Controlling compilation
+<tr><td><tt>-cc <i>PROGRAM</i></tt>
+    <td>Specifies the C compiler to use, such as <tt>cc</tt> or <tt>gcc</tt>.
+	If this option is given, the ordinary check for a compiler is
+	skipped, and the given compiler is used.  This option also causes
+	the cached values of <tt>CFLAGS</tt> (compiler options) and
+	<tt>LFLAGS</tt> (linker options) to be ignored; these options will
+	revert to the defaults, unless the <tt>-cflags</tt> or
+	<tt>-lflags</tt> options are also given.
+<tr><td><tt>-cflags <i>CFLAGS</i></tt>
+    <td>Specifies command-line options to pass to the compiler when
+	compiling source files.  The default depends on the compiler, but
+	typically includes standard optimization flags, such as <tt>-O2</tt>
+	for GCC.
+<tr><td><tt>-lflags <i>LFLAGS</i></tt>
+    <td>Specifies command-line options to pass to the compiler when linking
+	executable files.  The default is no flags.
+<tr><td><tt>-libs <i>LIBS</i></tt>
+    <td>Specifies any extra libraries to be used when linking the main
+	Services executable, using the linker library options <tt>-L</tt>
+	and <tt>-l</tt>.  Normally there is no need to use this option.
+<tr><td><tt>-os2</tt>
+    <td>Specifies that the system on which Services is being compiled is
+	an OS/2 system.  On such systems, Services may not compile
+	correctly without this switch.
+
+<tr><th colspan=2>Controlling installation
+<tr><td><tt>-program <i>NAME</i></tt>
+    <td>Specifies the name to be used for the executable file (default:
+	<tt>ircservices</tt>).  The configuration file
+	<tt>ircservices.conf</tt> and the <tt>ircservices-chk</tt> script (see
+	<a href="#6-ircservices-chk">section 2-6</a>) will also be renamed
+	to <tt><i>NAME</i>.conf</tt> and <tt><i>NAME</i>-chk</tt>; the
+	installation directories selected by the <tt>-prefix</tt> option
+	(see below) will be changed to match; and the example configuration
+	files will use the given name in the default log, PID, and MOTD
+	files.
+<tr><td><tt>-bindest <i>DIR</i></tt>
+    <td>Specifies the directory to be used for program file installation.
+	The main <tt>ircservices</tt> executable file and the
+	<tt>ircservices-chk</tt> script will be installed in this directory.
+<tr><td><tt>-datdest <i>DIR</i></tt>
+    <td>Specifies the directory to be used for data file installation.  All
+	Services files and subdirectories except the two program files
+	listed above will be installed in this directory.
+<tr><td><tt>-prefix <i>DIR</i></tt>
+    <td>Specifies the directory to be used for installation as a GNU-style
+	installation prefix.  Program files will be installed in
+	<tt><i>DIR</i>/sbin</tt>, and data files will be installed in
+	<tt><i>DIR</i>/lib/ircservices</tt> (or
+	<tt><i>DIR</i>/lib/<i>NAME</i></tt>, where <tt><i>NAME</i></tt> is
+	the executable name given to the <tt>-program</tt> option).  If
+	this option is given, the <tt>-bindest</tt> and <tt>-datdest</tt>
+	options are ignored.
+
+<tr><th colspan=2>Controlling Services features (use <tt>-no-<i>option</i></tt>
+	to disable)
+<tr><td><tt>-use-local-funcs</tt>
+    <td>Forces the use of compatibility functions over system library
+	functions.  Normally, Services will use all system library
+	functions available, except when a bug is detected in one of the
+	functions; if this option is given, Services will instead make use
+	of its own versions of these functions.  This can be useful when
+	debugging Services, or if you suspect a bug in the system libraries.
+<tr><td><tt>-use-static-modules</tt>
+    <td>Forces modules to be compiled statically, even if dynamic modules
+	could be used.  Using static modules results in a larger executable
+	file and more memory usage than using dynamic modules, but may be
+	marginally faster.  On some systems, dynamic modules are not
+	supported, and modules will be compiled statically even if
+	<tt>-no-use-static-modules</tt> is given.
+<tr><td><tt>-sorted-lists</tt>
+    <td>Causes Services to keep the nickname and channel lists sorted; this
+	can cause a performance penalty on large networks.  <b>Enabled by
+	default</b> (use <tt>-no-sorted-lists</tt> to disable).
+<tr><td><tt>-clean-compile</tt>
+    <td>Attempts to compile Services with no compiler warnings; this may
+	cause a slight performance penalty.  <b>Enabled by default</b> (use
+	<tt>-no-clean-compile</tt> to disable).
+<tr><td><tt>-memchecks</tt>
+    <td>Performs extra checks on memory allocation.  This option is
+	intended for debugging only, and causes a significant performance
+	penalty.
+<tr><td><tt>-showallocs</tt>
+    <td>Causes all memory allocation activity to be logged to the Services
+	logfile.  This option is intended for debugging only, and will
+	generate extremely large log files.  This option is ignored unless
+	<tt>-memchecks</tt> is enabled.
+<tr><td><tt>-dumpcore</tt>
+    <td>Causes Services to attempt to write a core file if it crashes.
+	This option can be useful in obtaining a backtrace to aid
+	debugging; however, it prevents Services from shutting down
+	cleanly, so you will not see a "shutting down" notice from Services
+	when it detects a crash.
+
+<tr><th colspan=2>Other options
+<tr><td><tt>-check</tt>
+    <td>Checks whether this script has already been run and whether the
+	cache is up-to-date.  Exits with status 0 if up-to-date, 1 if not.
+	This option is used by the Makefile to ensure that the
+	<tt>configure</tt> script is run before compilation.
+
+</table>
+</div>
+
+<p>When the script starts up, it will first determine the directories in
+which Services should be installed.  These can be specified either through
+the <tt>-bindest</tt>/<tt>-datdest</tt> options or the <tt>-prefix</tt>
+option; if none of these are present, the script will use the same
+directories as when you last ran the script (if you have not run the script
+before or you use the <tt>-ignore-cache</tt> option, the defaults are
+<tt>/usr/local/sbin</tt> for the executable program and
+<tt>/usr/local/lib/ircservices</tt> for the data files).
+
+<p>After setting the installation directories, <tt>configure</tt> will
+check your system and print out status messages as it proceeds.  At the
+end, if no errors occur, it will print out a message telling you to
+proceed with compilation.
+
+<p><li><b>Edit <tt>defs.h</tt> and the <tt>Makefile</tt>, if necessary</b>.
+There are a few settings at the top of these files which can be changed as
+needed.  Usually, however, there is no need to change them, and you can
+proceed directly to compilation.
+
+<p>One case in which you may want to modify a setting is if you run a
+regional network which uses a language other than English as its primary
+language; in this case, you can change the <tt>DEF_LANGUAGE</tt> setting in
+<tt>defs.h</tt> to your local langauge.
+
+<p><li><b>Compile the program.</b>  Run the command <tt>make</tt> (or
+<tt>gmake</tt>, depending on your system) from the top-level directory.
+Compilation time will vary depending on your system; on the author's system
+(Athlon64X2 4400+, 2GB RAM), compiling the entire program takes
+approximately one minute.  If you have a multiple-processor system, you can
+use <tt>make -j<i>N</i></tt> (or <tt>gmake -j<i>N</i></tt>) to compile in
+parallel using <tt><i>N</i></tt> threads, which will significantly reduce
+compilation time.  Parallel compilation is also useful if your system has
+slow I/O (such as disk access), since it lets one compilation run while
+another is waiting for a disk access to complete.
+
+<p><li><b>Install the program and data files.</b>  Run the command <tt>make
+install</tt> (or <tt>gmake install</tt>) and the program and data files
+will be copied to their destinations.  The program file is installed as
+<tt>ircservices</tt> in the program installation directory; the data
+installation directory will contain sample configuration files (see
+<a href="#4">section 2-4</a>), language data files, the
+<a href="5.html#3"><tt>convert-db</tt></a> utility, and (if you compiled
+modules with dynamic linking, which is the default on systems which support
+it) module files.
+
+<p>Note that if you are compiling the program as the same user you will
+install as, you can just use the single command <tt>make install</tt> to
+compile and install in one step.
+
+<p>If you need to install Services to a separate subtree, for example when
+setting up Services in a chroot'd environment, set the
+<tt>INSTALL_PREFIX</tt> variable on the <tt>make</tt> command line.  For
+example, if the installation prefix is set as <tt>/usr/local</tt>, then:
+<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;make install INSTALL_PREFIX=/usr/local/chroot/</tt>
+<br>will install files into <tt>/usr/local/chroot/usr/local/bin</tt> and
+<tt>/usr/local/chroot/usr/local/lib/ircservices</tt>.  (The path given <i>must</i> include a trailing slash.)
+
+</ol>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=4></a>
+<h3>2-4. Configuring Services</h3>
+
+<p>Once Services has been installed, it must be configured for your
+network.  Services uses two text files to control its behavior:
+<tt>ircservices.conf</tt> and <tt>modules.conf</tt>.  (If Services is
+configured with a different program name, the first file's name will
+change to <tt><i>program-name</i>.conf</tt> as well; however, in this
+manual, the default of <tt>ircservices.conf</tt> is assumed.)
+<tt>ircservices.conf</tt> contains settings that affect Services as a
+whole, such as the remote server to connect to; <tt>modules.conf</tt>
+contains settings that apply to individual modules, such as NickServ and
+ChanServ.  These files are stored in the Services data directory (the
+directory you gave when running the <tt>configure</tt> script; this is
+<tt>/var/opt/ircservices</tt> for the binary distributions).
+
+<p>When Services is installed, two sample files,
+<tt>example-ircservices.conf</tt> and <tt>example-modules.conf</tt>, are
+installed in the data directory.  If you are installing Services for the
+first time, you should start out by copying or renaming these files to
+<tt>ircservices.conf</tt> and <tt>modules.conf</tt> respectively.  Each file
+contains detailed information about all possible settings, which can also
+be found in <a href=a.html>Appendix A</a>.  When setting up Services for
+the first time, you should at least check these settings:
+
+<div align=center>
+<b>Table 2-3.</b>  Commonly used configuration directives<br><br>
+<table border=1>
+<tr><th>File<th>Setting and syntax<th>Description
+<tr><td><tt>ircservices.conf</tt>
+    <td><tt>RemoteServer <i>host</i>[:<i>port</i>] <i>password</i></tt>
+    <td>Sets the server to which Services connects and the password used to
+	connect.
+<tr><td><tt>ircservices.conf</tt>
+    <td><tt>ServerName <i>name</i></tt>
+    <td>Sets the server name Services will use on the IRC network.
+<tr><td><tt>ircservices.conf</tt>
+    <td><tt>ServerDesc <i>description</i></tt>
+    <td>Sets the server description provided by Services.
+<tr><td><tt>ircservices.conf</tt>
+    <td><tt>ServiceUser <i>user</i>@<i>host</i></tt>
+    <td>Sets the username and hostname used by Services clients.  You may
+	want to set this to an E-mail address at which users can ask
+	questions about Services or your IRC network.
+<tr><td><tt>ircservices.conf</tt>
+    <td><tt>LoadModule <i>module-name</i></tt>
+    <td>Loads the specified module.  The example configuration file lists
+	all of the possible modules; select which ones you want to load or
+	not load.  In particular, make sure you select the correct protocol
+	module and enter its name in the line which reads
+	"<tt>LoadModule protocol/(insert protocol name here)</tt>"
+	or Services will not be able to start.
+<tr><td height=3>
+<tr><td><tt>modules.conf</tt>
+    <td><tt>Module protocol/<i>protocol-name</i></tt>
+    <td>Change this line (the first <tt>Module</tt> line in the file) so it
+	contains the same protocol module you specified in
+	<tt>ircservices.conf</tt>.
+<tr><td><tt>modules.conf</tt>
+    <td><tt>FromAddress <i>user</i>@<i>host</i></tt>
+    <td><tt>mail/main</tt> module:  Sets the E-mail address used as the
+	sender on outgoing mail.  Set this to an address at which users can
+	contact you with questions about Services.
+<tr><td><tt>modules.conf</tt>
+    <td><tt>FromName "<i>name</i>"</tt>
+    <td><tt>mail/main</tt> module:  Set this to the "name" you want to use
+	as the sender on outgoing mail.  If you don't want a name (just the
+	E-mail address), leave this setting commented out.
+<tr><td><tt>modules.conf</tt>
+    <td><tt>ServicesRoot <i>nick</i></tt>
+    <td><tt>operserv/main</tt> module:  Set this to the nickname which
+	should be granted Services root (super-user) privileges.
+<tr><td><tt>modules.conf</tt>
+    <td><tt>ListenTo <i>address</i>:<i>port</i></tt>
+    <td><tt>httpd/main</tt> module:  Sets the ports to which the Services
+	HTTP server will listen.  See <a href="3.html#6">section 3-6</a>
+	for details.
+</table>
+</div>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=5></a>
+<h3>2-5. Configuring your IRC server</h3>
+
+<p>The IRC server to which Services will connect must be configured to
+allow Services to connect as a server.  For traditional irc2-based servers,
+this involves adding appropriate <tt>C:</tt> and <tt>N:</tt> lines to the
+server's configuration file; consult your IRC server program's
+documentation for details.
+
+<p>Some IRC server programs, including traditional irc2-based ones, do not
+allow servers to introduce other servers, <i>i.e.</i> act as hubs, without
+a special configuration setting (an <tt>H:</tt> line in irc2-based
+servers).  If this setting is missing from any server in your network,
+Services may be disconnected when you use the
+<a href="4.html#oper.jupe"><tt>JUPE</tt></a> command.
+
+<p>In addition, some server programs support a "U-line" or similar concept,
+allowing servers named in a <tt>U:</tt> line or other configuration
+directive to override normal privilege checks (and consequently preventing
+other servers from overriding those checks).  If your server program has
+such an option, ensure that it is set on all servers in your network, or
+you may encounter problems such as ChanServ being unable to change channel
+modes.
+
+<p>Also see the notes in <a href="#table1">table 2-1</a> above for special
+considerations when configuring particular types of IRC servers.
+
+<p><hr>
+
+<a name=6></a>
+<h3>2-6. Starting, stopping and controlling Services</h3>
+
+<p>Services can be started by simply running the <tt>ircservices</tt>
+program from a shell prompt.  Upon starting, Services will parse its
+command-line arguments and the <tt>ircservices.conf</tt> file, then open
+the log file; if there are no errors, it will then print a short message to
+the terminal, put itself in the background and return control to the shell.
+If an error does occur, Services will print an error message and exit.
+
+<p>Several command-line options can be used to modify Services' behavior or
+override settings in the <tt>ircservices.conf</tt> configuration file; these
+are summarized in table 2-4 below.  The command-line option <tt>-help</tt>
+can be used to get a list of all available options.
+
+<div align=center>
+<b>Table 2-4.</b>  <tt>ircservices</tt> command-line options<br><br>
+<table border=1>
+<tr><th>Option<th>Meaning
+<tr><td><tt>-help</tt>
+    <td>Prints a list of available options.
+<tr><td><tt>-dir=<i>pathname</i></tt>
+    <td>Uses <tt><i>pathname</i></tt> as the data directory instead of the
+	compiled-in default.
+<tr><td><tt>-remote=<i>host</i>[:<i>port</i>]</tt>
+    <td>Connects to the specified server, overriding the
+	<tt>RemoteServer</tt> setting in <tt>ircservices.conf</tt>.
+<tr><td><tt>-log=<i>filename</i></tt>
+    <td>Writes logging information to <tt><i>filename</i></tt>, overriding
+	the <tt>LogFilename</tt> setting in <tt>ircservices.conf</tt>.
+<tr><td><tt>-debug</tt>
+    <td>Starts Services in debug mode; using this option multiple times
+	will produce more debugging output.
+<tr><td><tt>-readonly</tt>
+    <td>Starts Services in read-only mode; database and log files will not
+	be written to, and online data modification will be limited to
+	Services administrators.
+<tr><td><tt>-nofork</tt>
+    <td>Prevents Services from forking (going into the background) after
+	initialization, and causes log messages to be written to the
+	terminal as well as the log file.
+<tr><td><tt>-noexpire</tt>
+    <td>Disables expiration of database entries (nicknames, channels,
+	autokills, and so on).
+<tr><td><tt>-noakill</tt>
+    <td>Disables autokill checking.  (However, the autokill list itself can
+	still be modified.)
+<tr><td><tt>-forceload</tt>
+    <td>When using the <tt>database/version4</tt> module, attempts to load
+	as much data from corrupted databases as possible, rather than
+	aborting when an error is found.
+<tr><td><tt>-encrypt-all</tt>
+    <td>Re-encrypts all passwords on startup using the encryption type
+	selected in <tt>ircservices.conf</tt>.  (Passwords encrypted with
+	one type generally cannot be re-encrypted with a different type, so
+	this is generally useful only to ensure that no passwords are left
+	unencrypted after activating encryption.)
+<tr><td><tt>-import=<i>filename</i></tt>
+    <td>Imports data into Services' databases (see <a href="5.html#2">section
+	5-2</a>).
+</table>
+</div>
+
+<p>Once in the background, Services will load language files and modules,
+then try to connect to the remote server specified in <tt>ircservices.conf</tt>
+(or on the command line).  If any errors occur during these steps, an error
+message will be printed to the log file and Services will terminate.  If
+Services appears to start up correctly but does not connect to your IRC
+network, check the log file for any errors that may have occurred.
+
+<p>Once Services successfully connects to your IRC network, it will
+continue running until either:
+<ul><li>the remote server closes the connection (for example, because of a
+	<tt>/SQUIT</tt> command);
+    <li>an OperServ <a href="4.html#oper.restart"><tt>RESTART</tt></a>,
+	<a href="4.html#oper.shutdown"><tt>SHUTDOWN</tt></a>, or
+	<a href="4.html#oper.quit"><tt>QUIT</tt></a> command is received; or
+    <li>a termination signal (<tt>SIGINT</tt> [<tt>^C</tt>],
+	<tt>SIGQUIT</tt>, <tt>SIGTERM</tt>, or <tt>SIGKILL</tt>, as well as
+	fatal program errors) is received.
+</ul>
+In any of these cases (except in the case of a <tt>SIGKILL</tt> signal,
+which Services cannot detect), an appropriate message will be written to
+the log file describing why Services terminated.
+
+<p>The debug output level and read-only setting can be modified while
+Services is running using the OperServ
+<a href="4.html#oper.set"><tt>SET</tt></a> command as needed, and other
+OperServ commands can be used to monitor the status of Services or (as
+mentioned above) shut down or restart Services.
+
+<p>While it is running, Services will periodically save modified data
+(newly registered nicknames and channels, modified settings, and so on) to
+disk.  This is done in such a way that even if Services crashes while
+writing the data, the previous contents of the databases will remain intact.
+However, should the database files become corrupt (whether because of a bug
+in Services or as the result of hardware failure or tampering), the
+<tt>-forceload</tt> command-line option can be used to recover as much data
+as possible from the corrupted data file.  It is also <b>strongly
+recommended</b> that you make regular backups of your data files, to reduce
+potential damage from such problems.
+
+<p>If the contents of the <tt>ircservices.conf</tt> or <tt>modules.conf</tt>
+configuration files are changed, Services can be instructed to reread the
+files with either the OperServ
+<a href="4.html#oper.rehash"><tt>REHASH</tt></a> command or the
+<tt>SIGHUP</tt> signal.  If no errors are found in the configuration files,
+Services' settings will be updated with the new configuration file
+contents.  Modules can also be loaded and unloaded this way without
+restarting Services by adding or removing <tt>LoadModule</tt> directives in
+<tt>ircservices.conf</tt>; however, modules will not be able to be unloaded
+if other loaded modules depend on them.  (For example, since the ChanServ
+module depends on NickServ being available, you cannot remove the NickServ
+module while leaving the ChanServ module loaded.  You can, however, unload
+both of them at once.)
+
+<a name="6-ircservices-chk"></a>
+<p>If the system Services runs on supports periodic execution of programs,
+such as via the <tt>cron</tt> utility, you can use the supplied script
+<tt>ircservices-chk</tt>, installed in the same directory as the
+<tt>ircservices</tt> executable, to ensure that Services comes back up
+quickly if it should crash or otherwise terminate unexpectedly.  (Of
+course, you will need to disable this check if you ever shut down Services
+intentionally!)  On a typical Unix system, the following line, when added
+using the <tt>crontab</tt> utility, will cause the <tt>ircservices-chk</tt>
+script to be run once every five minutes (here,
+<tt>/path/to/ircservices-chk</tt> represents the full path to the
+<tt>ircservices-chk</tt> script):
+
+<div align=center>
+<blockquote>
+<tt>0,5,10,15,20,25,30,35,40,45,50,55 * * * *&nbsp;&nbsp;&nbsp;&nbsp;/path/to/ircservices-chk</tt>
+</blockquote>
+</div>
+
+<p>If you need to pass options to the <tt>ircservices</tt> executable,
+simply add them after <tt>ircservices-chk</tt> in the line above.  You can
+also prevent the script from generating output (which would be sent to you
+by mail) by adding the <tt>-q</tt> option after <tt>ircservices-chk</tt>
+and before any other options.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<p align=right><font size=-1><a href="1.html">Previous section: About IRC Services</a> |
+<a href="index.html">Table of Contents</a> |
+<a href="3.html">Next section: Overview of Services features</a></font>
+
+</body>
+</html>

docs/5.html

@@ -0,0 +1,670 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual - 5. Importing and exporting databases</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>5. Importing and exporting databases</h2>
+
+<p>5-1. <a href="#1">Exporting Services databases in XML format</a>
+<br>5-2. <a href="#2">Importing (merging) data from an XML file</a>
+<br>5-3. <a href="#3">Converting data from other Services-like programs</a>
+<br>&nbsp;&nbsp;&nbsp;&nbsp;5-3-1. <a href="#3-1">Using the
+	<tt>convert-db</tt> program</a>
+<br>&nbsp;&nbsp;&nbsp;&nbsp;5-3-2. <a href="#3-2">Notes on converting
+	databases from particular programs</a>
+
+<p align=right><font size=-1><a href=4.html>Previous section: Services command reference</a> |
+<a href=index.html>Table of Contents</a></font>
+
+<p><hr>
+
+<a name=1></a>
+<h3>5-1. Exporting Services databases in XML format</h3>
+
+<p>In order to facilitate processing of the Services databases by other
+programs, Services provides the ability to export the databases in XML
+format.  This is accomplished through the <tt>misc/xml-export</tt> module
+and, optionally, the <a href="3.html#6">HTTP server</a> built into
+Services.
+
+<p>The <tt>misc/xml-export</tt> module adds an extra command-line option,
+<tt>-export</tt>, to Services.  Since the command line is parsed before
+Services connects to the network, the module must be specified in your
+<tt>ircservices.conf</tt> file to enable this option.  The option has the
+format "<tt>-export</tt>" or "<tt>-export=<i>filename</i></tt>", where
+<tt><i>filename</i></tt> is the name of the file to write the XML data to;
+if it does not begin with a slash, it is taken to be relative to the
+Services data directory (the directory containing the database and log
+files).  If <tt><i>filename</i></tt> is not given or is a single hyphen
+("<tt>-</tt>"), the data will be printed on standard output.  When the
+export completes, Services will terminate without connecting to the IRC
+network.  This action can be performed while another copy of Services is
+running, but the output will not include changes made online since the
+last time the databases were saved to disk.  (It is also possible for the
+running copy of Services to report a "data directory locked" error if it
+tries to save the databases while the export operation is in progress.
+This is harmless; you can force the databases to be written after the
+export completes by using the OperServ
+<a href="4.html#oper.update"><tt>UPDATE</tt></a> command, but do not use
+the <tt>FORCE</tt> option while the export is still running as this may
+result in corrupted database files.)
+
+<p>Additionally, if the <tt>misc/xml-export</tt> module is loaded into
+Services, the HTTP database access module (<tt>httpd/dbaccess</tt>) will
+display an "XML database download" link.  Clicking on the link will display
+the XML data in your browser, which you can then save (for Firefox and
+Internet Explorer, select "Save as..." or "Save page as..." from the
+browser's File menu).  Alternatively, you can download the link directly
+without displaying it in your browser; in Firefox, hold the Alt key while
+clicking on the link, and in Internet Explorer, right-click on the link and
+select "Save target as..." from the pop-up menu.
+
+<p>The format of the exported XML data is described in
+<a href=b.html>Appendix B</a>.
+
+<p><b>Notes:</b> Services will not respond to any network activity while you
+are downloading the database.  If you have a large database, this can make
+Services appear to "freeze" with respect to the IRC network, and it may
+even get disconnected from the network in extreme cases.  Additionally, be
+aware that the data may change after you have downloaded it; if you want to
+avoid this, for example when exporting data to move it to another machine
+or network, use the command-line option <tt>-export</tt> (after shutting
+Services down) rather than the HTTP server interface.
+
+<p><b>Note to Internet Explorer users:</b>  Some versions of Internet
+Explorer have a bug which can prevent the XML data from being displayed or
+downloaded properly.  If you have this problem, use another browser, or add
+the following key to your registry using the Registry Editor
+(<tt>regedit</tt>), as described in Microsoft Knowledge Base article
+<a href="http://support.microsoft.com/default.aspx?scid=kb;EN-US;q239750">Q239750</a>
+<font size=-1>[<tt>support.microsoft.com</tt>]</font>:
+<div align=center><table border=0>
+<tr><td align=right>Key:<td>&nbsp;
+    <td><tt>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet&nbsp;Settings</tt>
+<tr><td align=right>Value&nbsp;name:<td>&nbsp;<td><tt>IsTextPlainHonored</tt>
+<tr><td align=right>Value&nbsp;type:<td>&nbsp;<td><tt>DWORD</tt>
+<tr><td align=right>Value&nbsp;data:<td>&nbsp;<td><tt>HEX 0x1</tt>
+</table></div>
+Improper use of the Registry Editor can cause your system to malfunction,
+so be careful when making any changes.  You may also need to upgrade your
+system files as described in the Knowledge Base article linked to above
+if you are using Windows 95, Windows 98, or Windows NT 4.0.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=2></a>
+<h3>5-2. Importing (merging) data from an XML file</h3>
+
+<p>Just as it can export data in XML format, Services can also read in XML
+data and import (merge) it into its databases.  Importing is handled by the
+<tt>misc/xml-import</tt> module.  Unlike exporting, however, importing
+cannot be done via the HTTP server; it is always done through the command
+line.  For this reason, the <tt>misc/xml-import</tt> module must be loaded
+at startup if it is to be used, rather than via an OperServ
+<a href="4.html#oper.rehash"><tt>REHASH</tt></a> or a <tt>SIGHUP</tt>
+signal.
+
+<p>To import a set of data stored in XML format into Services, start
+Services with the command-line option "<tt>-import=<i>filename</i></tt>",
+where <tt><i>filename</i></tt> is the name of the file containing the data;
+if the filename does not begin with a slash, it is taken to be relative to
+the Services data directory.  Services will parse the data file, and if no
+errors are found, the data will be merged into Services' databases and the
+program will terminate.  If problems are found, they will be printed on
+standard output and the databases will not be modified.
+
+<p>Normally, if nickname or channel "collisions" occur&mdash;that is, if a
+nickname or channel in the input data is already registered in Services'
+databases&mdash;Services will skip over that nickname group or channel,
+respectively.  (For nicknames, the entire nickname group is skipped to
+prevent cases where, for example, a user's secondary nick is available but
+the primary nick is registered to someone else.)  This behavior can be
+modified by the
+<a href="a.html#misc/xml-import.OnNicknameCollision"><tt>OnNicknameCollision</tt></a> and
+<a href="a.html#misc/xml-import.OnChannelCollision"><tt>OnChannelCollision</tt></a>
+options in <tt>modules.conf</tt>.  Additionally, Services can be made to
+output a list of all data imported by setting the
+<a href="a.html#misc/xml-import.VerboseImport"><tt>VerboseImport</tt></a>
+option (which is set in the example <tt>modules.conf</tt> provided with
+Services).
+
+<p>Note that the maximum user count and OperServ
+<a href="4.html#oper.su"><tt>SU</tt></a> password will not be imported;
+news items will not be imported unless the
+<a href="a.html#misc/xml-import.ImportNews"><tt>ImportNews</tt></a> option
+(in <tt>modules.conf</tt>) is set.  Also, any autokills, autokill
+exclusions, session limit exceptions, or S-lines which collide with those
+in the database will be automatically skipped.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=3></a>
+<h3>5-3. Converting data from other Services-like programs</h3>
+
+<a name=3-1></a>
+<h4>5-3-1. Using the <tt>convert-db</tt> program</h4>
+
+<p>For users of other Services-like programs who want to switch to IRC
+Services, a program called <tt>convert-db</tt> is supplied to convert
+databases used by such programs into XML data files, which can then be
+imported into Services as described in <a href="#2">section 5-2</a> above.
+This program is installed into the Services data directory
+(<tt>/var/opt/ircservices</tt> for binary distributions,
+<tt>/usr/local/lib/ircservices</tt> by default for source distributions).
+
+<p>In its simplest form, <tt>convert-db</tt> takes the pathname of the
+directory containing the database files to convert on the command line,
+and writes the converted XML data to standard output.  A typical invocation
+might look like this:
+<blockquote>
+	<tt>convert-db /usr/local/lib/<i>someprogram</i> &gt; <i>someprogram</i>.xml</tt>
+</blockquote>
+<tt>convert-db</tt> will look at the files in the directory given and
+attempt to determine automatically what program created them; if this
+succeeds, it will proceed to read in the database files and convert them to
+XML.  If <tt>convert-db</tt> cannot determine what program created the
+files, you can tell it explicitly by adding a <tt>+<i>program-name</i></tt>
+option in front of the path name (see the full syntax description below for
+valid values for <tt><i>program-name</i></tt>).
+
+<p>Note that not all features of all programs are supported by Services,
+and some settings may be lost when you import data.  See
+<a href="#3-2">section 5-3-2</a> below for notes on particular programs,
+and <a href="#2">section 5-2</a> for information on importing the converted
+data into Services.
+
+<p>The full syntax for <tt>convert-db</tt> is as follows:
+<blockquote>
+	<tt>convert-db [-v] [+<i>program-name</i>] [<i>options</i></tt> . . . <tt>] <i>pathname</i></tt>
+</blockquote>
+The options and parameters are:
+<ul>
+<li><tt>-v</tt>: Display progress information as the data is converted.
+<li><tt>+<i>program-name</i></tt>: Explicitly indicates what program was
+	used to create the data files.  A list of possible
+	<tt><i>program-name</i></tt> values is given in table 5-1 below.
+	<tt><i>program-name</i></tt> values are not case sensitive.
+<li><tt><i>options</i></tt>: Additional options specific to each type of
+	data file controlling details of the data conversion; see below.
+<li><tt><i>pathname</i></tt>: Specifies the pathname of the directory
+	containing the database files.
+</ul>
+
+<div align=center>
+<b>Table 5-1.</b>  Values for <tt>+<i>program-name</i></tt> parameter to
+	<tt>convert-db</tt><br><br>
+<table border=1>
+<tr><th><tt><i>program-name</i></tt>
+    <th>Name&nbsp;of&nbsp;program
+    <th>Supported&nbsp;versions
+<tr><td><tt>anope</tt>
+    <td><a href="http://www.anope.org/">Anope Services</a>
+	<font size=-1>[<tt>www.anope.org</tt>]</font>
+    <td>All versions
+<tr><td><tt>auspice</tt>
+    <td>Auspice Services
+    <td>2.5 and later
+<tr><td><tt>bolivia</tt>
+    <td>Bolivia IRC Services
+    <td>1.2.0
+<tr><td><tt>cygnus</tt>
+    <td><a href="http://www.habber.net/services/index.php">Cygnus</a>
+	<font size=-1>[<tt>www.habber.net</tt>]</font>
+    <td>0.2.0
+<tr><td><tt>daylight</tt>
+    <td>Daylight
+    <td>12
+<tr><td><tt>epona</tt>
+    <td>Epona IRC Services
+    <td>1.3.0 and later
+<tr><td><tt>hybserv</tt>
+    <td><a href="http://www.hybserv.net/">HybServ</a>
+	<font size=-1>[<tt>www.hybserv.net</tt>]</font>
+    <td>All 1.x versions
+<tr><td><tt>ircs-1.2</tt>
+    <td>Internet Relay Chat Services (IRCS)
+    <td>1.2, 1.3
+<tr><td><tt>magick-1.4</tt>
+    <td>Magick IRC Services (Magick I)
+    <td>1.4
+<tr><td><tt>ptlink</tt>
+    <td><a href="http://sourceforge.net/projects/ptlinksoft/">PTlink
+	Services</a> <font size=-1>[<tt>sourceforge.net</tt>]</font>
+    <td>2.13.0 through 2.26-eol.1
+<tr><td><tt>sirv</tt>
+    <td><a href="http://www.sirv.net/">SirvNET Services</a>
+	<font size=-1>[<tt>www.sirv.net</tt>]</font>
+    <td>2.9.0 and earlier
+<tr><td><tt>trircd-4.26</tt>
+    <td>trircd IRC Services
+    <td>4.26
+<tr><td><tt>wrecked-1.2</tt>
+    <td>WreckedNet IRC Services
+    <td>1.2.0
+</table>
+</div>
+
+<p>Note that the following programs and versions are <i>not</i> supported,
+because they do not store data in standard disk files:
+<ul>
+<li>Anope 1.7.11 and later, when using MySQL databases (a standard file
+	format is still available as of version 1.7.19)
+<li>PTlink Services 3.0.0 and later
+</ul>
+
+<p>Additional options are available for the following data file types:
+
+<p><b><tt>anope</tt></b>
+<ul>
+<li><tt>-ircd=<i>protocol</i></tt>: Selects the protocol to use for
+	interpreting channel modes.  By default, only basic channel modes
+	(<tt>+i</tt>, <tt>+k</tt>, <tt>+l</tt>, <tt>+m</tt>, <tt>+n</tt>,
+	<tt>+p</tt>, <tt>+s</tt>, and <tt>+t</tt>) will be imported for
+	channel mode locks; to import extended modes provided by particular
+	specify the corresponding protocol from the following list (for
+	Anope 1.7.6 and later, use the same name as in the
+	<tt>IRCDModule</tt> configuration directive):
+	<ul>
+		<li><tt>bahamut</tt> for Bahamut
+		<li><tt>dreamforge</tt> for Dreamforge
+		<li><tt>hybrid</tt> for IRCD-Hybrid
+		<li><tt>ptlink</tt> for PTlink IRCd
+		<li><tt>ultimate2</tt> for UltimateIRCD 2.x
+		<li><tt>ultimate3</tt> for UltimateIRCD 3.x
+		<li><tt>unreal</tt> for UnrealIRCd
+		<li><tt>viagra</tt> for Viagra IRCd
+	</ul>
+<li><tt>-encryption=<i>type</i></tt>: Selects the encryption type for
+	databases from Anope 1.7.18 and later.  These versions of Anope do
+	not record the encryption type used with passwords stored in the
+	databases; in order to use such passwords, you must specify the
+	proper encryption type with this option:
+	<ul>
+		<li><tt>none</tt>: No encryption (<tt>enc_none</tt> module)
+		<li><tt>md5</tt>: MD5 encryption (<tt>enc_md5</tt>,
+			<tt>enc_old</tt> modules)
+		<li><tt>sha1</tt>: SHA-1 encryption (<tt>enc_sha1</tt>
+			module)&mdash;<i>not supported</i> by Services
+			(passwords will be converted correctly, but will
+			not be usable without a third-party module)
+	</ul>
+	<b>Note:</b> If you use this option and your database contains a
+	mix of encrypted and unencrypted passwords from Anope 1.7.17 or
+	earlier, some of the passwords will not work.
+</ul>
+
+<p><b><tt>cygnus</tt></b>
+<ul>
+<li><tt>-tzfile=<i>filename</i></tt>: Specifies an alternative time zone
+	file to use when loading nickname time zone data.  <tt>convert-db</tt>
+	defaults to the data from the <tt>cygnus.zone</tt> file distributed
+	with Cygnus 0.2.0; if you have modified this file or created your
+	own time zone list, you will need to use this option to get nickname
+	time zones converted correctly.
+<li><tt>-no-timezones</tt>: Causes all nickname time zone settings to be
+	reset to default (the time zone Services runs in).
+<li><tt>-reset-memo-limits</tt>: Causes all nickname memo limits to be reset
+	to default; see the notes on Cygnus database conversion.
+</ul>
+
+<p><b><tt>hybserv</tt></b>
+<ul>
+<li><tt>-crypt</tt>: Indicates that all passwords are encrypted.  Without
+	this option, all passwords are assumed to be in plain text.
+</ul>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<a name=3-2></a>
+<h4>5-3-2. Notes on converting databases from particular programs</h4>
+
+<p>Note that this is not a comprehensive list of differences; only the
+major differences and types of data that cannot be converted are listed.
+
+<p><b>All programs</b>
+<ul>
+<li>The setter and reason for a forbidden nickname or channel will not be
+	imported.
+<li>Channel privilege level settings (the equivalent of the ChanServ
+	<tt>LEVELS</tt> command), on programs that support them, will not
+	be imported; all channels' privilege levels will be reset to the
+	default values.
+<li>Services does not record the setter and last used time for channel
+	access entries; this data will be lost on conversion for programs
+	that do record it.
+<li>Services does not support "bots" or a "BotServ", and all such data will
+	be lost on conversion.
+</ul>
+
+<p><b>Anope</b>
+<ul>
+<li>For version 1.7.11 and later, databases must be stored using the
+	standard ("FFF") format; MySQL databases are not supported.
+<li>Anope versions through 1.7.17 contain the MD5 encryption bug present
+	in versions of IRC Services before 4.5; as a result, encrypted
+	passwords will not work by default.  As a workaround, you can
+	enable the
+	<a href="a.html#encryption/md5.EnableAnopeWorkaround"><tt>EnableAnopeWorkaround</tt></a>
+	configuration option for the <tt>encryption/md5</tt> module in
+	<tt>modules.conf</tt>, but be aware that this may reduce the
+	security of your passwords.  There are also rare cases in which
+	passwords may be truncated in the databases; if you encounter such
+	a case, the password will have to be changed manually by a Services
+	administrator.</li>
+<li>Services does not store the following information; it will be lost when
+	the databases are converted:
+    <ul>
+	<li>ICQ number for nicknames
+	<li>Last used time for channel access entries
+    </ul>
+<li>The NickServ <tt>SET AUTOOP OFF</tt> option present in Anope 1.7.15 and
+	later is converted to <tt>SET NOOP ON</tt>; however, the behavior
+	in of <tt>NOOP</tt> in Services is slightly different, as it only
+	prevents the nickname from being added to channel access lists (the
+	nickname will still be auto-opped if it already has that privilege
+	in a channel).
+<li>Services does not allow multiple users to have Services super-user
+	privileges (except temporarily with the
+	<a href="4.html#oper.su"><tt>SU</tt></a> command); all users with
+	"root" privileges in Anope will be converted to Services
+	administrators.
+<li>Services does not distinguish between using the ChanServ <tt>OP</tt>,
+	<tt>VOICE</tt>, and related commands on oneself or on other users;
+	both operations use the same privilege level.
+<li>Services does not support the ChanServ <tt>SECUREFOUNDER</tt>,
+	<tt>SIGNKICK</tt>, or <tt>XOP</tt> settings.  (<tt>XOP</tt>-style
+	commands can be enabled for all channels by loading the
+	<tt>chanserv/access-xop</tt> module.)
+<li>Nickname requests (nicknames which have been registered but not
+	confirmed via E-mail) are discarded; users with pending nickname
+	requests will need to re-register.
+</ul>
+
+<p><b>Auspice</b>
+<ul>
+<li>The NickServ <tt>NOOP</tt> option behaves slightly differently in
+	Services: it prevents the nickname from being added to channel
+	access lists, but the nickname will still be auto-opped if it
+	already has that privilege in a channel.
+<li>The ChanServ <tt>TIMEOP</tt> feature in version 2.6 and later is not
+	supported.  Nicknames on a channel's <tt>TIMEOP</tt> list will not
+	be added to the channel's access list for Services, and thus will
+	have no privileges on the channel.
+<li>Services does not support "root" and "master" privilege levels as in
+	Auspice.  There can only be one root nickname, which is set in
+	<tt>modules.conf</tt>; all root/master settings in the data files
+	will be discarded.  (Admin/oper settings will be retained.)  Note
+	that Services admins can perform any function (except modifying the
+	admin list), including modifying Services settings and shutting
+	down Services.
+<li>NickServ <tt>AUTH</tt>, <tt>COMMENT</tt>, <tt>NOTE</tt>, <tt>LOCK</tt>,
+	<tt>MARK</tt>, <tt>SET KILL HIGH</tt>, <tt>SETFLAG AUTOJOIN</tt>,
+	and <tt>SETMLOCK</tt>, as well as ChanServ <tt>BADWORDS</tt>,
+	<tt>FREEZE</tt>, and <tt>MARK</tt>, are not supported.  Nickname
+	notes will be converted to non-expiring memos with the user
+	themselves as the sender; other data will be lost.
+<li>Services uses a different news system than Auspice; network and channel
+	news items will not be converted.
+<li>Aside from the above, Services does not store the following
+	information; it will be lost when the databases are converted:
+    <ul>
+	<li>UIN, age, and gender for nicknames
+	<li>Last <tt>GETPASS</tt> user and <tt>HOLD</tt> setter and reason
+	    for channels
+    </ul>
+<li>E-mailing of log files is not supported.
+</ul>
+
+<p><b>Bolivia</b>
+<ul>
+<li>The NickServ <tt>NOOP</tt> option behaves slightly differently in
+	Services: it prevents the nickname from being added to channel
+	access lists, but the nickname will still be auto-opped if it
+	already has that privilege in a channel.
+<li>Limiting channels to privileged users (the <tt>LEVEL</tt> command) is
+	not supported, and such restrictions will be discarded when
+	converting the databases.  However, some IRC servers (such as
+	Unreal) have channel modes allowing channels to be limited to IRC
+	operators or administrators only, and Services allows those modes
+	to be locked on with the <tt>SET MLOCK</tt> command.
+<li>ChanServ <tt>FREEZE</tt> is not supported.
+<li>ChanServ <tt>HOLD</tt> setter will be lost when converting.
+<li>E-mailing of log files is not supported.
+</ul>
+
+<p><b>Cygnus</b>
+<ul>
+<li>Services does not store the UIN, real name, age, sex, or location for
+	nicknames; this information will be lost when the databases are
+	converted.
+<li>Services does not send replies using <tt>PRIVMSG</tt>; the
+	<tt>NOTICE</tt> and <tt>PRIVMSG</tt> nickname settings will be
+	ignored.
+<li>The following options/features are not supported:
+	<ul>
+	<li>NickServ <tt>NEVEROP</tt> and <tt>NOSUCCESSOR</tt>
+	<li>ChanServ <tt>LIMITED</tt>
+	<li>MemoServ <tt>RECEIPTS</tt>
+	<li>RootServ <tt>MARK</tt>
+	</ul>
+<li>Nicknames designated as CSOPs will be converted to Services operators.
+	Note that the privileges granted by IRC Services to Services
+	operators are different from those granted by Cygnus to CSOPs.
+<li>Nicknames will retain their memo limit settings in the converted data;
+	however, they will not be affected by changes to the
+	<a href="a.html#memoserv/main.MSMaxMemos"><tt>MSMaxMemos</tt></a>
+	setting.  (Memo limits can be reset to the default, which follows
+	the <tt>MSMaxMemos</tt> setting, with the <tt>-reset-memo-limits</tt>
+	option.)
+<li>If you have modified the time zone list used by Cygnus
+	(<tt>cygnus.zone</tt>), nickname time zones will not be transferred
+	correctly by default.  Use the <tt>-tzfile=</tt> option to ensure
+	that time zones are loaded from your time zone file, or use the
+	<tt>-no-timezones</tt> option to reset all time zone settings to
+	default.
+<li>Authentication for channels is not supported; authentication codes and
+	"verify" information will be discarded.
+<li>Channel access list entries in IRC Services must always be registered
+	nicknames; <tt><i>user</i>@<i>host</i></tt> entries, and any
+	entries not matching a registered nickname, will be deleted.
+<li>While the channel topic-lock setting will be retained, the lock level
+	(founder/SOP/AOP/HOP/VOP) will be reset to the IRC Services default
+	(AOP).  If you use the <tt>LEVELS</tt> command (in the
+	<tt>chanserv/access-levels</tt> submodule), you can change the
+	level of the <tt>TOPIC</tt> command to set which users are
+	allowed to change the topic.
+<li>While not directly related to the databases, note that Services uses
+	the <a href="4.html#nick.auth"><tt>AUTH</tt></a> command, not the
+	<tt>REGISTER</tt> or <tt>SET EMAIL</tt> commands, to authenticate
+	nicknames.
+</ul>
+
+<p><b>Daylight</b>
+<ul>
+<li>Services does not support the <tt>XMANAGEMENT</tt> channel setting.
+</ul>
+
+<p><b>Epona</b>
+<ul>
+<li>Epona contains the MD5 encryption bug present in versions of IRC
+	Services before 4.5; as a result, encrypted passwords will not work
+	by default.  As a workaround, you can enable the
+	<a href="a.html#encryption/md5.EnableAnopeWorkaround"><tt>EnableAnopeWorkaround</tt></a>
+	configuration option for the <tt>encryption/md5</tt> module in
+	<tt>modules.conf</tt>, but be aware that this may reduce the
+	security of your passwords.  There are also rare cases in which
+	passwords may be truncated in the databases; if you encounter such
+	a case, the password will have to be changed manually by a Services
+	administrator.</li>
+<li>Services does not store the following information; it will be lost when
+	the databases are converted:
+    <ul>
+	<li>ICQ number for nicknames
+	<li>Last used time for channel access entries
+    </ul>
+<li>Services does not distinguish between using the ChanServ <tt>OP</tt>,
+	<tt>VOICE</tt>, and related commands on oneself or on other users.
+<li>By default, only basic channel modes (<tt>+i</tt>, <tt>+k</tt>,
+	<tt>+l</tt>, <tt>+m</tt>, <tt>+n</tt>, <tt>+p</tt>, <tt>+s</tt>,
+	and <tt>+t</tt>) will be imported for channel mode locks.  To
+	import extended modes provided by particular IRC servers, use one
+	of the following command-line options:
+	<ul>
+		<li><tt>-ircd=bahamut</tt> for Bahamut
+		<li><tt>-ircd=ultimate2</tt> for UltimateIRCD
+		<li><tt>-ircd=unreal</tt> for UnrealIRCd
+	</ul>
+</ul>
+
+<p><b>HybServ</b>
+<ul>
+<li>Services does not store GSM, phone, or ICQ number for nicknames; this
+	information will be lost when the databases are converted.
+<li>Services does not have the concept of "permanent passwords", as in
+	HybServ 1.6.1+UniBG, and such passwords will be discarded on
+	import.
+<li>Services does not support the NickServ <tt>AUTOMASK</tt>, <tt>HIDE
+	URL</tt>, <tt>NOREGISTER</tt>, or <tt>NOCHANOPS</tt> settings, or
+	the ChanServ <tt>GUARD</tt> or <tt>VERBOSE</tt> settings.
+<li>The NickServ <tt>NOOP</tt> option behaves slightly differently in
+	Services: it prevents the nickname from being added to channel
+	access lists, but the nickname will still be auto-opped if it
+	already has that privilege in a channel.
+<li>The NickServ <tt>HIDE ALL</tt> setting is treated as a combination of
+	<tt>HIDE EMAIL</tt>, <tt>HIDE USERMASK</tt>, and <tt>HIDE QUIT</tt>.
+	The nickname URL and options cannot be hidden.
+<li>Temporary forbids are imported as permanent (Services does not support
+	the notion of a "temporary" or "timed" forbid).
+<li>"Forgotten" channels are not supported, and will not be imported.
+<li>Services does not have a system of "operator modes" like HybServ, and
+	no operator mode information will be imported.
+<li>Statistics information (maximum number of users/channels/etc.) will not
+	be imported.
+<li>The founder of a channel will be removed from the channel's access list
+	(founders always have full channel privileges and do not need to be
+	added to the access list).
+<li>Channel privilege levels will be reset to the Services defaults on
+	import.  Channel access levels will also be modified to fit within
+	the -999&nbsp;.&nbsp;.&nbsp;.&nbsp;999 range used by Services, as follows:
+<p align=center><table border=1>
+<tr><th>HybServ level<th>Services level
+<tr><td align=center>-10000<td align=center>-999
+<tr><td align=center>-9999&nbsp;.&nbsp;.&nbsp;.&nbsp;-10<td align=center>-999&nbsp;.&nbsp;.&nbsp;.&nbsp;-1
+<tr><td align=center>-9&nbsp;.&nbsp;.&nbsp;.&nbsp;-1<td align=center>-1
+<tr><td align=center>0&nbsp;.&nbsp;.&nbsp;.&nbsp;5<td align=center>0&nbsp;.&nbsp;.&nbsp;.&nbsp;30
+<tr><td align=center>5&nbsp;.&nbsp;.&nbsp;.&nbsp;10<td align=center>30&nbsp;.&nbsp;.&nbsp;.&nbsp;50
+<tr><td align=center>10&nbsp;.&nbsp;.&nbsp;.&nbsp;15<td align=center>50&nbsp;.&nbsp;.&nbsp;.&nbsp;100
+<tr><td align=center>15&nbsp;.&nbsp;.&nbsp;.&nbsp;20<td align=center>100&nbsp;.&nbsp;.&nbsp;.&nbsp;110
+<tr><td align=center>20&nbsp;.&nbsp;.&nbsp;.&nbsp;200<td align=center>110&nbsp;.&nbsp;.&nbsp;.&nbsp;200
+<tr><td align=center>200&nbsp;.&nbsp;.&nbsp;.&nbsp;1000<td align=center>200&nbsp;.&nbsp;.&nbsp;.&nbsp;300
+<tr><td align=center>1000&nbsp;.&nbsp;.&nbsp;.&nbsp;9000<td align=center>300&nbsp;.&nbsp;.&nbsp;.&nbsp;900
+<tr><td align=center>9000&nbsp;.&nbsp;.&nbsp;.&nbsp;9999<td align=center>900&nbsp;.&nbsp;.&nbsp;.&nbsp;999
+<tr><td align=center>10000<td align=center>999
+</table>
+<p><b>WARNING:</b> As a result of differences in the default level settings
+between HybServ and Services, some users will have access to commands which
+they did not previously have access to.  In particular, the <tt>ACCESS</tt>
+command is available to all users with access level 40 (HybServ level 8) or
+above, and the <tt>CLEAR</tt> command is available to all users with
+access level 100 (HybServ level 15) or above.  Conversely, the
+<tt>INVITE</tt> command is available only to users with access level 50
+(HybServ level 10) or above; auto-voice users cannot use it.
+</ul>
+
+<p><b>IRCS</b>
+<ul>
+<li>By default, IRCS supports channels with names longer than 63 characters
+	(including the leading "#").  Services does not support these by
+	default, and such channels will not be imported.
+<li>Channel autoop/autovoice cannot be set for individual nicknames.  All
+	nicks with appropriate access will be opped even if ChanServ
+	<tt>SET AUTOOP OFF</tt> was used for the nick.
+<li>The numeric access level for <tt>SOP</tt> is different from that used
+	in Services, so some access levels will be altered to match the
+	default <tt>SOP</tt> level in Services.  (Channel privileges will
+	remain unchanged.)
+<li>The "senior", "junior", and "helper" OperServ access levels do not
+	exist in Services.  Users on the "senior" list will be moved to the
+	Services admin list; users on other lists will be moved to the
+	Services operator list.  <b>WARNING:</b> As a result of the above,
+	users on the "senior" list will be given access to the
+	<tt>JUPE</tt> and <tt>LISTIGNORE</tt> commands.
+</ul>
+
+<p><b>Magick I 1.4</b>
+<ul>
+<li>Services does not send replies using <tt>PRIVMSG</tt>; the
+	<tt>NI_PRIVMSG</tt> nickname setting will be ignored.
+<li>Services does not have a "channel news" system like Magick, and all
+	channel news items will be discarded.
+</ul>
+
+<p><b>PTlink</b>
+<ul>
+<li>PTlink supports several encryption methods; of these, the "JP2" method
+	is not supported by Services, and any passwords encrypted with this
+	method will be reset to the respective nick or channel name.
+<li>Services does not store the following information; it will be lost when
+	the databases are converted:
+    <ul>
+	<li>ICQ number, location, birthdate, time of last identify, and
+	    authentication code (2.22.0 and later) for nicknames
+        <li>maximum number of users and time of maximum for channels
+    </ul>
+<li>An apparent bug in PTlink causes the successor field of some channels
+	to be corrupted; this will result in warnings when loading the
+	channel database.
+<li>What PTlink refers to as "SXlines" are known as "SGlines" in Services;
+	SXline database records (in versions of PTlink that support it)
+	will be converted to SGline records.
+</ul>
+
+<p><b>SirvNET</b>
+<ul>
+<li>The NickServ <tt>NOOP</tt> option behaves slightly differently in
+	Services: it prevents the nickname from being added to channel
+	access lists, but the nickname will still be auto-opped if it
+	already has that privilege in a channel.
+<li>Limiting channels to priviliged users (the <tt>LEVEL</tt> command) is
+	not supported, and such restrictions will be discarded when
+	converting the databases.  However, some IRC servers (such as
+	Unreal) have channel modes allowing channels to be limited to IRC
+	operators or administrators only, and Services allows those modes
+	to be locked on with the <tt>SET MLOCK</tt> command.
+<li>NickServ <tt>AUTH</tt> and ChanServ <tt>FREEZE</tt> are not supported.
+<li>ChanServ <tt>HOLD</tt> setter and reason will be lost when converting.
+<li>E-mailing of log files is not supported.
+</ul>
+
+<p><b>trircd</b>
+<ul>
+<li><tt>SET EXCEPTION</tt>, <tt>SET INVITES</tt>, <tt>HIDE OPTIONS</tt>,
+	and <tt>HIDE DESC</tt> channel settings are not supported.
+</ul>
+
+<p><b>Wrecked 1.2.0</b>
+<ul>
+<li>Services does not send replies using <tt>PRIVMSG</tt>; the
+	<tt>NI_PRIVMSG</tt> nickname setting will be ignored.
+<li>The <tt>VOPALL</tt> channel setting is not supported.
+</ul>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<p align=right><font size=-1><a href=4.html>Previous section: Services command reference</a> |
+<a href=index.html>Table of Contents</a></font>
+
+</body>
+</html>

docs/FDL.html

@@ -0,0 +1,468 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services - Documentation license terms (GNU Free Documentation License, version 1.2)</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Documentation license terms</h2>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a> |
+<a href=copyright.html>Copyright notice and disclaimer</a></font>
+
+<p><hr>
+
+<h2 align=center>GNU Free Documentation License</h2>
+<h3 align=center>Version 1.2, November 2002</h3>
+
+<p> Copyright (C) 2000,2001,2002  Free Software Foundation, Inc.
+<br>     51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+<br> Everyone is permitted to copy and distribute verbatim copies
+<br> of this license document, but changing it is not allowed.
+
+<h3 align=center>0. PREAMBLE</h3>
+
+<p>
+The purpose of this License is to make a manual, textbook, or other
+functional and useful document "free" in the sense of freedom: to
+assure everyone the effective freedom to copy and redistribute it,
+with or without modifying it, either commercially or noncommercially.
+Secondarily, this License preserves for the author and publisher a way
+to get credit for their work, while not being considered responsible
+for modifications made by others.
+
+<p>
+This License is a kind of "copyleft", which means that derivative
+works of the document must themselves be free in the same sense.  It
+complements the GNU General Public License, which is a copyleft
+license designed for free software.
+
+<p>
+We have designed this License in order to use it for manuals for free
+software, because free software needs free documentation: a free
+program should come with manuals providing the same freedoms that the
+software does.  But this License is not limited to software manuals;
+it can be used for any textual work, regardless of subject matter or
+whether it is published as a printed book.  We recommend this License
+principally for works whose purpose is instruction or reference.
+
+
+<h3 align=center>1. APPLICABILITY AND DEFINITIONS</h3>
+
+<p>
+This License applies to any manual or other work, in any medium, that
+contains a notice placed by the copyright holder saying it can be
+distributed under the terms of this License.  Such a notice grants a
+world-wide, royalty-free license, unlimited in duration, to use that
+work under the conditions stated herein.  The "Document", below,
+refers to any such manual or work.  Any member of the public is a
+licensee, and is addressed as "you".  You accept the license if you
+copy, modify or distribute the work in a way requiring permission
+under copyright law.
+
+<p>
+A "Modified Version" of the Document means any work containing the
+Document or a portion of it, either copied verbatim, or with
+modifications and/or translated into another language.
+
+<p>
+A "Secondary Section" is a named appendix or a front-matter section of
+the Document that deals exclusively with the relationship of the
+publishers or authors of the Document to the Document's overall subject
+(or to related matters) and contains nothing that could fall directly
+within that overall subject.  (Thus, if the Document is in part a
+textbook of mathematics, a Secondary Section may not explain any
+mathematics.)  The relationship could be a matter of historical
+connection with the subject or with related matters, or of legal,
+commercial, philosophical, ethical or political position regarding
+them.
+
+<p>
+The "Invariant Sections" are certain Secondary Sections whose titles
+are designated, as being those of Invariant Sections, in the notice
+that says that the Document is released under this License.  If a
+section does not fit the above definition of Secondary then it is not
+allowed to be designated as Invariant.  The Document may contain zero
+Invariant Sections.  If the Document does not identify any Invariant
+Sections then there are none.
+
+<p>
+The "Cover Texts" are certain short passages of text that are listed,
+as Front-Cover Texts or Back-Cover Texts, in the notice that says that
+the Document is released under this License.  A Front-Cover Text may
+be at most 5 words, and a Back-Cover Text may be at most 25 words.
+
+<p>
+A "Transparent" copy of the Document means a machine-readable copy,
+represented in a format whose specification is available to the
+general public, that is suitable for revising the document
+straightforwardly with generic text editors or (for images composed of
+pixels) generic paint programs or (for drawings) some widely available
+drawing editor, and that is suitable for input to text formatters or
+for automatic translation to a variety of formats suitable for input
+to text formatters.  A copy made in an otherwise Transparent file
+format whose markup, or absence of markup, has been arranged to thwart
+or discourage subsequent modification by readers is not Transparent.
+An image format is not Transparent if used for any substantial amount
+of text.  A copy that is not "Transparent" is called "Opaque".
+
+<p>
+Examples of suitable formats for Transparent copies include plain
+ASCII without markup, Texinfo input format, LaTeX input format, SGML
+or XML using a publicly available DTD, and standard-conforming simple
+HTML, PostScript or PDF designed for human modification.  Examples of
+transparent image formats include PNG, XCF and JPG.  Opaque formats
+include proprietary formats that can be read and edited only by
+proprietary word processors, SGML or XML for which the DTD and/or
+processing tools are not generally available, and the
+machine-generated HTML, PostScript or PDF produced by some word
+processors for output purposes only.
+
+<p>
+The "Title Page" means, for a printed book, the title page itself,
+plus such following pages as are needed to hold, legibly, the material
+this License requires to appear in the title page.  For works in
+formats which do not have any title page as such, "Title Page" means
+the text near the most prominent appearance of the work's title,
+preceding the beginning of the body of the text.
+
+<p>
+A section "Entitled XYZ" means a named subunit of the Document whose
+title either is precisely XYZ or contains XYZ in parentheses following
+text that translates XYZ in another language.  (Here XYZ stands for a
+specific section name mentioned below, such as "Acknowledgements",
+"Dedications", "Endorsements", or "History".)  To "Preserve the Title"
+of such a section when you modify the Document means that it remains a
+section "Entitled XYZ" according to this definition.
+
+<p>
+The Document may include Warranty Disclaimers next to the notice which
+states that this License applies to the Document.  These Warranty
+Disclaimers are considered to be included by reference in this
+License, but only as regards disclaiming warranties: any other
+implication that these Warranty Disclaimers may have is void and has
+no effect on the meaning of this License.
+
+
+<h3 align=center>2. VERBATIM COPYING</h3>
+
+<p>
+You may copy and distribute the Document in any medium, either
+commercially or noncommercially, provided that this License, the
+copyright notices, and the license notice saying this License applies
+to the Document are reproduced in all copies, and that you add no other
+conditions whatsoever to those of this License.  You may not use
+technical measures to obstruct or control the reading or further
+copying of the copies you make or distribute.  However, you may accept
+compensation in exchange for copies.  If you distribute a large enough
+number of copies you must also follow the conditions in section 3.
+
+<p>
+You may also lend copies, under the same conditions stated above, and
+you may publicly display copies.
+
+
+<h3 align=center>3. COPYING IN QUANTITY</h3>
+
+<p>
+If you publish printed copies (or copies in media that commonly have
+printed covers) of the Document, numbering more than 100, and the
+Document's license notice requires Cover Texts, you must enclose the
+copies in covers that carry, clearly and legibly, all these Cover
+Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
+the back cover.  Both covers must also clearly and legibly identify
+you as the publisher of these copies.  The front cover must present
+the full title with all words of the title equally prominent and
+visible.  You may add other material on the covers in addition.
+Copying with changes limited to the covers, as long as they preserve
+the title of the Document and satisfy these conditions, can be treated
+as verbatim copying in other respects.
+
+<p>
+If the required texts for either cover are too voluminous to fit
+legibly, you should put the first ones listed (as many as fit
+reasonably) on the actual cover, and continue the rest onto adjacent
+pages.
+
+<p>
+If you publish or distribute Opaque copies of the Document numbering
+more than 100, you must either include a machine-readable Transparent
+copy along with each Opaque copy, or state in or with each Opaque copy
+a computer-network location from which the general network-using
+public has access to download using public-standard network protocols
+a complete Transparent copy of the Document, free of added material.
+If you use the latter option, you must take reasonably prudent steps,
+when you begin distribution of Opaque copies in quantity, to ensure
+that this Transparent copy will remain thus accessible at the stated
+location until at least one year after the last time you distribute an
+Opaque copy (directly or through your agents or retailers) of that
+edition to the public.
+
+<p>
+It is requested, but not required, that you contact the authors of the
+Document well before redistributing any large number of copies, to give
+them a chance to provide you with an updated version of the Document.
+
+
+<h3 align=center>4. MODIFICATIONS</h3>
+
+<p>
+You may copy and distribute a Modified Version of the Document under
+the conditions of sections 2 and 3 above, provided that you release
+the Modified Version under precisely this License, with the Modified
+Version filling the role of the Document, thus licensing distribution
+and modification of the Modified Version to whoever possesses a copy
+of it.  In addition, you must do these things in the Modified Version:
+
+<ol type="A">
+<li>Use in the Title Page (and on the covers, if any) a title distinct
+   from that of the Document, and from those of previous versions
+   (which should, if there were any, be listed in the History section
+   of the Document).  You may use the same title as a previous version
+   if the original publisher of that version gives permission.
+<li>List on the Title Page, as authors, one or more persons or entities
+   responsible for authorship of the modifications in the Modified
+   Version, together with at least five of the principal authors of the
+   Document (all of its principal authors, if it has fewer than five),
+   unless they release you from this requirement.
+<li>State on the Title page the name of the publisher of the
+   Modified Version, as the publisher.
+<li>Preserve all the copyright notices of the Document.
+<li>Add an appropriate copyright notice for your modifications
+   adjacent to the other copyright notices.
+<li>Include, immediately after the copyright notices, a license notice
+   giving the public permission to use the Modified Version under the
+   terms of this License, in the form shown in the Addendum below.
+<li>Preserve in that license notice the full lists of Invariant Sections
+   and required Cover Texts given in the Document's license notice.
+<li>Include an unaltered copy of this License.
+<li>Preserve the section Entitled "History", Preserve its Title, and add
+   to it an item stating at least the title, year, new authors, and
+   publisher of the Modified Version as given on the Title Page.  If
+   there is no section Entitled "History" in the Document, create one
+   stating the title, year, authors, and publisher of the Document as
+   given on its Title Page, then add an item describing the Modified
+   Version as stated in the previous sentence.
+<li>Preserve the network location, if any, given in the Document for
+   public access to a Transparent copy of the Document, and likewise
+   the network locations given in the Document for previous versions
+   it was based on.  These may be placed in the "History" section.
+   You may omit a network location for a work that was published at
+   least four years before the Document itself, or if the original
+   publisher of the version it refers to gives permission.
+<li>For any section Entitled "Acknowledgements" or "Dedications",
+   Preserve the Title of the section, and preserve in the section all
+   the substance and tone of each of the contributor acknowledgements
+   and/or dedications given therein.
+<li>Preserve all the Invariant Sections of the Document,
+   unaltered in their text and in their titles.  Section numbers
+   or the equivalent are not considered part of the section titles.
+<li>Delete any section Entitled "Endorsements".  Such a section
+   may not be included in the Modified Version.
+<li>Do not retitle any existing section to be Entitled "Endorsements"
+   or to conflict in title with any Invariant Section.
+<li>Preserve any Warranty Disclaimers.
+</ol>
+
+<p>
+If the Modified Version includes new front-matter sections or
+appendices that qualify as Secondary Sections and contain no material
+copied from the Document, you may at your option designate some or all
+of these sections as invariant.  To do this, add their titles to the
+list of Invariant Sections in the Modified Version's license notice.
+These titles must be distinct from any other section titles.
+
+<p>
+You may add a section Entitled "Endorsements", provided it contains
+nothing but endorsements of your Modified Version by various
+parties&mdash;for example, statements of peer review or that the text has
+been approved by an organization as the authoritative definition of a
+standard.
+
+<p>
+You may add a passage of up to five words as a Front-Cover Text, and a
+passage of up to 25 words as a Back-Cover Text, to the end of the list
+of Cover Texts in the Modified Version.  Only one passage of
+Front-Cover Text and one of Back-Cover Text may be added by (or
+through arrangements made by) any one entity.  If the Document already
+includes a cover text for the same cover, previously added by you or
+by arrangement made by the same entity you are acting on behalf of,
+you may not add another; but you may replace the old one, on explicit
+permission from the previous publisher that added the old one.
+
+<p>
+The author(s) and publisher(s) of the Document do not by this License
+give permission to use their names for publicity for or to assert or
+imply endorsement of any Modified Version.
+
+
+<h3 align=center>5. COMBINING DOCUMENTS</h3>
+
+<p>
+You may combine the Document with other documents released under this
+License, under the terms defined in section 4 above for modified
+versions, provided that you include in the combination all of the
+Invariant Sections of all of the original documents, unmodified, and
+list them all as Invariant Sections of your combined work in its
+license notice, and that you preserve all their Warranty Disclaimers.
+
+<p>
+The combined work need only contain one copy of this License, and
+multiple identical Invariant Sections may be replaced with a single
+copy.  If there are multiple Invariant Sections with the same name but
+different contents, make the title of each such section unique by
+adding at the end of it, in parentheses, the name of the original
+author or publisher of that section if known, or else a unique number.
+Make the same adjustment to the section titles in the list of
+Invariant Sections in the license notice of the combined work.
+
+<p>
+In the combination, you must combine any sections Entitled "History"
+in the various original documents, forming one section Entitled
+"History"; likewise combine any sections Entitled "Acknowledgements",
+and any sections Entitled "Dedications".  You must delete all sections
+Entitled "Endorsements".
+
+
+<h3 align=center>6. COLLECTIONS OF DOCUMENTS</h3>
+
+<p>
+You may make a collection consisting of the Document and other documents
+released under this License, and replace the individual copies of this
+License in the various documents with a single copy that is included in
+the collection, provided that you follow the rules of this License for
+verbatim copying of each of the documents in all other respects.
+
+<p>
+You may extract a single document from such a collection, and distribute
+it individually under this License, provided you insert a copy of this
+License into the extracted document, and follow this License in all
+other respects regarding verbatim copying of that document.
+
+
+<h3 align=center>7. AGGREGATION WITH INDEPENDENT WORKS</h3>
+
+<p>
+A compilation of the Document or its derivatives with other separate
+and independent documents or works, in or on a volume of a storage or
+distribution medium, is called an "aggregate" if the copyright
+resulting from the compilation is not used to limit the legal rights
+of the compilation's users beyond what the individual works permit.
+When the Document is included in an aggregate, this License does not
+apply to the other works in the aggregate which are not themselves
+derivative works of the Document.
+
+<p>
+If the Cover Text requirement of section 3 is applicable to these
+copies of the Document, then if the Document is less than one half of
+the entire aggregate, the Document's Cover Texts may be placed on
+covers that bracket the Document within the aggregate, or the
+electronic equivalent of covers if the Document is in electronic form.
+Otherwise they must appear on printed covers that bracket the whole
+aggregate.
+
+
+<h3 align=center>8. TRANSLATION</h3>
+
+<p>
+Translation is considered a kind of modification, so you may
+distribute translations of the Document under the terms of section 4.
+Replacing Invariant Sections with translations requires special
+permission from their copyright holders, but you may include
+translations of some or all Invariant Sections in addition to the
+original versions of these Invariant Sections.  You may include a
+translation of this License, and all the license notices in the
+Document, and any Warranty Disclaimers, provided that you also include
+the original English version of this License and the original versions
+of those notices and disclaimers.  In case of a disagreement between
+the translation and the original version of this License or a notice
+or disclaimer, the original version will prevail.
+
+<p>
+If a section in the Document is Entitled "Acknowledgements",
+"Dedications", or "History", the requirement (section 4) to Preserve
+its Title (section 1) will typically require changing the actual
+title.
+
+
+<h3 align=center>9. TERMINATION</h3>
+
+<p>
+You may not copy, modify, sublicense, or distribute the Document except
+as expressly provided for under this License.  Any other attempt to
+copy, modify, sublicense or distribute the Document is void, and will
+automatically terminate your rights under this License.  However,
+parties who have received copies, or rights, from you under this
+License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+
+<h3 align=center>10. FUTURE REVISIONS OF THIS LICENSE</h3>
+
+<p>
+The Free Software Foundation may publish new, revised versions
+of the GNU Free Documentation License from time to time.  Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.  See
+http://www.gnu.org/copyleft/.
+
+<p>
+Each version of the License is given a distinguishing version number.
+If the Document specifies that a particular numbered version of this
+License "or any later version" applies to it, you have the option of
+following the terms and conditions either of that specified version or
+of any later version that has been published (not as a draft) by the
+Free Software Foundation.  If the Document does not specify a version
+number of this License, you may choose any version ever published (not
+as a draft) by the Free Software Foundation.
+
+
+<h3 align=center>ADDENDUM: How to use this License for your documents</h3>
+
+<p>
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and
+license notices just after the title page:
+
+<blockquote>
+    Copyright (c)  YEAR  YOUR NAME.<br>
+    Permission is granted to copy, distribute and/or modify this document
+    under the terms of the GNU Free Documentation License, Version 1.2
+    or any later version published by the Free Software Foundation;
+    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
+    A copy of the license is included in the section entitled "GNU
+    Free Documentation License".
+</blockquote>
+
+<p>
+If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+replace the "with...Texts." line with this:
+
+<blockquote>
+    with the Invariant Sections being LIST THEIR TITLES, with the
+    Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
+</blockquote>
+
+<p>
+If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+<p>
+If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of
+free software license, such as the GNU General Public License,
+to permit their use in free software.
+
+<p><hr>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a> |
+<a href=copyright.html>Copyright notice and disclaimer</a> |
+<a href="#top">Top</a></font>
+
+</body>
+</html>

docs/GPL.html

@@ -0,0 +1,425 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services - License terms (GNU General Public License, version 2)</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>License terms</h2>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a> |
+<a href=copyright.html>Copyright notice and disclaimer</a></font>
+
+<p><hr>
+
+<h2 align=center>GNU GENERAL PUBLIC LICENSE</h2>
+<h3 align=center>Version 2, June 1991</h3>
+
+<p> Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+<br> 675 Mass Ave, Cambridge, MA 02139, USA
+<br> Everyone is permitted to copy and distribute verbatim copies
+<br> of this license document, but changing it is not allowed.
+
+<h3 align=center>Preamble</h3>
+
+<p>
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software&mdash;to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+<p>
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+<p>
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+<p>
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+<p>
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+<p>
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+<p>
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+<p>
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+<p><hr>
+<h3 align=center>GNU GENERAL PUBLIC LICENSE</h3>
+
+<p align=center>
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+<p>
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+<p>
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+<p>
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+<p>
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+<p>
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+<p><blockquote>
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+<p>
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+<p>
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+</blockquote>
+
+<p>
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+<p>
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+<p>
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+<p>
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+<p><blockquote>
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+<p>
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+<p>
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+</blockquote>
+
+<p>
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+<p>
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+<p>
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+<p>
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+<p>
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+<p>
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+<p>
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+<p>
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+<p>
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+<p>
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+<p>
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+<p>
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+<p>
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+<p align=center>NO WARRANTY
+
+<p>
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+<p>
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+<p align=center>END OF TERMS AND CONDITIONS
+
+<p><hr>
+
+<h3 align=center>Appendix: How to Apply These Terms to Your New Programs</h3>
+
+<p>
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+<p>
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+<p><pre>
+    &lt;one line to give the program's name and a brief idea of what it does.&gt;
+    Copyright (C) 19yy  &lt;name of author&gt;
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+</pre>
+
+<p>
+Also add information on how to contact you by electronic and paper mail.
+
+<p>
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+<p><pre>
+    Gnomovision version 69, Copyright (C) 19yy name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+</pre>
+
+<p>
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items&mdash;whatever suits your program.
+
+<p>
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+<p><blockquote>
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+<p>
+  &lt;signature of Ty Coon&gt;, 1 April 1989
+  <br>Ty Coon, President of Vice
+</blockquote>
+
+<p>
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
+
+<p><hr>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a> |
+<a href=copyright.html>Copyright notice and disclaimer</a> |
+<a href="#top">Top</a></font>
+
+</body>
+</html>

docs/WhatsNew

@@ -0,0 +1,736 @@
+                                What's New
+               =============================================
+               Summaries of changes in new Services versions
+
+Note: This is intended to highlight only the major changes between
+      versions.  For a complete list of changes, see the "Changes" file.
+
+------------
+Version 5.1:
+------------
+Database handling, the one aspect of Services which has remained
+essentially unchanged since version 1.0, has finally undergone a fairly
+significant redesign.  Rather than using specialized data load and save
+routines tailored for the core Services pseudoclients, Services now
+implements a generic database table system, which has the dual benefits of
+separating the data storage system from the rest of Services (allowing
+alternative storage methods to be implemented easily) and allowing third-
+party modules and extensions to create their own non-volatile databases
+without resorting to custom load/save routines.  The default database file
+format has also been changed to be more flexible and error-resilient than
+the old format (which admittedly isn't saying much); see the "upgrading"
+section of the manual for instructions on switching your databases to the
+new format.
+
+The often-criticized channel memo system has also been redesigned for this
+version.  Instead of storing channel memos with the channel, memos are now
+sent to the founder and all users on the channel with a particular access
+level (by default level 100, or SOP level).  These memos are distinguished
+from ordinary memos by text that says "(for #channel)" when reading the
+memo.  As a result of this change, users will be notified about new channel
+memos in the same way as ordinary user-to-user memos.
+
+NOTICE: When loading databases from version 5.0 or earlier, all channel
+        memos will be deleted.
+
+Encryption support has also been improved.  Encryption is no longer an
+all-or-nothing affair; the encryption method is stored with each password,
+so that enabling or disabling encryption will have no effect on passwords
+that were previously set.  The "encryption/unix-crypt" module has been
+added, allowing the use of the Unix crypt() function to encrypt passwords.
+
+The NickServ and ChanServ SENDPASS commands added in version 5.0 have been
+removed in favor of the new NickServ REAUTH command.  This command
+generates an authentication code which the user can use once to identify to
+their nickname in place of the password, and then change the password as
+needed.  Channel passwords can always be changed by the founder after
+nickname identification, rendering ChanServ SENDPASS unnecessary.
+
+Long LIST/VIEW responses are now handled more cleanly.  Except for NickServ
+ACCESS LIST (since nickname access lists are generally short) and MemoServ
+LIST (since memos are numbered), every list now includes an "end of list"
+message indicating both the number of entries displayed and the total
+number of entries in the list; the configuration directive ListMax,
+replacing NSListMax and CSListMax, sets the maximum number of entries
+displayed for any of these commands.  It is also possible to skip a certain
+number of entries by adding a "+NNN" after the command, allowing all of the
+entries in a long list to be viewed bit by bit.
+
+At the development level, handling of module compilation has been improved,
+allowing third-party modules to be simply "dropped in" without requiring
+changes to Makefiles or other Services distribution files.  An extension
+interface has been added to Services' multilingual support as well,
+allowing modules to add their own language strings and load their own
+language files.
+
+Other changes:
+  + Command aliases can now be added for NickServ, ChanServ, and MemoServ
+        commands via the NSAlias, CSAlias, and MSAlias directives.
+  + Notices are now sent to the user when sending of a mail authentication
+        code message fails.  (However, errors after the message has been
+        handed off to the mail server cannot be detected.)
+  + A new configuration directive, RejectEmail, now allows selected E-mail
+        addresses to be rejected by NickServ and ChanServ commands.
+  + NickServ has a new option, NOOP, which prevents nicknames from being
+        added to channel access lists.  (It does not prevent the nickname
+        from being opped when already present on an access list.)
+  + NickServ INFO will now indicate when a nickname's user is using a
+        different linked nickname if the nickname group's PRIVATE option
+        is not set.
+  + NickServ now has a RESTOREMAIL command (in the nickserv/mail-auth
+        module), which allows a user to restore their nickname's last
+        authenticated E-mail address if, for example, SET EMAIL is used
+        with an incorrect address.
+  + NickServ SET/UNSET by Services administrators for others' nicknames is
+        now done by putting a "!" before the nick to avoid ambiguity; for
+        example, "SET !nick NOEXPIRE ON" instead of "SET nick NOEXPIRE ON".
+  + ChanServ REGISTER and SET PASSWORD now check for and disallow easily
+        guessable passwords.
+  + ChanServ has a new option, MEMO-RESTRICTED, which prevents users
+        without the channel MEMO privilege from sending memos to the
+        channel.
+  + ChanServ ACCESS now includes a LISTLEVEL subcommand to list access
+        entries with a given level or within a given level range.
+  + ChanServ AKICK and MemoServ IGNORE now support matching by IP address
+        (on servers which support client IP address information).
+  + ChanServ OP, VOICE, and similar commands can now be used with multiple
+        nicknames.
+  + MemoServ now has a RENUMBER command to remove "holes" in the memo
+        number sequence.
+  + MemoServ FORWARD now sends all selected memos in a single E-mail
+        message, rather than sending each memo in a separate message.
+  + OperServ AKILL and related commands now have a CHECK subcommand which
+        can be used to find all masks that match a given user/hostname.
+  + SQlines are no longer applied to IRC operators during Services startup
+        or netjoins if the IRC protocol in use supports sending user modes
+        with the NICK message.  This includes the bahamut, hybrid,
+        inspircd, monkey, ptlink, ratbox, solid-ircd, trircd, and unreal
+        protocol modules.
+  + The ignore system has been redesigned, and now keeps better track of
+        how much load each user is putting on Services.  The ignorance
+        threshold can be fine-tuned via the configuration file.
+  + A new "unsorted list" mode has been added to improve Services'
+        performance on large networks.  By giving the -no-sorted-list
+        option to the configure script, Services will not try to keep
+        nicknames and channels in alphabetical order; this means that
+        commands such as NickServ LIST will no longer return nicknames in
+        order, but Services will run significantly faster.
+  + Support has been added for the InspIRCd, ircd-ratbox, and solid-ircd
+        IRC servers.
+  + Unreal's NICKCHARS protocol option, allowing non-ASCII characters in
+        nicknames, is now supported.
+  + The name of the Services executable can now be changed, using the
+        -prefix option to the configure script.  The name given will also
+        be used in the main configuration filename (normally
+        ircservices.conf) and cron script (ircservices-chk), as well as
+        default filenames in the configuration file.
+  * ChanServ DROP now behaves like NickServ DROP: dropping a channel now
+        requires the channel password to be entered with the DROP command,
+        and DROPCHAN has been added as a separate command for Services
+        administrators to drop arbitrary channels.
+  * The ChanServ ACCESS, XOP, and AKICK commands no longer use entry
+        numbers; the DEL and LIST subcommands now work with nicknames
+        (hostmasks for the AKICK command) only.
+  * The binary distributions (RPM and Debian packages) now install into
+        /opt/ircservices and /var/opt/ircservices, rather than /usr/sbin
+        and /usr/lib/ircservices.
+  * Tab characters are no longer used (or allowed) in the source code.
+  - The deprecated nickserv/oldlink module, which provided support for the
+        format of the LINK command used in version 4 of Services, has been
+        removed.
+  - Support for "modeless channels", with names of the form "+name", has
+        been removed.  (Support for registering such channels was removed
+        in version 5.0.0; this version removes the special handling for
+        such channels in other parts of the program.)
+  - Support for the "channel owner" mode present in the PTlink (+a),
+        trircd (+u), and Unreal (+q) IRC servers has been removed, as there
+        are too many differing opinions on its proper use.
+  - Language support for Italian and Portuguese has been removed, due to
+        the lack of volunteers to maintain them.
+  - Support for old versions of GCC (anything before GCC 3.2) has been
+        removed.
+Configuration file changes:
+  + IncludeFile has been added to allow configuration directives to be
+        split up into multiple files, and may be used in both
+        ircservices.conf and modules.conf.
+  + NoAdminPasswordCheck (ircservices.conf) has been added in release
+        5.1.16 to allow password checks to be bypassed for Services
+        administrators.
+  + LoadLanguageText (ircservices.conf) has been added to allow replacement
+        of Services text strings at runtime.
+  + RejectEmail (ircservices.conf) has been added to allow rejection of
+        selected E-mail addresses.
+  + NSAlias (module nickserv/main), CSAlias (module chanserv/main), and
+        MSAlias (module memoserv/main) have been added to allow creation of
+        command aliases.
+  + NSRegDenyIfSuspended (module nickserv/main) has been added to prevent
+        registration of new nicknames by users with suspended nicknames.
+  + NSSetEmailDelay (module nickserv/main) has been added to enforce a
+        delay between consecutive uses of the SET EMAIL command, thereby
+        reducing the potential for sending mailbombs.
+  + CSDefModeLock (module chanserv/main) has been added to allow the
+        default mode lock for newly registered channels to be changed.
+  + CSSkipModeRCheck (module chanserv/main) has been added to allow the
+        check of a nickname's registration status at channel join time
+        (used to kick unregistered nicknames from channels locked +R) to
+        be skipped.
+  + MSExpireDelay (module memoserv/main) has been added to allow memo
+        expiration to be delayed until a certain time after the memo is
+        first read.
+  + MaxMessages (module mail/main) has been added to allow a limit to be
+        placed on the total number of messages in transit.
+  * ListMax (ircservices.conf) has been added in place of NSListMax and
+        CSListMask to set a limit on the number of entries displayed for
+        all LIST-like commands.
+  * WallAdminPrivs (ircservices.conf) has been added in place of
+        WallGetpass and WallSetpass to cause a WALLOPS/GLOBOPS to be sent
+        on all NickServ and ChanServ commands that use Services
+        administrator privileges.
+  * The database name configuration directives (NickServDB, ChanServDB,
+        etc.) have been moved from the various pseudoclient module sections
+        to the database/version4 module section, and now explicitly specify
+        filenames.
+  - The nickserv/sendpass and chanserv/sendpass modules (and therefore
+        their respective configuration sections) have been removed.
+  - CSAutokickReason (module chanserv/main) has been removed, as the
+        built-in reason prefix "AKICK by <nick>" makes it unnecessary.
+  - MSExpireUnread (module memoserv/main) has been removed, since it
+        results in silent data loss.
+  - MSNotifyAll (module memoserv/main) has been removed, since it is
+        required for channel memos.  MemoServ will now always behave as if
+        MSNotifyAll was set.
+  - MaxSockets (module mail/smtp) has been removed, since MaxMessages now
+        performs the same function.
+
+------------
+Version 5.0:
+------------
+The single biggest addition to this version of Services is module support.
+This allows the various functions of Services to be added to and modified
+without having to touch the main source code itself.  Modules also provide
+much more flexibility in configuring Services; IRC server support and
+database file format can be selected by simply loading the appropriate
+module, and you can even choose which of the pseudoclients (NickServ,
+ChanServ, etc.) you want available.  See the example configuration files
+in the "data" subdirectory for more information.
+
+Services is now capable of sending E-mail.  Currently, this functionality
+is used by:
+  + The new "authentication" feature of NickServ (in the
+    "nickserv/mail-auth" module).  This sends a message to a user upon
+    nickname registration or E-mail address change, and requires the user
+    to "authenticate" their nickname with a random numeric code included in
+    the message before it is recognized as a valid registered nick by
+    Services.
+  + The new SENDPASS command for NickServ and ChanServ (in the
+    "nickserv/sendpass" and "chanserv/sendpass" modules, respectively).
+    which allows a user to send themselves their nick or channel password.
+  + The new memo forwarding function of Services, which allows users to
+    have their memos automatically forwarded to their E-mail address.
+
+Services also sports a built-in HTTP server (module "httpd/main"), which
+(with the help of additional modules in the "httpd" directory) can be used
+for queries about nicknames, channels, and network status.  See the
+documentation (section 3-6) for details on its abilities, and please submit
+a feature request if you have any additional ideas for what functionality
+the server should provide.
+
+Nickname links have been redesigned for simplicity and robustness.  In the
+new linking system, nicks are organized into single-level "groups" which
+share settings the way linked nicks did in previous versions, rather than
+multi-level "trees" as version 4 used.  The LINK command has changed as
+well: instead of creating a link from the current (unlinked but registered)
+nick to a registered master nick, the link is made from the current
+registered nick to a new (unregistered) nick, to simplify registration of
+multiple links at once and to offer slightly better protection against
+"rogue links" created by guessing nick passwords (though as always, the
+best defense is to use good passwords).  The old behavior of the LINK
+command is still available through the "nickserv/oldlink" module, although
+this module is deprecated and will be removed in a future version.
+
+Finally, the documentation for Services (what used to be in the README and
+FAQ files) has been greatly expanded and rewritten in HTML, and now includes
+references for all Services pseudoclient commands and configuration options.
+The manual also contains important information for users upgrading from
+version 4.x or earlier; if you are already using Services and plan to
+upgrade to version 5.0, please read this information before upgrading.
+
+Other changes:
+  + Nicknames now have an "Information" line, similar to a channel's
+        description, which can be set freely for each group of nicks.
+  + The number of nicknames that can be registered per E-mail address can
+        now be limited (NSRegMaxEmail configuration directive).
+  + The default options for newly registered channels can now be set in the
+        configuration file.
+  + Identifies for nicknames are now recorded, removing the necessity to
+        re-identify after every nick change.
+  + The Services stamp of the last user to identify for a nick is now
+        recorded on disk, removing the necessity to re-identify when
+        Services is restarted.
+  + A time zone can be set for each registered nick, to allow users to get
+        information from Services in their own time zones.
+  + Nicknames can be listed by E-mail address with the new LISTEMAIL command.
+  + Users can set channels to automatically join whenever they identify for
+        their nickname (nickserv/autojoin module) on IRC servers supporting
+        the SVSJOIN command (such as Unreal or trircd).
+  + The NickServ and ChanServ REGISTER and GETPASS commands can now be
+        (individually) disabled via the configuration file.
+  + Users with auto-op access for a channel will now be opped when they
+        identify for their nickname even if they are already in the channel.
+  + Channel access levels are now limited to -999..999; default levels have
+        been rescaled to make better use of the available range (in
+        particular, levels -25..25 have been multiplied by 10).
+  + The ChanServ OP, VOICE, etc. commands now default to the person sending
+        the command if a target nick is not specified (e.g. "OP #channel").
+  + ChanServ now has a KICK command.
+  + Channel information can now be hidden with the new ChanServ SET HIDE
+        command, similar to the NickServ command of the same name.
+  + The ChanServ STATUS command is now available to normal (non-admin) users
+        with sufficient privileges on the target channel.
+  + Users can prevent certain other users from sending memos to them
+        (memoserv/ignore module).
+  + Autokill exclusions (exceptions to autokill masks) are now supported
+        through the EXCLUDE command (operserv/akill module).
+  + S-lines (SGLINE/SQLINE/SZLINE) are now supported (operserv/sline
+        module), and can even be used (except SZLINE) on servers which do
+        not support S-lines natively.
+  + Services now records the last time an autokick or autokill was
+        triggered, as well as the set time for autokicks.
+  + The maximum expiry time for autokills set by Services operators (as
+        opposed to Services admins) can now be limited.
+  + OperServ now has a SERVERMAP command to show the IRC server tree.
+  + Services is now slightly more robust against denial-of-service attacks
+        which use repeated HELP messages to overload network buffers; if
+        the network buffer size exceeds the threshold defined by the
+        NetBufferLimit configuration directive, Services will ignore
+        commands sent to it until the buffer size decreases.  The OperServ
+        STATS command has a new option, NETWORK, which can be used to show
+        the current network buffer status.
+  + Support for the Chunky Monkey and trircd IRC servers is now available.
+  + Services can now synchronize the clocks of all servers on the network
+        for IRC server types which support this feature (Unreal).
+  + Configuration files can now be re-read (rehashed) while Services is
+        running, using either the new OperServ REHASH command or kill -HUP.
+  + The log file can now be rotated automatically based on the date.
+  + Databases can now be imported (merged) and exported in XML format.
+  + A sample crontab script is now included in the distribution.
+  * The configuration file has been changed to accommodate modules;
+        ircservices.conf (formerly services.conf) now contains only options
+        related to core Services functionality, while module-related
+        options (including NickServ, ChanServ, etc. settings) are in a new
+        file called "modules.conf".  Many options have been added, changed,
+        or removed; see the example configuration files for details.
+  * The network I/O subsystem has been completely redesigned for robustness
+        and ease of use; multiple sockets (including listener sockets) can
+        be used simultaneously via read/write callbacks, and sockets now
+        have variable buffer sizes, allowing more efficient use of memory.
+  * Database handling has been improved to avoid database corruption on
+        power outage or process termination/crash.
+  * The "do not abuse NickServ" warning in the main NickServ help message
+        is now optional, to allow networks more freedom in writing their
+        own policies.
+  * Passwords, URLs, and E-mail addresses are now shared by each group of
+        linked nicks.
+  * NickServ DROP now requires a password to avoid accidental use, and
+        drops all linked nicks in a group at once.  The command for
+        Services administrators to drop a nick is now DROPNICK.
+  * The channel "#", which has been known to cause problems with both IRC
+        servers and Services-like programs, is now explicitly not
+        supported; Services will refuse to register, forbid, or import it.
+  * Users must now identify for their nickname before registering a channel.
+  * Channel autokicks specified by nickname now work for that nickname
+        only, not for any nicks linked to it.
+  * The CSRestrictDelay option now works correctly and is enabled by default.
+  * Newly-registered nicks will now always use the default language set in
+        config.h, even if that language is changed after registration.
+  * Command-line options that take values now use an "=" instead of a space
+        between the option name and the value.
+  * The database conversion utility (convert-db) now outputs an XML
+        database file, which can be used with the XML import feature,
+        rather than writing databases directly.
+  * The configuration script "configure" now asks fewer questions, and can
+        be completely automated if the "-prefix" option is used.
+  * "configure" now understands GNU-style options, e.g.: --prefix=/usr
+  - The AUTODEOP and NOJOIN channel levels have been removed in favor of
+        the SECUREOPS and RESTRICTED channel options.
+  - The deprecated CheckClones functionality has been removed in favor of
+        session limiting.
+  - The IrcIIHelp pseudoclient (online help for the ircII client) has been
+        removed.
+  - The "listnicks" and "listchans" programs have been removed in favor of
+        the built-in HTTP server.
+
+------------
+Version 4.5:
+------------
+  ! I'm Back: Andrew Church <achurch@achurch.org> (new address) is once
+        again taking over Services development.
+  ! NOTICE to those using encryption:  Services 4.4.x and earlier had a bug
+        in the encryption routine causing passwords to be incorrectly
+        encrypted.  This bug is fixed in 4.5.0, but as a consequence, all
+        passwords set in earlier versions are not directly readable by
+        Services.  A workaround is available in the "configure" script, but
+        enabling this workaround may decrease the security of some
+        passwords.  I recommend enabling the workaround for the first 30
+        days (or whatever you have your nickname expiration period set to),
+        adding a logon news item asking users to set their password again
+        (this can be the same as the old password, as long as they run the
+        SET PASSWORD command again), and disabling the workaround after
+        that time has passed.
+  + Added SOP, AOP, and VOP commands as an alternate method of managing
+        channel access lists.  (ACCESS can still be used as before.)
+  + Added experimental support for the Unreal server (version 3.1.1).  When
+        using the Unreal server, ChanServ supports the commands HOP, HALFOP,
+        DEHALFOP, PROTECT, and DEPROTECT, and the following access levels:
+          - AUTOHALFOP (automatic mode +h), level 4 (HOP)
+          - HALFOP (can use HALFOP/DEHALFOP commands), level 4 (HOP)
+          - AUTOPROTECT (automatic mode +a), level 10 (SOP)
+          - PROTECT (can use PROTECT/DEPROTECT commands), level 10 (SOP)
+  + Services now supports the "Services stamp" feature in DAL 4.4.15+
+        compatible servers (including Dreamforge, Bahamut, and Unreal).
+        This feature allows Services to attach an ID value to each user
+        which will be retained even when the network splits, for increased
+        security when re-granting privileges after a split.
+  + Added support for suspending channels.  Like suspended nicknames, all
+        settings will be retained during the suspension period.
+  + Channel modes can now be buffered to reduce "mode flooding".
+  + Services can now be configured to require an E-mail address at nickname
+        registration time.
+  + Users can now be warned when their nicks are about to expire.
+  + Added UNSET command to NickServ and ChanServ for clearing URLs and
+        E-mail addresses.
+  + Added VOICE and DEVOICE commands to ChanServ, and VOICE access level
+        (default 3, the same as auto-voice).
+  + Added OperServ CLEARCHAN command to remove all users from a channel.
+  + Added OperServ SU command to allow any Services admin to gain super-user
+        privileges (with the appropriate password).
+  + Services will now log changes to nickname E-mail addresses.
+  + Services can now be configured to send warnings and/or suspend nicks and
+        channels when there are a large number of bad password attempts on
+        them; see the new BadPassWarning and BadPassSuspend options.
+  + Time specifications (in services.conf, for autokills, etc.) can now
+        include multiple units, for example "1h30m".
+  + Sending a SIGUSR2 signal to Services will cause the log file to be
+        closed and reopened.  Use in combination with "mv" to rotate the
+        log file.
+  + The import-db utility can now convert databases from the Sirv (versions
+        1.4.0 and 2.7.0), Daylight, Epona (version 1.3.4), and PTlink
+        (version 2.18.0 and above) programs.
+  + German and Dutch are now available as language options.
+  * Support for the DALnet Bahamut server has been improved.  Note that
+        only versions 1.4.23 and later are supported (support for earlier
+        versions has been dropped).
+  * Services will now check E-mail and URL addresses for nicks and channels
+        to ensure that they are syntactically valid.
+  * The OPDEOP channel access level has been renamed to OP-DEOP.
+  * OperServ ROTATELOG command removed in favor of the signal method.
+  * Services has been greatly optimized, easing operations on large
+        networks or low-power servers.
+  * Many, many bugs have been fixed.
+
+New configuration options:
+  + BadPassWarning   : Sets the bad password limit per nick/channel before
+        sending a WALLOPS/GLOBOPS warning.
+  + BadPassSuspend   : Sets the bad password limit per nick/channel before
+        automatically suspending the nick/channel in question.
+  + MergeChannelModes: Merges multiple channel mode changes into one message.
+  + NoBouncyModes    : Disable mode-bounce checking.
+  + NSExpireWarning  : Sets the time before expiration during which the user
+        is warned that their nick will expire soon.
+  + NSRequireEmail   : Makes Services require an E-mail address upon nick
+        registration.
+  + NSMaxLinkDepth   : Sets the maximum depth for nested nickname links.
+  + PingFrequency    : Sets the period after which a PING message is sent.
+  + ServerNumeric    : Sets the server numeric for Services (Unreal only).
+  + WallOSChannel    : Send a wallops/globops on MODE/KICK/CLEAR{MODES,CHAN}.
+  + WallSU           : Send a wallops/globops on OperServ SU.
+  + SessionLimitAkill: Automatically adds an autokill when a session limit
+        is exceeded repeatedly.
+Removed configuration options:
+  * WallOSMode, WallOSKick, and WallOSClearmodes removed in favor of
+        WallOSChannel.  These options can no longer be set separately.
+  * Deprecated configuration directive "ListOpersOnly" removed.  Use
+        "NSListOpersOnly" and "CSListOpersOnly" instead.
+
+------------
+Version 4.4:
+------------
+  + Support for DALnet's Bahamut ircd has been added. It should be noted that
+    the Bahamut ircd is still being developed and may not be stable yet. If
+    you are going to use the Bahamut ircd, use version 1.2 or later.
+  + Nicknames can be suspended, preventing people from identifying for them.
+    However, suspended nicknames retain all their settings, unlike forbidden
+    nicknames, and can be used to deny the use of a nickname temporarily with
+    the intention to eventually give it back.
+  + Made forbidden nicks and channels more robust.
+  + Began the addition of an internal Statistics Server (StatServ).
+  * Fixed many little bugs in the help system, such as the wrong help being
+    shown to Services Admins.
+
+New configuration options:
+  + StatServName   : Nickname of the Statistics server pseudo client.
+  + StatServDB     : Filename of statistic database (not yet used).
+  + ImmediatelySendAkill: Send AKILL to servers as it is added.
+  + WallOSException: Send a wallops when a session limit exception is added.
+  + SSOpersOnly    :  Limits StatServ use to opers only.
+  + NSSuspendExpire: Expiry time for nick suspends.
+  + NSSuspendGrace : Minimum amount of time a nick must exist for, after
+        being unsuspended, before it can expire.
+  + CSSuspendExpire: Expiry time for channel suspendes.
+  + CSSuspendGrace : Minimum amount of time a channel must exist for, after
+        being unsuspended, before it can expire.
+
+------------
+Version 4.3:
+------------
+  + Due to a lack of time, Andy Church has handed over the maintenance and
+    development of Services to myself, Andrew Kempe. To quote him, "I have
+    (I hope) created something people find useful; I don't want to let it
+    rot for my own lack of time to continue work on it." Although he's left
+    large shoes to fill, I hope to continue his work in the same light. I'd
+    also like to stress that even though I'm the new, quoted, "maintainer"
+    (*cringe*) of services, I'm always open to constructive critisim,
+    suggestions and the like. I hope Andy will remain associated with Services
+    and it's development, even if only in a minor role/way. Andy, thanks for
+    a great codebase upon which to develop! Finally, there will be a couple
+    of changes taking place, such as a new distribution site and a new mailing
+    list address. These changes are detailed below.
+  + New Services mailing list address: ircservices@ender.shadowfire.org
+    Everyone who was on the old mailing list, as of 1999/08/12, has been moved
+    to the new list. See section 9 of the README for information about using
+    this list.
+  + New Services website:
+        http://ender.shadowfire.org/ircservices/
+  + New Services distribution sites:
+        Official: ftp://ender.shadowfire.org/pub/ircservices/
+        Mirror:   ftp://ftp.electrocity.com/pub/ircservices/
+    I will try to get all the previous versions of Services online there soon.
+  + Services can now limit the number of client connections per hostname. This
+    is intended to supercede the CheckClones code. It is also possible to
+    specify limits for specific hosts or hostmasks. Users causing the limit
+    to be exceeded are killed.
+  + Extended the INFO and AKICK commands.
+    display hidden/additional information.
+  + Services now supports DALnet's +r usermode and +r/+R channel modes.
+  + See Changes.lang for a list of the new/modified language strings.
+
+New configuration options:
+  + NSSecureAdmins : When enabled, prevents the use of the DROP, GETPASS, and
+        SET PASSWORD commands by Services admins on other Services admins or
+        the Services root.
+  + WallExceptionExpire: Send a WALLOPS/GLOBOPS when an exception expires.
+  + LimitSessions  : Enables session limiting.
+  + DefSessionLimit: Default session limit per hostname.
+  + MaxSessionLimit: Maximum session limit for a session limit exception.
+  + ExceptionExpiry: Default expiry time for a session limit exception.
+  + SessionLimitExceeded: KILL message used when enforcing a session limit.
+  + SessionLimitDetailsLoc: Message NOTICE'd to a user before they're killed to
+        enforce a session limit.
+
+------------
+Version 4.2:
+------------
+  + Default flags for newly registered nicks can now be configured via
+        services.conf.
+  + The NickServ LINK command can now be disabled via an option in
+        services.conf.
+  + Services admins can list all nicks linked to a given one.
+  + Forbidden and no-expire nicks can be listed by Services admins with the
+        NickServ LIST command.
+  + Services will (optionally) log when a new user maximum is reached.
+  + Services can now be configured to automatically kill users which
+        trigger its clone detection.  This option is HIGHLY DISCOURAGED,
+        however; see data/example.conf for details.
+
+New configuration options:
+  + NSDef...       : Default flags for newly registered nicknames.
+  + NSEnforcerUser : Username/hostname for NickServ kill enforcement
+        (previously "enforcer"@services.hostname).
+  + NSDisableLinkCommand: Disables use of the NickServ LINK command.
+  + NSListOpersOnly: Like ListOpersOnly, but only applies to NickServ.
+  + NSListMax      : Maximum number of nicks displayed for NickServ LIST.
+  + CSListOpersOnly: Like ListOpersOnly, but only applies to ChanServ.
+  + CSListMax      : Maximum number of channels displayed for ChanServ LIST.
+  + CSRestrictDelay: Amount of time to wait after startup before enforcing
+        RESTRICTED/NOJOIN (only partially works).
+  + WallAkillExpire: Send a WALLOPS/GLOBOPS when an autokill expires.
+  + The clone kill option name has been intentionally omitted to force
+        users to read the documentation before using it.
+
+------------
+Version 4.1:
+------------
+  + Most features of Services can now (finally!) be configured via a
+        control file (like ircd's ircd.conf) rather than requiring changes
+        to be made in config.h.  See the README for more information.
+  + Added database importer to allow the use of databases created by other
+        Services-like programs.
+  + Added news system, allowing users to be sent a message when they
+        connect to the network and/or /oper.
+  + Added channel "successor" setting, allowing a "secondary founder" to be
+        designated who will receive control of the channel if the founder's
+        nick expires.
+  + ChanServ will now send more informative error messages when users try
+        to use the DALnet AOP and SOP commands.
+  + Added ChanServ SET OPNOTICE and SET LEAVEOPS settings.
+  + Several more list-type commands can use number lists and ranges
+        (MemoServ LIST/READ, ChanServ ACCESS/AKICK LIST).
+  + Command syntax error messages now obey the user's language setting.
+  + Maximum user count is now dated and saved to disk.
+  + Added vsnprintf() function for systems lacking a real one.
+  * Database error-recovery improved.
+  * Services now compiles warning-free (on all tested systems).
+
+------------
+Version 4.0:
+------------
+This release of Services has two major additions:
+
+  + Multi-language support.  Services can now "speak" in multiple
+        languages; each user can select (on a per-nick basis) which
+        language they would like to receive messages from Services in,
+        including help messages.  Currently supported languages are
+        English, Japanese, Portugese, Spanish, and Turkish; translations
+        into Afrikaans, Dutch, French, and Malaysian are underway.
+  + Nick linking.  Nicknames can now be linked together, allowing a user to
+        keep just one set of nickname settings and memos and have many
+        different "aliases".  Any setting changes made to one of a set of
+        linked nicks will immediately affect all of them; if one of a set
+        of linked nicks is entered in (for example) a channel access list,
+        then the user will have the same access level when using any nick
+        in that set.
+
+In addition, there is now a mailing list for Services discussion and
+announcements.  To subscribe, send mail to services-request@dragonfire.net
+with a subject of "subscribe" and a body of "subscribe <your-address>"
+(without the angle brackets).  More information is at the bottom of the
+README.
+
+Services also has a World Wide Web site, located at:
+        http://achurch.dragonfire.net/services/
+
+Other notable additions/changes include:
+
+  + Services will now track a user's IDENTIFY's across nick changes and
+        network splits (on networks with some sort of timestamp support).
+        An IDENTIFY now lasts until the user disconnects from IRC.
+  + Channels can now receive memos.  By default, any user with access level
+        10 or higher on a channel can list, read, and delete channel memos.
+  + Users' last quit messages are now recorded and displayed in NickServ
+        INFO.
+  + Users can choose to hide parts of their nickname information from other
+        users in the NickServ INFO display.
+  + NickServ's SET KILL command now has QUICK and IMMED options to reduce
+        the time before a kill to 20 seconds or kill immediately,
+        respectively.  (However, the IMMED option is disabled by default in
+        config.h.)
+  + Nickname and channel URLs and E-mail addresses can be unset by passing
+        no parameter.
+  + A message can be set for a channel which will be /notice'd to a user
+        when the user enters the channel.
+  + Users can now set their own memo limits within the range 0 through
+        DEF_MEMO_MAX with the SET LIMIT command.
+  + The MemoServ DEL command now understands ranges (x-y) and commas.
+  + MemoServ now has an INFO command, which reports the total number of
+        memos, number of unread memos, and memo limit for the user giving
+        the command.  Services admins can view that information for any
+        user.
+  + A new OperServ privilege level has been added: Services operator.  The
+        OperServ MODE, KICK, and AKILL commands have been restricted to
+        Services operators and above.
+  + A new OperServ command has been added: CLEARMODES, for Services
+        operators, which will clear all modes, bans, and optionally +o/+v
+        from any channel.
+  + Services admins can now disable expiration of specific nicknames and
+        channels with the NickServ and ChanServ SET NOEXPIRE command, and
+        can set any nick or channel parameters (including passwords)
+        without needing to use the IDENTIFY command.
+  + Services can now be configured to send a WALLOPS/GLOBOPS when the
+        OperServ MODE, CLEARMODES, and/or KICK commands are used.
+  * Services databases have been made portable; they can be moved from one
+        machine / CPU type to another safely.
+  * Services should now be happier about compiling under OS/2 and various
+        different Unices.
+  * Services now gets time zone information from the system rather than
+        requiring it to be defined in config.h or given on the command line.
+
+
+------------
+Version 3.3:
+------------
+Version 3.3 is primarily a maintenance release, getting a lot of bug fixes
+out and significantly optimizing the code.  Other notable changes:
+
+  + MemoServ LIST and READ commands have new forms: LIST NEW and READ LAST.
+  + Nicknames now have a PRIVATE flag, preventing them from appearing in
+        LIST results.
+  + Nicknames' last-seen times are now updated periodically while a nick's
+        owner is online.
+  + Network reads and writes are now buffered.
+  * Channel auto-voice is now enabled by default at an access level of 3.
+  * NickServ STATUS output changed; the word "STATUS" is now included at
+        the beginning of each line.
+
+
+------------
+Version 3.2:
+------------
+
+  + URL and E-mail address fields added to nickname and channel records.
+  + Frequency-of-use limit added to NickServ REGISTER command, much like
+        the frequency-of-use limit on MemoServ SEND command.
+  + Services admins can now be set online (using the OperServ ADMIN
+        command), and no longer need to be defined in config.h.
+  + OperServ RESTART command added to allow Services to be terminated and
+        restarted without needing command-line intervention.
+  * ~ at the beginning of a username (added by many IRC servers when an
+        ident response is not received) is no longer ignored, which
+        eliminates channel autokick problems on such servers.
+  * IRC server message processing code modularized, which should simplify
+        adding support for additional protocols.
+  * More bugs squashed, as usual.
+
+
+------------
+Version 3.1:
+------------
+
+  + A limit can be set on the number of memos a nick can keep, and the
+        limit can be varied or removed on a per-nick basis.
+  + A limit can be set on the maximum number of channels a nick can
+        register.  (This is not yet settable on a per-nick basis.)
+  + The permissible frequency of use of the MemoServ SEND command can be
+        set to prevent (or at least limit) memo flooding; for example, the
+        default configuration prevents users from using the SEND command
+        more often than once every five seconds.
+  + Memo notification can be enabled or disabled on a per-nick basis.
+  + OperServ autokills can be set to expire after a certain period of time,
+        and can default to either not expiring or to having a certain
+        duration.
+  + Slightly increased protocol support: basic support for ircd.dal 4.4.x
+        (x >= 15) is now present, as is support for the ircu GLINE command.
+        Services should also work better with classic irc2.x servers.
+  * Clone detection actually works now.
+  * Many, many bugs fixed, as usual.  Also removed a typo in os-help.c that
+        somehow made it into the 3.0.10 distribution.
+
+
+------------
+Version 3.0: (changes since 2.2.26)
+------------
+
+  + ChanServ access levels can finally be customized!  ChanServ has a new
+        command, LEVELS, which allows the numeric access levels to be
+        fine-tuned for each channel.  There are 11 settings available,
+        each of which corresponds to a particular ChanServ command or
+        function; for example, one can set the level at which users are
+        automatically opped, and one can define a level at which users
+        are to be automatically voiced as well.
+  + Services admins can now view channel access and autokick lists and
+        nickname access lists.
+  + Read-only mode can now be set (and unset) both from the command line
+        and during operation.
+  * Channel access lists may now only contain registered nicknames; this
+        allows Services to run much faster and simplifies channel access
+        checks.
+  * Numerous bugs, memory leaks, and potential security holes squashed.

docs/b.html

@@ -0,0 +1,721 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual - Appendix B. XML data format description</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Appendix B. XML data format description</h2>
+
+<p>B-1. <a href="#1">Data file structure</a>
+<br>B-2. <a href="#2">Tag index</a>
+
+<p align=right><font size=-1><a href="index.html">Table of Contents</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=1></a>
+<h3>B-1. Data file structure</h3>
+
+<p>The example data below shows the structure of the XML data used by
+Services; click on a tag for information about that tag (from the
+<a href="#2">tag index</a> below).  An ellipsis (<tt>...</tt>) indicates
+where data is entered.
+
+<p>
+<pre>
+&lt;<a href="#ircservices-db">ircservices-db</a>&gt;
+    &lt;<a href="#constants">constants</a>&gt;
+        &lt;<A HREF="#LANG_DEFAULT">LANG_DEFAULT</A>&gt;...&lt;/<A HREF="#LANG_DEFAULT">LANG_DEFAULT</A>&gt;
+        &lt;<A HREF="#CHANMAX_UNLIMITED">CHANMAX_UNLIMITED</A>&gt;...&lt;/<A HREF="#CHANMAX_UNLIMITED">CHANMAX_UNLIMITED</A>&gt;
+        &lt;<A HREF="#CHANMAX_DEFAULT">CHANMAX_DEFAULT</A>&gt;...&lt;/<A HREF="#CHANMAX_DEFAULT">CHANMAX_DEFAULT</A>&gt;
+        &lt;<A HREF="#TIMEZONE_DEFAULT">TIMEZONE_DEFAULT</A>&gt;...&lt;/<A HREF="#TIMEZONE_DEFAULT">TIMEZONE_DEFAULT</A>&gt;
+        &lt;<A HREF="#ACCLEV_FOUNDER">ACCLEV_FOUNDER</A>&gt;...&lt;/<A HREF="#ACCLEV_FOUNDER">ACCLEV_FOUNDER</A>&gt;
+        &lt;<A HREF="#ACCLEV_INVALID">ACCLEV_INVALID</A>&gt;...&lt;/<A HREF="#ACCLEV_INVALID">ACCLEV_INVALID</A>&gt;
+        &lt;<A HREF="#ACCLEV_SOP">ACCLEV_SOP</A>&gt;...&lt;/<A HREF="#ACCLEV_SOP">ACCLEV_SOP</A>&gt;
+        &lt;<A HREF="#ACCLEV_AOP">ACCLEV_AOP</A>&gt;...&lt;/<A HREF="#ACCLEV_AOP">ACCLEV_AOP</A>&gt;
+        &lt;<A HREF="#ACCLEV_HOP">ACCLEV_HOP</A>&gt;...&lt;/<A HREF="#ACCLEV_HOP">ACCLEV_HOP</A>&gt;
+        &lt;<A HREF="#ACCLEV_VOP">ACCLEV_VOP</A>&gt;...&lt;/<A HREF="#ACCLEV_VOP">ACCLEV_VOP</A>&gt;
+        &lt;<A HREF="#ACCLEV_NOP">ACCLEV_NOP</A>&gt;...&lt;/<A HREF="#ACCLEV_NOP">ACCLEV_NOP</A>&gt;
+        &lt;<A HREF="#MEMOMAX_UNLIMITED">MEMOMAX_UNLIMITED</A>&gt;...&lt;/<A HREF="#MEMOMAX_UNLIMITED">MEMOMAX_UNLIMITED</A>&gt;
+        &lt;<A HREF="#MEMOMAX_DEFAULT">MEMOMAX_DEFAULT</A>&gt;...&lt;/<A HREF="#MEMOMAX_DEFAULT">MEMOMAX_DEFAULT</A>&gt;
+        &lt;<A HREF="#NEWS_LOGON">NEWS_LOGON</A>&gt;...&lt;/<A HREF="#NEWS_LOGON">NEWS_LOGON</A>&gt;
+        &lt;<A HREF="#NEWS_OPER">NEWS_OPER</A>&gt;...&lt;/<A HREF="#NEWS_OPER">NEWS_OPER</A>&gt;
+        &lt;<A HREF="#MD_AKILL">MD_AKILL</A>&gt;...&lt;/<A HREF="#MD_AKILL">MD_AKILL</A>&gt;
+        &lt;<A HREF="#MD_EXCLUSION">MD_EXCLUDE</A>&gt;...&lt;/<A HREF="#MD_EXCLUDE">MD_EXCLUDE</A>&gt;
+        &lt;<A HREF="#MD_EXCEPTION">MD_EXCEPTION</A>&gt;...&lt;/<A HREF="#MD_EXCEPTION">MD_EXCEPTION</A>&gt;
+        &lt;<A HREF="#MD_SGLINE">MD_SGLINE</A>&gt;...&lt;/<A HREF="#MD_SGLINE">MD_SGLINE</A>&gt;
+        &lt;<A HREF="#MD_SQLINE">MD_SQLINE</A>&gt;...&lt;/<A HREF="#MD_SQLINE">MD_SQLINE</A>&gt;
+        &lt;<A HREF="#MD_SZLINE">MD_SZLINE</A>&gt;...&lt;/<A HREF="#MD_SZLINE">MD_SZLINE</A>&gt;
+    &lt;/<a href="#constants">constants</a>&gt;
+    &lt;<a href="#maxusercnt">maxusercnt</a>&gt;...&lt;/<a href="#maxusercnt">maxusercnt</a>&gt;
+    &lt;<a href="#maxusertime">maxusertime</a>&gt;...&lt;/<a href="#maxusertime">maxusertime</a>&gt;
+    &lt;<a href="#supass">supass</a> [cipher="..."]&gt;...&lt;/<a href="#supass">supass</a>&gt;
+    &lt;<a href="#nickgroupinfo">nickgroupinfo</a>&gt;
+        &lt;<a href="#id">id</a>&gt;...&lt;/<a href="#id">id</a>&gt;
+        &lt;<a href="#nicks">nicks</a> count='...'&gt;
+            &lt;<a href="#array-element">array-element</a>&gt;...&lt;/<a href="#array-element">array-element</a>&gt;
+        &lt;/<a href="#nicks">nicks</a>&gt;
+        &lt;<a href="#mainnick">mainnick</a>&gt;...&lt;/<a href="#mainnick">mainnick</a>&gt;
+        &lt;<a href="#pass">pass</a> [cipher="..."]&gt;...&lt;/<a href="#pass">pass</a>&gt;
+        &lt;<a href="#url">url</a>&gt;...&lt;/<a href="#url">url</a>&gt;
+        &lt;<a href="#email">email</a>&gt;...&lt;/<a href="#email">email</a>&gt;
+        &lt;<a href="#last_email">last_email</a>&gt;...&lt;/<a href="#last_email">last_email</a>&gt;
+        &lt;<a href="#info">info</a>&gt;...&lt;/<a href="#info">info</a>&gt;
+        &lt;<a href="#flags">flags</a>&gt;...&lt;/<a href="#flags">flags</a>&gt;
+        &lt;<a href="#os_priv">os_priv</a>&gt;...&lt;/<a href="#os_priv">os_priv</a>&gt;
+        &lt;<a href="#authcode">authcode</a>&gt;...&lt;/<a href="#authcode">authcode</a>&gt;
+        &lt;<a href="#authset">authset</a>&gt;...&lt;/<a href="#authset">authset</a>&gt;
+        &lt;<a href="#authreason">authreason</a>&gt;...&lt;/<a href="#authreason">authreason</a>&gt;
+	&lt;<a href="#suspend_who">suspend_who</a>&gt;...&lt;/<a href="#suspend_who">suspend_who</a>&gt;
+	&lt;<a href="#suspend_reason">suspend_reason</a>&gt;...&lt;/<a href="#suspend_reason">suspend_reason</a>&gt;
+	&lt;<a href="#suspend_time">suspend_time</a>&gt;...&lt;/<a href="#suspend_time">suspend_time</a>&gt;
+	&lt;<a href="#suspend_expires">suspend_expires</a>&gt;...&lt;/<a href="#suspend_expires">suspend_expires</a>&gt;
+        &lt;<a href="#language">language</a>&gt;...&lt;/<a href="#language">language</a>&gt;
+        &lt;<a href="#timezone">timezone</a>&gt;...&lt;/<a href="#timezone">timezone</a>&gt;
+        &lt;<a href="#channelmax">channelmax</a>&gt;...&lt;/<a href="#channelmax">channelmax</a>&gt;
+        &lt;<a href="#access">access</a> count='...'&gt;
+            &lt;<a href="#array-element">array-element</a>&gt;...&lt;/<a href="#array-element">array-element</a>&gt;
+        &lt;/<a href="#access">access</a>&gt;
+        &lt;<a href="#ajoin">ajoin</a> count='...'&gt;
+            &lt;<a href="#array-element">array-element</a>&gt;...&lt;/<a href="#array-element">array-element</a>&gt;
+        &lt;/<a href="#ajoin">ajoin</a>&gt;
+        &lt;<a href="#memoinfo">memoinfo</a>&gt;
+            &lt;<a href="#memos">memos</a> count='...'&gt;
+                &lt;<a href="#memo">memo</a>&gt;
+                    &lt;<a href="#number">number</a>&gt;...&lt;/<a href="#number">number</a>&gt;
+                    &lt;<a href="#flags">flags</a>&gt;...&lt;/<a href="#flags">flags</a>&gt;
+                    &lt;<a href="#time">time</a>&gt;...&lt;/<a href="#time">time</a>&gt;
+                    &lt;<a href="#sender">sender</a>&gt;...&lt;/<a href="#sender">sender</a>&gt;
+                    &lt;<a href="#channel">channel</a>&gt;...&lt;/<a href="#channel">channel</a>&gt;
+                    &lt;<a href="#text">text</a>&gt;...&lt;/<a href="#text">text</a>&gt;
+                &lt;/<a href="#memo">memo</a>&gt;
+            &lt;/<a href="#memos">memos</a>&gt;
+            &lt;<a href="#memomax">memomax</a>&gt;...&lt;/<a href="#memomax">memomax</a>&gt;
+        &lt;/<a href="#memoinfo">memoinfo</a>&gt;
+        &lt;<a href="#ignore">ignore</a> count='...'&gt;
+            &lt;<a href="#array-element">array-element</a>&gt;...&lt;/<a href="#array-element">array-element</a>&gt;
+        &lt;/<a href="#ignore">ignore</a>&gt;
+    &lt;/<a href="#nickgroupinfo">nickgroupinfo</a>&gt;
+    &lt;<a href="#nickinfo">nickinfo</a>&gt;
+        &lt;<a href="#nick">nick</a>&gt;...&lt;/<a href="#nick">nick</a>&gt;
+        &lt;<a href="#status">status</a>&gt;...&lt;/<a href="#status">status</a>&gt;
+        &lt;<a href="#last_usermask">last_usermask</a>&gt;...&lt;/<a href="#last_usermask">last_usermask</a>&gt;
+        &lt;<a href="#last_realmask">last_realmask</a>&gt;...&lt;/<a href="#last_realmask">last_realmask</a>&gt;
+        &lt;<a href="#last_realname">last_realname</a>&gt;...&lt;/<a href="#last_realname">last_realname</a>&gt;
+        &lt;<a href="#last_quit">last_quit</a>&gt;...&lt;/<a href="#last_quit">last_quit</a>&gt;
+        &lt;<a href="#time_registered">time_registered</a>&gt;...&lt;/<a href="#time_registered">time_registered</a>&gt;
+        &lt;<a href="#last_seen">last_seen</a>&gt;...&lt;/<a href="#last_seen">last_seen</a>&gt;
+        &lt;<a href="#nickgroup">nickgroup</a>&gt;...&lt;/<a href="#nickgroup">nickgroup</a>&gt;
+    &lt;/<a href="#nickinfo">nickinfo</a>&gt;
+    &lt;<a href="#channelinfo">channelinfo</a>&gt;
+        &lt;<a href="#name">name</a>&gt;...&lt;/<a href="#name">name</a>&gt;
+        &lt;<a href="#founder">founder</a>&gt;...&lt;/<a href="#founder">founder</a>&gt;
+        &lt;<a href="#successor">successor</a>&gt;...&lt;/<a href="#successor">successor</a>&gt;
+        &lt;<a href="#founderpass">founderpass</a> [cipher="..."]&gt;...&lt;/<a href="#founderpass">founderpass</a>&gt;
+        &lt;<a href="#desc">desc</a>&gt;...&lt;/<a href="#desc">desc</a>&gt;
+        &lt;<a href="#url">url</a>&gt;...&lt;/<a href="#url">url</a>&gt;
+        &lt;<a href="#email">email</a>&gt;...&lt;/<a href="#email">email</a>&gt;
+        &lt;<a href="#time_registered">time_registered</a>&gt;...&lt;/<a href="#time_registered">time_registered</a>&gt;
+        &lt;<a href="#last_used">last_used</a>&gt;...&lt;/<a href="#last_used">last_used</a>&gt;
+        &lt;<a href="#last_topic">last_topic</a>&gt;...&lt;/<a href="#last_topic">last_topic</a>&gt;
+        &lt;<a href="#last_topic_setter">last_topic_setter</a>&gt;...&lt;/<a href="#last_topic_setter">last_topic_setter</a>&gt;
+        &lt;<a href="#last_topic_time">last_topic_time</a>&gt;...&lt;/<a href="#last_topic_time">last_topic_time</a>&gt;
+        &lt;<a href="#flags">flags</a>&gt;...&lt;/<a href="#flags">flags</a>&gt;
+	&lt;<a href="#suspend_who">suspend_who</a>&gt;...&lt;/<a href="#suspend_who">suspend_who</a>&gt;
+	&lt;<a href="#suspend_reason">suspend_reason</a>&gt;...&lt;/<a href="#suspend_reason">suspend_reason</a>&gt;
+	&lt;<a href="#suspend_time">suspend_time</a>&gt;...&lt;/<a href="#suspend_time">suspend_time</a>&gt;
+	&lt;<a href="#suspend_expires">suspend_expires</a>&gt;...&lt;/<a href="#suspend_expires">suspend_expires</a>&gt;
+        &lt;<a href="#levels">levels</a>&gt;
+            &lt;<A HREF="#CA_INVITE">CA_INVITE</A>&gt;...&lt;/<A HREF="#CA_INVITE">CA_INVITE</A>&gt;
+            &lt;<A HREF="#CA_AKICK">CA_AKICK</A>&gt;...&lt;/<A HREF="#CA_AKICK">CA_AKICK</A>&gt;
+            &lt;<A HREF="#CA_SET">CA_SET</A>&gt;...&lt;/<A HREF="#CA_SET">CA_SET</A>&gt;
+            &lt;<A HREF="#CA_UNBAN">CA_UNBAN</A>&gt;...&lt;/<A HREF="#CA_UNBAN">CA_UNBAN</A>&gt;
+            &lt;<A HREF="#CA_AUTOOP">CA_AUTOOP</A>&gt;...&lt;/<A HREF="#CA_AUTOOP">CA_AUTOOP</A>&gt;
+            &lt;<A HREF="#CA_AUTODEOP">CA_AUTODEOP</A>&gt;...&lt;/<A HREF="#CA_AUTODEOP">CA_AUTODEOP</A>&gt;
+            &lt;<A HREF="#CA_AUTOVOICE">CA_AUTOVOICE</A>&gt;...&lt;/<A HREF="#CA_AUTOVOICE">CA_AUTOVOICE</A>&gt;
+            &lt;<A HREF="#CA_OPDEOP">CA_OPDEOP</A>&gt;...&lt;/<A HREF="#CA_OPDEOP">CA_OPDEOP</A>&gt;
+            &lt;<A HREF="#CA_ACCESS_LIST">CA_ACCESS_LIST</A>&gt;...&lt;/<A HREF="#CA_ACCESS_LIST">CA_ACCESS_LIST</A>&gt;
+            &lt;<A HREF="#CA_CLEAR">CA_CLEAR</A>&gt;...&lt;/<A HREF="#CA_CLEAR">CA_CLEAR</A>&gt;
+            &lt;<A HREF="#CA_NOJOIN">CA_NOJOIN</A>&gt;...&lt;/<A HREF="#CA_NOJOIN">CA_NOJOIN</A>&gt;
+            &lt;<A HREF="#CA_ACCESS_CHANGE">CA_ACCESS_CHANGE</A>&gt;...&lt;/<A HREF="#CA_ACCESS_CHANGE">CA_ACCESS_CHANGE</A>&gt;
+            &lt;<A HREF="#CA_MEMO">CA_MEMO</A>&gt;...&lt;/<A HREF="#CA_MEMO">CA_MEMO</A>&gt;
+            &lt;<A HREF="#CA_VOICE">CA_VOICE</A>&gt;...&lt;/<A HREF="#CA_VOICE">CA_VOICE</A>&gt;
+            &lt;<A HREF="#CA_AUTOHALFOP">CA_AUTOHALFOP</A>&gt;...&lt;/<A HREF="#CA_AUTOHALFOP">CA_AUTOHALFOP</A>&gt;
+            &lt;<A HREF="#CA_HALFOP">CA_HALFOP</A>&gt;...&lt;/<A HREF="#CA_HALFOP">CA_HALFOP</A>&gt;
+            &lt;<A HREF="#CA_AUTOPROTECT">CA_AUTOPROTECT</A>&gt;...&lt;/<A HREF="#CA_AUTOPROTECT">CA_AUTOPROTECT</A>&gt;
+            &lt;<A HREF="#CA_PROTECT">CA_PROTECT</A>&gt;...&lt;/<A HREF="#CA_PROTECT">CA_PROTECT</A>&gt;
+        &lt;/<a href="#levels">levels</a>&gt;
+        &lt;<a href="#chanaccesslist">chanaccesslist</a> count='...'&gt;
+            &lt;<a href="#chanaccess">chanaccess</a>&gt;
+                &lt;<a href="#nickgroup">nickgroup</a>&gt;...&lt;/<a href="#nickgroup">nickgroup</a>&gt;
+                &lt;<a href="#level">level</a>&gt;...&lt;/<a href="#level">level</a>&gt;
+            &lt;/<a href="#chanaccess">chanaccess</a>&gt;
+        &lt;/<a href="#chanaccesslist">chanaccesslist</a>&gt;
+        &lt;<a href="#akicklist">akicklist</a> count='...'&gt;
+            &lt;<a href="#akick">akick</a>&gt;
+                &lt;<a href="#mask">mask</a>&gt;...&lt;/<a href="#mask">mask</a>&gt;
+	        &lt;<a href="#reason">reason</a>&gt;...&lt;/<a href="#reason">reason</a>&gt;
+                &lt;<a href="#who">who</a>&gt;...&lt;/<a href="#who">who</a>&gt;
+                &lt;<a href="#set">set</a>&gt;...&lt;/<a href="#set">set</a>&gt;
+                &lt;<a href="#lastused">lastused</a>&gt;...&lt;/<a href="#lastused">lastused</a>&gt;
+            &lt;/<a href="#akick">akick</a>&gt;
+        &lt;/<a href="#akicklist">akicklist</a>&gt;
+        &lt;<a href="#mlock">mlock</a>&gt;
+            &lt;<a href="#mlock.on">mlock.on</a>&gt;...&lt;/<a href="#mlock.on">mlock.on</a>&gt;
+            &lt;<a href="#mlock.off">mlock.off</a>&gt;...&lt;/<a href="#mlock.off">mlock.off</a>&gt;
+            &lt;<a href="#mlock.limit">mlock.limit</a>&gt;...&lt;/<a href="#mlock.limit">mlock.limit</a>&gt;
+            &lt;<a href="#mlock.key">mlock.key</a>&gt;...&lt;/<a href="#mlock.key">mlock.key</a>&gt;
+            &lt;<a href="#mlock.link">mlock.link</a>&gt;...&lt;/<a href="#mlock.link">mlock.link</a>&gt;
+            &lt;<a href="#mlock.flood">mlock.flood</a>&gt;...&lt;/<a href="#mlock.flood">mlock.flood</a>&gt;
+            &lt;<a href="#mlock.joindelay">mlock.joindelay</a>&gt;...&lt;/<a href="#mlock.joindelay">mlock.joindelay</a>&gt;
+            &lt;<a href="#mlock.joinrate1">mlock.joinrate1</a>&gt;...&lt;/<a href="#mlock.joinrate1">mlock.joinrate1</a>&gt;
+            &lt;<a href="#mlock.joinrate2">mlock.joinrate2</a>&gt;...&lt;/<a href="#mlock.joinrate2">mlock.joinrate2</a>&gt;
+        &lt;/<a href="#mlock">mlock</a>&gt;
+        &lt;<a href="#entry_message">entry_message</a>&gt;...&lt;/<a href="#entry_message">entry_message</a>&gt;
+    &lt;/<a href="#channelinfo">channelinfo</a>&gt;
+    &lt;<a href="#news">news</a>&gt;
+        &lt;<a href="#type">type</a>&gt;...&lt;/<a href="#type">type</a>&gt;
+        &lt;<a href="#num">num</a>&gt;...&lt;/<a href="#num">num</a>&gt;
+        &lt;<a href="#text">text</a>&gt;...&lt;/<a href="#text">text</a>&gt;
+        &lt;<a href="#who">who</a>&gt;...&lt;/<a href="#who">who</a>&gt;
+        &lt;<a href="#time">time</a>&gt;...&lt;/<a href="#time">time</a>&gt;
+    &lt;/<a href="#news">news</a>&gt;
+    &lt;<a href="#maskdata">maskdata</a> type='...'&gt;
+        &lt;<a href="#num">num</a>&gt;...&lt;/<a href="#num">num</a>&gt;
+        &lt;<a href="#mask">mask</a>&gt;...&lt;/<a href="#mask">mask</a>&gt;
+        &lt;<a href="#limit">limit</a>&gt;...&lt;/<a href="#limit">limit</a>&gt;
+        &lt;<a href="#reason">reason</a>&gt;...&lt;/<a href="#reason">reason</a>&gt;
+        &lt;<a href="#who">who</a>&gt;...&lt;/<a href="#who">who</a>&gt;
+        &lt;<a href="#time">time</a>&gt;...&lt;/<a href="#time">time</a>&gt;
+        &lt;<a href="#expires">expires</a>&gt;...&lt;/<a href="#expires">expires</a>&gt;
+        &lt;<a href="#lastused">lastused</a>&gt;...&lt;/<a href="#lastused">lastused</a>&gt;
+    &lt;/<a href="#maskdata">maskdata</a>&gt;
+    &lt;<a href="#serverstats">serverstats</a>&gt;
+        &lt;<a href="#name">name</a>&gt;...&lt;/<a href="#name">name</a>&gt;
+        &lt;<a href="#t_join">t_join</a>&gt;...&lt;/<a href="#t_join">t_join</a>&gt;
+        &lt;<a href="#t_quit">t_quit</a>&gt;...&lt;/<a href="#t_quit">t_quit</a>&gt;
+        &lt;<a href="#quit_message">quit_message</a>&gt;...&lt;/<a href="#quit_message">quit_message</a>&gt;
+    &lt;/<a href="#serverstats">serverstats</a>&gt;
+&lt;/<a href="#ircservices-db">ircservices-db</a>&gt;
+</pre>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=2></a>
+<h3>B-2. Tag index</h3>
+
+<dl>
+
+<dt><a name="ircservices-db"></a><b><tt>ircservices-db</tt></b>
+    <dd>The enclosing tag for the entire database.
+
+<dt><a name="constants"></a><b><tt>constants</tt></b>
+    <dd>Contains the various constant values used in this data set.
+
+<dt><a name="LANG_DEFAULT"></a><b><tt>LANG_DEFAULT</tt></b>
+    <dd>Contains the value of the <tt>LANG_DEFAULT</tt> constant as a
+	decimal integer.
+
+<dt><a name="CHANMAX_UNLIMITED"></a><b><tt>CHANMAX_UNLIMITED</tt></b>
+    <dd>Contains the value of the <tt>CHANMAX_UNLIMITED</tt> constant as a
+	decimal integer.
+
+<dt><a name="CHANMAX_DEFAULT"></a><b><tt>CHANMAX_DEFAULT</tt></b>
+    <dd>Contains the value of the <tt>CHANMAX_DEFAULT</tt> constant as a
+	decimal integer.
+
+<dt><a name="TIMEZONE_DEFAULT"></a><b><tt>TIMEZONE_DEFAULT</tt></b>
+    <dd>Contains the value of the <tt>TIMEZONE_DEFAULT</tt> constant as a
+	decimal integer.
+
+<dt><a name="ACCLEV_FOUNDER"></a><b><tt>ACCLEV_FOUNDER</tt></b>
+    <dd>Contains the value of the <tt>ACCLEV_FOUNDER</tt> constant as a
+	decimal integer.
+
+<dt><a name="ACCLEV_INVALID"></a><b><tt>ACCLEV_INVALID</tt></b>
+    <dd>Contains the value of the <tt>ACCLEV_INVALID</tt> constant as a
+	decimal integer.
+
+<dt><a name="ACCLEV_SOP"></a><b><tt>ACCLEV_SOP</tt></b>
+    <dd>Contains the value of the <tt>ACCLEV_SOP</tt> constant as a
+	decimal integer.
+
+<dt><a name="ACCLEV_AOP"></a><b><tt>ACCLEV_AOP</tt></b>
+    <dd>Contains the value of the <tt>ACCLEV_AOP</tt> constant as a
+	decimal integer.
+
+<dt><a name="ACCLEV_HOP"></a><b><tt>ACCLEV_HOP</tt></b>
+    <dd>Contains the value of the <tt>ACCLEV_HOP</tt> constant as a
+	decimal integer.
+
+<dt><a name="ACCLEV_VOP"></a><b><tt>ACCLEV_VOP</tt></b>
+    <dd>Contains the value of the <tt>ACCLEV_VOP</tt> constant as a
+	decimal integer.
+
+<dt><a name="ACCLEV_NOP"></a><b><tt>ACCLEV_NOP</tt></b>
+    <dd>Contains the value of the <tt>ACCLEV_NOP</tt> constant as a
+	decimal integer.
+
+<dt><a name="MEMOMAX_UNLIMITED"></a><b><tt>MEMOMAX_UNLIMITED</tt></b>
+    <dd>Contains the value of the <tt>MEMOMAX_UNLIMITED</tt> constant as a
+	decimal integer.
+
+<dt><a name="MEMOMAX_DEFAULT"></a><b><tt>MEMOMAX_DEFAULT</tt></b>
+    <dd>Contains the value of the <tt>MEMOMAX_DEFAULT</tt> constant as a
+	decimal integer.
+
+<dt><a name="NEWS_LOGON"></a><b><tt>NEWS_LOGON</tt></b>
+    <dd>Contains the value of the <tt>NEWS_LOGON</tt> constant as a
+	decimal integer.
+
+<dt><a name="NEWS_OPER"></a><b><tt>NEWS_OPER</tt></b>
+    <dd>Contains the value of the <tt>NEWS_OPER</tt> constant as a
+	decimal integer.
+
+<dt><a name="MD_AKILL"></a><b><tt>MD_AKILL</tt></b>
+    <dd>Contains the value of the <tt>MD_AKILL</tt> constant as a
+	decimal integer.
+
+<dt><a name="MD_EXCLUDE"></a><b><tt>MD_EXCLUDE</tt></b>
+    <dd>Contains the value of the <tt>MD_EXCLUDE</tt> constant as a
+	decimal integer.
+
+<dt><a name="MD_EXCEPTION"></a><b><tt>MD_EXCEPTION</tt></b>
+    <dd>Contains the value of the <tt>MD_EXCEPTION</tt> constant as a
+	decimal integer.
+
+<dt><a name="MD_SGLINE"></a><b><tt>MD_SGLINE</tt></b>
+    <dd>Contains the value of the <tt>MD_SGLINE</tt> constant as a
+	decimal integer.
+
+<dt><a name="MD_SQLINE"></a><b><tt>MD_SQLINE</tt></b>
+    <dd>Contains the value of the <tt>MD_SQLINE</tt> constant as a
+	decimal integer.
+
+<dt><a name="MD_SZLINE"></a><b><tt>MD_SZLINE</tt></b>
+    <dd>Contains the value of the <tt>MD_SZLINE</tt> constant as a
+	decimal integer.
+
+<dt><a name="maxusercnt"></a><b><tt>maxusercnt</tt></b>
+    <dd>Contains the maximum number of users seen on the network as a
+	decimal integer.
+
+<dt><a name="maxusertime"></a><b><tt>maxusertime</tt></b>
+    <dd>Contains the timestamp of the time when the maximum number of users
+	on the network was recorded as a decimal integer.
+
+<dt><a name="supass"></a><b><tt>supass</tt></b>
+    <dd>Contains the password for the OperServ
+	<a href="4.html#oper.su"><tt>SU</tt></a> command.  If the "cipher"
+	attribute is given, it specifies the name of the algorithm used to
+	encrypt the password; if not given, the password is not encrypted.
+
+<dt><a name="nickgroupinfo"></a><b><tt>nickgroupinfo</tt></b>
+    <dd>Contains data related to a single nickname group.
+
+<dt><a name="id"></a><b><tt>id</tt></b>
+    <dd>Contains the ID value for this nickname group as a decimal integer.
+	The ID value is a positive integer unique across all nickname groups.
+
+<dt><a name="nicks"></a><b><tt>nicks count='<i>n</i>'</tt></b>
+    <dd>Contains <tt><i>n</i></tt>
+	<tt>&lt;<a href="#array-element">array-element</a>&gt;</tt> tags
+	which contain the nicknames associated with this nickname group.
+
+<dt><a name="array-element"></a><b><tt>array-element</tt></b>
+    <dd>Contains a text string used as an array element.
+
+<dt><a name="mainnick"></a><b><tt>mainnick</tt></b>
+    <dd>Contains the index number in the <tt>nicks</tt> array of the main
+	nick for the nick group as a decimal integer.
+
+<dt><a name="pass"></a><b><tt>pass</tt></b>
+    <dd>Contains a nickname group password.  If the "cipher" attribute is
+	given, it specifies the name of the algorithm used to encrypt the
+	password; if not given, the password is not encrypted.
+
+<dt><a name="url"></a><b><tt>url</tt></b>
+    <dd>Contains a URL for a nickname group or channel.
+
+<dt><a name="email"></a><b><tt>email</tt></b>
+    <dd>Contains an E-mail address for a nickname group or channel.
+
+<dt><a name="last_email"></a><b><tt>last_email</tt></b>
+    <dd>Contains the last authenticated E-mail address for a nickname
+	group, if the E-mail address has been changed and not yet been
+	authenticated.
+
+<dt><a name="info"></a><b><tt>info</tt></b>
+    <dd>Contains the information text for a nickname group.
+
+<dt><a name="authcode"></a><b><tt>authcode</tt></b>
+    <dd>Contains the authentication code for a nickname group as a decimal
+	integer.  If no authentication code is set, contains the number 0
+	(zero).
+
+<dt><a name="authset"></a><b><tt>authset</tt></b>
+    <dd>Contains the timestamp of the time at which the nickname group's
+	authentication code was set, if an authentication code is set.
+
+<dt><a name="authreason"></a><b><tt>authreason</tt></b>
+    <dd>Contains the reason code for the nickname group's authentication
+	code, if an authentication code is set.
+
+<dt><a name="suspend_who"></a><b><tt>suspend_who</tt></b>
+    <dd>Contains the nickname responsible for suspending a nickname or
+	channel.
+
+<dt><a name="suspend_reason"></a><b><tt>suspend_reason</tt></b>
+    <dd>Contains the reason for suspending a nickname or channel.
+
+<dt><a name="suspend_time"></a><b><tt>suspend_time</tt></b>
+    <dd>Contains the timestamp of the time the nickname or channel was
+	suspended as a decimal integer.
+
+<dt><a name="suspend_expires"></a><b><tt>suspend_expires</tt></b>
+    <dd>Contains the timestamp of the time the nickname's or channel's
+	suspension expires (or zero if the suspension does not expire) as
+	a decimal integer.
+
+<dt><a name="flags"></a><b><tt>flags</tt></b>
+    <dd>Contains flags for a nickname or channel as a decimal integer.
+
+<dt><a name="os_priv"></a><b><tt>os_priv</tt></b>
+    <dd>Contains the OperServ privilege level of a nickname group as a
+	decimal integer.
+
+<dt><a name="language"></a><b><tt>language</tt></b>
+    <dd>Contains the language (or <tt>LANG_DEFAULT</tt>) selected for a
+	nickname group as a decimal integer.
+
+<dt><a name="timezone"></a><b><tt>timezone</tt></b>
+    <dd>Contains the timezone offset from UTC in minutes (or
+	<tt>TIMEZONE_DEFAULT</tt>) selected for the nickname as a decimal
+	integer.
+
+<dt><a name="channelmax"></a><b><tt>channelmax</tt></b>
+    <dd>Contains the maximum number of channels a nickname group is
+	permitted to register (or <tt>CHANMAX_UNLIMITED</tt> or
+	<tt>CHANMAX_DEFAULT</tt>) as a decimal integer.
+
+<dt><a name="access"></a><b><tt>access count='<i>n</i>'</tt></b>
+    <dd>Contains <tt><i>n</i></tt>
+	<tt>&lt;<a href="#array-element">array-element</a>&gt;</tt> tags
+	containing the nickname group's access list entries.
+
+<dt><a name="ajoin"></a><b><tt>ajoin count='<i>n</i>'</tt></b>
+    <dd>Contains <tt><i>n</i></tt>
+	<tt>&lt;<a href="#array-element">array-element</a>&gt;</tt> tags
+	containing the nickname group's autojoin list entries.
+
+<dt><a name="memoinfo"></a><b><tt>memoinfo</tt></b>
+    <dd>Contains a nickname group or channel's memo data.
+
+<dt><a name="memos"></a><b><tt>memos count='<i>n</i>'</tt></b>
+    <dd>Contains <tt><i>n</i></tt> <tt>&lt;<a href="#memo">memo</a>&gt;</tt>
+	tags containing memos.
+
+<dt><a name="memo"></a><b><tt>memo</tt></b>
+    <dd>Contains the data for a single memo.
+
+<dt><a name="number"></a><b><tt>number</tt></b>
+    <dd>Contains the number of the memo as a decimal integer.
+
+<dt><a name="time"></a><b><tt>time</tt></b>
+    <dd>Contains the timestamp of the time a memo was sent or the time a
+	news or mask-data entry was added as a decimal integer.
+
+<dt><a name="sender"></a><b><tt>sender</tt></b>
+    <dd>Contains the nickname of the sender of the memo.
+
+<dt><a name="channel"></a><b><tt>channel</tt></b>
+    <dd>If the memo is a channel memo, contains the name of the channel the
+	memo was sent to.
+
+<dt><a name="text"></a><b><tt>text</tt></b>
+    <dd>Contains the text of a memo or news item.
+
+<dt><a name="memomax"></a><b><tt>memomax</tt></b>
+    <dd>Contains the maximum number of memos the nickname group or channel
+	is allowed to store (or <tt>MEMOMAX_UNLIMITED</tt> or
+	<tt>MEMOMAX_DEFAULT</tt>) as a decimal integer.
+
+<dt><a name="ignore"></a><b><tt>ignore count='<i>n</i>'</tt></b>
+    <dd>Contains <tt><i>n</i></tt>
+	<tt>&lt;<a href="#array-element">array-element</a>&gt;</tt> tags
+	containing the nickname group's memo ignore list entries.
+
+<dt><a name="nickinfo"></a><b><tt>nickinfo</tt></b>
+    <dd>Contains data for a single nickname.
+
+<dt><a name="nick"></a><b><tt>nick</tt></b>
+    <dd>Contains the nickname with which the data is associated.
+
+<dt><a name="status"></a><b><tt>status</tt></b>
+    <dd>Contains the nickname's "status" field as a decimal integer.
+
+<dt><a name="last_usermask"></a><b><tt>last_usermask</tt></b>
+    <dd>Contains the nickname's last seen usermask (possibly including a
+	fakehost).
+
+<dt><a name="last_realmask"></a><b><tt>last_realmask</tt></b>
+    <dd>Contains the nickname's last seen real usermask.
+
+<dt><a name="last_realname"></a><b><tt>last_realname</tt></b>
+    <dd>Contains the nickname's last seen real name.
+
+<dt><a name="last_quit"></a><b><tt>last_quit</tt></b>
+    <dd>Contains the nickname's last quit message.
+
+<dt><a name="time_registered"></a><b><tt>time_registered</tt></b>
+    <dd>Contains the timestamp of the time the nickname or channel was
+	registered as a decimal integer.
+
+<dt><a name="last_seen"></a><b><tt>last_seen</tt></b>
+    <dd>Contains the timestamp of the last time the nickname's owner was
+	seen online as a decimal integer.
+
+<dt><a name="nickgroup"></a><b><tt>nickgroup</tt></b>
+    <dd>Contains the ID value of the nickname group with which this
+	nickname or channel access list entry is associated.
+
+<dt><a name="channelinfo"></a><b><tt>channelinfo</tt></b>
+    <dd>Contains data for a channel.
+
+<dt><a name="name"></a><b><tt>name</tt></b>
+    <dd>Contains the name of the channel or server with which the following
+	data is associated.
+
+<dt><a name="founder"></a><b><tt>founder</tt></b>
+    <dd>Contains the ID value of the founder's nickname group as a decimal
+	integer.
+
+<dt><a name="successor"></a><b><tt>successor</tt></b>
+    <dd>Contains the ID value of the successor's nickname group as a
+	decimal integer.
+
+<dt><a name="founderpass"></a><b><tt>founderpass</tt></b>
+    <dd>Contains the channel's founder password.  If the "cipher" attribute
+	is given, it specifies the name of the algorithm used to encrypt
+	the password; if not given, the password is not encrypted.
+
+<dt><a name="desc"></a><b><tt>desc</tt></b>
+    <dd>Contains the channel's description.
+
+<dt><a name="last_used"></a><b><tt>last_used</tt></b>
+    <dd>Contains the timestamp of the last time a channel was used.
+
+<dt><a name="last_topic"></a><b><tt>last_topic</tt></b>
+    <dd>Contains the last seen topic of the channel.
+
+<dt><a name="last_topic_setter"></a><b><tt>last_topic_setter</tt></b>
+    <dd>Contains the nickname of the setter of the last seen topic of the
+	channel.
+
+<dt><a name="last_topic_time"></a><b><tt>last_topic_time</tt></b>
+    <dd>Contains the timestamp of the time the last seen topic of the
+	channel was set.
+
+<dt><a name="levels"></a><b><tt>levels</tt></b>
+    <dd>Contains tags for each channel access level.
+
+<dt><a name="CA_INVITE"></a><b><tt>CA_INVITE</tt></b>
+    <dd>Contains the value of the <tt>CA_INVITE</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_AKICK"></a><b><tt>CA_AKICK</tt></b>
+    <dd>Contains the value of the <tt>CA_AKICK</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_SET"></a><b><tt>CA_SET</tt></b>
+    <dd>Contains the value of the <tt>CA_SET</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_UNBAN"></a><b><tt>CA_UNBAN</tt></b>
+    <dd>Contains the value of the <tt>CA_UNBAN</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_AUTOOP"></a><b><tt>CA_AUTOOP</tt></b>
+    <dd>Contains the value of the <tt>CA_AUTOOP</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_AUTODEOP"></a><b><tt>CA_AUTODEOP</tt></b>
+    <dd>Contains the value of the <tt>CA_AUTODEOP</tt> level as a
+	decimal integer.  Always -1 in Services 5.1.
+
+<dt><a name="CA_AUTOVOICE"></a><b><tt>CA_AUTOVOICE</tt></b>
+    <dd>Contains the value of the <tt>CA_AUTOVOICE</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_OPDEOP"></a><b><tt>CA_OPDEOP</tt></b>
+    <dd>Contains the value of the <tt>CA_OPDEOP</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_ACCESS_LIST"></a><b><tt>CA_ACCESS_LIST</tt></b>
+    <dd>Contains the value of the <tt>CA_ACCESS_LIST</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_CLEAR"></a><b><tt>CA_CLEAR</tt></b>
+    <dd>Contains the value of the <tt>CA_CLEAR</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_NOJOIN"></a><b><tt>CA_NOJOIN</tt></b>
+    <dd>Contains the value of the <tt>CA_NOJOIN</tt> level as a
+	decimal integer.  Always -100 in Services 5.1.
+
+<dt><a name="CA_ACCESS_CHANGE"></a><b><tt>CA_ACCESS_CHANGE</tt></b>
+    <dd>Contains the value of the <tt>CA_ACCESS_CHANGE</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_MEMO"></a><b><tt>CA_MEMO</tt></b>
+    <dd>Contains the value of the <tt>CA_MEMO</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_VOICE"></a><b><tt>CA_VOICE</tt></b>
+    <dd>Contains the value of the <tt>CA_VOICE</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_AUTOHALFOP"></a><b><tt>CA_AUTOHALFOP</tt></b>
+    <dd>Contains the value of the <tt>CA_AUTOHALFOP</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_HALFOP"></a><b><tt>CA_HALFOP</tt></b>
+    <dd>Contains the value of the <tt>CA_HALFOP</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_AUTOPROTECT"></a><b><tt>CA_AUTOPROTECT</tt></b>
+    <dd>Contains the value of the <tt>CA_AUTOPROTECT</tt> level as a
+	decimal integer.
+
+<dt><a name="CA_PROTECT"></a><b><tt>CA_PROTECT</tt></b>
+    <dd>Contains the value of the <tt>CA_PROTECT</tt> level as a
+	decimal integer.
+
+<dt><a name="chanaccesslist"></a><b><tt>chanaccesslist count='<i>n</i>'</tt></b>
+    <dd>Contains <tt><i>n</i></tt>
+	<tt>&lt;<a href="#chanaccess">chanaccess</a>&gt;</tt> tags
+	containing the entries on the channel's access list.
+
+<dt><a name="chanaccess"></a><b><tt>chanaccess</tt></b>
+    <dd>Contains the data for a channel access list entry.
+
+<dt><a name="level"></a><b><tt>level</tt></b>
+    <dd>Contains the level for a channel access list entry as a decimal
+	integer.
+
+<dt><a name="akicklist"></a><b><tt>akicklist count='<i>n</i>'</tt></b>
+    <dd>Contains <tt><i>n</i></tt>
+	<tt>&lt;<a href="#akick">akick</a>&gt;</tt> tags containing the
+	entries on the channel's autokick list.
+
+<dt><a name="akick"></a><b><tt>akick</tt></b>
+    <dd>Contains the data for a channel autokick list entry.
+
+<dt><a name="mask"></a><b><tt>mask</tt></b>
+    <dd>Contains the mask associated with a channel autokick or mask-data
+	entry.
+
+<dt><a name="who"></a><b><tt>who</tt></b>
+    <dd>Contains the nickname of the user who added a channel autokick or
+	mask-data entry.
+
+<dt><a name="set"></a><b><tt>set</tt></b>
+    <dd>Contains the timestamp of the time a channel autokick entry was added.
+
+<dt><a name="lastused"></a><b><tt>lastused</tt></b>
+    <dd>Contains the timestamp of the last time a channel autokick or
+	mask-data entry was added.
+
+<dt><a name="mlock"></a><b><tt>mlock</tt></b>
+    <dd>Contains the data for a channel's mode lock.
+
+<dt><a name="mlock.on"></a><b><tt>mlock.on</tt></b>
+    <dd>Contains the string of modes locked on for the channel.
+
+<dt><a name="mlock.off"></a><b><tt>mlock.off</tt></b>
+    <dd>Contains the string of modes locked off for the channel.
+
+<dt><a name="mlock.limit"></a><b><tt>mlock.limit</tt></b>
+    <dd>Contains the channel's locked limit, if any.
+
+<dt><a name="mlock.key"></a><b><tt>mlock.key</tt></b>
+    <dd>Contains the channel's locked key, if any.
+
+<dt><a name="mlock.link"></a><b><tt>mlock.link</tt></b>
+    <dd>Contains the channel's locked link channel, if any.
+
+<dt><a name="mlock.flood"></a><b><tt>mlock.flood</tt></b>
+    <dd>Contains the channel's locked flood setting, if any.
+
+<dt><a name="mlock.joindelay"></a><b><tt>mlock.joindelay</tt></b>
+    <dd>Contains the channel's locked join delay setting, if any.
+
+<dt><a name="mlock.joinrate1"></a><b><tt>mlock.joinrate1</tt></b>
+    <dd>Contains the first part of the channel's locked join rate limit
+	setting, if any.
+
+<dt><a name="mlock.joinrate2"></a><b><tt>mlock.joinrate2</tt></b>
+    <dd>Contains the second part of the channel's locked join rate limit
+	setting, if any.
+
+<dt><a name="entry_message"></a><b><tt>entry_message</tt></b>
+    <dd>Contains the channel's entry message, if any.
+
+<dt><a name="news"></a><b><tt>news</tt></b>
+    <dd>Contains the data for a news item.
+
+<dt><a name="type"></a><b><tt>type</tt></b>
+    <dd>Contains the type of the news item (<tt>NEWS_LOGON</tt> or
+	<tt>NEWS_OPER</tt>) or mask-data entry (<tt>MD_*</tt>) as a decimal
+	integer.
+
+<dt><a name="num"></a><b><tt>num</tt></b>
+    <dd>Contains the number of the news item as a decimal integer.
+
+<dt><a name="maskdata"></a><b><tt>maskdata</tt></b>
+    <dd>Contains the data for a mask-data entry.
+
+<dt><a name="limit"></a><b><tt>limit</tt></b>
+    <dd>Contains the limit for an exception list entry as a decimal integer.
+
+<dt><a name="reason"></a><b><tt>reason</tt></b>
+    <dd>Contains the reason given for an autokick or mask-data entry.
+
+<dt><a name="expires"></a><b><tt>expires</tt></b>
+    <dd>Contains the timestamp of the time at wich a mask-data entry
+	expires (or zero if the entry does not expire) as a decimal integer.
+
+<dt><a name="serverstats"></a><b><tt>serverstats</tt></b>
+    <dd>Contains the data for a StatServ server entry.
+
+<dt><a name="t_join"></a><b><tt>t_join</tt></b>
+    <dd>Contains the timestamp of the last time the server joined the
+	network as a decimal integer.
+
+<dt><a name="t_quit"></a><b><tt>t_quit</tt></b>
+    <dd>Contains the timestamp of the last time the server disconnected
+	from the network as a decimal integer.
+
+<dt><a name="quit_message"></a><b><tt>quit_message</tt></b>
+    <dd>Contains the server's last quit message.
+
+</dl>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<p align=right><font size=-1><a href="index.html">Table of Contents</a></font>
+
+</body>
+</html>

docs/c.html

@@ -0,0 +1,72 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual - Appendix C. Using Services code in other programs</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Appendix C. Using Services code in other programs</h2>
+
+<p align=right><font size=-1><a href="index.html">Table of Contents</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<p>IRC Services is distributed under the <a href=GPL.html>GNU General
+Public License, version 2</a> or later (please read the license for the
+exact terms, of which this section is only a summary).  Under this license,
+you may distribute Services either as-is or modified, either for free or
+for profit, with the following limitations:
+
+<p><ul><li>You must make the source code to the entire program, including
+any modifications, available to anyone who asks for it.
+
+<p><li>You must distribute the program under the GNU General Public
+License; you may not change the licensing terms, except that you may
+elect to use a newer version of the license.
+
+<p><li>If you make any changes to any files included with the program,
+you must include a clear notice of your changes in each changed file.
+(Also note that under most countries' copyright laws, it is illegal to
+remove or alter copyright notices on copyrighted material, such as
+Services.)</ul>
+
+<p>This is particularly important to keep in mind for programs which use
+code from Services, which includes not only derivative programs distributed
+under a different name but any program that uses code from any part of
+Services.  Under the GNU General Public License, <i>if you use code from
+Services in another program and distribute the other program with the
+Services code in it, then the other program is considered a "derivative
+work" of Services and must be distributed under the terms above.</i>  If
+this is not acceptable to you, you have three options:
+
+<p><ul><li>Do not use Services code at all.
+
+<p><li>Release the part of the program that uses Services code
+separately from the rest of your program (for example, as a run-time
+loadable module), if this is possible.  In this case, the part of the
+program that uses Services code must be released under the GNU General
+Public License, but the remainder need not be.  Note, however, that your
+program must function substantially the same whether the part with the
+Services code is present or not.
+
+<p><li><a href="1.html#6">Contact the author</a> directly and ask for
+permission to use the code under different terms.  In this case, please
+state clearly what part of Services you want to use and what you are using
+it for, as well as the terms under which your software will be released and
+used.  (I have in the past allowed small portions of the Services source
+code to be used under alternate terms.)</ul>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<p align=right><font size=-1><a href="index.html">Table of Contents</a></font>
+
+</body>
+</html>

docs/convert-db.8

@@ -0,0 +1,19 @@
+.TH CONVERT-DB 8 "Services for IRC Networks" "" \" -*- nroff -*-
+.SH NAME
+convert-db \- database conversion program for IRC Services
+.SH SYNOPSIS
+.B convert-db
+[
+.I options
+] 
+[+
+.I program-name
+] 
+.I directory
+.SH DESCRIPTION
+convert-db is a tool provided with Services for IRC Networks to convert
+databases from similar programs to a format which can be read by the
+ircservices(8) daemon program.
+.PP
+There is no manpage documentation; please see the HTML documentation for
+details.

docs/copyright.html

@@ -0,0 +1,53 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual - Copyright notice and disclaimer</title>
+</head>
+
+<body>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Copyright notice and disclaimer</h2>
+
+<p>IRC Services is copyright (c) 1996-2009 Andrew Church.  There is
+absolutely NO WARRANTY provided with this software, including the implied
+warranties of merchantability, fitness for a particular purpose, and
+noninfringement; in other words, if it blows up in your face, you get to
+clean up the mess.  While the author has made reasonable efforts to avoid
+errors in this software, it is written and distributed as a hobby, and as
+such the author provides no guarantee that it will function correctly or
+that it will not cause direct or indirect damage in any particular
+circumstance.
+
+<p>IRC Services is provided under the terms of the
+<a href=GPL.html>GNU General Public License (GPL), Version 2</a> or later,
+and may be freely distributed, with certain limitations described in that
+license (notably, if you distribute IRC Services <i>or any portion of it</i>
+at all then you must distribute the source code as well).  You are not
+required to accept the license if you will only use IRC Services privately;
+however, if you do not accept the license, international copyright law
+forbids you from copying or distributing IRC Services.
+
+<p>This documentation is copyright (c) 2009 Andrew Church, and is
+separately provided under the terms of the <a href=FDL.html>GNU Free
+Documentation License (FDL), Version 1.2</a> or later, with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  It may likewise
+be freely distributed, with certain limitations described in that license.
+
+<p>New, revised versions of the GPL and FDL are published from time to
+time; you may, at your option, follow the terms and conditions of any later
+version of the GPL and FDL than the respective versions listed above.  At
+the time of writing, the latest versions of the GPL and FDL can be found at
+<a href="http://www.gnu.org/copyleft/"><tt>http://www.gnu.org/copyleft/</tt></a>.
+
+<p>Plain text versions of the GPL and FDL can be found in the files
+<tt>GPL.txt</tt> and <tt>FDL.txt</tt> in the top directory of the Services
+source code distribution.
+
+<p><hr>
+
+<p><font size=-1><a href="index.html">Table of Contents</a></font>
+
+</body>
+</html>

docs/d.html

@@ -0,0 +1,146 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual - Appendix D. Known issues</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Appendix D. Known issues</h2>
+
+<p align=right><font size=-1><a href="index.html">Table of Contents</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<p>There are a few issues which have been reported as bugs in the past or
+discovered by the author, but which either are not consistently
+reproduceable or are a consequence of the way Services works and not easily
+avoidable.  These issues are listed below.</p>
+
+<h3>Nickname and NickServ issues</h3>
+
+<p><ul><li>When setting NickServ options for other users as a Services
+administrator, NickServ will incorrectly respond with "Your (option name)
+has been changed" or similar messages, as though the Services admin's
+nickname settings had been changed.  (The target nickname's settings are
+in fact correctly modified, while the admin's settings are left alone.)
+
+<p><li>If you disable one or more of the <tt>nickserv/access</tt>,
+<tt>nickserv/autojoin</tt>, <tt>memoserv/main</tt>, and
+<tt>memoserv/ignore modules</tt>, delete a nickgroup, create a new
+nickgroup that has the same ID, and re-enable the module(s), the new
+nickgroup will keep any data from those module(s) that belonged to the old
+nickgroup.  Since nickgroup IDs are assigned randomly, this should be a
+rare occurrence.
+
+</ul>
+
+<h3>Channel and ChanServ issues</h3>
+
+<p><ul><li>Services appears to incorrectly detect "mode bouncing" (<i>i.e.,</i>
+the IRC server reversing Services' mode changes) in some cases.  When this
+occurs, commands like <tt>KICK</tt> and <tt>TOPIC</tt> as well as auto-ops
+and mode locking will no longer work on that channel.  If this problem
+occurs, appropriate messages will be written to the log file; the problem
+can be worked around by either clearing the channel (removing all users
+from the channel) or restarting Services.  Adding the
+<a href="a.html#NoBouncyModes"><tt>NoBouncyModes</tt></a> directive in
+<tt>ircservices.conf</tt> will prevent this problem from occurring, but
+will cause mode floods if you have an incorrectly configured server on your
+network.
+
+<p><li>If a user without auto-op privileges enters a registered, empty
+channel and sends a MODE command to change the channel modes before
+Services removes the user's channel operator privileges, the changed modes
+will remain in effect on the channel.  On some IRC servers, such as
+InspIRCd and ircd-ratbox, this can be avoided by setting the
+<a href="a.html#protocol/(insert_protocol_name_here).CSSetChannelTime"><tt>CSSetChannelTime</tt></a>
+option in <tt>modules.conf</tt>.
+
+<p><li>When kicking users from forbidden channels (or in other cases when a
+user tries to join an empty channel and is kicked), Services will generate
+debug log messages about "<tt>MODE +b for unknown channel</tt>".  These are
+a side effect of the order in which Services processes the operations
+involved in the kickban; they are harmless and can be safely ignored.  The
+same or similar messages can also appear during a netburst when modes are
+sent for a channel after all the users in the channel have been kicked, or
+when joins and modes are sent for a user who gets autokilled.
+
+<p><li>If you try to enter an empty channel and get kicked and banned by
+ChanServ, you cannot get in with <tt>UNBAN</tt> or <tt>INVITE</tt> even if
+you would normally have privileges to do so because ChanServ reports that
+the channel does not exist.  This is because ChanServ does not keep track
+of channels that it is currently residing in after a kickban in the same
+way that it does for ordinary users.
+
+<p><li>When using protocols that support ban exceptions, users can get
+around the "ban" part of a kickban in an empty channel by sending a ban
+exception quickly enough that the server processes it before Services is
+able to kick the user, allowing the user to repeatedly rejoin the channel
+(and get immediately kicked again).  This is a side effect of Services not
+tracking empty channels in which ChanServ is residing, but if your IRC
+server's flood protection is set up properly, this will not be a problem in
+practice (there are many ways for users to generate more network traffic
+than a join/part loop).
+
+<p><li>There appear to be some cases in which channel modes (<tt>+k</tt>
+and <tt>+o</tt> have been reported) are set twice in succession for the
+same channel.  This naturally has no effect on the channel itself, but some
+users have reported it as annoying.  Services attempts to detect and
+correct this, but it may still occur in some cases.
+
+</ul>
+
+<h3>Administration and other issues</h3>
+
+<p><ul><li>If you are not using encrypted passwords, then all passwords will
+be truncated to be at most 32 characters (or <tt>PASSMAX</tt> characters,
+if you change the value of <tt>PASSMAX</tt> in the <tt>defs.h</tt> source
+file) long.  As a result, any password with the same initial sequence of
+characters will be treated as a match, even if it is not exactly the same
+password initially set.
+
+<p><li>When setting another nickname's password or a channel's password as
+a Services administrator, NickServ (or ChanServ) will send out the
+"<tt><i>ADMIN</i> used SET PASSWORD as Services admin for <i>TARGET</i></tt>"
+global message even if the password change is rejected due to length or
+similarity with the target nickname or channel name.  This is difficult to
+fix cleanly in the current code structure (which is one reason the message
+was written as "used SET PASSWORD" instead of "changed password").  Since
+this is expected to be a rare occurrence, clarity of code was given
+preference over adding special-case processing for this case.  Note that
+setting the
+<a href="a.html#NoAdminPasswordCheck"><tt>NoAdminPasswordCheck</tt></a>
+option in <tt>ircservices.conf</tt> will disable all password checks for
+Services administrators, thus avoiding this problem.
+
+<p><li>When using the Bahamut protocol, Services will log warnings about
+missing IP addresses each time an opermasked client connects to the network
+or rejoins after a netsplit.  This is unavoidable on Services' part, since
+the Bahamut protocol does not seem to provide a way to differentiate between
+opermasked clients and servers which do not send IP addresses at all.
+
+<p><li>It has been reported that using the OperServ <tt>JUPE</tt> command
+on a Bahamut-based network for a server two or more hops away from the
+Services uplink server can cause Services to be dropped from the network.
+
+<p><li>If you compile on a Macintosh (OSX) system using dynamic modules,
+the <tt>encryption/unix-crypt</tt> module may fail to load.  If this
+happens, compile using static modules instead (<tt>./configure
+-use-static-modules</tt>).
+
+</ul>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<p align=right><font size=-1><a href="index.html">Table of Contents</a></font>
+
+</body>
+</html>

docs/faq.html

@@ -0,0 +1,954 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services - Frequently Asked Questions (FAQ)</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Frequently Asked Questions (FAQ)</h2>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<h2 align=center>Frequently Asked Questions (FAQ) concerning Services</h2>
+
+<p><hr width="50%">
+
+<h2>Index:</h2>
+
+<h3>A. General questions</h3>
+<a href="#A1">A.1. What is Services (a.k.a. IRC Services or Services for
+	IRC Networks)?</a>
+<br><a href="#A2">A.2. Where can I find Services?</a>
+<br><a href="#A3">A.3. Does Services run under Windows?</a>
+<br><a href="#A4">A.4. How about other operating systems?</a>
+
+<h3>B. Compiling and starting Services</h3>
+B.1. (deleted)
+<br><a href="#B1.5">B.1.5. Why does <tt>configure</tt> complain that my
+	compiler has bugs in it?  Can't you work around them?</a>
+<br><a href="#B2">B.2. <tt>configure</tt> reports that my system doesn't
+	have the <tt>strtok()</tt> function.  Isn't that a bug?</a>
+<br><a href="#B3">B.3. When I run "<tt>make</tt>", I get an error message like
+	"<tt>missing separator</tt>", "<tt>Need an operator</tt>",
+	"<tt>Unexpected end of line seen</tt>", etc.</a>
+<br><a href="#B3.5">B.3.5. I get an error like "<tt>Makefile.inc not
+	found</tt>".</a>
+<br>B.4. (deleted)
+<br><a href="#B5">B.5. I need support for the XYZ protocol.</a>
+<br><a href="#B6">B.6. Whenever I start Services, I get a message on my IRC
+	server saying "<tt>connection refused</tt>" or something similar,
+	and Services gives an error message from the server saying
+	"<tt>Closing Link: </tt>. . .".</a>
+<br><a href="#B7">B.7. My IRC server is giving me messages like "<tt>Connection
+	to services.example.net[127.0.0.1] activated</tt>" and then
+	"<tt>Access denied -- no N line</tt>".  Why?</a>
+<br><a href="#B8">B.8. When I say "<tt>/connect services.*</tt>", it doesn't
+	work!</a>
+<br><a href="#B9">B.9. Services complains in the logfile about being unable to
+	load the default language, or gives messages like "<tt>Warning: bad
+	number of strings (747, wanted 863) for language 0 (en_us)</tt>".</a>
+
+<h3>C. Running Services</h3>
+<a href="#C1">C.1. Services keeps giving errors saying that the data
+	directory is locked and the databases won't be updated.</a>
+<br><a href="#C1.5">C.1.5. Services is giving "Can't create temporary
+	database file" errors.</a>
+<br><a href="#C2">C.2. Services can't keep up with my network&mdash;it is
+	eventually disconnected with "<tt>Max SendQ exceeded</tt>".  What
+	can I do about this?</a>
+<br><a href="#C3">C.3. Services starts up okay, but if I try to register a
+	nickname, it replies with "<tt>Sorry, registration failed</tt>" or
+	"<tt>Internal error - unable to process request.</tt>"</a>
+<br><a href="#C4">C.4. Services crashed with a segmentation fault.</a>
+<br><a href="#C5">C.5. Services' channel mode setting doesn't work.  I can't
+	set modes with OperServ, and every time ChanServ tries to set a
+	mode, my server reverses the change.</a>
+<br><a href="#C5.5">C.5.5. But my U:lines are set correctly!</a>
+<br><a href="#C6">C.6. My server sometimes sends messages saying "<tt>Notice --
+	User on services.example.net remotely JOINing new channel</tt>".</a>
+<br><a href="#C7">C.7. How can I make Services send replies using
+	<tt>PRIVMSG</tt> (<tt>/msg</tt>) instead of <tt>NOTICE</tt>?</a>
+<br><a href="#C8">C.8. Can I make ChanServ send channel modes all at once
+	instead of one at a time?</a>
+<br><a href="#C9">C.9. I sometimes get errors in the log file about "user
+	record not found", "non-existent nick", or "unknown channel".  What
+	are these?</a>
+<br><a href="#C10">C.10. Long messages from Services sometimes get a colon
+	(":") inserted in the middle.</a>
+<br><a href="#C11">C.11. Services crashes when loading databases on SPARC
+	systems.</a>
+<br><a href="#C12">C.12. When using Services with InspIRCd, the IRC server
+	gives a warning about "nonstandard modes".</a>
+
+<h3>D. NickServ features</h3>
+<a href="#D1">D.1. Some people get nick collided when their nickname is
+	changed to <tt>Guest###</tt>.</a>
+<br><a href="#D2">D.2. Trying to use <tt>REGISTER</tt> or <tt>SET EMAIL</tt>
+	resulted in an "address is unauthenticated" message, but the user
+	hasn't registered any nicknames before.</a>
+
+<h3>E. ChanServ features</h3>
+<a href="#E1">E.1. How do I make ChanServ join/stay in a channel?</a>
+<br><a href="#E2">E.2. Services ignored the <tt>SET SUCCESSOR</tt> setting and
+	deleted a channel when the founder expired.</a>
+<br><a href="#E3">E.3. When ChanServ sets the topic for a channel, it always
+	appends "<tt>(<i>nickname</i>)</tt>" to the end.  How do I make it
+	not do that?</a>
+<br><a href="#E4">E.4. The <tt>ACCESS</tt> command is confusing to some
+	users.  Can you add a channel option to select between the
+	<tt>ACCESS</tt> and <tt>XOP</tt> commands?</a>
+<br><a href="#E5">E.5. Why can't you force users to register E-mail
+	addresses with channels like you can with nicknames?</a>
+<br><a href="#E6">E.6. If I use <tt>SET MLOCK</tt> on a channel to set a
+	key, then anyone who enters the channel when empty can see it!  How
+	do I avoid this?</a>
+<br>E.7. (deleted)
+<br><a href="#E8">E.8. If a channel operator sets mode <tt>-o+v</tt> on
+	himself, ChanServ always sends <tt>-v</tt>.</a>
+<br><a href="#E9">E.9. ChanServ <tt>UNBAN</tt> doesn't work properly on
+	Unreal.</a>
+<br><a href="#E10">E.10. Why are the <tt>STATUS</tt> error messages so
+	strange?  Why doesn't <tt>STATUS</tt> obey the language setting in
+	NickServ?</a>
+<br><a href="#E11">E.11. Whenever a user enters an empty channel, I see
+	messages about "channel TS", and the user loses and then gets
+	channel ops again.</a>
+<br><a href="#E12">E.12. When a user is autokicked from a channel,
+	sometimes Services doesn't ban them and they get stuck in a
+	join/kick loop.</a>
+
+<h3>F. OperServ features</h3>
+<a href="#F1">F.1. Using the OperServ <tt>JUPE</tt> command results in server
+	messages like "<tt>Server juped.server introduced by non-hub server
+	services.example.net</tt>" or causes Services to be disconnected.</a>
+<br><a href="#F2">F.2. I can't use the <tt>ADMIN</tt> command to add
+	Services administrators&mdash;it tells me "<tt>Permission
+	denied.</tt>"</a>
+<br><a href="#F3">F.3. How can I set up multiple Services super-users?</a>
+<br><a href="#F4">F.4. When I add an autokill, the users matching it don't
+	get killed.</a>
+<br><a href="#F5">F.5. Services reports (via <tt>/stats u</tt> or <tt>/msg
+	OperServ STATS</tt>) a different number of users online than I get
+	from doing <tt>/lusers</tt>.</a>
+<br><a href="#F6">F.6. Trying to use OperServ gives me "Access denied", but my
+	nick is in the ServicesRoot directive and is registered, and I've
+	identified for my nick.</a>
+<br><a href="#F7">F.7. I used the <tt>RAW</tt> command to do something, and
+	then Services stopped working!</a>
+<br><a href="#F8">F.8. On Unreal, every time I use the <tt>/gline</tt>
+	command, Services cancels the G:line.</a>
+<br><a href="#F9">F.9. Services doesn't add <tt>AKILL</tt>s/G:lines for
+	users matching autokill masks.</a>
+<br><a href="#F10">F.10. Services doesn't kill users matching a newly-added
+	autokill mask even if <tt>ImmediatelySendAutokill</tt> is set.</a>
+
+<h3>Z. Bug reporting and feature requests</h3>
+<i>(section deleted)</i>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=A></a>
+<h3 align=center>A. General questions</h3>
+
+<a name=A1></a>
+<p><dl><dt><b>A.1. What is Services (a.k.a. IRC Services or Services for
+	IRC Networks)?</b>
+<dd><p>
+	Services is a software package providing various services such as
+	nickname and channel registration for IRC networks.
+	<a href=index.html>Read the documentation</a> for more information.
+</dl>
+
+<a name=A2></a>
+<p><dl><dt><b>A.2. Where can I find Services?</b>
+<dd><p>
+	See <a href="1.html#3">section 1-3</a> of the manual.
+</dl>
+
+<a name=A3></a>
+<p><dl><dt><b>A.3. Does Services run under Windows?</b>
+<dd><p>
+	Services has been reported to run when compiled under the
+	<a href="http://sources.redhat.com/cygwin/">Cygwin</a>
+	<font size=-1>[<tt>sources.redhat.com</tt>]</font> environment for
+	Windows, but has not been tested extensively and is not supported
+	by the author.
+	<p>
+	One user has reported success in running Services as a Windows
+	service; however, the database files must be owned by the Windows
+	user under which Services runs (<i>e.g.</i> Administrator), and the
+	files' security properties must be changed to prevent the file
+	owner from being altered.
+</dl>
+
+<a name=A4></a>
+<p><dl><dt><b>A.4. How about other operating systems?</b>
+<dd><p>
+	Services was at one point reported to be usable under OS/2;
+	however, it has not been tested recently and is not supported.
+	The author has also heard reports of Services being used with
+	moderate success on AmigaOS.
+</dl>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=B></a>
+<h3 align=center>B. Compiling and starting Services:</h3>
+
+<a name=B1></a>
+<p><dl><dt><i>B.1. (deleted)</i>
+</dl>
+
+<a name=B1.5></a>
+<p><dl><dt><b>B.1.5. Why does <tt>configure</tt> complain that my
+	compiler has bugs in it?  Can't you work around them?</b>
+<dd><p>
+	GCC versions earlier than 3.4 have bugs which cause the
+	<tt>__builtin_apply()</tt> and <tt>__builtin_return()</tt>
+	pseudofunctions to be miscompiled (see GCC Bugzilla, bugs
+	<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8028">8028</a> and
+	<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11151">11151</a>
+	<font size=-1>[<tt>gcc.gnu.org</tt>]</font>, for details).
+	Working around this problem requires the use of assembly language,
+	so workarounds are platform-specific; Services has workarounds for
+	these bugs on the Intel x86, SPARC, and PowerPC platforms, but on
+	other systems, you will need to use GCC 3.4 or later, or the
+	<tt>configure</tt> script will report an error and refuse to
+	continue.
+</dl>
+
+<a name=B2></a>
+<p><dl><dt><b>B.2. <tt>configure</tt> reports that my system doesn't
+	have the <tt>strtok()</tt> function.  Isn't that a bug?</b>
+<dd><p>
+	Many system libraries, including some versions of the libraries
+	used with Linux and Solaris, have subtle bugs in their
+	<tt>strtok()</tt> implementations which cause Services to perform
+	improperly, or even crash in some cases. The <tt>configure</tt>
+	script checks for these bugs, and reports <tt>strtok()</tt> as "not
+	found" if one or more bugs are present.  (In fairness, the
+	definition of <tt>strtok()</tt> is vague in some respects, and
+	developers of these libraries may have interpreted it differently
+	than the way it is used in Services.)
+</dl>
+
+<a name=B3></a>
+<p><dl><dt><b>B.3. When I run "<tt>make</tt>", I get an error message like
+	"<tt>missing separator</tt>", "<tt>Need an operator</tt>",
+	"<tt>Unexpected end of line seen</tt>", etc.</b>
+<dd><p>
+	Your <tt>make</tt> program isn't compatible with the Makefile for
+	Services.  The Makefile was designed to work with GNU
+	<tt>make</tt>, version 3.79 or later, and may not work with older
+	versions or other systems' "<tt>make</tt>" programs.  In
+	particular, the <tt>make</tt> programs bundled with SunOS/Solaris
+	and FreeBSD have been reported not to work; you will need to use
+	GNU <tt>make</tt> on these systems.  See the
+	<a href="2.html#1">system requirements section</a> for details.
+</dl>
+
+<a name=B3.5></a>
+<p><dl><dt><b>B.3.5. I get an error like "<tt>Makefile.inc not found</tt>".</b>
+<dd><p>
+	You forgot to run the <tt>configure</tt> script first.  See the
+	<a href="2.html#3">installation directions</a>.
+</dl>
+
+<a name=B4></a>
+<p><dl><dt><i>B.4. (deleted)</i>
+</dl>
+
+<a name=B5></a>
+<p><dl><dt><b>B.5. I need support for the XYZ protocol.</b>
+<dd><p>
+	Services can be made to support new IRC protocols with the addition
+	of new protocol modules.  You will need to write a protocol module
+	to support the specific protocol you want to use; see the
+	<a href="tech/index.html">technical manual</a> for details.
+</dl>
+
+<a name=B6></a>
+<p><dl><dt><b>B.6. Whenever I start Services, I get a message on my IRC
+	server saying "<tt>connection refused</tt>" or something similar,
+	and Services gives an error message from the server saying
+	"<tt>Closing Link: </tt>.&nbsp;.&nbsp;.".</b>
+<dd><p>
+	You need to configure your IRC server to accept Services as an IRC
+	server.  For IRC servers based on the irc2.x distribution, that
+	involves adding two lines like the following to your
+	<tt>ircd.conf</tt> file:
+	<blockquote>
+	<tt>C:127.0.0.1:password:services.whatever.net::99</tt>
+	<br><tt>N:127.0.0.1:password:services.whatever.net::99</tt>
+	</blockquote>
+	See your IRC server's documentation for details about configuring
+	your servers to accept connections from Services.
+	<p>
+	Note particularly that "no N:line" errors can mean any of several
+	things:
+	<p><ul>
+	<li>Services' IP address or host name is different than that in the
+	    first parameter to the <tt>N:</tt> line.  On some systems,
+	    using "<tt>localhost</tt>" in the <tt>RemoteServer</tt>
+	    configuration directive will not always get you the IP address
+	    <tt>127.0.0.1</tt>!  To check what hostname or IP address the
+	    IRC server thinks you have, start up an IRC client on the same
+	    machine you are running Services on, connect to the server
+	    given in the <tt>RemoteServer</tt> directive, and do a
+	    <tt>/whois</tt> on yourself; the hostname in the <tt>/whois</tt>
+	    response should be used as the first <tt>N:</tt> line parameter.
+	<p>
+	<li>Your IRC server has been compiled to use encrypted <tt>N:</tt>
+	    line passwords but you gave a plaintext password as the second
+	    <tt>N:</tt> line parameter, or vice versa.
+	<p>
+	<li>The server name given as the third <tt>N:</tt> line parameter
+	    does not match the name given in the <tt>ServerName</tt>
+	    configuration directive.  The third parameter is not the
+	    IP address or hostname of the remote server (Services in this
+	    case), but rather the server name presented in the server
+	    registration (<tt>SERVER</tt>) message; this is an important
+	    distinction that can be easily forgotten.
+	</ul>
+</dl>
+
+<a name=B7></a>
+<p><dl><dt><b>B.7. My IRC server is giving me messages like "<tt>Connection
+	to services.example.net[127.0.0.1] activated</tt>" and then
+	"<tt>Access denied -- no N line</tt>".  Why?</b>
+<dd><p>
+	This is typically caused by including a port number in the C:line
+	for Services, which tells your server to try to autoconnect to it.
+	This is not what you want, because Services will connect to the
+	server itself, but does not listen for servers to connect to it.
+	The solution is to remove the port number from the C:line.
+</dl>
+
+<a name=B8></a>
+<p><dl><dt><b>B.8. When I say "<tt>/connect services.*</tt>", it doesn't
+	work!</b>
+<dd><p>
+	As described in answer B.7 above, Services does not listen for
+	connections, so you cannot <tt>/connect</tt> to it.
+</dl>
+
+<a name=B9></a>
+<p><dl><dt><b>B.9. Services complains in the logfile about being unable to
+	load the default language, or gives messages like "<tt>Warning: bad
+	number of strings (747, wanted 863) for language 0 (en_us)</tt>".</b>
+<dd><p>
+	You forgot to run "<tt>make install</tt>" after compiling Services.
+</dl>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=C></a>
+<h3 align=center>C. Running Services:</h3>
+
+<a name=C1></a>
+<p><dl><dt><b>C.1. Services keeps giving errors saying that the data
+	directory is locked and the databases won't be updated.</b>
+<dd><p>
+	This can occur if Services was interrupted (<i>e.g.,</i> by a power
+	failure) or crashed while writing the databases.  Remove the file
+	given in the warning message (this is the file specified by the
+	<tt>ircservices.conf</tt>
+	<a href="a.html#LockFilename"><tt>LockFilename</tt></a> directive,
+	by default "<tt>.lock</tt>" in the Services data directory), then
+	use the OperServ <a href="4.html#oper.update"><tt>UPDATE</tt></a>
+	command to save the databases; alternatively, the <tt>FORCE</tt>
+	option can be used with the OperServ <tt>UPDATE</tt> command to
+	perform both steps at once.
+</dl>
+
+<a name=C1.5></a>
+<p><dl><dt><b>C.1.5. Services is giving "Can't create temporary database
+	file" errors.</b>
+<dd><p>
+	Make certain that (1) the disk on which the databases are stored is
+	not full, and (2) that Services has permission to create files in
+	the data directory (on Unix systems, this means that the user-ID that
+	Services runs as must have write and execute permission on the data
+	directory, as well as execute permission on all parent directories
+	of the data directory).
+</dl>
+
+<a name=C2></a>
+<p><dl><dt><b>C.2. Services can't keep up with my network&mdash;it is
+	eventually disconnected with "<tt>Max SendQ exceeded</tt>".  What
+	can I do about this?</b>
+<dd><p>
+	If you have a really large network (tens of thousands of
+	simultaneous users), Services in its default configuration may not
+	be able to keep up with all the network traffic.  Here are some
+	possible ways to speed Services up:
+	<p><ul>
+	<li>Run it on a faster computer.  (Services does <i>not</i> need to
+	    run on the same system as an IRC server!  If you have several
+	    computers connected via Ethernet or another type of high-speed
+	    network, it's perfectly fine to have an ircd on one machine and
+	    Services on a separate machine.)
+	<li>Remove all unneeded modules from <tt>ircservices.conf</tt>.
+	<li>Configure Services with the <tt>-no-sorted-lists</tt> option
+	    and recompile.  (This will speed up nickname and channel
+	    access, but commands like NickServ and ChanServ LIST will no
+	    longer return names in alphabetical order.)
+	<li>Reduce the nickname and channel expiration periods.
+	<li>Reduce the size of your autokill, S-line, and session limit
+	    exception lists as much as possible, or remove the relevant
+	    modules (<tt>operserv/akill</tt>, <tt>operserv/sline</tt>, and
+	    <tt>operserv/sessions</tt>) entirely.
+	<li>Reduce the maximum number of autokicks per channel.  (This will
+	    not have a direct effect, but it may keep the problem from
+	    getting worse.)
+	<li>Increase the <tt>UpdateTimeout</tt> setting in
+	    <tt>ircservices.conf</tt>, to reduce the frequency of database
+	    synchronization.  However, keep in mind that this will mean
+	    more potential data loss if/when Services falls off your
+	    network or crashes.
+	<li><b>Don't</b> run in debug mode!
+	</ul>
+	<p>Services has been successfully used on networks as large as
+	22,000 simultaneous users with 260,000 registered nicks.
+</dl>
+
+<a name=C3></a>
+<p><dl><dt><b>C.3. Services starts up okay, but if I try to register a
+	nickname, it replies with "<tt>Sorry, registration failed</tt>" or
+	"<tt>Internal error - unable to process request.</tt>"</b>
+<dd><p>
+	Make sure you've selected the correct IRC protocol (IRC server)
+	module in <tt>ircservices.conf</tt>, as described in
+	<a href="2.html#4">section 2-4</a>.
+</dl>
+
+<a name=C4></a>
+<p><dl><dt><b>C.4. Services crashed with a segmentation fault.</b>
+<dd><p>
+	Hopefully most of the bugs have been worked out of Services by now,
+	but if you run into a problem like this, you may find the
+	<tt>cron</tt> utility useful for dealing with such with it; the
+	<tt>ircservices-chk</tt> script, installed in the same place as the
+	<tt>ircservices</tt> executable, will check whether Services is
+	running and restart it if not (see
+	<a href="2.html#6-ircservices-chk">section 2-6</a> for details).
+</dl>
+
+<a name=C5></a>
+<p><dl><dt><b>C.5. Services' channel mode setting doesn't work.  I can't
+	set modes with OperServ, and every time ChanServ tries to set a
+	mode, my server reverses the change.</b>
+<dd><p>
+	If you're running the DALnet, Unreal, or Undernet IRC server, make
+	sure <i>every</i> server on your network has a U:line for Services
+	in <tt>ircd.conf</tt>; for example:
+	<blockquote>
+	<tt>U:services.whatever.net:*:*</tt>
+	</blockquote>
+	Services will report in a <tt>WALLOPS</tt> or <tt>GLOBOPS</tt>
+	message the first time it discovers it cannot change modes.
+</dl>
+
+<a name=C5.5></a>
+<p><dl><dt><b>C.5.5. But my U:lines are set correctly!</b>
+<dd><p>
+	If the <tt>ircd.conf</tt> file was created, edited, or copied from
+	a Windows computer, then it may be corrupt (Windows inserts
+	<tt>^M</tt> characters at the end of every line), which will cause
+	the ircd to not recognize the U:line.  Use a text editor such as vi
+	or Emacs to remove the <tt>^M</tt> characters, or re-create the
+	file from scratch.
+</dl>
+
+<a name=C6></a>
+<p><dl><dt><b>C.6. My server sometimes sends messages saying "<tt>Notice --
+	User on services.example.net remotely JOINing new channel</tt>".</b>
+<dd><p>
+	This is normal, and happens whenever ChanServ kicks a user from a
+	channel in which they were the first to enter (for example, a user
+	without privileges entering a channel with the <tt>RESTRICTED</tt>
+	setting active, or a user on the channel's autokick list).  In this
+	case, ChanServ joins the channel for a short period of time to
+	prevent the user from joining again immediately after they've been
+	kicked.  If you are using the Bahamut or Unreal IRC servers, this
+	will result in a message like the above; it can be safely ignored.
+</dl>
+
+<a name=C7></a>
+<p><dl><dt><b>C.7. How can I make Services send replies using
+	<tt>PRIVMSG</tt> (<tt>/msg</tt>) instead of <tt>NOTICE</tt>?</b>
+<dd><p>
+	You can't.  RFC 1459 (the IRC protocol definition) requires that
+	all automated clients send all replies using <tt>NOTICE</tt> rather
+	than <tt>PRIVMSG</tt>, and Services follows that requirement.  If
+	you want to change how Services replies appear in your IRC client,
+	change your client's settings.
+</dl>
+
+<a name=C8></a>
+<p><dl><dt><b>C.8. Can I make ChanServ send channel modes all at once
+	instead of one at a time?</b>
+<dd><p>
+	Yes; enable the <tt>MergeChannelModes</tt> directive in
+	<tt>ircservices.conf</tt>.  (Note that this has minor security
+	implications&mdash;be sure to read the comments in the example
+	configuration file.)
+</dl>
+
+<a name=C9></a>
+<p><dl><dt><b>C.9. I sometimes get errors in the log file about "user
+	record not found", "non-existent nick", or "unknown channel".  What
+	are these?</b>
+<dd><p>
+	These messages can appear when Services disconnects a user from the
+	network or removes (kicks) a user from a channel, and are the
+	result of time lag inherent in all networked systems.  For example,
+	if an autokilled user connects to the network and immediately sends
+	a <tt>/join</tt> command to join a channel, the user's server may
+	receive the <tt>/join</tt> before it receives the disconnection
+	message from Services.  Services will then receive the <tt>/join</tt>
+	for what it thinks is a user who no longer exists, and reports that
+	it received a message for a non-existent nickname.
+	<p>
+	These messages do not indicate a bug or other problem, and can be
+	safely ignored.
+</dl>
+
+<a name=C10></a>
+<p><dl><dt><b>C.10. Long messages from Services sometimes get a colon
+	(":") inserted in the middle.</b>
+<dd><p>
+	This is caused by a bug in the "mIRC" IRC client for Windows
+	computers; if you try to send a very long message using the
+	<tt>/operserv</tt> (or <tt>/nickserv</tt>, etc.) command, such as a
+	long global notice, then mIRC will insert a colon in the middle of
+	it.  There is nothing Services can do to fix this, since Services
+	can't tell whether the colon was intentionally put there or not.
+	If you experience this problem, try upgrading mIRC to the latest
+	version or using another IRC client.  Alternatively, as a
+	workaround you can use <tt>/msg OperServ</tt> instead of
+	<tt>/operserv</tt>.
+	<p>
+	See also <a href="http://trout.snt.utwente.nl/ubbthreads/ubbthreads.php?ubb=showflat&amp;Number=117232&amp;site_id=1#import">this thread</a>
+	<font size=-1>[<tt>trout.snt.utwente.nl</tt>]</font> on the mIRC
+	forums.
+</dl>
+
+<a name=C11></a>
+<p><dl><dt><b>C.11. Services crashes when loading databases on SPARC
+	systems.</b>
+<dd><p>
+	This is due to a bug in some versions of GCC running on SPARC
+	systems.  Services contains a temporary workaround for this
+	problem, but it is very compiler- and environment-specific, and it
+	may not work for you.  The bug has been filed in the GCC bug
+	database as
+	<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11151">bug
+	11151</a> <font size=-1>[<tt>gcc.gnu.org</tt>]</font>, and has been
+	fixed as of GCC 3.4.
+</dl>
+
+<a name=C12></a>
+<p><dl><dt><b>C.12. When using Services with InspIRCd, the IRC server
+	gives a warning about "nonstandard modes".</b>
+<dd><p>
+	A message like the following:
+	<blockquote><tt>WARNING: The server services.example.net is sending
+		nonstandard modes: 'ChanServ MODE +r' where FMODE should be
+		used, and may cause desyncs.</tt></blockquote>
+<p>
+	is a side effect of the way Services works, and can be safely
+	ignored; the "may cause desyncs" text does not apply to Services.
+</dl>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=D></a>
+<h3 align=center>D. NickServ features:</h3>
+
+<a name=D1></a>
+<p><dl><dt><b>D.1. Some people get nick collided when their nickname is
+	changed to <tt>Guest###</tt>.</b>
+<dd><p>
+	Make sure you have <tt>Guest*</tt> (or whatever prefix you
+	specified in <tt>ircservices.conf</tt>) listed in a Q:line in the
+	<tt>ircd.conf</tt> file for <i>all</i> of your servers.  For
+	example:
+
+	<blockquote>
+	<tt>Q::Reserved for Services:Guest*</tt>
+	</blockquote>
+
+	This prevents people from using <tt>Guest###</tt> nicks and
+	colliding people who get their nicks changed.  Note that some IRC
+	servers will generate messages whenever someone gets their nick
+	changed to <tt>Guest###</tt> by Services and a configuration line
+	like the above is used; you may want to modify your IRC client's
+	configuration so it doesn't display the messages (or change the IRC
+	server itself so it doesn't generate them).
+	<p>
+	Alternatively, if your IRC server supports SQlines, you can set an
+	SQline on the same mask using the OperServ <tt>SQLINE ADD</tt>
+	command (in the <tt>operserv/sline</tt> module), and Services will
+	take care of making sure all servers have Q:lines for the nick.
+</dl>
+
+<a name=D2></a>
+<p><dl><dt><b>D.2. Trying to use <tt>REGISTER</tt> or <tt>SET EMAIL</tt>
+	resulted in an "address is unauthenticated" message, but the user
+	hasn't registered any nicknames before.</b>
+<dd><p>
+	Another user may have set the same E-mail address on their
+	nickname.  Use the <tt>LISTEMAIL</tt> command to see what nicknames
+	have the problem address associated with them.
+</dl>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=E></a>
+<h3 align=center>E. ChanServ features:</h3>
+
+<a name=E1></a>
+<p><dl><dt><b>E.1. How do I make ChanServ join/stay in a channel?</b>
+<dd><p>
+	You don't.  Use a bot instead.
+</dl>
+
+<a name=E2></a>
+<p><dl><dt><b>E.2. Services ignored the <tt>SET SUCCESSOR</tt> setting and
+	deleted a channel when the founder expired.</b>
+<dd><p>
+	Normally, this is because the successor had too many channels
+	registered; in this case, you will see an entry in the log file
+	like the following:
+
+	<blockquote>
+	<tt>[date] Successor (SuccessorNick) of channel #somechannel owns
+	    too many channels, deleting channel #somechannel</tt>
+	</blockquote>
+</dl>
+<a name=E3></a>
+<p><dl><dt><b>E.3. When ChanServ sets the topic for a channel, it always
+	appends "<tt>(<i>nickname</i>)</tt>" to the end.  How do I make it
+	not do that?</b>
+<dd><p>
+	This has nothing to do with Services, and is a feature of the IRC
+	server itself which occurs when Services sets the topic on a
+	channel.  The "(nickname)" is not actually included in the topic,
+	and the second and later users to join the channel will not see it.
+	There is no way to disable it for the first user, unless you modify
+	the IRC server itself.
+</dl>
+<a name=E4></a>
+<p><dl><dt><b>E.4. The <tt>ACCESS</tt> command is confusing to some
+	users.  Is there a way to select between the <tt>ACCESS</tt> and
+	<tt>XOP</tt> commands?</b>
+<dd><p>
+	No; just tell those users to not use the <tt>ACCESS</tt> command.
+	(You can also disable the <tt>ACCESS</tt> command for the whole
+	network by removing or commenting out the
+	<tt>LoadModule&nbsp;chanserv/access-levels</tt> line in
+	<tt>ircservices.conf</tt>, but this will prevent even users who
+	understand the <tt>ACCESS</tt> command from using it.)
+</dl>
+<a name=E5></a>
+<p><dl><dt><b>E.5. Why can't you force users to register E-mail
+	addresses with channels like you can with nicknames?</b>
+<dd><p>
+	Such functionality is unneeded, because ChanServ requires users to
+	register their nicknames before allowing them to register channels.
+	As long as you require users to include E-mail addresses with
+	nicknames, you can just look up the address for the channel
+	founder's nickname if a problem arises with a particular channel.
+</dl>
+
+<a name=E6></a>
+<p><dl><dt><b>E.6. If I use <tt>SET MLOCK</tt> on a channel to set a
+	key, then anyone who enters the channel when empty can see it!  How
+	do I avoid this?</b>
+<dd><p>
+	Set the <tt>RESTRICTED</tt> option for the channel, as described in
+	<a href="4.html#chan.set_mlock">the help for <tt>SET MLOCK</tt></a>,
+	or use a bot to keep the channel open.
+</dl>
+
+<a name=E7></a>
+<p><dl><dt><i>E.7. (deleted)</i>
+</dl>
+
+<a name=E8></a>
+<p><dl><dt><b>E.8. If a channel operator sets mode <tt>-o+v</tt> on
+	himself, ChanServ always sends <tt>-v</tt>.</b>
+<dd><p>
+	This is a side effect of security measures which prevent non-autoop
+	users from getting a <tt>+v</tt> in before Services deops them.
+	Either do the <tt>+v</tt> before the <tt>-o</tt> or use the
+	ChanServ <tt>VOICE</tt> command.
+</dl>
+
+<a name=E9></a>
+<p><dl><dt><b>E.9. ChanServ <tt>UNBAN</tt> doesn't work properly on
+	Unreal.</b>
+<dd><p>
+	In recent versions of Unreal, it is possible to set bans on a
+	user's IP address.  However, Unreal 3.2 servers do not send client
+	IP address information to Services, so it is impossible to tell
+	which IP-address bans match the user; thus the <tt>UNBAN</tt>
+	command will fail to remove them.  Unreal 3.2.1 and later do send
+	IP addresses to Services, so if you upgrade all of your servers the
+	problem will go away.
+</dl>
+
+<a name=E10></a>
+<p><dl><dt><b>E.10. Why are the <tt>STATUS</tt> error messages so
+	strange?  Why doesn't <tt>STATUS</tt> obey the language setting in
+	NickServ?</b>
+<dd><p>
+	The <tt>STATUS</tt> command is intended primarily for use by bots,
+	to allow them to take advantage of access level information stored
+	in Services.  For this reason, the responses to the <tt>STATUS</tt>
+	command, including error messages, need to have a fixed format that
+	can be understood by a computer.
+</dl>
+
+
+<a name=E11></a>
+<p><dl><dt><b>E.11. Whenever a user enters an empty channel, I see
+	messages about "channel TS", and the user loses and then gets
+	channel ops again.</b>
+<dd><p>
+	These messages and mode changes are harmless, and are caused by the
+<a href="a.html#protocol/(insert_protocol_name_here).CSSetChannelTime"><tt>CSSetChannelTime</tt></a>
+	configuration option (see also <a href="3.html#2-1.channel-ts">the
+	relevant part of section 3-2-1</a>).  This functionality is
+	implemented by sending a message to the network that Services has
+	the "proper" timestamp (TS) and modes for the channel.
+	Unfortunately, many IRC servers blindly cancel their own modes,
+	including the channel ops of the user who initially joined the
+	channel, before noticing that Services is not actually changing any
+	modes; this results in the server sending out a "<tt>-o</tt>" mode
+	change immediately followed by a "<tt>+o</tt>".  Some servers also
+	seem to think that the timestamp change is a bug (or hack attempt)
+	and send out a warning to IRC operators about it.
+	<p>
+	All of these messages are harmless and can be safely ignored, but
+	if they bother you, you may want to consider disabling the
+	<tt>CSSetChannelTime</tt> option.
+</dl>
+
+
+<a name=E12></a>
+<p><dl><dt><b>E.12. When a user is autokicked from a channel,
+	sometimes Services doesn't ban them and they get stuck in a
+	join/kick loop.</b>
+<dd><p>
+	If you are using the Unreal IRC server, this may be caused by
+	"extended ban types", specifically third-party Unreal modules that
+	add ban types beyond the standard types in Unreal 3.2 (<tt>q</tt>,
+	<tt>n</tt>, <tt>c</tt>, and <tt>r</tt>); Services cannot support
+	such ban types, since their behavior is undefined by the base
+	Unreal protocol.  Try disabling such modules and see if the problem
+	persists.
+</dl>
+
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=F></a>
+<h3 align=center>F. OperServ features:</h3>
+
+<a name=F1></a>
+<p><dl><dt><b>F.1. Using the OperServ <tt>JUPE</tt> command results in server
+	messages like "<tt>Server juped.server introduced by non-hub server
+	services.example.net</tt>" or causes Services to be disconnected.</b>
+<dd><p>
+	In all irc2.x-derived IRC servers (and possibly others), every
+	server on the network must have an H:line for Services in the
+	<tt>ircd.conf</tt> file, which looks something like:
+
+	<blockquote>
+	<tt>H:*::services.example.net</tt>
+	</blockquote>
+</dl>
+
+<a name=F2></a>
+<p><dl><dt><b>F.2. I can't use the <tt>ADMIN</tt> command to add Services
+	administrators&mdash;it tells me "<tt>Permission denied.</tt>"</b>
+<dd><p>
+	Did you define yourself as the Services super-user?  You need to
+	insert your nickname in the
+	<a href="a.html#operserv/main.ServicesRoot"><tt>ServicesRoot</tt></a>
+	directive in the <tt>operserv/main</tt> section of
+	<tt>modules.conf</tt>.  Also make sure that you have registered and
+	identified for your nickname, and that you have IRC operator
+	privileges.
+</dl>
+
+<a name=F3></a>
+<p><dl><dt><b>F.3. How can I set up multiple Services super-users?</b>
+<dd><p>
+	You can't.  However, you can allow Services administrators to
+	obtain Services super-user privilege by setting a password with the
+	OperServ <a href="4.html#oper.set_supass"><tt>SET SUPASS</tt></a>
+	command; Services admins can then use the
+	<a href="4.html#oper.su"><tt>SU</tt></a> command to obtain Services
+	super-user privilege.
+</dl>
+
+<a name=F4></a>
+<p><dl><dt><b>F.4. When I add an autokill, the users matching it don't get
+	killed.</b>
+<dd><p>
+	Services does not kill users when an autokill is added; it only
+	kills them when they next connect.  This is designed behavior,
+	intended to reduce the possibility of a mistyped autokill causing
+	the wrong users to get killed.  (Suppose you typed "<tt>AKILL ADD
+	*@*</tt>" and then accidentally hit Enter before finishing the host
+	mask&nbsp;.&nbsp;.&nbsp;.)
+</dl>
+
+<a name=F5></a>
+<p><dl><dt><b>F.5. Services reports (via <tt>/stats u</tt> or <tt>/msg
+	OperServ STATS</tt>) a different number of users online than I get
+	from doing <tt>/lusers</tt>.</b>
+<dd><p>
+	Services doesn't count its own pseudo-clients (NickServ, ChanServ,
+	etc.) in its user count, so Services will normally report a number
+	somewhat lower than /lusers.  This number will vary depending on
+	which pseudo-clients are loaded, and will also change as nickname
+	enforcers are introduced and removed.
+	<p>
+	If you have a very large and/or busy network, there may be an
+	additional offset, either positive or negative, caused by lag
+	(1) between users signing on/off and Services recognizing them, or
+	(2) between Services killing a user and the servers receiving the
+	kill.  On a network with under 500 simultaneous clients, this
+	difference should typically not be more than one at any time, but
+	it can increase quickly as the network grows in size.  (If the
+	difference is abnormally large, see <a href="#C2">question C.2</a>
+	for ways to speed Services up.)
+	<p>
+	Finally, you may have encountered a bug in Services.  If the
+	difference in counts increases over time without a corresponding
+	increase in the number of users online, then this is the most
+	likely explanation.
+</dl>
+
+<a name=F6></a>
+<p><dl><dt><b>F.6. Trying to use OperServ gives me "Access denied", but my
+	nick is in the <tt>ServicesRoot</tt> directive and is registered,
+	and I've identified for my nick.</b>
+<dd><p>
+	You need to be opered (<i>i.e.,</i> user mode <tt>+o</tt> from using
+	<tt>/oper</tt>; this is different from channel operator mode) to
+	access OperServ.
+</dl>
+
+<a name=F7></a>
+<p><dl><dt><b>F.7. I used the <tt>RAW</tt> command to do something, and
+	then Services stopped working!</b>
+<dd><p>
+	To quote from the help for the <tt>RAW</tt> command:
+
+	<blockquote>
+	<tt>This command is intended primarily for testing of Services
+	    and IRC servers; it has a very limited range of uses on a
+	    live network, and can wreak havoc on a network or cause
+	    Services to crash if used improperly.  <b>DO NOT USE THIS
+	    COMMAND</b> unless you are absolutely certain you know
+	    what you are doing!</tt>
+	</blockquote>
+
+	In particular, Services does <i>not</i> process any messages sent
+	with the <tt>RAW</tt> command; so if (for example) you use
+	<tt>KILL</tt> to kill a user, Services will think the user is still
+	online, and if they connect to the network again, Services may fail
+	to recognize the new user or even crash.  You should not use the
+	<tt>RAW</tt> command without a detailed understanding of both the
+	IRC protocol and the internal design of Services itself.
+</dl>
+
+<a name=F8></a>
+<p><dl><dt><b>F.8. On Unreal, every time I use the <tt>/gline</tt> command,
+	Services cancels the G:line.</b>
+<dd><p>
+	This is designed behavior.  Use the OperServ
+	<a href="4.html#oper.akill"><tt>AKILL</tt></a> command instead of
+	the <tt>/gline</tt> command.
+</dl>
+
+<a name=F9></a>
+<p><dl><dt><b>F.9. Services doesn't add <tt>AKILL</tt>s/G:lines for users
+	matching autokill masks.</b>
+<dd><p>
+	If you have
+	<a href="a.html#operserv/akill.EnableExclude"><tt>EnableExclude</tt></a>
+	defined in the <tt>operserv/akill</tt> section of
+	<tt>modules.conf</tt>, but your IRC server does not support
+	autokill exclusions, then Services will not add <tt>AKILL</tt>s or
+	G:lines, because doing so would prevent autokill exclusions from
+	working properly.  See <a href="3.html#4-3-exclude">section
+	3-4-3</a> for details.
+</dl>
+
+<a name=F10></a>
+<p><dl><dt><b>F.10. Services doesn't kill users matching a newly-added
+	autokill mask even if <tt>ImmediatelySendAutokill</tt> is set.</b>
+<dd><p>
+	Services never kills users when a new autokill is added; the
+	<a href="a.html#operserv/akill.ImmediatelySendAutokill"><tt>ImmediatelySendAutokill</tt></a>
+	configuration directive only causes Services to send the autokill
+	itself (that is, the user/host mask from which to prohibit new
+	connections) to the IRC servers on your network.  This is a safety
+	feature intended to limit the damage caused by a mistyped autokill;
+	see also <a href="#F4">answer F.4</a> above.
+	<p>
+	Note that some IRC servers will themselves kill users matching a
+	newly-added autokill; this is unrelated to Services.
+</dl>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<a name=Z></a>
+<h3 align=center>Z. Bug reporting and feature requests:</h3>
+
+<p><i>(This section has been deleted since Services is no longer being
+maintained.)</i>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<!------------------------------------------------------------------------>
+<p><hr>
+
+<p align=right><font size=-1><a href="index.html">Table of Contents</a></font>
+
+</body>
+</html>

docs/index.html

@@ -0,0 +1,46 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services Manual</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Table of Contents</h2>
+
+<h3><a href=copyright.html>Copyright notice and disclaimer</a></h3>
+
+<h3><a href=upgrade.html>Important information for users upgrading from
+	earlier versions of IRC Services</a></h3>
+
+<h3>1. <a href=1.html>About IRC Services</a></h3>
+
+<h3>2. <a href=2.html>Installing and using Services</a></h3>
+
+<h3>3. <a href=3.html>Overview of Services features</a></h3>
+
+<h3>4. <a href=4.html>Services command reference</a></h3>
+
+<h3>5. <a href=5.html>Importing and exporting databases</a></h3>
+
+<h3>Appendix A. <a href=a.html>List of all configuration directives</a></h3>
+
+<h3>Appendix B. <a href=b.html>XML data format description</a></h3>
+
+<h3>Appendix C. <a href=c.html>Using Services code in other
+	programs</a></h3>
+
+<h3>Appendix D. <a href=d.html>Known issues</a></h3>
+
+<h3><a href=faq.html>Frequently Asked Questions (FAQ)</a></h3>
+
+<p><hr>
+
+<h2 align=center><a href="tech/index.html">IRC Services Technical Reference
+Manual</a></h2>
+
+</body>
+</html>

docs/ircservices-chk.8

@@ -0,0 +1,14 @@
+.TH IRCSERVICES 8 "Services for IRC Networks" "" \" -*- nroff -*-
+.SH NAME
+ircservices \- Services for IRC Networks daemon program
+.SH SYNOPSIS
+.B ircservices-chk
+[
+.I options
+]
+.SH DESCRIPTION
+\fBircservices-chk\fR checks whether Services for IRC Networks
+(\fBircservices\fR) is running, and restarts it with the supplied options
+if not.
+.PP
+Please see the HTML documentation (section 2-5 in particular) for details.

docs/ircservices.8

@@ -0,0 +1,15 @@
+.TH IRCSERVICES 8 "Services for IRC Networks" "" \" -*- nroff -*-
+.SH NAME
+ircservices \- Services for IRC Networks daemon program
+.SH SYNOPSIS
+.B ircservices
+[
+.I options
+]
+.SH DESCRIPTION
+Services for IRC Networks (also known as IRC Services or just Services)
+provides nickname and channel registration and many other services for
+use on IRC (Internet Relay Chat) networks.
+.PP
+There is no manpage documentation; please see the HTML documentation for
+details.

docs/tech/1.html

@@ -0,0 +1,232 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Style-Type" content="text/css"/>
+<style type="text/css">@import "style.css";</style>
+<title>IRC Services Technical Reference Manual - 1. Program structure overview</title>
+</head>
+
+<body>
+<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
+
+<h2 class="section-title">1. About this manual</h2>
+
+<p class="section-toc">
+     1-1. <a href="#s1">Intended audience</a>
+<br/>1-2. <a href="#s2">Structure of this manual</a>
+<br/>1-3. <a href="#s3">History of Services development</a>
+</p>
+
+<p class="backlink"><a href="index.html">Table of Contents</a> |
+<a href="2.html">Next section: Core Services functionality</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s1">1-1. Intended audience</h3>
+
+<p>This manual is written with an intended audience of programmers looking
+to change or extend the IRC Services source code, and covers the overall
+structure of the code as well as details on each of Services' functions.
+The content of this manual is highly technical, and requires a reasonably
+high level of expertise (both in programming in general and in the C
+language and Unix computer systems in particular) to peruse.</p>
+
+<p>For information on installing and using IRC Services, please see the
+<a href="../index.html">user's manual</a>.</p>
+
+<p>Note that this manual describes Services for IRC Networks version 5.1.24,
+and its contents may not be applicable to modified versions or derivative
+programs.  Also, this manual is intended to be used alongside the source
+code; details of function parameters, structure fields, and the like are
+often omitted for the sake of brevity and clarity. <!-- Use the source,
+Luke! --> </p>
+
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s2">1-2. Structure of this manual</h3>
+
+<p>Services can be broken up into two parts: the <b>core functionality</b>,
+which implements the "IRC server" part of Services, and <b>modules</b>,
+which add the "bot-like" functions to Services as well as provide common
+interfaces to differing implementations of some functions.</p>
+
+<p>The core Services functionality is primarily discussed in
+<a href="2.html">section 2</a>.  Two topics, however, are given their own
+sections due to their complexity: communications (<a href="3.html">section
+3</a>) and module handling (<a href="4.html">section 4</a>).</p>
+
+<p>Modules are divided into four groups:</p>
+
+<ul>
+<li><b>protocol modules</b> (<a href="5.html">section 5</a>), which
+handle the interface between the generic IRC server implemented by the
+Services core and the particular protocols used by various IRC servers;</li>
+<li><b>database modules</b> (<a href="6.html">section 6</a>), which handle
+the storage and retrieval of data used by pseudoclients and other Services
+functions;</li>
+<li><b>pseudoclient modules</b> (<a href="7.html">section 7</a>), which
+implement the various pseudoclients themselves; and</li>
+<li><b>other modules</b> (<a href="8.html">section 8</a>), including all
+modules not covered above.</li>
+</ul>
+
+<p><a href="9.html">Section 9</a> covers <tt>convert-db</tt>, the tool
+included with Services to convert databases from other Services-like
+programs to an XML data stream that can then be imported into Services
+itself.  The compilation of Services (the <tt>configure</tt> script and
+<tt>Makefile</tt> files) is described in <a href="10.html">section 10</a>,
+and areas where Services could potentially be improved are discussed in
+<a href="11.html">section 11</a>.</p>
+
+<p>A source code reference is included as <a href="a.html">Appendix A</a>
+(by source file) and <a href="b.html">Appendix B</a> (by function name).</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s3">1-3. History of Services development</h3>
+
+<p>Before discussing the details of the Services code base, it is worth
+mentioning the history of Services development.</p>
+
+<p>Originally, I (Andrew Church, the developer of Services) started writing
+Services as something of a "quick hack" for my personal server, which I had
+set up for the use of a channel I frequented at the time that had decided
+to move away from the DALnet IRC network.  DALnet did not at the time&mdash;and
+to the best of my knowledge still does not&mdash;publish the source code to
+their nickname and channel registration services, nor was I able to locate
+any other similar usable open-source software, so I took the route of
+writing my own.  This motive had, at least initially, significant influence
+on the user interface design; the service nicknames NickServ and ChanServ
+seem to have been around since the early days of IRC, but the basic
+commands, such as <tt>REGISTER</tt>, <tt>SET</tt>, and the NickServ
+<tt>RECOVER</tt> and <tt>RELEASE</tt> functions, were based on those seen
+on DALnet.  (Ironically, it seems that DALnet has since incorporated at
+least one feature, the channel successor concept, from this program due to
+user pressure.)</p>
+
+<p>The first "release" of Services&mdash;using the term loosely,
+since I had no interest in releasing Services publicly at this
+point&mdash;was made on April 5, 1996, when the program first went online.
+Since my IRC server was mainly for private use, there was little call for
+additional features, and aside from occasional bug fixes, not much
+development was performed during this time.  The code base itself could be
+called "functional" at best; while I have always put effort into writing
+good code rather than simply "working" code, I had considerably less skill
+in programming at that time.  In fact, work on Services accounted for a
+significant amount of my programming experience during its first several
+years of existence, and careful reading of the Services source code may
+well reveal the effect of that experience.</p>
+
+<p>My private IRC server eventually expanded into a small network, as
+friends of mine connected servers of their own.  I stored a copy of the
+Services source code on each server, both to function as a backup of the
+code itself and to allow a backup copy of Services to be started in case
+the primary one should fail for some reason.  This backfired, however, when
+one such server was broken into on November 19, 1996; a few days later, we
+received a message essentially accusing us of stealing Services from
+another IRC network called IceNet.  Investigation showed the purported
+"original" Services to in fact be a copy of my own program, presumably
+taken from the broken-into server.  I was naturally upset, and exchanged
+several angry messages with an IceNet administrator, but the situation was
+amicably resolved in the end, and IceNet continued using my program.</p>
+
+<p>After this incident, I began receiving occasional requests for copies of
+the program, and at some point over the next month or two I decided that,
+since so many people seemed interested in it and I had no particular reason
+to keep it secret, I would release the source code publicly, free for
+anyone to use.  The first public release was version 2.2.0, on January 10,
+1997.  This sudden "change of heart" is also the reason Services has such a
+generic name: I had not originally planned to publish the program, so I had
+not bothered to come up with a distinctive name for it.  The moniker
+"EsperNet Services", from the name of the network for which I developed it,
+appeared every now and then, but (partly to avoid users of the program
+flooding EsperNet administrators with help requests) I only called it
+"Services".  The current full name, "Services for IRC Networks", was chosen
+when the program was listed on the <a href="http://freshmeat.net/">FreshMeat
+software index</a> <span class="remotehost">[freshmeat.net]</span>.</p>
+
+<p>I continued Services development through mid-1999, extending the program
+to deal with users' feature requests and my own experience.  But after
+graduating from university and moving to Japan to work, I found myself with
+little time available for work on Services; so, after doing some
+preliminary work for version 4.3, I handed the code base off to Andrew
+Kempe, a user of Services who had contributed numerous suggestions and
+improvements.  At the time, I had already had some preliminary thoughts
+toward redesigning Services, including the module system which eventually
+saw the light of day in version 5.0, but as my IRC use had declined
+significantly, I had intended to just let Services go, to be developed by
+others with more interest.</p>
+
+<p>However, in late 2000, Andrew Kempe wrote to me explaining that he no
+longer had time to work on Services, and I ended up deciding to continue
+Services development where he had left off.  I reviewed his additions,
+notably the session limiting system (now the <tt>operserv/sessions</tt>
+module), and began preparations for releasing version 4.5.  I also began
+using the CVS source code management tool to keep better track of changes
+to the code.  (I had at one point considered taking advantage of CVS to
+allow others to update the code as well, but copyright issues aside, there
+were simply very few people I trusted to write code to my standards, and
+with the exception for a time of a friend from EsperNet, I was the only one
+who actually developed the code.)</p>
+
+<p>After releasing version 4.5.0, I decided to start work on a major
+redesign of Services, including the implementation of my former module
+idea.  Over the five years until this time, the Services source code had
+not undergone any significant redesign, and the result of continually
+adding features on top of other features was, to put it politely, a mess.
+In one of my favorite computer science books, <i>The Mythical Man-Month</i>,
+the author, Dr. Frederick Brooks, gives as one of the tenets of software
+development: "<i>Plan to throw one away; you will, anyhow</i>" (chapter
+11).  Indeed, I had learned a lot about both software design and
+programming in general and IRC service software in particular over the
+years, and it was easy to see where the current Services code was
+inadequate or poorly designed.  So, around the release of version 4.5.8, I
+split off a copy of the code base, added in the module support system I had
+started work on separately, and began a year-plus effort to clean up the
+code.  I did not actually rewrite the program from scratch, since I lacked
+both the time and the incentive to do so, but the structure of the program
+was vastly improved.</p>
+
+<p>The one major goal for version 5.0 which I did not complete was a new
+database implementation.  The database system which existed at the time was
+heavily intertwined with the individual pseudoclients (NickServ, ChanServ,
+and so on), making it very difficult for third parties to add new features
+that required persistent data; this was exacerbated by the database file
+format, originally just a binary dump of the data structures stored in
+memory, which lacked any sort of flexibility at all and was highly
+susceptible to data corruption.  Every time a new field was added, the
+database files' identifying version number was incremented, rendering the
+files incompatible with previous versions, and requiring highly complex
+routines in later releases to handle data from earlier versions.  It had
+been my intention to implement a format-agnostic system for 5.0 along with
+a more expandable and robust file format, but this proved to be too much to
+handle at once, and I ended up simply moving all of the database handling
+to a module (<tt>database/version4</tt>) that used dozens of hacks to read
+and write the data in a format that remained compatible with the previous
+version (4.5).</p>
+
+<p>After a couple of years of on-and-off work, I finally found the time to
+go back and redesign the database system, and the result is the code
+present in this version.  However, as I no longer use IRC, my interest in
+continuing development of Services has waned, and I have ended Services
+development as of version 5.1.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<p class="backlink"><a href="index.html">Table of Contents</a> |
+<a href="2.html">Next section: Core Services functionality</a></p>
+
+</body>
+</html>

docs/tech/10.html

@@ -0,0 +1,884 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Style-Type" content="text/css"/>
+<style type="text/css">@import "style.css";</style>
+<title>IRC Services Technical Reference Manual - 10. Compilation</title>
+</head>
+
+<body>
+<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
+
+<h2 class="section-title">10. Compilation</h2>
+
+<p class="section-toc">
+     10-1. <a href="#s1">Compilation overview</a>
+<br/>10-2. <a href="#s2">The <tt>configure</tt> script</a>
+<br/>10-3. <a href="#s3">The compilation process</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;10-3-1. <a href="#s3-1">Core source files</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;10-3-2. <a href="#s3-2">Modules</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;10-3-3. <a href="#s3-3">Language files</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;10-3-4. <a href="#s3-4">The <tt>tools</tt> and <tt>data</tt> directories</a>
+<br/>10-4. <a href="#s4">Installation</a>
+<br/>10-5. <a href="#s5">Assumptions</a>
+</p>
+
+<p class="backlink"><a href="9.html">Previous section: The database conversion tool</a> | 
+<a href="index.html">Table of Contents</a> |
+<a href="11.html">Next section: Future work</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s1">10-1. Compilation overview</h3>
+
+<p>Services uses the common <tt>configure; make; make install</tt> method
+for compilation.  The <tt>configure</tt> script in the top directory tests
+the system compiler and environment to ensure Services can be compiled and
+to compensate for differences between systems, such as broken or missing
+implementations of system library functions; once it has run, the source
+files are compiled using the <tt>make</tt> tool.  Once compilation is
+complete, the command <tt>make install</tt> will install the executable
+and data files to their final location on the system as specified by
+parameters to the <tt>configure</tt> script (or using the defaults from
+that script).</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s2">10-2. The <tt>configure</tt> script</h3>
+
+<p>Before the source code can be compiled, certain features of the compiler
+and environment need to be checked, and appropriate settings made; this is
+performed by the <tt>configure</tt> script present in the top directory.
+The script performs the following operations:</p>
+
+<ul>
+
+<li class="spaced">Defines miscellaneous utility functions.</li>
+
+<li class="spaced">Creates a temporary directory, for storing files used in
+the tests.  The directory name is defined to be "conf-tmp" at the top of
+the script.  If the directory already exists (because a previous
+<tt>configure</tt> run was aborted, for example), that directory is
+used.</li>
+
+<li class="spaced">Initializes configuration and command-line option
+variables.</li>
+
+<li class="spaced">Parses command-line options.  See
+<a href="../2.html#table2-2">table 2-2</a> in section 2 of the main
+manual for a list of all recognized options.</li>
+
+<li class="spaced">Loads the results of any previous run from the cache
+file, <tt>config.cache</tt>, unless the <tt>-ignore-cache</tt> option is
+given.  If the cache was created by an earlier version of the script,
+appropriate adjustments are made to the cached results (usually clearing
+the affected variable or variables so that the modified test is run
+again).  Note that the loading is done via a <tt>source</tt> command,
+executing the commands in the cache file directly, which can lead to
+security problems if the user is tricked into storing a malicious cache
+file in the Services directory.</li>
+
+<li class="spaced">Determines installation directories for executable files
+(variable <tt>BINDEST</tt>) and data files (variable <tt>DATDEST</tt>),
+either from the <tt>-prefix</tt>, <tt>-bindest</tt>, and <tt>-datdest</tt>
+options, or from the defaults included in the script, as follows:
+<ul>
+<li>If the <tt>-prefix</tt> option is given with a parameter
+<tt><i>PATH</i></tt>, then the executable directory is set to
+<tt><i>PATH</i>/sbin</tt> and the data directory is set to
+<tt><i>PATH</i>/lib/<i>PROGRAM</i></tt>, where <tt><i>PROGRAM</i></tt> is
+the program name given to the <tt>-program</tt> option (or the default of
+"<tt>ircservices</tt>" if the <tt>-program</tt> option is not given).</li>
+<li>If the <tt>-prefix</tt> option is not given and the <tt>-bindest</tt>
+option is given, then the executable directory is set to the path given by
+the <tt>-bindest</tt> option.</li>
+<li>If neither of the <tt>-prefix</tt> or <tt>-bindest</tt> options are
+given, then the executable directory is set to the cached value of the
+<tt>BINDEST</tt> variable if present; otherwise, the default of
+<tt>/usr/local/sbin</tt> is used.</li>
+<li>If the <tt>-prefix</tt> option is not given and the <tt>-datdest</tt>
+option is present, then the data directory is set to the path given by the
+<tt>-datdest</tt> option.</li>
+<li>If neither of the <tt>-prefix</tt> or <tt>-datdest</tt> options are
+given, but the <tt>-bindest</tt> option is given, then the data directory
+is set to a path derived from the executable directory, by either replacing
+a trailing <tt>/sbin</tt> or <tt>/bin</tt> with <tt>/lib/<i>PROGRAM</i></tt>
+or appending <tt>/lib</tt> if the executable directory does not end in
+<tt>/sbin</tt> or <tt>/bin</tt>.</li>
+<li>If none of the <tt>-prefix</tt>, <tt>-bindest</tt>, or <tt>-datdest</tt>
+options are given, then the data directory is set to the cached value of
+the <tt>DATDEST</tt> variable if present; otherwise, the default of
+<tt>/usr/local/lib/<i>PROGRAM</i></tt> is used.</li>
+</ul>
+Note that the current Services architecture does not allow data files to be
+stored in multiple separate locations.</li>
+
+<li class="spaced">Opens the log file (<tt>configure.log</tt>).
+Significant commands run by the script, and the results of all tests, are
+logged to this file to aid diagnosis in case of problems.  Each test is
+given a distinctive name, written at the beginning of each line in the log;
+these names are given in the descriptions below.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_test_nt</span>)
+Checks whether the shell's built-in <tt>test</tt> command, if any, or the
+system <tt>/bin/test</tt> or <tt>/usr/bin/test</tt> command supports the
+<tt>-nt</tt> option for testing whether one file is newer than another.
+Some shells, such as <tt>/bin/sh</tt> on at least some versions of the
+Solaris operating system, do not support the <tt>-nt</tt> test.  This test
+is required for module compilation
+(see <a href="#s3-2">section 10-3-2</a>).</li>
+
+<li class="spaced">(<span class="configure-test-name">find_cc</span>)
+Determines the program to use to compile source files.  This program is
+assumed to be able to link object files into an executable as well.  If the
+<tt>-cc</tt> option or a cached result is available, they are used in that
+order of preference, and subsequent compiler checks are bypassed.
+Otherwise, the commands <tt>gcc</tt>, <tt>icc</tt>, and <tt>cc</tt> are
+checked in that order, and the first one that is able to compile a short
+test program is used as the C compiler.  (However, if <tt>gcc</tt> is
+chosen and the version cannot be confirmed to be at least 3.2, the script
+aborts; likewise, if another compiler is chosen and it is unable to compile
+ANSI C programs, the script aborts.)  Finally, the chosen compiler is
+tested to ensure that it understands variadic-argument macros and the
+<tt>va_copy</tt> function, C99 features that Services makes use of.</li>
+
+<li class="spaced">(<span class="configure-test-name">find_ccopts</span>)
+Determines the command-line options to use with the C compiler for
+compiling source code.  If the <tt>-cflags</tt> option is given, the
+specified option string is used; if <tt>-cflags</tt> is not given and the
+cached result for the C compiler program name was chosen, the cached option
+string is used; otherwise, a default option string is chosen by the
+<tt>def_cc_flags</tt> function.  In the latter case, the compiler is
+checked for the presence of the GCC
+<a href="http://www.research.ibm.com/trl/projects/security/ssp/">stack-protector
+extension</a> <span class="remotehost">[www.research.ibm.com]</span>; at
+least some versions of this extension have a bug which causes incorrect
+code to be generated, and if the extension is present and this bug is
+detected, <tt>-fno-stack-protector</tt> is added to the default option
+string to disable this extension.  A test is made with the default flags to
+ensure that the compiler accepts them, and if the test fails, an empty
+option string is used instead.
+<br/><br/>
+Regardless of the method used to find the flags, a final test is made to
+ensure that the compilation with the selected flag set does not cause the
+stack-protector bug to appear.  (This bug relates to the GCC
+<tt>__builtin_apply</tt> and <tt>__builtin_return</tt> facility for passing
+a function call through to a different function, used in Services to handle
+imported functions in the <tt>database/version4</tt> module.  There have
+been other bugs in the implementation of this facility as well, so the test
+is carefully written to avoid triggering them.)</li>
+
+<li class="spaced">(<span class="configure-test-name">check_gcc_builtin</span>)
+Checks for bugs in the implementation of the GCC <tt>__builtin_apply</tt>
+and <tt>__builtin_return</tt> facility, if understood by the compiler.  At
+least three bugs are present in various versions of GCC, noted in the GCC
+Bugzilla tracker as bugs
+<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8028">8028</a>,
+<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11151">11151</a>, and
+<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20076">20076</a>
+<span class="remotehost">[gcc.gnu.org]</span>.  Bug 20076 is not relevant
+to Services, but if one of the other bugs is detected, the script will
+activate assembly-language workarounds for i386, Sparc, and PowerPC CPUs,
+and abort on other processors since no workaround is available.
+</li>
+
+<li class="spaced">(<span class="configure-test-name">find_lflags</span>)
+Determines what options to use when linking executables.  Uses the option
+string given with the <tt>-lflags</tt> option, the previous cached result,
+or an empty string, in that order of preference.</li>
+
+<li class="spaced">(<span class="configure-test-name">find_exe_suffix</span>)
+Checks what filename extension, if any, is appended to executable
+filenames by the compiler/linker.</li>
+
+<li class="spaced">(<span class="configure-test-name">find_libs</span>)
+Determines what additional libraries need to be specified on the link
+command line.  Checks are made for <tt>-lm</tt>, <tt>-lsocket</tt>,
+<tt>-lresolv</tt>, <tt>-lnsl</tt>, and <tt>-lcrypt</tt>; if relevant
+functions from these libraries cannot be called without the corresponding
+<tt>-l</tt> option, the option is added to the library option string.  If
+the <tt>-libs</tt> option is passed to the script, its parameter is
+appended to the library option string after all library checks are done.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_shared</span>)
+Checks whether dynamic (shared-object) modules can be used.  If the
+<tt>-use-static-modules</tt> option is given, dynamic modules are disabled;
+if not, and if a cached result is available, that result is used.
+Otherwise, a check is first made for the presence of the <tt>dlfcn.h</tt>
+header file, using the <tt>test_include</tt> function (see the
+<tt>check_stdint</tt> test below).  If this file is present, the script
+proceeds to check whether <tt>-ldl</tt> is needed to access the dynamic
+loader functions and ensure that <tt>-rdynamic</tt> and <tt>-shared</tt>
+can be used with the compiler.  A check is then made that attempts to open
+shared objects with unresolved symbols fail, and that shared objects with
+no unresolved symbols can in fact be used properly.  If these tests
+succeed, a final check is made to determine whether symbol lookups require
+an underscore prepended to the symbol name or not.  If any test fails,
+dynamic modules are disabled.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_ranlib</span>)
+Checks whether the <tt>ranlib</tt> program exists on the system.  If a
+cached result is not available, a dummy file is created, and the
+<tt>ar</tt> program is used to add it to a dummy archive (if <tt>ar</tt> is
+not available, the script aborts).  <tt>ranlib</tt> is then run on this
+archive, and the success or failure of the command is recorded.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_stdint</span>)
+Checks for the presence of the <tt>stdint.h</tt> header.  This is done by
+calling the <tt>test_include</tt> function, which first checks whether the
+given file exists in /usr/include, then, if the file is not found, checks
+whether a test program that includes the file with <tt>#include</tt> can be
+compiled.  The variable <tt>HAVE_<i>header_name</i></tt>, where
+<tt><i>header_name</i></tt> is the header filename converted to upper case
+with non-alphanumeric characters replaced by underscores, is then set to 1
+or 0 if the test succeeded or failed, respectively.  The return value of
+the function itself is the success or failure of the test.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_strings</span>)
+Checks for the presence of the <tt>strings.h</tt> header.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_sysselect</span>)
+Checks for the presence of the <tt>sys/select.h</tt> header.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_sysproto</span>)
+Checks for the presence of the <tt>sys/proto.h</tt> header.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_int8</span>)
+Determines what type can be used for 8-bit integers.  The <tt>char</tt>
+type, and the <tt>int8_t</tt> type if the <tt>stdint.h</tt> header is
+present, are checked first, giving preference to <tt>int8_t</tt> if
+available; if neither is an 8-bit type, a <tt>byte</tt> type is checked for
+next.  If that type does not exist or is not 8 bits wide, the script
+aborts.  The selected type is used to declare the <tt>int8</tt> and
+<tt>uint8</tt> types.  (As described in <a href="11.html#s1">section
+11-1</a>, Services development was started before <tt>stdint.h</tt> and
+the sized integer types were standardized, hence the use of nonstandard
+type names.)</li>
+
+<li class="spaced">(<span class="configure-test-name">check_int16</span>)
+Determines what type can be used for 16-bit integers, selecting among
+<tt>int16_t</tt> (if present), <tt>int</tt>, and <tt>short</tt> in that
+order.  The selected type is used to declare the <tt>int16</tt> and
+<tt>uint16</tt> types.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_int32</span>)
+Determines what type can be used for 32-bit integers, selecting among
+<tt>int32_t</tt> (if present), <tt>int</tt>, and <tt>long</tt> in that
+order.  The selected type is used to declare the <tt>int32</tt> and
+<tt>uint32</tt> types.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_int_size</span>)
+Finds the size of the <tt>int</tt> type.  If the <tt>int</tt> type is less
+than 16 bits wide (a violation of the C standard), the script aborts.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_long_size</span>)
+Finds the size of the <tt>long</tt> type.  If the <tt>long</tt> type is less
+than 32 bits wide (a violation of the C standard), the script aborts.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_ptr_size</span>)
+Finds the size of pointer types.  If pointers are smaller than integers,
+the script aborts (see <a href="#s5">section 10-5</a> regarding this
+assumption).</li>
+
+<li class="spaced">(<span class="configure-test-name">check_time_t</span>)
+Finds the size of the <tt>time_t</tt> type.  If the <tt>time_t</tt> type is
+less than 32 bits wide, the script aborts.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_gid_t</span>)
+Checks for the presence of the <tt>gid_t</tt> type and finds its size.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_socklen_t</span>)
+Checks for the presence of the <tt>socklen_t</tt> type.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_aix_intNN</span>)
+Checks whether system headers define the <tt>int16</tt> and <tt>int32</tt>
+types, which clash with type names used in Services.  The
+<tt>sys/systypes.h</tt> header in at least some versions of the AIX
+operating system seems to define these.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_strerror</span>)
+Checks for how system error numbers can be converted to descriptive
+strings.  The <tt>strerror()</tt> function is used preferentially if
+present; if not, a compatibility function in <tt>compat.c</tt> implements
+<tt>strerror()</tt>, using either the system's <tt>sys_errlist[]</tt> array
+if present, or a built-in message list if not.  However, if the
+<tt>-use-local-funcs</tt> option was given, this test is skipped and the
+compatibility function (assuming no <tt>sys_errlist[]</tt>) is used.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_compat</span>)
+Checks for compatibility functions that need to be enabled.  At this stage,
+the <tt>-use-local-funcs</tt> option is checked and, if present,
+compatibility functions for all functions below through <tt>strsignal()</tt>
+are enabled.  If not, and cached results are available for all functions,
+those results are used.  If not, testing proceeds to each individual
+function test.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_hstrerror</span>)
+Checks for the presence of the <tt>check_hstrerror()</tt> function.  This
+is done by calling the <tt>test_function</tt> function, which attempts to
+compile a test program which calls the function (the contents of the test
+program are specified by the called).  If the compilation succeeds and the
+test program returns a successful exit code (0), the function is assumed to
+exist.  As with <tt>test_include</tt>, the variable
+<tt>HAVE_<i>function_name</i></tt> (where <tt><i>function_name</i></tt> is
+the function name in upper-case) and return value are set according to the
+test result.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_snprintf</span>)
+Checks for the presence and behavior of the <tt>snprintf()</tt> function
+(if found, the <tt>vsnprintf()</tt> function is assumed to also exist).
+Services ignores the possibility of string truncation&mdash;which is
+probably a security issue in some cases; see also
+<a href="11.html#s1">section 11-1</a>&mdash;and expects <tt>snprintf()</tt>
+to return the number of characters actually written into the buffer.  If
+<tt>snprintf()</tt> is available but uses a different return value scheme,
+a compatibility function translates the return value to what Services
+expects.  If <tt>snprintf()</tt> is not available at all, the version
+included in <tt>vsnprintf.c</tt> is used.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_strtok</span>)
+Checks for the presence and behavior of the <tt>strtok()</tt> function.
+Some system library implementations of <tt>strtok()</tt> have been found to
+contain bugs, which are checked for by this test.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_stricmp</span>)
+Checks for the presence of the <tt>stricmp()</tt> function.  This is
+equivalent to the POSIX <tt>strcasecmp()</tt> function, but has a more
+concise and clearer name (I always have to stop and remember that the
+"case" in <tt>strcasecmp</tt> means that case is <i>ignored</i> rather
+than that it is compared).  If <tt>stricmp()</tt> is not available but
+<tt>strcasecmp()</tt> is available, the former is made an alias for the
+latter via <tt>#define</tt>.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_strdup</span>)
+Checks for the presence of the <tt>strdup()</tt> function.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_strspn</span>)
+Checks for the presence of the <tt>strspn()</tt> and <tt>strcspn()</tt>
+functions (the variable set is <tt>HAVE_STRSPN</tt>).</li>
+
+<li class="spaced">(<span class="configure-test-name">check_strsignal</span>)
+Checks for the presence of the <tt>strsignal()</tt> function.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_gettimeofday</span>)
+Checks for the presence of the <tt>gettimeofday()</tt> function.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_setgrent</span>)
+Checks for the presence of the <tt>setgrent()</tt> function.  However, if
+the <tt>gid_t</tt> type does not exist, the test is not executed and the
+function is assumed to not exist.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_setregid</span>)
+Checks for the presence of the <tt>setregid()</tt> function.  However, if
+the <tt>gid_t</tt> type does not exist, the test is not executed and the
+function is assumed to not exist.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_umask</span>)
+Checks for the presence of the <tt>umask()</tt> function.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_fork</span>)
+Checks for the presence of the <tt>fork()</tt> function.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_gethostbyname</span>)
+Checks for the presence of the <tt>gethostbyname()</tt> function.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_getsetrlimit</span>)
+Checks for the presence of the <tt>getrlimit()</tt> and <tt>setrlimit()</tt>
+functions.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_crypt</span>)
+Checks for the presence of the <tt>crypt()</tt> function.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_install</span>)
+Checks whether a working <tt>install</tt> program exists on the system.  If
+not, the <tt>install-script</tt> script included in the top source
+directory is used instead.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_install-d</span>)
+Checks whether <tt>install -d</tt> can be used to create directories.  If
+not, <tt>mkdir</tt> is tried as a workaround, falling back to the
+<tt>install-script</tt> script if necessary.</li>
+
+<li class="spaced">(<span class="configure-test-name">check_copy_recurse</span>)
+Determines what command should be used to copy entire directories.  The
+default command is <tt>cp -dpr</tt> in Linux and Cygwin environments, and
+<tt>cp -pr</tt> in other environments.  If this command does not work, the
+<tt>tar</tt> command is used as a substitute if possible (see the
+<tt>cp-recursive</tt> script in the top source directory).  If <tt>tar</tt>
+cannot be used either, the script aborts.</li>
+
+<li class="spaced">Creates the file <tt>config.h</tt>, containing the
+results of configuration relevant to the source code (such as compilation
+options and required compatibility functions) as <tt>#define</tt>
+preprocessor macros.  If the <tt>config.h</tt> file already exists and the
+content of the new <tt>config.h</tt> to be written is unchanged from that
+in the existing file, the existing file is left untouched, so as not to
+cause an unneeded recompile of all source files if <tt>configure</tt> is
+re-run with identical parameters.</li>
+
+<li class="spaced">Creates the file <tt>Makefile.inc</tt>, containing the
+results of configuration relevant to compilation commands (such as the
+compiler command and options and installation directories) as <tt>make</tt>
+variables.  As above, if <tt>Makefile.inc</tt> already exists and its
+content has not changed, the old file is left alone.</li>
+
+<li class="spaced">Creates the cache file <tt>config.cache</tt>, saving the
+results of configuration so that a subsequent run of the <tt>configure</tt>
+script will execute faster.  The file is written as a sequence of shell
+commands, so that it can simply be sourced at runtime rather than parsing
+each line individually.</li>
+
+</ul>
+
+<p>Note that a deliberate decision was made to not use the GNU
+<tt>autoconf</tt>/<tt>automake</tt>/<tt>libtool</tt> suite of tools, as
+they are overly complex for the range of systems Services is expected to be
+used on.  (I have seen far too many programs where running the
+autoconf-generated <tt>configure</tt> script takes longer than compiling
+the program itself.)</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s3">10-3. The compilation process</h3>
+
+<p>Overall compilation is controlled by the <tt>Makefile</tt> in the top
+source directory.  When run with no target specified, the default target
+<tt>all</tt> is used, which first checks that the <tt>configure</tt> script
+has been run (aborting with a notice to the user if not), then proceeds to
+actual compilation with the <tt>myall</tt> target.  This target compiles
+the main program (<tt>ircservices</tt> or <tt>ircservices.exe</tt>), then
+generates the language files and creates the <tt>convert-db</tt> and
+<tt>ircservices-chk</tt> tools.</p>
+
+<p>Additional targets available are: <tt>install</tt>, which installs
+program and data files to the appropriate directories (see
+<a href="#s4">section 10-4</a>); <tt>clean</tt>, which removes most
+generated files, such as object and executable files; and
+<tt>spotless</tt>, or <tt>distclean</tt> in the GNU style, which removes
+<i>all</i> generated files (including <tt>config.cache</tt>).  All of these
+targets are called recursively for the <tt>modules</tt>, <tt>lang</tt>, and
+<tt>tools</tt> directories.</p>
+
+<p>The main Makefile also includes two rules, for <tt>services.h</tt> and
+<tt>language.h</tt>, which cause those files to be <tt>touch</tt>ed (the
+file timestamp updated) whenever any sub-header file changes.  This is
+done because it is considered easier than ensuring that every dependency
+list stays up to date with all sub-header files.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s3-1">10-3-1. Core source files</h4>
+
+<p>Compilation of the main executable starts with compilation of the core
+source files, stored in the top source directory.  The object files to be
+created are listed in alphabetical order in the <tt>$(OBJS)</tt> variable.
+The options used for compilation are <tt>-DSTATIC_MODULES</tt> if using
+static modules, followed by the options selected by the <tt>configure</tt>
+script (in the <tt>$(BASE_CFLAGS)</tt> variable), followed by the options
+in the <tt>$(MORE_CFLAGS)</tt> variable (defined at the top of the
+Makefile, intended for users to add or change extra options on the fly).</p>
+
+<p>After compiling all of the core source files, compilation proceeds to
+the modules, as described below; finally, a <tt>version.c</tt> file is
+generated by the <tt>version.sh</tt> script, containing the program version
+number and a build number (extracted from the previous contents of
+<tt>version.c</tt>) which is incremented by one each build, and this file
+is compiled and linked with the rest of the main source files, as well as
+the modules when compiling modules statically, to produce the main
+executable.</p>
+
+<p>Note that one core header file, <tt>langstrs.h</tt>, is copied from the
+language file subdirectory, where it is first generated if necessary; see
+<a href="#s3-3">section 10-3-3</a> below for details.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s3-2">10-3-2. Modules</h4>
+
+<p>Compilation of modules is handled by <tt>modules/Makefile</tt> and its
+auxiliary file, <tt>modules/Makerules</tt>.  The top directory's Makefile
+calls one of two targets in <tt>modules/Makefile</tt> to compile all
+available modules: <tt>all-dynamic</tt> if dynamic linking is in use,
+<tt>all-static</tt> for static linking.  Both of these targets perform the
+same basic function: search for all subdirectories of the <tt>modules</tt>
+directory that contain Makefiles, and call the <tt>all-dynamic</tt> or
+<tt>all-static</tt> target in each subdirectory's Makefile.</p>
+
+<p>Since the subdirectory search is performed at compilation time, it is
+possible to add new modules to Services by simply copying the directory
+containing the module source code and Makefile into the <tt>modules</tt>
+directory.  This is in fact the recommended method for installing
+third-party modules, and the module compilation system was designed with
+this aim in mind.</p>
+
+<p>Of the two main targets in <tt>modules/Makefile</tt>, the
+<tt>all-dynamic</tt> target is the simpler of the two.  It loops through
+all subdirectories, calling the <tt>all-dynamic</tt> target in each, then
+updates a dummy <tt>.stamp</tt> file if the subdirectory's <tt>.stamp</tt>
+file was updated.  This file is used by the main Makefile to determine
+whether <tt>version.c</tt> should be regenerated.</p>
+
+<p>For static modules, the process is slightly more complicated, since a
+list of all modules and exported symbols must be provided to the core
+module manager.  In addition to calling each subdirectory's
+<tt>all-static</tt> target, the <tt>.modext-*</tt>, <tt>.modsyms-*</tt>,
+and <tt>.modlist-*</tt> files in each subdirectory are concatenated to
+form module and symbol lists; these are then compiled into an additional
+object file, <tt>modlist.o</tt>, and an archive (<tt>modules.a</tt>) is
+created containing this file and all module object files.  This archive is
+then linked into the final executable.</p>
+
+<p>The compilation of individual modules is handled by the
+<tt>modules/Makerules</tt> file, which is included by each subdirectory's
+Makefile.  This file is designed so that individual module Makefiles need
+only set up some variables with lists of files to be compiled and include
+the <tt>Makerules</tt> file.  However, due in part to limitations of the
+GNU <tt>make</tt> program, the actual implementation is quite complex, and
+as a side effect it takes <tt>make</tt> considerable time to process the
+module subdirectories even when no files need to be recompiled.</p>
+
+<p>The limitation in <tt>make</tt> which I found no easy way around during
+development is that there is (or was; see <a href="11.html#s1-gmake">the
+relevant note in section 11-1</a> for a method that works with newer
+versions of GNU <tt>make</tt>) no way to specify a rule in which the name
+of a variable specifying a dependency varies with the target name.  For
+example, suppose a subdirectory contains two modules, <tt>module1</tt> and
+<tt>module2</tt>.  If each module consists of only one source file and has
+no other dependencies, the rule is simple (assuming dynamic modules, and
+assuming the presence of a <tt>%.o: %.c</tt> compilation rule):</p>
+
+<div class="code">%.so: %.o
+	$(CC_SHARED) $^ -o $@</div>
+
+<p>However, suppose that <tt>module1</tt> depends on file <tt>aux1.o</tt>
+and <tt>module2</tt> depends on files <tt>aux2.o</tt> and <tt>aux3.o</tt>.
+If these are specified in <tt>$(OBJECTS-module1.so)</tt> and
+<tt>$(OBJECTS-module2.so)</tt>, one might then be tempted to write:</p>
+
+<div class="code">%.so: %.o $(OBJECTS-%.so)
+	$(CC_SHARED) $^ -o $@</div>
+
+<p>Unfortunately, this does not substitute <tt>module1</tt> or
+<tt>module2</tt> in the <tt>$(OBJECTS-%.so)</tt> reference, but uses the
+value of the variable literally named <tt>OBJECTS-%.so</tt>.  Nor does it
+work to use <tt>$@</tt> instead of <tt>%.so</tt> in the variable name:</p>
+
+<div class="code">%.so: OBJECTS = $(OBJECTS-$@)
+%.so: %.o $(OBJECTS)
+	$(CC_SHARED) $^ -o $@</div>
+
+<p>Here, <tt>$(OBJECTS)</tt> is only defined for commands inside the
+pattern rule, so it cannot be used in the dependency list.  Likewise,
+<tt>$@</tt> is only defined for the command list, so specifying
+<tt>$(OBJECTS-$@)</tt> in the dependency list also does not work.</p>
+
+<p>The upshot of all this is that in order to have a dependency list that
+varies with the target, it is necessary to call <tt>make</tt> recursively.
+The bulk of the <tt>Makerules</tt> file is dedicated to handling this
+recursive calling and setting variables appropriately for each target.</p>
+
+<p>The Makefile for a module directory typically consists only of variable
+definitions followed by the line "<tt>include ../Makerules</tt>".  Chief
+among the variables required is the <tt>$(MODULES)</tt> variable, which
+lists the modules contained in the directory; each module is specified with
+a <tt>.so</tt> extension (static modules are compiled to <tt>.a</tt>
+archives, but the filename translation is handled transparently by the
+<tt>Makerules</tt> file), and is assumed to be compiled from a source file
+of the same name with a <tt>.c</tt> extension.  If any additional object
+files are required by the module, they are specified in a variable named
+<tt>$(OBJECTS-<i>module</i>.so)</tt>, where <tt><i>module</i></tt> is
+replaced by the module name.  Header file dependencies can be specified
+through the <tt>$(INCLUDE)</tt> variable for dependencies common to all
+object files, and <tt>$(INCLUDE-<i>object</i>.o)</tt> for a particular
+object file.  If any object requires a special rule for compilation, that
+rule can be written in the Makefile, but rules are not needed for the
+ordinary case of compiling a <tt>.c</tt> source file to a <tt>.o</tt>
+object file.</p>
+
+<p>When the subdirectory's <tt>all-dynamic</tt> or <tt>all-static</tt> rule
+is first invoked, the script first checks, via pattern rules, that no
+modules have names ending in <tt>_static</tt> (which would conflict with
+the static module compilation procedure, as described below) or beginning
+with a period (which would conflict with the temporary files created during
+compilation).  Then, for each module, <tt>make</tt> is called recursively
+with the <tt>$(TARGET)</tt> variable set to the target module name (with
+no filename extension), <tt>$(OBJECTS)</tt> variable set to the contents of
+the particular module's object list (<tt>$(OBJECTS-<i>module</i>.so)</tt>),
+and <tt>$(REALLY_COMPILE)</tt>, the recursion level variable, set to 1.</p>
+
+<p>When called with <tt>$(REALLY_COMPILE)</tt> equal to 1,
+<tt>Makerules</tt> instead defines a rule for the target file,
+<tt>$(TARGET).so</tt> or <tt>$(TARGET).a</tt>  For dynamic modules, this
+simply involves compiling the relevant files and linking them into a
+shared object; for static modules, however, the objects will eventually be
+archived into a single <tt>modules.a</tt> archive, so no <tt>.a</tt> file
+for the individual module is actually needed.  What the rule does instead
+is to record each object file's name in the <tt>.$(DIRNAME).lst</tt> file,
+which is then used by the <tt>all-static</tt> rule to link all object files
+in the directory into a single object <tt>$(DIRNAME).o</tt> for storing in
+the <tt>modules.a</tt> archive.  (A dummy <tt>$(TARGET).a</tt> file is also
+created so that <tt>make</tt> can perform its file timestamp checks.)  In
+addition, since the static module manager requires a list of names and
+pointers for all variables and functions exported by each module, the
+static module compilation rule searches through all source files&mdash;each
+object file is assumed to correspond to a single source file with the same
+name and a <tt>.c</tt> extension, and no header files are checked&mdash;for
+<tt>EXPORT_VAR()</tt>, <tt>EXPORT_ARRAY()</tt>, and <tt>EXPORT_FUNC()</tt>
+macro invocations.  The export information given to these macros, along
+with declarations for the implicitly exported variables
+<tt>_this_module_ptr</tt> and <tt>module_version</tt>, array
+<tt>module_config[]</tt>, and functions <tt>init_module()</tt> and
+<tt>exit_module()</tt>, are written to two temporary files:
+<tt>.modext-<i>module</i>.h</tt>, containing <tt>extern</tt> declarations,
+and <tt>.modsyms-<i>module</i>.c</tt>, containing the actual symbol
+entries.  A line with the module name and symbol array pointer is also
+written to <tt>.modlist-<i>module</i>.c</tt> for later inclusion in the
+overall module list.</p>
+
+<p>For each individual object file, <tt>Makerules</tt> first (at recursion
+level 1) generates a rule for compiling the object file that calls
+<tt>make</tt> recursively, with <tt>$(TARGET)</tt> now set to the object
+file's base filename (with the <tt>.o</tt> extension stripped),
+<tt>$(INCLUDES2)</tt> set to the particular object file's dependency list
+from <tt>$(INCLUDES-<i>object</i>.o)</tt>, <tt>-DMODULE</tt> and
+<tt>-DMODULE_ID=<i>module-id</i></tt> appended to <tt>$(CFLAGS)</tt>
+(<tt><i>module-id</i></tt> is a C-style identifier derived from the
+directory and module name, used to make common module identifiers unique),
+and <tt>$(REALLY_COMPILE)</tt> set to 2.  In addition, for the main file
+of a module (the source file with the same name as the module),
+<tt>-DMODULE_MAIN_FILE</tt> is also appended to <tt>$(CFLAGS)</tt>.</p>
+
+<p>In this second recursion level, the actual source file compilation is
+performed.  The <tt><i>object</i>.o</tt> rule does not perform the actual
+compilation, but depends on a <tt>.compiled-<i>object</i>.o</tt> dummy file
+whose rule performs the compilation and on a dummy <tt>FRC</tt> (force)
+rule; this hack prevents <tt>make</tt> from outputting "nothing to do"
+messages for every unchanged object file.  The compilation command itself
+is similar to that used for the core source code, but the command is
+prefixed by a <tt>cd</tt> to the top directory, so that the relative path
+to the source file is saved in the object file's debug information.  This
+allows debuggers to easily find the proper source file, even if multiple
+module subdirectories have identically-named source files.</p>
+
+<p>For static modules, a slight change is made for the module's main source
+file: rather than compiling the source file to <tt><i>module</i>.o</tt>,
+the object file is given the filename <tt><i>module</i>_static.o</tt>, and
+the five implicitly exported variables/functions (<tt>init_module()</tt>,
+etc.) are renamed via <tt>-D</tt> options to names containing the
+<tt><i>module-id</i></tt> so that they do not cause symbol conflicts with
+other modules at link time.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s3-3">10-3-3. Language files</h4>
+
+<p>The language files, stored in the <tt>lang</tt> directory, are
+precompiled into binary format to speed the startup of Services, as
+described in <a href="2.html#s8-4">section 2-8-4</a>.  This precompilation
+is performed by the <tt>langcomp</tt> program, compiled from
+<tt>langcomp.c</tt>.  When called with the <tt>all</tt> target, the
+Makefile first compiles <tt>langcomp</tt>, then runs it on each language
+source file to generate the corresponding precompiled binary file.  In the
+special case of the Japanese language files (<tt>ja_*.l</tt>), which
+correspond to the various encodings common on Japanese computer systems,
+the EUC file (<tt>ja_euc.l</tt>) is treated as canonical, and when it
+changes, the <tt>jconv.pl</tt> script is automatically run to regenerate
+the <tt>ja_sjis.l</tt> file before compiling it to binary format.  (There
+was also a JIS-encoded file, <tt>ja_jis.l</tt>, in the past, but this was
+dropped because of extra % characters in the text causing <tt>printf()</tt>
+functions to break.)</p>
+
+<p>The list of standard language strings is taken from the English language
+file, <tt>en_us.l</tt>; a simple <tt>grep</tt> is used to extract the
+string names to the <tt>index</tt> file, and this file is then used to
+generate <tt>langstrs.h</tt>, which contains the string names both as
+preprocessor (<tt>#define</tt>) constants and as a string array, available
+if <tt>LANGSTR_ARRAY</tt> is defined.  The core source file
+<tt>language.c</tt> uses this array for looking up string names when
+loading external language files at runtime.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s3-4">10-3-4. The <tt>tools</tt> and <tt>data</tt> directories</h4>
+
+<p>The <tt>tools</tt> directory contains two additional programs:
+<tt>convert-db</tt>, the database conversion tool discussed in
+<a href="9.html">section 9</a>, and <tt>ircservices-chk</tt>, a simple
+script designed to run from a periodic execution utility such as
+<tt>cron</tt> to ensure that Services is restarted if it should stop for
+any reason (such as a crash).</p>
+
+<p>In addition to the main source file <tt>convert-db</tt> and the
+<tt>convert-*.c</tt> source files that handle particular database types,
+<tt>convert-db</tt> makes use of three source files from the main source
+code: <tt>compat.c</tt>, containing compatibility functions;
+<tt>modules/database/fileutil.c</tt>, containing routines to read and write
+data in binary database files; and <tt>modules/misc/xml-export.c</tt>,
+containing routines to generate an XML file from loaded data.  These three
+files are compiled using special rules, which include the
+<tt>-DCONVERT_DB</tt> compiler option to trigger special handling in the
+source files for the <tt>convert-db</tt> tool.</p>
+
+<p>The "compilation" of <tt>ircservices-chk</tt> consists of simply
+replacing the <tt>@PROGRAM@</tt>, <tt>@BINDEST@</tt> and <tt>@DATDEST@</tt>
+fields in the template file <tt>ircservices-chk.in</tt> with the actual
+file/pathnames, writing the output to the file <tt>ircservices-chk</tt>
+(more precisely, <tt>$(PROGRAM)-chk</tt>, where <tt>$(PROGRAM)</tt> is the
+value of the <tt>-program</tt> option given to the <tt>configure</tt>
+script), and marking that file executable with <tt>chmod</tt>.</p>
+
+<p>Likewise, the two sample configuration files
+(<tt>example-ircservices.conf</tt> and <tt>example-modules.conf</tt>) in
+the <tt>data</tt> subdirectory are generated from template files, replacing
+occurrences of <tt>@PROGRAM@</tt> with the actual program name to give
+appropriate defaults for various file names.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s4">10-4. Installation</h3>
+
+<p>The <tt>install</tt> target, which like <tt>all</tt> defers actual work
+to the <tt>myinstall</tt> target, first creates the target directories,
+<tt>$(BINDEST)</tt> and <tt>$(DATDEST)</tt>, if they do not exist; copies
+the main executable file to the <tt>$(BINDEST)</tt> directory; and calls
+the <tt>install</tt> target in the <tt>modules</tt>, <tt>lang</tt>,
+<tt>tools</tt>, and <tt>data</tt> directories.  However, when static
+modules are being used, the module install is skipped (since the module
+objects are linked directly into the executable, there is nothing to
+install).</p>
+
+<p>The module installation consists of calling the <tt>install</tt> target
+in each module subdirectory; this target, declared in the
+<tt>modules/Makerules</tt> file, creates a subdirectory of the same name
+inside the <tt>modules</tt> directory under <tt>$(DATDEST)</tt>, then
+copies all module shared-object files into that directory.</p>
+
+<p>The language installation first creates a <tt>language</tt> directory
+under <tt>$(DATDEST)</tt>; the precompiled language files are then copied
+into that directory.</p>
+
+<p>The tool installation copies the <tt>ircservices-chk</tt> script to
+<tt>$(BINDEST)</tt>, and the <tt>convert-db</tt> program to
+<tt>$(DATDEST)</tt>.  The latter is not copied to the executable file
+directory to avoid the possibility that the executable file name conflicts
+with another program installed on the system.  (A better solution might be
+to rename the program to something like <tt>ircservices-convert</tt>.)</p>
+
+<p>The data file installation copies the example configuration files,
+<tt>example-ircservices.conf</tt> and <tt>example-modules.conf</tt>, to
+<tt>$(DATDEST)</tt>; <tt>example-ircservices.conf</tt> is renamed at this
+time to <tt>example-$(PROGRAM).conf</tt>.  If the <tt>helpfiles</tt>
+directory does not exist under <tt>$(DATDEST)</tt>, it is copied from the
+<tt>helpfiles</tt> subdirectory of the <tt>data</tt> directory.</p>
+
+<p>Since the <tt>install</tt> target depends on the <tt>all</tt> (or more
+precisely, the <tt>myall</tt>) target, it is also possible to perform
+compilation and installation in one step by simply executing <tt>make
+install</tt>.</p>
+
+<p>If the variable <tt>INSTALL_PREFIX</tt> is set, its value is prepended
+to all pathnames used for installation; for example, the
+<tt>ircservices</tt> executable file is installed to
+<tt>$(INSTALL_PREFIX)$(BINDEST)/ircservices</tt>.  This allows Services to
+be installed to an alternate root directory, such as when preparing a
+chroot'd environment or a distribution image.  This variable is not set by
+any of the Makefiles, but can be set on the <tt>make</tt> command line.
+(Note that there is no slash after <tt>$(INSTALL_PREFIX)</tt>; inserting
+one would have the side effect of prefixing <tt>$(BINDEST)</tt> and
+<tt>$(DATDEST)</tt> with a slash when no prefix was given, which could
+potentially have undesired side effects.)</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s5">10-5. Assumptions</h3>
+
+<p>Finally, it is worth noting a few assumptions made by the source code.
+These are all believed to hold on any system Services is likely to be used
+on, and some are double-checked by the <tt>configure</tt> script.</p>
+
+<ul>
+<li class="spaced"><b>Pointer values are at least as large as <tt>int</tt>
+values.</b>  The module system uses <tt>void&nbsp;*</tt> as type
+placeholders for module callbacks, as described in
+<a href="4.html#s5-3">section 4-5-3</a>, and some database management
+routines, such as in the OperServ news and autokill modules (see
+<a href="7.html#s2-2-1">section 7-2-2-1</a>, for example) store integer
+values in pointer fields.  While these are admittedly very crocky ways of
+doing things, they do require that pointers be at least large enough to
+hold values that may be stored in them.  The <tt>configure</tt> script
+checks that pointers are at least as large as <tt>int</tt>s, and aborts if
+not.</li>
+
+<li class="spaced"><b>Character values are exactly 8 bits.</b>  More
+precisely, a <tt>char</tt> variable is exactly one byte in size (whatever
+size a byte may be).  This is not checked by the <tt>configure</tt> script,
+but it is mandated by the C standard and should not be a problem.</li>
+
+<li class="spaced"><b>Unprototyped routines can accept up to five arguments
+regardless of type.</b>  Or to be more accurate, all of the first five
+arguments to a routine are stored in same-size locations regardless of
+type.  This requirement is a side effect of the module callback calling
+method mentioned above, and holds on at least x86 (where everything except
+<tt>long long</tt> is 32 bits) and x86-64 (where the first five arguments
+are all passed in registers).  Note that this is not checked by the
+<tt>configure</tt> script.</li>
+
+<li class="spaced"><b>Pointer aliasing (type-punning) is allowed.</b>  The
+C standard disallows "aliasing" of pointers of different types (C99 6.5 (7));
+in other words, if you have a pointer variable <tt>struct foostruct
+*foo</tt>, you may not assign the value of <tt>foo</tt> to <tt>struct
+barstruct *bar</tt> and then modify the contents of <tt>*bar</tt>.  This
+sounds like a good idea on the surface, but it turns out to be quite
+inconvenient in practice; in particular, it prevents the use of "derived
+structures", where the first member of one structure is a second structure
+(similar to a derived class in object-oriented languages).  It would in
+theory be possible, if unduly verbose, to rewrite the code to obey the
+aliasing rules; but for convenience, Services simply assumes that this sort
+of aliasing is permitted.  The <tt>configure</tt> script does not check for
+this directly, since any effect would be compiler-dependent and difficult
+(if not impossible) to detect reliably, but the script does enable the
+<tt>-fno-strict-aliasing</tt> option when compiling with GCC, which
+disables optimizations that rely on this aliasing rule.</li>
+
+<li class="spaced"><b>The <tt>NULL</tt> pointer is bitwise zero for all
+pointer types.</b>  For the sake of efficiency (and concise source code),
+arrays or structures containing pointers are often cleared by using
+<tt>calloc()</tt> to allocate precleared memory or <tt>memset()</tt> to
+fill the memory region with the byte value 0, and it is assumed that these
+operation are equivalent to individually assigning the <tt>NULL</tt> value
+to each pointer.  The C standard does not require that <tt>NULL</tt> be
+stored in memory as the value zero, only that it compare equal to zero, but
+every system I have used so far uses bitwise zero for <tt>NULL</tt>, so I
+have not made an effort to write "correct" code.  Note that the
+<tt>configure</tt> script does not check for this.</li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<p class="backlink"><a href="9.html">Previous section: The database conversion tool</a> | 
+<a href="index.html">Table of Contents</a> |
+<a href="11.html">Next section: Future work</a></p>
+
+</body>
+</html>

docs/tech/11.html

@@ -0,0 +1,447 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Style-Type" content="text/css"/>
+<style type="text/css">@import "style.css";</style>
+<title>IRC Services Technical Reference Manual - 11. Future work</title>
+</head>
+
+<body>
+<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
+
+<h2 class="section-title">11. Future work</h2>
+
+<p class="section-toc">
+     11-1. <a href="#s1">Design issues</a>
+<br/>11-2. <a href="#s2">User interface issues</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-1. <a href="#s2-1">NickServ issues</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-2. <a href="#s2-2">ChanServ issues</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-3. <a href="#s2-3">MemoServ issues</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-4. <a href="#s2-4">OperServ issues</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-5. <a href="#s2-5">StatServ issues</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-6. <a href="#s2-6">Other issues</a>
+<br/>&nbsp;&nbsp;&nbsp;&nbsp;11-2-7. <a href="#s2-7">Rejected suggestions</a>
+</p>
+
+<p class="backlink"><a href="10.html">Previous section: Compilation</a> | 
+<a href="index.html">Table of Contents</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s1">11-1. Design issues</h3>
+
+<ul>
+
+<li class="spaced">Services currently operates under the assumption that
+enough memory will be available for its needs, and simply aborts the
+program in most cases if a memory allocation fails (the <tt>smalloc()</tt>
+function).  On modern systems this should be true most of the time anyway,
+but a better design would eliminate <tt>smalloc()</tt> and friends, and
+instead degrade gracefully when out of resources (for example, returning an
+"internal error" or "out of resources" message to a pseudoclient command).</li>
+
+<li class="spaced">Services ignores the possibility of truncation when
+using the <tt>snprintf()</tt> and <tt>vsnprintf()</tt> functions.  In most
+cases, such truncation would only result in the user seeing a truncated
+response string, and I have (at least in recent development) made an effort
+to check for overflow in security-related situations before calling
+<tt>snprintf()</tt>, but I cannot rule out the possibility that some
+security issues related to string truncation exist.  The code should be
+rewritten to (1) use an <tt>snprintf()</tt> that follows the POSIX
+standard of returning the number of bytes that would be written given an
+infinite buffer and (2) check the return value for overflow where
+pertinent.</li>
+
+<li class="spaced">As also mentioned in <a href="10.html#s5">section
+10-5</a>, the module callback implementation relies on the very flaky
+assumption that any type can be passed through a <tt>void&nbsp;*</tt> and
+come out unscathed on the other side, regardless of the parameter types
+used by the called function.  This happens to work on the Intel x86
+architecture because everything is 32 bits, and on the AMD x86-64
+architecture because the first five parameters (the maximum supported for
+callbacks in the current implementation) are passed in registers rather
+than on the stack, but there is no guarantee that this will also work on
+future (or other existing) architectures.  The implementation also assumes
+that a function can be passed more parameters than it actually accepts
+without any harm.  One possible alternative is to use variadic argument
+lists, but this would require changing all callback functions to take a
+<tt>va_list</tt> argument and retrieve the arguments manually; due to the
+amount of work this would take, the current implementation has been left
+alone for this release, and a redesign is left for future work.</li>
+
+<li class="spaced">Services defines its own types for integers of specific
+sizes: <tt>int8</tt>, <tt>uint32</tt>, and the like.  The standard header
+file <tt>stdint.h</tt> declares similar types, using names like
+<tt>int8_t</tt> and <tt>uint32_t</tt>; however, these are not used because
+this header file did not exist (or was not standardized, at least) during
+the early stages of Services' development, when the need for sized integer
+types arose.  Changing the code to use the standard types would remove the
+need to define those types in the <tt>configure</tt> script.</li>
+
+<li class="spaced">It has been suggested from time to time that Services
+use a full-fledged database management system such as MySQL for database
+storage, to allow easy access to the data by other programs such as CGI
+scripts on a web server.  In fact, the major services programs I am aware
+of which are currently (October 2007) under development seem to be taking
+this route.  However, Services has been designed from the start with the
+assumption that its data will never be modified by any outside process, and
+in fact, even the change from periodic expiration to expiration on access
+made during 5.0 alpha development caused several dangling-pointer bugs to
+surface.  Attempting to use external databases that could be modified by
+other programs within the current Services framework would at best cause
+such modified data to be overwritten when Services saved its databases, and
+at worst cause Services to crash when it tried to access data that had been
+modified without its knowledge.  That said, this design decision enforces a
+single-threaded execution model for the entire program, and for that reason
+alone is a good target for redesign.  (With respect to read-only access to
+Services data, XML-based data export was added in version 5.0.)</li>
+
+<li class="spaced">In relation to the above, XML has also been suggested as
+a native database format.  I have been reluctant to do this, both from the
+practical point of view that writing the databases in a textual format
+takes considerably longer than doing so in a binary format and would impair
+Services' responsiveness, and because I see XML as a data interchange
+format rather than a data storage format and believe that the two should be
+handled separately.  However, the former issue may well be moot for smaller
+networks, and the latter is a matter of taste; in addition, the current XML
+import and export modules lack the flexibility of the database system, as
+discussed at the top of <a href="8.html#s4-1">section 8-4-1</a>, so I leave
+this issue here for consideration.</li>
+
+<li class="spaced">Currently, Services records all log messages to a single
+log file, in a format intended for human perusal rather than machine
+processing.  This could be improved with an "event log" system and logging
+modules, whereby a common log function is called with some sort of event
+identifier and event data, and the log module(s) then perform appropriate
+actions; this would allow, for example, the creation of a log file with
+all nickname-related events stored in a format easily parsable by other
+programs, or the creation of an online "log channel" to which nickname and
+channel operations are sent.</li>
+
+<li class="spaced">ChanServ currently requires a password for founder-level
+access to registered channels.  However, since those privileges are also
+granted to the founder him/herself upon nickname identification, channel
+passwords could be considered optional; deliberately not setting a password
+on a channel would thus prevent the channel from being taken over by
+password theft.  However, the password also serves as an extra measure to
+prevent accidental dropping of channels (the <tt>DROP</tt> command requires
+password authentication), so an alternate method would have to be
+considered if channel passwords were made optional.</li>
+
+<li class="spaced">As mentioned in <a href="7.html#s4-1-4">section
+7-4-1-4</a>, it may be desirable to include "successor" channels in a
+user's owned-channel count.  This would alleviate the potential for a
+channel with a successor to nonetheless disappear on deletion of the
+founder's nickname (because the successor owned too many channels at that
+particular time).</li>
+
+<li class="spaced">Services has used a level-based access system since its
+inception, in which channel users are assigned a single numeric access
+level; this level then determines what privileges (if any) the user is
+allowed on the channel.  While more flexible than a simple system like the
+XOP command set, the use of numbers can prove confusing and difficult to
+understand, and there is no way to selectively grant higher-level
+privileges without also granting lower-level ones.  A system such as the
+"role" system used in PTlink Services 3.x, in which privileges are
+individually granted to users, could help solve these problems.</li>
+
+<li class="spaced">The use of binary bitfields to represent channel modes
+allows for efficient processing; however, it causes problems when changing
+from one protocol to another, because channels' mode lock data is stored
+using those same bitfields.  One way around this is to simply export and
+re-import the data using XML (which is probably a good idea in any case, to
+compensate for things like different processing of nicknames and channel
+names).  An alternative approach would be to store the modes as strings, at
+the cost of additional processing and storage requirements.  Still another
+approach might define a common set of mode bits among all protocols,
+allowing other protocols' modes to be interpreted properly; in essence, the
+set of modes defined in the core mode handling would be the union of all
+those defined in the standard protocol modules, rather than the
+intersection.  However, this would require wider data fields to handle the
+necessity of giving every mode its own unique bit, and would leave
+third-party protocol modules without a way to express their own custom
+modes.  The wisdom of including protocol-specific data in the Services core
+is also questionable.</li>
+
+<li class="spaced">The OperServ privilege system is currently very coarse.
+It essentially provides only three distinct classes: no privileges,
+Services operator, and Services administrator.  (The super-user class is
+identical to the administrator class except for the ability to modify the
+Services administrator list and to bypass the NSSecureAdmins security
+restrictions.)  Moreover, the privileges granted to Services operators are
+very limited, while those granted to Services administrators are extremely
+powerful, leaving no "middle ground".  At least one user of Services has
+noted that the inability to view user information, for example to resolve
+disputes between users, without also granting full administrator privileges
+is problematic.  Services would benefit from a review of these privilege
+classes; for example, it might be wise to require super-user privileges for
+dangerous commands such as <tt>JUPE</tt> and <tt>SHUTDOWN</tt>, which would
+then allow the administrator class to be used for tasks such as viewing
+user information.</li>
+
+<li class="spaced">Related to the above, it might be useful to allow
+OperServ privileges and related commands (such as NickServ and ChanServ
+<tt>FORBID</tt> or <tt>INFO ALL</tt>) to be assigned to different classes
+based on configuration settings.  For example, one network might decide to
+allow Services operators to use information retrieval commands (currently
+limited to Services administrators), while another might choose to let all
+IRC operators use the OperServ <tt>AKILL</tt> command.  Note that allowing
+this sort of configuration will require dynamically-generated help messages
+(since the required privilege class may change at runtime), in addition to
+new OperServ privilege-checking functions similar to
+<tt>is_services_oper()</tt> and <tt>is_services_admin()</tt>.</li>
+
+<li class="spaced">Configuration directives have been added somewhat
+haphazardly over the course of Services' development, and could probably
+use a review and overhaul.  In particular, there are several "negative
+options", including <tt>NoBouncyModes</tt>, <tt>NoSplitRecovery</tt>, and
+<tt>NoAdminPasswordCheck</tt>, which were added as negatives to avoid
+changing Services' behavior in the middle of a release series.  These have
+the unintuitive effect that <i>enabling</i> the option <i>disables</i> a
+particular behavior; ideally, such options should be written as positives
+(<i>e.g.,</i> <tt>BouncyModeCheck</tt> or <tt>SplitRecovery</tt>) and
+enabled in the default configuration file.</li>
+
+<li class="spaced" id="s1-gmake">As described in
+<a href="10.html#s3-2">section 10-3-2</a>, the module compilation process
+makes use of several time-consuming tricks to simplify the individual
+modules' Makefiles.  However, version 3.81 of GNU <tt>make</tt> introduced
+the special target <tt>.SECONDEXPANSION</tt>, which causes dependency lists
+in subsequent rules to be expanded twice; for example, a rule
+<div class="code">%.so: %.o $$(OBJECTS-$$@)</div>
+(note the escaped <tt>$</tt> characters, to prevent expansion on the first
+pass) would do what it looks like&mdash;supply a dependency list using a
+variable name derived from the target module name.  Use of this feature
+could substantially simplify the <tt>modules/Makerules</tt> file, at the
+expense of incompatibility with versions 3.79 and 3.80 of GNU
+<tt>make</tt>.</li>
+
+</ul>
+
+<p>There are also several issues listed in <a href="../d.html">Appendix
+D</a> of the user's manual.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s2">11-2. User interface issues</h3>
+
+<p>A number of possible functionality additions or changes have been
+considered by the author or suggested by users over the years.  These are
+summarized by subsystem below, in no particular order.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s2-1">11-2-1. NickServ issues</h4>
+
+<ul>
+<li class="spaced">Allow certain nicknames (specified by wildcard mask)
+	to be used but not registered.  <i>Suggested by Mark Hetherington
+	<tt>&lt;mark@ctcp.net&gt;</tt></i></li>
+<li class="spaced">Include successor channels in the output of the
+	<tt>LISTCHANS</tt> command.  <i>Suggested by Marc-Andre A. Fuentes
+	<tt>&lt;nothing@psychopat.org&gt;</tt></i></li>
+<li class="spaced">When using the <tt>nickserv/mail-auth</tt> module,
+	perform a DNS (MX) lookup on the domain in the E-mail address given
+	to the <tt>REGISTER</tt> or <tt>SET EMAIL</tt> address before
+	actually trying to send the authentication code message.
+	<i>Suggested by Brian <tt>&lt;n1uro@n1uro.com&gt;</tt></i></li>
+<li class="spaced">Include Services administrator or operator status in
+	the output from the <tt>INFO</tt> command.  <i>Suggested by Yusuf
+	Iskenderoglu <tt>&lt;uhc0@stud.uni-karlsruhe.de&gt;</tt></i></li>
+<li class="spaced">When the <tt>NSForceNickChange</tt> configuration option
+	is set, have the <tt>GHOST</tt> command change target users' nicks
+	rather than killing them outright.  <i>Suggested by Mark
+	Hetherington <tt>&lt;mark@ctcp.net&gt;</tt></i></li>
+<li class="spaced">An option to warn users via E-mail when a nickname is
+	about to expire.  <i>Suggested by Hans v Steenbergen
+	<tt>&lt;thebeast@xs4all.nl&gt;</tt></i></li>
+<li class="spaced">An option to allow users to change their "fake usermask"
+	(username and hostname shown in <tt>/whois</tt> output) to their
+	registered E-mail address, on servers supporting such a feature.</li>
+<li class="spaced">Allow Services administrators to modify other nicknames'
+	access lists.  <i>Suggested by Mauritz Antunes
+	<tt>&lt;mauritz@brasnet.org&gt;</tt></i></li>
+<li class="spaced">An option to limit the set of languages users are
+	allowed to select with <tt>SET LANGUAGE</tt>.  <i>Suggested by
+	Mauritz Antunes <tt>&lt;mauritz@brasnet.org&gt;</tt></i></li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s2-2">11-2-2. ChanServ issues</h4>
+
+<ul>
+<li class="spaced">Better integration of channel keys with ChanServ; for
+	example, authorized users should have a way to enter even if a
+	channel key is set, much like they can use the <tt>UNBAN</tt> or
+	<tt>INVITE</tt> commands to get around channel bans or mode
+	<tt>+i</tt>.</li>
+<li class="spaced">An option to autokill users entering a forbidden
+	channel (<i>e.g.,</i> to efficiently remove botnets from a
+	network).</li>
+<li class="spaced">Allow autokick exceptions.  <i>Suggested by Dionisios
+	K. <tt>&lt;admin@vonitsanet.gr&gt;</tt></i></li>
+<li class="spaced">A configuration option listing channel modes that uers
+	are not allowed to change, like a mode lock enforced on all
+	channels.  <i>Suggested by <tt>&lt;medice@gmx.at&gt;</tt></i></li>
+<li class="spaced">A ChanServ <tt>LINK</tt> command, like the NickServ
+	command of the same name but for channels.  <i>Suggested by Craig
+	McLure <tt>&lt;Craig@chatspike.net&gt;</tt></i></li>
+<li class="spaced">A <tt>VERBOSE</tt> option, causing ChanServ to send
+	notices (like for <tt>OPNOTICE</tt>) to the channel for all
+	ChanServ commands.  <i>Suggested by
+	<tt>&lt;martin@e-tech.us&gt;</tt></i></li>
+<li class="spaced">A command to look up channels by E-mail address.
+	<i>Suggested by Finny Merrill <tt>&lt;griever@t2n.org&gt;</tt></i></li>
+<li class="spaced">More intelligent handling of a missing "<tt>#</tt>" in
+	the channel name parameter for <tt>REGISTER</tt>.  <i>Suggested by
+	<tt>&lt;jollino@sogno.net&gt;</tt></i></li>
+<li class="spaced">A better method of determining a channel's "last-used"
+	time than the last time a user was auto-opped (but avoiding overly
+	sensitive schemes that update the last-used time even for
+	spambots).</li>
+<li class="spaced">An option to send an explanatory notice to a user who
+	tries to use a restricted ChanServ command on a channel with the
+	<tt>SECURE</tt> option set, without identifying for their
+	nickname.</li>
+<li class="spaced">Record the nickname of the user that added each access
+	entry and the last time the access entry was used.</li>
+<li class="spaced">Display access entries ordered by level.</li>
+<li class="spaced">Allow modification of (adding modes from or removing
+	modes to) channel mode locks, rather than wholesale replacement
+	only.</li>
+<li class="spaced">When switching IRC server types that do not share the
+	same set of channel modes, graceful degradation of locked modes not
+	available with the new protocol.  <i>Suggested by Yusuf
+	Iskenderoglu <tt>&lt;uhc0@stud.uni-karlsruhe.de&gt;</tt></i></li>
+<li class="spaced">Treat the <tt>/topic</tt> IRC command identically to the
+	ChanServ <tt>TOPIC</tt> command when determining whether to allow a
+	topic change on a channel with <tt>TOPICLOCK</tt> set.  <i>Suggested
+	by Casey <tt>&lt;caseyclaydon@fastmail.com.au&gt;</tt></i></li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s2-3">11-2-3. MemoServ issues</h4>
+
+<ul>
+<li class="spaced">A setting to reverse the meaning of the ignore list, so
+	that only users on the list are allowed to send memos.</li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s2-4">11-2-4. OperServ issues</h4>
+
+<ul>
+<li class="spaced">A command to kill nicknames matching a wildcard or
+	regular expression.  <i>Suggested by Guy Antony Halse
+	<tt>&lt;guy@rucus.ru.ac.za&gt;</tt></i></li>
+<li class="spaced">An option to send a notice to autokilled users of the
+	autokill expiration time before performing the actual kill.
+	<i>Suggested by <tt>&lt;saturn@jetirc.net&gt;</tt></i></li>
+<li class="spaced">The ability to use full regular expressions, not just
+	simple wildcards, in autokill and other wildcard masks.
+	<i>Suggested by Aragon Gouveia
+	<tt>&lt;aragon@phat.za.net&gt;</tt></i></li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s2-5">11-2-5. StatServ issues</h4>
+
+<ul>
+<li class="spaced">Keep track of the number of users per domain on each
+	server.  <i>Suggested by Ali Sor
+	<tt>&lt;alisor@softhome.net&gt;</tt></i></li>
+<li class="spaced">Keep track of statistics such as the number of joins
+	and kicks for each channel and the number of connections made by
+	each user or nickname.  <i>Suggested by
+	<tt>&lt;Georges@Berscheid.lu&gt;</tt></i></li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s2-6">11-2-6. Other issues</h4>
+
+<ul>
+<li class="spaced">An option or module to log all <tt>WALLOPS</tt> (and
+	<tt>GLOBOPS</tt>, etc.) messages.  <i>Suggested by Andrew
+	Kempe.</i></li>
+<li class="spaced">An in-program method to clear one or more databases
+	(currently, this can only be done by removing the corresponding
+	database files).  <i>Suggested by
+	<tt>&lt;RealCFC@chatfirst.com&gt;</tt></i></li>
+<li class="spaced">A network status page, possibly with graphs (see for example
+	<a href="http://irc.netsplit.de/"><tt>irc.netsplit.de</tt></a>).
+	<i>Suggested by <tt>&lt;jollino@sogno.net&gt;</tt></i></li>
+<li class="spaced">An option to autokill users who are killed repeatedly
+	for bad passwords.  <i>Suggested by Jonathan Morton
+	<tt>&lt;chromi@cyberspace.org&gt;</tt></i></li>
+<li class="spaced">The ability to reconnect to the uplink server if
+	disconnected.</li>
+<li class="spaced">A way to send commands to OperServ (or possibly other
+	pseudoclients) from another process.</li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+
+<h4 class="subsubsection-title" id="s2-7">11-2-7. Rejected suggestions</h4>
+
+<p>In addition to the above, the author has explicitly rejected a few
+feature suggestions as unnecessary or inappropriate for inclusion in
+Services; however, they are recorded here for the consideration of future
+developers.</p>
+
+<ul>
+<li class="spaced"><b>Automatic opping/voicing/etc. of users on channel
+	access list changes.</b>  For example, automatically setting
+	<tt>+o</tt> on a user added to the access list with auto-op
+	privileges.  While this is certainly not a useless feature, access
+	list changes are typically one-time events, and do not warrant the
+	added complexity of including such a feature; the user can be
+	manually opped or voiced just as easily.</li>
+<li class="spaced"><b>Allow identification to multiple nicknames.</b>
+	This can result in ambiguities when handling channel access levels.
+	For example, suppose a user has identified to two nicknames,
+	GoodNick and BadNick.  If on a certain channel, GoodNick has an
+	access level of 50 but BadNick has an access level of -10, what
+	access level should the user be granted?  The answer varies with
+	the particular channel and user, and rather than attempting to
+	invent a system of options and rules to handle every possible
+	circumstance, Services simply disallows identification to multiple
+	nicknames entirely.  (Services will remember whether a user has
+	identified for a nickname if the user temporarily switches to
+	another nickname.)</li>
+<li class="spaced"><b>A channel option or configuration file setting to
+	make ChanServ join channels, or a BotServ pseudoclient to do the
+	same thing.</b>  This is one of the most common feature requests,
+	but it has consistently been rejected as incompatible with the
+	design of Services as a streamlined network tool rather than a
+	users' toy, and also because standard bots can provide equivalent
+	functionality much more flexibly than a single Services
+	pseudoclient could.</li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<p class="backlink"><a href="10.html">Previous section: Compilation</a> | 
+<a href="index.html">Table of Contents</a></p>
+
+</body>
+</html>

docs/tech/c.html

@@ -0,0 +1,959 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Style-Type" content="text/css"/>
+<style type="text/css">@import "style.css";</style>
+<title>IRC Services Technical Reference Manual - Appendix C. List of callbacks</title>
+</head>
+
+<body>
+<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
+
+<h2 class="section-title">Appendix C. List of callbacks</h2>
+
+<p class="section-toc">
+     C-1. <a href="#s1">General notes</a>
+<br/>C-2. <a href="#s2">Services core callbacks</a>
+<br/>C-3. <a href="#s3">OperServ callbacks</a>
+<br/>C-4. <a href="#s4">NickServ callbacks</a>
+<br/>C-5. <a href="#s5">ChanServ callbacks</a>
+<br/>C-6. <a href="#s6">MemoServ callbacks</a>
+<br/>C-7. <a href="#s7">StatServ callbacks</a>
+<br/>C-8. <a href="#s8">HTTP server callbacks</a>
+</p>
+
+<p class="backlink"><a href="index.html">Table of Contents</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s1">C-1. General notes</h3>
+
+<p>The callbacks provided by Services are listed in this appendix under the
+names used to access them (<i>e.g.,</i> with <tt>add_callback()</tt>).
+When using Services core callbacks, use a <tt><i>module</i></tt> parameter
+of <tt>NULL</tt>.</p>
+
+<p>Where the descriptions below refer to "processing" a message, they refer
+to a message that is meant specifically for the callback in question and
+which is not to be passed on to other modules or the Services core.</p>
+
+<p>Except as otherwise specified, callbacks which return zero must leave
+all arguments unchanged, and callbacks which return nonzero may modify any
+arguments which are not specified as <tt>const</tt>.</p>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s2">C-2. Services core callbacks</h3>
+
+<dl>
+<dt><tt><b>channel create</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt>, <tt>User *<i>user</i></tt>,
+	<tt>int32 <i>mode</i></tt></dt>
+    <dd>Called when a channel is created (<i>i.e.</i>, when a client joins
+	a nonexistent channel).  The client that created the channel and
+	that client's modes (<tt>CUMODE_*</tt>) are also passed to the
+	callback (note that the client is not yet in the channel's client
+	list).  The callback routine should always return 0.</dd>
+
+<dt><tt><b>channel delete</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt></dt>
+    <dd>Called when a channel is about to be deleted (<i>i.e.</i>, when the
+	last client has left the channel).  The callback routine should
+	always return 0.</dd>
+
+<dt><tt><b>channel JOIN</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt>,
+	<tt>struct c_userlist *<i>u</i></tt></dt>
+    <dd>Called when a client has joined a channel.  The callback routine
+	should always return 0.</dd>
+
+<dt><tt><b>channel JOIN check</b></tt>
+<br/>Parameters: <tt>const char *<i>channel</i></tt>, <tt>User *<i>user</i></tt></dt>
+    <dd>Called when a client is about to join a channel.  The callback
+	routine should return 1 to refuse the client access to the channel
+	or 0 to allow the <tt>JOIN</tt> to proceed normally.</dd>
+
+<dt><tt><b>channel KICK</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt>, <tt>User *<i>user</i></tt>,
+	<tt>const char *<i>reason</i></tt>, <tt>const char *<i>source</i></tt></dt>
+    <dd>Called when a client has been kicked from a channel.  The callback
+	routine should always return 0.</dd>
+
+<dt><tt><b>channel MODE</b></tt>
+<br/>Parameters: <tt>const char *<i>source</i></tt>,
+	<tt>Channel *<i>channel</i></tt>, <tt>int <i>modechar</i></tt>,
+	<tt>int <i>add</i></tt>, <tt>char **<i>av</i></tt></dt>
+    <dd>Called for each valid mode character in a <tt>MODE</tt> message,
+	except for channel user modes (<tt>+o</tt>, <tt>+v</tt>, etc.).
+	<tt><i>add</i></tt> is nonzero if adding modes, zero if removing
+	them.  <tt><i>av</i></tt> points to the first argument for the
+	mode; there are guaranteed to be enough arguments for the mode
+	character (provided the number of parameters in the mode definition
+	is set correctly).  The callback routine should return 1 if it
+	processes the mode, 0 otherwise.</dd>
+
+<dt><tt><b>channel mode change</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt></dt>
+    <dd>Called when a channel's modes have changed.  The callback routine
+	should always return 0.</dd>
+
+<dt><tt><b>channel umode change</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt>,
+	<tt>struct c_userlist *<i>user</i></tt></dt>
+    <dd>Called when a client's modes on a channel have changed.  The
+	callback routine should always return 0.</dd>
+
+<dt><tt><b>channel PART</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt>, <tt>User *<i>user</i></tt>,
+	<tt>const char *<i>reason</i></tt></dt>
+    <dd>Called when a client parts from a channel.  The callback routine
+	should always return 0.</dd>
+
+<dt><tt><b>channel TOPIC</b></tt>
+<br/>Parameters: <tt>Channel *channel</tt>, <tt>const char *topic</tt>,
+	<tt>const char *setter</tt>
+    <tt>time_t topic_time</tt></dt>
+    <dd>Called when a <tt>TOPIC</tt> command is received.  The callback
+	routine should return 0 to permit the topic change or 1 to refuse
+	it.  Note that <tt><i>setter</i></tt> may be in the form
+	"<tt><i>nick</i>!<i>user</i>@<i>host</i></tt>" instead of just a
+	nickname, depending on the remote server type; however, Services
+	currently stores only the nickname, and discards the username and
+	hostname if present.</dd>
+
+<dt><tt><b>clear channel</b></tt>
+<br/>Parameters: <tt>const char *<i>source</i></tt>,
+	<tt>Channel *<i>channel</i></tt>, <tt>int <i>what</i></tt>,
+	<tt>const void *<i>param</i></tt></dt>
+    <dd>Called whenever the <tt>clear_channel()</tt> function (in
+	<tt>actions.c</tt>) is called, before any other action is taken.
+	The callback routine should return 1 to terminate
+	<tt>clear_channel()</tt> processing or 0 to continue.  Note that
+	even if the callback routine returns 1, <tt>clear_channel()</tt>
+	will still flush out any channel mode changes, so the routine does
+	not need to do this itself.  See the comments above
+	<tt>clear_channel()</tt> in <tt>actions.c</tt> for the meaning of
+	the parameters.</dd>
+
+<dt><tt><b>command line</b></tt>
+<br/>Parameters: <tt>char *<i>option</i></tt>, <tt>char *<i>value</i></tt></dt>
+    <dd>Called at program startup for each command-line option.
+	<tt><i>option</i></tt> is the name of the option (the part of the
+	option string after the initial "<tt>-</tt>", up to and not
+	including any "<tt>=</tt>"), and <tt><i>value</i></tt>" is the text
+	after the "<tt>=</tt>" (<tt>NULL</tt> if no "<tt>=</tt>" is present).
+	<tt><i>option</i></tt> is guaranteed to be non-<tt>NULL</tt>.  The
+	callback routine should return 0 if it does not recognize the
+	option, 1 if it successfully processes the option, 2 if there is an
+	error processing the option, or 3 if no error occurred but Services
+	should terminate successfully.</dd>
+
+<dt><tt><b>connect</b></tt>
+<br/>Parameters: none</dt>
+    <dd>Called when a connection to the remote server is established.
+	Modules that want to send data to the remote server on startup
+	should use this callback; attempting to send data to the server
+	before the connection is established will cause the data to be
+	lost.  The callback routine should always return 0.</dd>
+
+<dt><tt><b>introduce_user</b></tt>
+<br/>Parameters: <tt>char *<i>nick</i></tt></dt>
+    <dd>Called whenever Services may need to introduce a pseudoclient (at
+	startup and when receiving a <tt>KILL</tt> message).  The
+	<tt><i>nick</i></tt> parameter is the nickname of the pseudoclient
+	which should be introduced (if it exists), or <tt>NULL</tt> when
+	introducing all pseudoclients.  The callback routine should return
+	1 if <tt>nick</tt> is not <tt>NULL</tt> <i>and</i> the routine
+	introduces a pseudoclient, 0 otherwise.  (If <tt>nick</tt> is
+	<tt>NULL</tt>, the routine should introduce any pseudoclients
+	necessary and return 0.)</dd>
+
+<dt><tt><b>load module</b></tt>
+<br/>Parameters: <tt>Module *<i>module</i></tt>,
+	<tt>const char *<i>modname</i></tt></dt>
+    <dd>Called when a module is loaded, after its <tt>init_module()</tt>
+	routine has been called.  <tt><i>modname</i></tt> is the name of
+	the module, either specified by the module (<tt>char
+	module_name[]</tt>) or copied from the module's path.  The callback
+	routine should always return 0.  This callback may be used, for
+	example, to add callback routines to a new module's callbacks when
+	the module is loaded.</dd>
+
+<dt><tt><b>m_privmsg</b></tt>
+<br/>Parameters: <tt>char *<i>source</i></tt>, <tt>char *<i>target</i></tt>,
+	<tt>char *<i>message</i></tt></dt>
+    <dd>Called for every <tt>PRIVMSG</tt> which is not ignored by Services.
+	The callback routine should return 1 if it processes the message,
+	0 otherwise.</dd>
+
+<dt><tt><b>m_whois</b></tt>
+<br/>Parameters: <tt>char *<i>source</i></tt>, <tt>char *<i>target</i></tt>,
+	<tt>char *<i>target_server</i></tt></dt>
+    <dd>Called for every <tt>WHOIS</tt> command.  The callback routine
+	should return 1 if it processes the message, 0 otherwise.</dd>
+
+<dt><tt><b>receive message</b></tt>
+<br/>Parameters: <tt>char *<i>source</i></tt>, <tt>char *<i>cmd</i></tt>,
+	<tt>int <i>ac</i></tt>, <tt>char **<i>av</i></tt></dt>
+    <dd>Called for every message received from the uplink server.  The
+	callback routine should return 1 if it processes the message, 0
+	otherwise.  Note that it is acceptable for a callback routine to
+	modify the parameters passed and return 0 to allow the next routine
+	to continue, subject to the following constraints:
+	<ul>
+	<li>The number of message parameters (<tt><i>ac</i></tt>) is not
+	    changed.</li>
+	<li>None of the strings (<tt><i>source</i></tt>, <tt><i>cmd</i></tt>,
+	    or any element of <tt><i>av</i></tt>) are lengthened.
+	    (Shortening strings is allowed.)</li>
+	</ul></dd>
+
+<dt><tt><b>reconfigure</b></tt>
+<br/>Parameters: <tt>int <i>after_configure</i></tt></dt>
+    <dd>Called twice when Services is signalled to re-read its
+	configuration files.  The first call is made before any module
+	configuration data is changed (but after the main Services
+	configuration settings have been updated), with
+	<tt>after_configure</tt> set to 0; the second call is made after
+	all configuration data has been successfully read and configuration
+	variables have been updated, with <tt>after_configure</tt> set to
+	1.  Callback routines should always return 0.</dd>
+
+<dt><tt><b>save data</b></tt>
+<br/>Parameters: none</dt>
+    <dd>Called whenever the save-data timeout runs out, or another action,
+	such as OperServ <tt>UPDATE</tt>, explicitly causes data saving to
+	occur.  The callback routine should always return 0.</dd>
+
+<dt><tt><b>save data complete</b></tt>
+<br/>Parameters: <tt>int <i>successful</i></tt></dt>
+    <dd>Called when a save-data operation completes.  The
+	<tt><i>successful</i></tt> parameter indicates whether the
+	operation succeeded or not.  The callback routine should always
+	return 0.</dd>
+
+<dt><tt><b>server create</b></tt>
+<br/>Parameters: <tt>Server *<i>server</i></tt></dt>
+    <dd>Called whenever a new server joins the network, after the server
+	record is created.  The callback routine should always return 0.</dd>
+
+<dt><tt><b>server delete</b></tt>
+<br/>Parameters: <tt>Server *<i>server</i></tt>,
+	<tt>const char *<i>reason</i></tt></dt>
+    <dd>Called whenever a server splits from the network, before the server
+	record is deleted.  The callback routine should always return 0.</dd>
+
+<dt><tt><b>set topic</b></tt>
+<br/>Parameters: <tt>const char *<i>source</i></tt>, <tt>Channel *<i>c</i></tt>,
+	<tt>const char *<i>topic</i></tt>, <tt>const char *<i>setter</i></tt>,
+	<tt>time_t <i>t</i></tt></dt>
+    <dd>Called twice whenever <tt>set_topic()</tt> (in <tt>actions.c</tt>)
+	is called to set the topic of a channel from Services.  Parameters
+	are as for <tt>set_topic()</tt> (in <tt>actions.c</tt>), except as
+	noted below; <tt><i>source</i></tt> will always be non-<tt>NULL</tt>.
+	The first call is done before the channel structure is modified,
+	and all callback routines must return 0 in this case.  The second
+	call is done after the channel structure is modified, but before
+	<tt>c-&gt;topic_time</tt> is changed; in this call,
+	<tt><i>topic</i></tt> and <tt><i>setter</i></tt> are both
+	<tt>NULL</tt>.  If the callback routine returns 1, no further
+	processing is done.  This is currently used to ensure that the
+	topic time is set so that the IRC servers will acknowledge the
+	change under certain protocols.</dd>
+
+<dt><tt><b>unload module</b></tt>
+<br/>Parameters: <tt>Module *<i>module</i></tt></dt>
+    <dd>Called when a module is unloaded, after its <tt>exit_module()</tt>
+	routine has been called.  The module handle <tt><i>module</i></tt>
+	is the same value as was passed to the "<tt>load module</tt>"
+	callback for this module, but the handle may not be used with any
+	module functions except <tt>get_module_name()</tt>.  The callback
+	routine should always return 0.  Note that it is not necessary (and
+	in fact not possible, as mentioned above) to use this callback to
+	remove callback functions from a module which is being unloaded;
+	those callback entries will be removed automatically.</dd>
+
+<dt><tt><b>user check</b></tt>
+<br/>Parameters: <tt>int <i>ac</i></tt>, <tt>char **<i>av</i></tt></dt>
+    <dd>Called whenever a client joins the network, before the
+	<tt>User</tt> record is created.  <tt><i>ac</i></tt> and
+	<tt><i>av</i></tt> are the argument list to the <tt>NICK</tt> (or
+	<tt>USER</tt>) message, as passed to <tt>users.c/do_nick()</tt>.
+	The callback routine should return 0 to allow the client to connect
+	or 1 to disallow (in this case the routine should take action to
+	remove the client from the network, such as sending a <tt>KILL</tt>
+	message).
+
+	<p><i>Notice:</i> When using <tt>add_callback_pri()</tt> with this
+	callback, never add a routine with priority less than -9, or the
+	<tt>operserv/sessions</tt> module will malfunction!</p></dd>
+
+<dt><tt><b>user create</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>int <i>ac</i></tt>,
+	<tt>char **<i>av</i></tt>, <tt>int <i>reconnect</i></tt></dt>
+    <dd>Called whenever a client joins the network, after the <tt>User</tt>
+	record is created.  <tt><i>ac</i></tt> and <tt><i>av</i></tt> are
+	the argument list to the <tt>NICK</tt> (or <tt>USER</tt>) message,
+	as passed to <tt>users.c/do_nick()</tt>.  <tt><i>reconnect</i></tt>
+	is nonzero for clients that are reconnecting after a network split.
+	The callback routine should always return 0.</dd>
+
+<dt><tt><b>user delete</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>reason</i></tt>,
+	<tt>int <i>is_kill</i></tt></dt>
+    <dd>Called whenever a client leaves the network (whether by
+	<tt>QUIT</tt> or <tt>KILL</tt>), before the <tt>User</tt> record is
+	deleted.  <tt><i>is_kill</i></tt> is 1 if the client is
+	disconnecting because of a <tt>KILL</tt>, 0 if because of a
+	<tt>QUIT</tt>.  The callback routine should always return 0.</dd>
+
+<dt><tt><b>user MODE</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>int <i>modechar</i></tt>,
+	<tt>int <i>add</i></tt>, <tt>char **<i>av</i></tt></dt>
+    <dd>Called for every mode character given in a client <tt>MODE</tt>
+	message.  <tt><i>add</i></tt> is nonzero when adding modes and zero
+	when subtracting.  <tt><i>av</i></tt> points to the first argument
+	for the mode; there are guaranteed to be enough arguments for the
+	mode character (provided the number of parameters in the mode
+	definition is set correctly).  The callback routine should return 1
+	if it processes the mode, 0 otherwise.</dd>
+
+<dt><tt><b>user nickchange (after)</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>const char *<i>oldnick</i></tt></dt>
+    <dd>Called whenever a client changes nicknames, after the nickname is
+	actually changed.  The callback routine should return 1 if it
+	kills the client, 0 otherwise.</dd>
+
+<dt><tt><b>user nickchange (before)</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>const char *<i>newnick</i></tt></dt>
+    <dd>Called whenever a client changes nicknames, before the nickname is
+	actually changed.  The callback routine should always return 0.
+	Note that clients should never be killed within this callback; use
+	the "<tt>user nickchange (after)</tt>" callback for that.</dd>
+
+<dt><tt><b>user servicestamp change</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt></dt>
+    <dd>Called when a client's Services timestamp (the <tt>servicestamp</tt>
+	field) is altered and the network should be informed of it.  The
+	callback routine should always return 0.</dd>
+</dl>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s3">C-3. OperServ callbacks</h3>
+
+<dl>
+<dt><tt><b>command</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>command</i></tt></dt>
+    <dd>Called for every message (other than a CTCP <tt>PING</tt> or empty
+	message) received by OperServ.  <tt><i>command</i></tt> is the
+	first word in the message (where words are separated by spaces);
+	the remaining text can be obtained through repeated calls to
+	<tt>strtok()</tt> with a <tt>NULL</tt> first parameter.  The
+	callback routine should return 1 if it processes the message, 0
+	otherwise.  If the routine does not process the message, it
+	<i>must not</i> call <tt>strtok()</tt>.</dd>
+
+<dt><tt><b>expire maskdata</b></tt>
+<br/>Parameters: <tt>uint32 <i>type</i></tt>, <tt>MaskData *<i>md</i></tt></dt>
+    <dd>Called when a <tt>MaskData</tt> entry is about to be expired, just
+	before it is actually deleted.  The callback routine should always
+	return 0.</dd>
+
+<dt><tt><b>HELP</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>HELP</tt> command is used with a parameter.
+	The callback should return 1 if it processes the message, 0
+	otherwise.</dd>
+
+<dt><tt><b>HELP COMMANDS</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>int <i>which</i></tt></dt>
+    <dd>Called when the <tt>HELP COMMANDS</tt> command is used.  The
+	<tt><i>which</i></tt> parameter is 0 when called after the list of
+	unprivileged (IRC operator) commands, 1 after the Services operator
+	commands, 2 after the Services administrator commands, and 3 after
+	the Services root commands.  The callback routine should always
+	return 0.</dd>
+
+<dt><tt><b>SET</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>char *<i>option</i></tt>,
+	<tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>SET</tt> command is used.  All parameters are
+	guaranteed to be valid (non-<tt>NULL</tt>); <tt><i>param</i></tt>
+	may contain multiple words.  The callback routine should return 1
+	if it processes the given option, 0 otherwise.</dd>
+
+<dt><tt><b>STATS</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>extra</i></tt></dt>
+    <dd>Called for every <tt>STATS</tt> command that is not plain
+	"<tt>STATS</tt>", "<tt>STATS ALL</tt>", "<tt>STATS NETWORK</tt>",
+	or "<tt>STATS RESET</tt>".  "<tt>extra</tt>" contains the remainder
+	of the message (after <tt>STATS</tt> and any following whitespace).
+	The callback routine should return 1 if it processes the command, 0
+	otherwise.</dd>
+
+<dt><tt><b>STATS ALL</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>,
+	<tt>const char *<i>s_OperServ</i></tt></dt>
+    <dd>Called for every <tt>STATS ALL</tt> command.
+	<tt><i>s_OperServ</i></tt> is the OperServ pseudoclient nickname;
+	the callback routine should send messages using this nickname.  The
+	callback routine should always return 0.</dd>
+
+<dt><tt><b>cancel_akill</b></tt> (<tt>operserv/akill</tt> module)
+<br/>Parameters: <tt>const char *<i>username</i></tt>,
+	<tt>const char *<i>host</i></tt></dt>
+    <dd>Called when an autokill is to be removed from the uplink server.
+	The callback routine should return 1 if it removes the autokill, 0
+	otherwise.</dd>
+
+<dt><tt><b>cancel_exclude</b></tt> (<tt>operserv/akill</tt> module)
+<br/>Parameters: <tt>const char *<i>username</i></tt>,
+	<tt>const char *<i>host</i></tt></dt>
+    <dd>Called when an autokill exclusion is to be removed from the uplink
+	server.  The callback routine should return 1 if it removes the
+	autokill exclusion, 0 otherwise.</dd>
+
+<dt><tt><b>send_akill</b></tt> (<tt>operserv/akill</tt> module)
+<br/>Parameters: <tt>const char *username</tt>, <tt>const char *host</tt>,
+	<tt>time_t expires</tt>, <tt>const char *who</tt>,
+	<tt>const char *reason</tt></dt>
+    <dd>Called when an autokill is to be sent to the uplink server.  The
+	callback routine should return 1 if it sends the autokill, 0
+	otherwise.</dd>
+
+<dt><tt><b>send_exclude</b></tt> (<tt>operserv/akill</tt> module)
+<br/>Parameters: <tt>const char *username</tt>, <tt>const char *host</tt>,
+	<tt>time_t expires</tt>, <tt>const char *who</tt>,
+	<tt>const char *reason</tt></dt>
+    <dd>Called when an autokill exclusion is to be sent to the uplink
+	server.  The callback routine should return 1 if it sends the
+	autokill exclusion, 0 otherwise.</dd>
+
+<dt><tt><b>cancel_sgline</b></tt> (<tt>operserv/sline</tt> module)
+<br/>Parameters: <tt>const char *<i>mask</i></tt></dt>
+    <dd>Called when an SGline is to be removed from the uplink server.
+	The callback routine should return 1 if it removes the SGline, 0
+	otherwise.</dd>
+
+<dt><tt><b>cancel_sqline</b></tt> (<tt>operserv/sline</tt> module)
+<br/>Parameters: <tt>const char *<i>mask</i></tt></dt>
+    <dd>Called when an SQline is to be removed from the uplink server.
+	The callback routine should return 1 if it removes the SQline, 0
+	otherwise.</dd>
+
+<dt><tt><b>cancel_szline</b></tt> (<tt>operserv/sline</tt> module)
+<br/>Parameters: <tt>const char *<i>mask</i></tt></dt>
+    <dd>Called when an SZline is to be removed from the uplink server.
+	The callback routine should return 1 if it removes the SZline, 0
+	otherwise.</dd>
+
+<dt><tt><b>send_sgline</b></tt> (<tt>operserv/sline</tt> module)
+<br/>Parameters: <tt>const char *<i>mask</i></tt>, <tt>time_t expires</tt>,
+	<tt>const char *who</tt>, <tt>const char *reason</tt></dt>
+    <dd>Called when an SGline is to be sent to the uplink server.  The
+	callback routine should return 1 if it sends the SGline, 0
+	otherwise.</dd>
+
+<dt><tt><b>send_sqline</b></tt> (<tt>operserv/sline</tt> module)
+<br/>Parameters: <tt>const char *<i>mask</i></tt>, <tt>time_t expires</tt>,
+	<tt>const char *who</tt>, <tt>const char *reason</tt></dt>
+    <dd>Called when an SQline is to be sent to the uplink server.  The
+	callback routine should return 1 if it sends the SQline, 0
+	otherwise.</dd>
+
+<dt><tt><b>send_szline</b></tt> (<tt>operserv/sline</tt> module)
+<br/>Parameters: <tt>const char *<i>mask</i></tt>, <tt>time_t expires</tt>,
+	<tt>const char *who</tt>, <tt>const char *reason</tt></dt>
+    <dd>Called when an SZline is to be sent to the uplink server.  The
+	callback routine should return 1 if it sends the SZline, 0
+	otherwise.</dd>
+</dl>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s4">C-4. NickServ callbacks</h3>
+
+<dl>
+<dt><tt><b>authed</b></tt> (module <tt>nickserv/mail-auth</tt>)
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>NickInfo *<i>ni</i></tt>,
+	<tt>NickGroupInfo *<i>ngi</i></tt>, <tt>int <i>authreason</i></tt></dt>
+    <dd>Called when a client successfully authenticates its nickname with
+	the <tt>AUTH</tt> command, after all normal processing has been
+	performed.  <tt><i>authreason</i></tt> is the value that the
+	<tt>ngi-&gt;authreason</tt> field had before being cleared (one of
+	the <tt>NICKAUTH_*</tt> constants).  The callback routine should
+	always return 0.</dd>
+
+<dt><tt><b>cancel user</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>int <i>old_status</i></tt>,
+	<tt>int <i>old_authstat</i></tt></dt>
+    <dd>Called whenever the <tt>cancel_user()</tt> routine is called for a
+	client with a registered nickname.  <tt><i>old_status</i></tt> is
+	the value of the client's nickname's <tt>status</tt> field while
+	the nickname was in use (when the callback is called, all temporary
+	flags will have been cleared); <tt><i>old_authstat</i></tt> is
+	likewise the value before clearing of the nickname group's
+	<tt>authstat</tt> field.  The callback routine should always
+	return 0.</dd>
+
+<dt><tt><b>check_expire</b></tt>
+<br/>Parameters: <tt>NickInfo *ni, NickGroupInfo *<i>ngi</i></tt></dt>
+    <dd>Called when a nickname is being checked for expiration, after the
+	nickname's last-used time has been updated (if appropriate).  The
+	callback routine should return 1 if the nickname should be expired,
+	0 otherwise.  If returning 1, the callback routine should log an
+	appropriate message.</dd>
+
+<dt><tt><b>check recognized</b></tt>
+<br/>Parameters: <tt>const User *<i>u</i></tt></dt>
+    <dd>Called whenever Services needs to check whether a client is
+	recognized as being the owner of the nickname it is using
+	(<i>e.g.,</i> when the client connects to the network).  The
+	<tt>User</tt> structure is guaranteed to have valid
+	<tt><i>ni</i></tt> and <tt><i>ngi</i></tt> pointers.  The callback
+	routine should return:
+	<ul>
+	<li>0, to indicate that the client was not recognized;</li>
+	<li>1, to indicate that the client was recognized as the owner of
+		the nickname; or</li>
+	<li>2, to indicate that the client should <i>not</i> be recognized
+		as the owner of the nickname, regardless of any subsequent
+		checks.</li>
+	</ul></dd>
+
+<dt><tt><b>collide</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt></dt>
+    <dd>Called whenever NickServ determines that a client should be
+	"collided".  The callback should return 1 if it handles colliding
+	the client (for example, by forcibly changing the client's
+	nickname), or 0 to allow normal collide processing to continue.</dd>
+
+<dt><tt><b>command</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>command</i></tt></dt>
+    <dd>Called for every message (other than a CTCP <tt>PING</tt> or empty
+	message) received by NickServ.  See the OperServ "<tt>command</tt>"
+	callback for details.</dd>
+
+<dt><tt><b>HELP</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>HELP</tt> command is used with a parameter.
+	The callback should return 1 if it processes the messages, 0
+	otherwise.</dd>
+
+<dt><tt><b>HELP COMMANDS</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>int <i>which</i></tt></dt>
+    <dd>Called when the <tt>HELP COMMANDS</tt> command is used.  The
+	<tt><i>which</i></tt> parameter is 0 when called after the list of
+	unprivileged commands and 1 after the list of privileged commands
+	(those shown to IRC operators).  The callback routine should always
+	return 0.</dd>
+
+<dt><tt><b>identified</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>int <i>old_authstat</i></tt></dt>
+    <dd>Called when a client identifies for its nickname via the IDENTIFY
+	command.  <tt><i>old_authstat</i></tt> is the authorization status
+	of the nickname before the identify took place.  The callback
+	routine should always return 0.</dd>
+
+<dt><tt><b>IDENTIFY check</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>char *<i>pass</i></tt></dt>
+    <dd>Called when a client attempts to identify for its nickname, after the
+	standard checks (whether the nickname exists, etc.) are done but before
+	the password itself is checked.  The callback routine should return
+	1 to disallow identification or 0 to allow processing to continue
+	normally.</dd>
+
+<dt><tt><b>nick delete</b></tt>
+<br/>Parameters: <tt>NickInfo *<i>ni</i></tt></dt>
+    <dd>Called when a nickname's registration is deleted.  The callback routine
+	should always return 0.</dd>
+
+<dt><tt><b>nickgroup delete</b></tt>
+<br/>Parameters: <tt>NickGroupInfo *<i>ngi</i></tt>,
+	<tt>const char *<i>oldnick</i></tt></dt>
+    <dd>Called when a nickname group is deleted (<i>i.e.</i>, when the last
+	nickname for the group is deleted), after the "<tt>nick delete</tt>"
+	callback is called.  <tt><i>oldnick</i></tt> is the nickname whose
+	deletion caused this nickname group to be deleted.  The callback
+	routine should always return 0.</dd>
+
+<dt><tt><b>REGISTER/LINK check</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>const char *<i>nick</i></tt>,
+	<tt>char *<i>password</i></tt>, <tt>char *<i>email</i></tt></dt>
+    <dd>Called when a client attempts to register its nickname, after the
+	validity of the parameters has been checked but before checking
+	whether the nickname exists or the password is strong enough.
+	<tt><i>u</i></tt> is the client that sent the <tt>REGISTER</tt>
+	command, and <tt><i>nick</i></tt> is their nickname (the same as
+	<tt><i>u</i>-&gt;nick</tt>).  <tt><i>email</i></tt> may be
+	<tt>NULL</tt> (if the client did not provide an E-mail address),
+	but <tt><i>password</i></tt> will always be non-<tt>NULL</tt>.
+	The callback routine should return 0 to allow the registration to
+	continue or 1 to disallow it.
+
+	<p>Also called by the <tt>nickserv/link</tt> module when a client
+	attempts to link a new nickname to its own.  In this case
+	<tt><i>nick</i></tt> is the requested target nickname (different
+	from <tt><i>u</i>-&gt;nick</tt>), and <tt><i>password</i></tt> and
+	<tt><i>email</i></tt> are both <tt>NULL</tt>.  The callback is
+	called after the nickname is checked for validity (length and
+	invalid characters), but before checking whether the client has
+	registered their current nickname.  The callback routine should
+	return 0 to allow the link to be made or 1 to disallow it.</p></dd>
+
+<dt><tt><b>registered</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>NickInfo *<i>ni</i></tt>,
+	<tt>NickGroupInfo *<i>ngi</i></tt>,
+	<tt>int *<i>replied</i></tt></dt>
+    <dd>Called when a client registers its nickname, after the data
+	structures have been set up.  The integer pointed to by
+	<tt><i>replied</i></tt> can be set to 1 to disable the standard
+	"your nickname has been registered" reply.  The callback need not call
+	<tt>put_<i>xxx</i>()</tt> even if it modifies <tt><i>ni</i></tt> or
+	<tt><i>ngi</i></tt>, as the caller will do so afterwards.  The
+	callback routine should always return 0.</dd>
+
+<dt><tt><b>SET</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>NickInfo *<i>ni</i></tt>,
+	<tt>NickGroupInfo *<i>ngi</i></tt>,
+	<tt>char *<i>option</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>SET</tt> command is used.  All parameters are
+	guaranteed to be valid (non-<tt>NULL</tt>), and standard permission
+	checks will have been performed (so <tt><i>u</i></tt> either is
+	identified for <tt><i>ni</i></tt>/<tt><i>ngi</i></tt> or is a
+	Services administrator).  The callback routine should return 1 if
+	it processes the given option, 0 otherwise.</dd>
+
+<dt><tt><b>SET EMAIL</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>NickGroupInfo *<i>ngi</i></tt>,
+	<tt>char *<i>last_email</i></tt></dt>
+    <dd>Called when the E-mail address associated with a nickname group is set,
+	changed, or unset.  <tt><i>u</i></tt> is the client making the
+	change; this may not necessarily be the owner of the nickname if, for
+	example, a Services administrator is making the change.  The new
+	address is stored in <tt><i>ngi</i>-&gt;email</tt>, while the
+	previous address is passed in <tt><i>last_email</i></tt> (this will
+	be <tt>NULL</tt> if no address was previously set).  The callback
+	routine should always return 0.</dd>
+
+<dt><tt><b>set identified</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>int <i>old_authstat</i></tt></dt>
+    <dd>Called whenever the <tt>set_identified()</tt> routine is called for
+	a client, after the nickname structure has been updated.
+	<tt><i>old_authstat</i></tt> is the previous value of the client
+	nickname's <tt>authstat</tt> field.  The callback routine should
+	always return 0.</dd>
+
+<dt><tt><b>UNSET</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>NickInfo *<i>ni</i></tt>,
+	<tt>NickGroupInfo *<i>ngi</i></tt>,
+	<tt>char *<i>option</i></tt></dt>
+    <dd>Called when the <tt>UNSET</tt> command is used.  All parameters are
+	guaranteed to be valid (non-<tt>NULL</tt>), and standard permission
+	checks will have been performed (so <tt><i>u</i></tt> either is
+	identified for <tt><i>ni</i></tt>/<tt><i>ngi</i></tt> or is a
+	Services administrator).  The callback routine should return 1 if
+	it processes the given option, 0 otherwise.</dd>
+
+<dt><tt><b>send_svsjoin</b></tt> (<tt>nickserv/autojoin</tt> module)
+<br/>Parameters: <tt>const char *nick</tt>, <tt>const char *channel</tt></dt>
+    <dd>Called when a client should be forced to join a channel.  The
+	callback routine should return 1 if it forces the client into the
+	channel, 0 otherwise.</dd>
+</dl>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s5">C-5. ChanServ callbacks</h3>
+
+<dl>
+<dt><tt><b>check_chan_user_modes</b></tt>
+<br/>Parameters: <tt>const char *<i>source</i></tt>, <tt>User *<i>user</i></tt>,
+	<tt>Channel *<i>c</i></tt>, <tt>int32 <i>modes</i></tt></dt>
+    <dd>Called when checking a client's modes on a channel, before any
+	standard checks are performed.  The mode change is being performed
+	by <tt><i>source</i></tt> (<tt>NULL</tt> for a channel join) on
+	<tt><i>user</i></tt> on channel <tt><i>c</i></tt>, and the client's
+	current modes on the channel are <tt><i>modes</i></tt>.  The
+	callback routine should return 0 to allow normal checking to
+	continue or 1 to abort further checks.
+
+	<p><b>Note:</b> <tt><i>source</i></tt> may be the empty string; this
+	indicates an internal call to verify a client's current modes.  In
+	this case callback routines should not make any decisions about
+	modes based on the value of <tt><i>source</i></tt>.</p></dd>
+
+<dt><tt><b>check_kick</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>const char *<i>chan</i></tt>,
+	<tt>ChannelInfo *<i>ci</i></tt>, <tt>char **<i>mask_ret</i></tt>,
+	<tt>const char **<i>reason_ret</i></tt></dt>
+    <dd>Called when checking whether a client should be kicked from a
+	channel, before any standard checks are performed.  All parameters
+        are guaranteed to be non-<tt>NULL</tt>, except for
+	<tt><i>ci</i></tt>, which will be <tt>NULL</tt> when the channel is
+	not registered.  The callback routine may return:
+	<ul>
+	<li>0, to allow normal processing to continue.</li>
+	<li>1, to cause the client to be kicked from the channel.  In this
+	       case, the callback routine must set <tt>*<i>mask_ret</i></tt>
+	       to a newly <tt>malloc()</tt>/<tt>smalloc()</tt>'d memory
+	       area containing the mask to be banned (<tt>create_mask()</tt>
+	       or <tt>sstrdup()</tt> may also be used) and
+	       <tt>*<i>reason_ret</i></tt> to a string for use as the
+	       reason in the kick.</li>
+	<li>2, to abort further processing and allow the client to enter the
+	       channel.</li>
+	</ul></dd>
+
+<dt><tt><b>check_modes</b></tt>
+<br/>Parameters: <tt>Channel *<i>channel</i></tt>,
+	<tt>ChannelInfo *<i>ci</i></tt>, <tt>int <i>add</i></tt>,
+	<tt>int32 <i>flag</i></tt></dt>
+    <dd>Called when checking a channel's modes against its mode lock for
+	every mode locked either on (<tt>add</tt> nonzero) or off
+	(<tt>add</tt> zero).  The callback routine should return 1 if it
+	processes the mode, 0 if not.  If a mode is not processed by any
+	callback and is further not specially handled by Services
+	(<tt>+k</tt> and <tt>+l</tt> modes), the default action is to
+	simply modify the channel's current modes to match the mode lock
+	(by calling <tt>set_cmode(...,"+<i>X</i>")</tt> or
+	<tt>set_cmode(...,"-<i>X</i>")</tt> for mode <tt><i>X</i></tt>), so
+	it is not necessary to add a callback for modes for which this
+	behavior is sufficient.</dd>
+
+<dt><tt><b>CLEAR</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>Channel *<i>channel</i></tt>,
+	<tt>char *<i>what</i></tt></dt>
+    <dd>Called when a valid <tt>CLEAR</tt> command is received (<i>i.e.</i>,
+	from a client with permission to use the command on the given
+	channel).  The callback routine should return 1 if it processes the
+	command, 0 if not.</dd>
+
+<dt><tt><b>command</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>command</i></tt></dt>
+    <dd>Called for every message (other than a CTCP <tt>PING</tt> or empty
+	message) received by ChanServ.  See the OperServ "<tt>command</tt>"
+	callback for details.</dd>
+
+<dt><tt><b>HELP</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>HELP</tt> command is used with a parameter.
+	The callback should return 1 if it processes the message, 0
+	otherwise.</dd>
+
+<dt><tt><b>HELP COMMANDS</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>int <i>which</i></tt></dt>
+    <dd>Called when the <tt>HELP COMMANDS</tt> command is used.  The
+	<tt><i>which</i></tt> parameter is 0 when called after the list of
+	unprivileged commands and 1 after the list of privileged commands
+	(those shown to IRC operators).  The callback routine should always
+	return 0.</dd>
+
+<dt><tt><b>INVITE</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>Channel *<i>c</i></tt>,
+	<tt>ChannelInfo *<i>ci</i></tt></dt>
+    <dd>Called whenever a valid <tt>INVITE</tt> command is received
+	(<i>i.e.</i>, the client has permission to use <tt>INVITE</tt> for
+	the channel).  The callback should return 0 to allow normal
+	processing to continue or 1 to abort further processing.</dd>
+
+<dt><tt><b>SET</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>ChannelInfo *<i>ci</i></tt>,
+	<tt>char *<i>option</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>SET</tt> command is used.  All parameters are
+	guaranteed to be valid (non-<tt>NULL</tt>), and standard permission
+	checks will have been performed (so `<tt>u</tt>' either is
+	identified for <tt><i>ci</i></tt> or is a Services administrator).
+	The callback routine should return 1 if it processes the given
+	option, 0 otherwise.</dd>
+
+<dt><tt><b>SET MLOCK</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>ChannelInfo *<i>ci</i></tt>,
+	<tt>int <i>modechar</i></tt>, <tt>int <i>add</i></tt>,
+	<tt>char **<i>av</i></tt></dt>
+    <dd>Called for each valid mode character in a <tt>SET MLOCK</tt>
+	command.  <tt><i>add</i></tt> is nonzero if adding modes, zero if
+	removing them.  <tt><i>av</i></tt> points to the first argument for
+	the mode; there are guaranteed to be enough arguments for the mode
+	character (provided the number of arguments in the mode definition
+	is set correctly.  The new mode lock (currently being constructed)
+	is stored in the <tt>ci-&gt;mlock</tt> structure.  The callback
+	routine should return 1 if it encounters an invalid parameter for a
+	mode, 0 otherwise.
+
+	<p>Also called with <tt><i>modechar</i></tt> set to zero when all
+	modes have been processed.  In this case, <tt><i>add</i></tt> and
+	<tt><i>av</i></tt> are undefined, and the callback routine should
+	return 1 if there is a problem with the mode lock, 0 otherwise.</p></dd>
+
+<dt><tt><b>UNBAN</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>Channel *<i>c</i></tt>,
+	<tt>ChannelInfo *<i>ci</i></tt></dt>
+    <dd>Called whenever a valid <tt>UNBAN</tt> command is received
+	(<i>i.e.</i>, the client has permission to use <tt>UNBAN</tt> for the
+	channel). The callback should return 0 to allow normal processing
+	to continue or 1 to abort further processing.</dd>
+
+<dt><tt><b>UNSET</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>ChannelInfo *<i>ci</i></tt>,
+	<tt>char *<i>option</i></tt></dt>
+    <dd>Called when the <tt>UNSET</tt> command is used.  All parameters are
+	guaranteed to be valid (non-<tt>NULL</tt>), and standard permission
+	checks will have been performed (so `<tt>u</tt>' either is
+	identified for <tt><i>ci</i></tt> or is a Services administrator).
+	The callback routine should return 1 if it processes the given
+	option, 0 otherwise.</dd>
+</dl>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s6">C-6. MemoServ callbacks</h3>
+
+<dl>
+<dt><tt><b>command</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>command</i></tt></dt>
+    <dd>Called for every message (other than a CTCP <tt>PING</tt> or empty
+	message) received by MemoServ.  See the OperServ "<tt>command</tt>"
+	callback for details.</dd>
+
+<dt><tt><b>HELP</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>HELP</tt> command is used with a parameter.
+	The callback should return 1 if it processes the message, 0
+	otherwise.</dd>
+
+<dt><tt><b>HELP COMMANDS</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>int <i>which</i></tt></dt>
+    <dd>Called when the <tt>HELP COMMANDS</tt> command is used.  The
+	<tt><i>which</i></tt> parameter is 0 when called after the list of
+	unprivileged commands and 1 after the list of privileged commands
+	(those shown to IRC operators).  The callback routine should always
+	return 0.</dd>
+
+<dt><tt><b>receive memo</b></tt>
+<br/>Parameters: <tt>const User *<i>sender</i></tt>,
+	<tt>const char *<i>target</i></tt>,
+	<tt>NickGroupInfo *<i>target_ngi</i></tt>,
+	<tt>const char *<i>channel</i></tt>, <tt>const char *<i>text</i></tt></dt>
+    <dd>Called when a nickname receives a memo.  <tt><i>sender</i></tt> is
+	the client sending the memo; <tt><i>target</i></tt> is the recipient's
+	nickname, and <tt><i>target_ngi</i></tt> is the corresponding
+	<tt>NickGroupInfo</tt> structure.  <tt><i>channel</i></tt> is the
+	name of the channel the memo was addressed to if a channel memo,
+	<tt>NULL</tt> if an ordinary memo.  The callback should return
+	0 to cause the memo to be received by the target nickname normally,
+	1 if it successfully delivered the memo, or an error message number
+	(from the language string list) if the memo could/should not be
+	delivered.
+
+	<p>Callback routines for this callback should use one of the
+	following two priorities (defined in <tt>memoserv.h</tt>):
+	<tt>MS_RECEIVE_PRI_CHECK</tt> for routines which check whether the
+	memo is allowed to be sent, or <tt>MS_RECEIVE_PRI_DELIVER</tt> for
+	actually sending the memo.</p></dd>
+
+<dt><tt><b>SET</b></tt>
+<br/>Parameters: <tt>User *<i>u</i></tt>, <tt>MemoInfo *<i>mi</i></tt>,
+	<tt>char *<i>option</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>SET</tt> command is used.  All parameters are
+	guaranteed to be valid (non-<tt>NULL</tt>), and standard permission
+	checks will have been performed.  <tt><i>mi</i></tt> points to the
+	MemoInfo for the client's nickname.  The callback routine should
+	return 1 if it handles the given option, 0 otherwise.</dd>
+</dl>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s7">C-7. StatServ callbacks</h3>
+
+<dl>
+<dt><tt><b>command</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>command</i></tt></dt>
+    <dd>Called for every message (other than a CTCP <tt>PING</tt> or empty
+	message) received by StatServ.  See the OperServ "<tt>command</tt>"
+	callback for details.</dd>
+
+<dt><tt><b>HELP</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>char *<i>param</i></tt></dt>
+    <dd>Called when the <tt>HELP</tt> command is used with a parameter.
+	The callback should return 1 if it processes the message, 0
+	otherwise.</dd>
+
+<dt><tt><b>HELP COMMANDS</b></tt>
+<br/>Parameters: <tt>User *<i>user</i></tt>, <tt>int <i>which</i></tt></dt>
+    <dd>Called when the <tt>HELP COMMANDS</tt> command is used.  The
+	<tt><i>which</i></tt> parameter is currently always 0.  The
+	callback routine should always return 0.</dd>
+</dl>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s8">C-8. HTTP server callbacks</h3>
+
+<dl>
+<dt><tt><b>auth</b></tt>
+<br/>Parameters: <tt>Client *<i>c</i></tt>, <tt>int *<i>close_ptr</i></tt></dt>
+    <dd>Called for each valid request received by the server.
+	<tt><i>c</i></tt> is the client from which the request was
+	received; the request data is stored in the client structure
+	(see <tt>http.h</tt>), and at a minimum the <tt>method</tt>,
+	<tt>url</tt>, <tt>version_major</tt>, and <tt>version_minor</tt>
+	fields will be set appropriately.  If the request is denied and the
+	connection should be closed after the reply is sent, the callback
+	routine should set <tt>*<i>close_ptr</i></tt> to a nonzero value
+	(<tt>*<i>close_ptr</i></tt> should not be modified if the request
+	is not denied).  The callback routine should return
+	<tt>HTTP_AUTH_ALLOW</tt> to explicitly allow the request to
+	proceed, <tt>HTTP_AUTH_DENY</tt> to deny the request (in which case
+	the module must send an appropriate error message), or
+	<tt>HTTP_AUTH_UNDECIDED</tt> to pass the request through to the
+	next callback; if all authorization callbacks pass the request
+	through, it is treated as allowed.</dd>
+
+<dt><tt><b>request</b></tt>
+<br/>Parameters: <tt>Client *<i>c</i></tt>, <tt>int *<i>close_ptr</i></tt></dt>
+    <dd>Called for each valid request received by the server and either
+	explicitly allowed or passed through by all authorization
+	callbacks.  <tt><i>c</i></tt> is the client from which the request
+	was received; the request data is stored in the client structure
+	(see <tt>http.h</tt>), and at a minimum the <tt>method</tt>,
+	<tt>url</tt>, <tt>version_major</tt>, and <tt>version_minor</tt>
+	fields will be set appropriately.  If the connection should be
+	closed after the reply is sent, the callback routine should set
+	<tt>*<i>close_ptr</i></tt> to a nonzero value.  The callback
+	routine should return 1 if it processes the request, 0 otherwise.</dd>
+</dl>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<p class="backlink"><a href="index.html">Table of Contents</a></p>
+
+</body>
+</html>

docs/tech/d.html

@@ -0,0 +1,349 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Style-Type" content="text/css"/>
+<style type="text/css">@import "style.css";</style>
+<title>IRC Services Technical Reference Manual - Appendix D. Coding style guidelines</title>
+</head>
+
+<body>
+<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
+
+<h2 class="section-title">Appendix D. Coding style guidelines</h2>
+
+<p class="section-toc">
+     D-1. <a href="#s1">Formatting</a>
+<br/>D-2. <a href="#s2">Identifier naming</a>
+</p>
+
+<p class="backlink"><a href="index.html">Table of Contents</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<p>The following guidelines were observed when writing the Services source
+code.  Note, however, that they were treated as guidelines, not rules, with
+the cardinal rule being "readability first".</p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s1">D-1. Formatting</h3>
+
+<ul>
+<li class="spaced">Lines must not be longer than 79 columns.</li>
+
+<li class="spaced">The basic indentation unit is four columns.</li>
+
+<li class="spaced">Tab (ASCII <tt>\011</tt>) characters are not permitted
+	in source files; indents should always be done using using spaces
+	(<tt>\040</tt>).  The source files distributed with Services
+	include settings for the Emacs and Vim editors that cause the Tab
+	key to insert spaces rather than a tab character.</li>
+
+<li class="spaced">Only one statement is allowed per line.  Statements
+	(including the empty statement "<tt>;</tt>") may not be written on
+	the same line as a control keyword (<tt>if</tt>, <tt>for</tt>, or
+	<tt>while</tt>).</li>
+
+<li class="spaced">Spaces are placed between binary operators and their
+	operands, except for the member-reference operators "<tt>-&gt;</tt>"
+	and "<tt>.</tt>"; spaces are not placed between unary operators and
+	their operands.  However, spaces may be omitted around binary
+	operators when it would improve readability.  Examples:
+
+	<div class="code">i = j * 2;
+user-&gt;channelcount++;
+result += i*60 + (j+59)/60;</div></li>
+
+<li class="spaced"><tt>NULL</tt>, not <tt>0</tt>, should always be used in
+	pointer comparisons.  For character comparisons, <tt>0</tt> is
+	preferred to <tt>'\0'</tt>, but the latter may also be used if it
+	does not go against the style of the surrounding code.  Do not use
+	<tt>'\0'</tt> with variables declared as type <tt>int8</tt> or
+	<tt>uint8</tt>, even though these types are usually equivalent to
+	<tt>char</tt> and <tt>unsigned char</tt>.</li>
+
+<li class="spaced">The construct "<tt>!!<i>expression</i></tt>" should not
+	be used.  Use "<tt><i>expression</i> != 0</tt>" (for characters or
+	integers) or "<tt><i>expression</i> != NULL</tt>" (for pointers)
+	instead.</li>
+
+<li class="spaced">Parentheses are required when <tt>&&</tt> and
+	<tt>||</tt> are used in the same expression to explicitly indicate
+	order of evaluation; do not rely on the default order of evaluation.
+	(Not using parentheses will generate a warning when using <tt>gcc
+	-Wall</tt>.)</li>
+
+<li class="spaced">Parentheses following the control statements "<tt>if</tt>",
+	"<tt>for</tt>", and "<tt>while</tt>", as well as the macros
+	<tt>LIST_FOREACH</tt>, <tt>LIST_FOREACH_SAFE</tt>, and
+	<tt>ARRAY_FOREACH</tt>, are preceded by a space.  Parentheses
+	following function or macro calls (other than the above) are not
+	preceded by a space.  Example:
+
+	<div class="code">if (flag)
+    function();</div></li>
+
+<li class="spaced">Spaces are placed after the comma of each parameter to a
+	function or macro; however, they may be omitted in function calls
+	which are themselves parameters to a function or macro, or when
+	including them would make the line exceed the length limit.  Spaces
+	are also placed after (but not before) the semicolons in a
+	<tt>for</tt> statement.  Spaces are not placed after the opening
+	parenthesis or before the closing parenthesis of a function/macro
+	call or control statement.  Examples:
+
+	<div class="code">function(param1, param2);
+function(param1, strchr(string,'/'), param3);
+for (i = 0; i < count; i++) ...</div></li>
+
+<li class="spaced">Opening braces of control statement blocks go on the
+	same line as the control statement (<tt>if</tt>, <tt>for</tt>,
+	etc.) associated with the block; function blocks and "naked blocks"
+	(those not associated with any control statement or function) have
+	the opening brace alone on a line, indented to the same level as
+	the surrounding code.  Closing braces are indented to the same
+	level as the line containing the opening brace.  Examples:
+
+        <div class="code">if (flag) {
+    /* indented code goes here */
+    ...
+}
+
+int function(int param1, char *param2)
+{
+    /* indented code goes here */
+    ...
+    /* start of a naked block */
+    {
+        int foo;
+        ...
+    }
+}</div></li>
+
+<li class="spaced">If an <tt>if</tt> statement is longer than one line, it
+	should be broken at logical operators (<tt>&&</tt> or <tt>||</tt>);
+	the operator should be placed at the beginning of the next line,
+	and should be indented to show which term the operator belongs
+	with.  The closing parenthesis for the <tt>if</tt> statement and
+	the subsequent open brace should be alone on a line, aligned with
+	the first line of the <tt>if</tt> statement.  (Braces are required
+	in this case.)  Conditions for <tt>for</tt> and <tt>while</tt>
+	statements should never span multiple lines, though a <tt>for</tt>
+	statement may be broken at the semicolons if necessary.  Examples:
+
+	<div class="code">if (ok && (strcmp(option, "option-name-1") == 0
+           || strcmp(option, "option-name-2") == 0)
+) {
+    ...
+}
+
+if (!init_first()
+ || !init_second()
+ || !init_third()
+ || !init_fourth()
+) {
+    /* This example outdents the || by three spaces to line
+     * up the terms.  Such outdenting is acceptable if it
+     * makes the code easier to read and understand. */
+    ...
+}
+
+for (exception = first_maskdata(MD_EXCEPTION); exception != NULL;
+     exception = next_maskdata(MD_EXCEPTION)
+) {
+    ...
+}</div></li>
+
+<li class="spaced">An <tt>else</tt> followed by an <tt>if</tt> is considered to be a
+	single keyword, "<tt>else if</tt>".  The <tt>if</tt> part should
+	always be placed on the same line as and immediately following the
+	<tt>else</tt>; the <tt>else if</tt> should never be split up onto
+	two lines, nor should braces be used around the <tt>if</tt> block.
+	The exception to this is when the <tt>else</tt> and <tt>if</tt>
+	refer to two conceptually distinct sets of conditions, in which
+	case the <tt>if</tt> block should be enclosed by braces and
+	indented.  Example:
+
+	<div class="code">res = check_password( /* ... */ );
+if (res == 0) {
+    ...
+} else if (res == 1) {
+    /* "else if" on a single line */
+    ...
+} else {
+    if (user-&gt;ni != NULL) {
+        /* "if" condition is different from "else"
+         * condition, thus separate */
+        ...
+    }
+}</div></li>
+
+<li class="spaced">Braces are always placed around the body of a control statement
+	(<tt>if</tt>, <tt>for</tt>, etc.).  The two exceptions are
+	<tt>else</tt> followed by <tt>if</tt>, mentioned above, and
+	statements for which the body, as well as the bodies of any
+	<tt>else if</tt> or <tt>else</tt> statements for an <tt>if</tt>
+	statement, are all one statement in length and do not contain any
+	nested control statements; in this latter case, braces are optional
+	(but recommended if any of the statements span multiple lines).
+	Examples:
+
+	<div class="code">for (i = 0; i < count; i++)
+    function(i);
+
+while (!done) {
+    /* Braces required because of the nested "if" */
+    if (do_stuff())
+        done = 1;
+}
+
+if (state == 0) {
+    a = b;
+} else if (state == 1) {
+    /* Every if/else body gets braces because this body
+     * has two statements */
+    b += a;
+    a = 0;
+} else {
+    state = 0;
+}</div></li>
+
+<li class="spaced">When using multiply-nested control statements, or a single control
+	statement which has a long block, the closing brace of the block
+	should be followed by a comment indicating what control statement
+	the block belongs to.  This should usually be the content of the
+	control statement, but may be abbreviated as long as its meaning is
+	clear.  If a long <tt>if</tt> block is followed by an <tt>else</tt>
+	clause, the <tt>else</tt> should likewise be documented.  Examples:
+
+	<div class="code">while (i < count) {
+    ...
+}  /* while (i < count) */
+
+if (flag) {
+    ...
+} else {  /* !flag */
+    ...
+}  /* if (flag) */
+
+for (node = first; node != NULL; node = node-&gt;next) {
+    ...
+}  /* for all nodes */</div></li>
+
+<li class="spaced"><tt>case</tt> and <tt>default</tt> labels for a <tt>switch</tt>
+	should be indented half of a normal indentation unit (two columns)
+	from the line containing the <tt>switch</tt> with which they are
+	associated; statements associated with a case should be indented a
+	full unit from the line containing the <tt>switch</tt> (half a unit
+	from the <tt>case</tt>).  If a case requires its own block, such as
+	when it declares its own local variables, the opening brace is
+	placed after the colon on the <tt>case</tt> line.  Example:
+
+	<div class="code">switch (variable) {
+  case 123: {
+    int foo;
+    ...
+    break;
+  }  /* case 123 */
+  default:
+    ...
+    return -1;
+}</div></li>
+
+<li class="spaced">When a case in a <tt>switch</tt> block does not contain a
+	<tt>break</tt> (or <tt>return</tt>) statement and deliberately
+	"falls through" to the next case, a comment to this effect should
+	be made at the bottom of the case.  Example:
+
+	<div class="code">switch (state) {
+  case 0:
+    ...
+    /* fall through */
+  case 1:
+    ...
+    break;
+}</div></li>
+
+<li class="spaced">Inline comments (comments placed to the right of a line of code)
+	should be aligned to start on the same column, when this does not
+	place too much space between the comment and the code or cause the
+	line to exceed 79 columns in length.  Inline comments after
+	unusually long lines (such as long field declarations in
+	structures) should be placed alone on the following line, indented
+	the proper amount.</li>
+
+<li class="spaced">The <tt>goto</tt> statement should not be used except in error
+	handling situations where it will help avoid multiple levels of
+	<tt>if</tt> nesting or other awkward code.  Labels for
+	<tt>goto</tt> should be outdented half of an indentation unit
+	from the surrounding code (<i>i.e.</i>, indented two columns less
+	than the surrounding code).</li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<h3 class="subsection-title" id="s2">D-2. Identifier naming</h3>
+
+<ul>
+<li class="spaced">Global variables and type names should use mixed upper- and
+	lower-case, with an upper-case letter at the beginning of each
+	distinct word in the name.</li>
+
+<li class="spaced">Preprocessor constants and macros should use all upper-case
+	letters, with an underscore between distinct words in the
+	name.</li>
+
+<li class="spaced">Structure names and local variables should use all lower-case
+	letters, with an underscore between distinct words in the
+	name.</li>
+
+<li class="spaced">Structure names for structures with an associated type name
+	(<i>i.e.</i>, from <tt>typedef</tt>) should be given the same name
+	as the type, except with all letters in lowercase and followed by
+	an underscore.  Example:
+
+	<div class="code">typedef struct mytype_ MyType;
+struct mytype_ {
+    MyType *next, *prev;
+    ...
+};</div></li>
+
+<li class="spaced">Names should be descriptive.  For global variables,
+	preprocessor macros and constants, type names, and structure
+	names, names should generally consist of one or more full words.
+	For local variables, short names and abbreviations are permitted
+	as long as it is clear what the variables are used for.  In
+	general, one-letter local variable names should not be used other
+	than the following:
+	<ul>
+	<li><tt>c</tt>: character</li>
+	<li><tt>f</tt>: file pointer (<tt>FILE *</tt>)</li>
+	<li><tt>i</tt>, <tt>j</tt>, <tt>k</tt>: integers (usually
+		counters)</li>
+	<li><tt>n</tt>, <tt>p</tt>, <tt>q</tt>: integers (<tt>p</tt> may
+		also be a pointer variable)</li>
+	<li><tt>s</tt>: string</li>
+	<li><tt>t</tt>: string or temporary variable</li>
+	<li><tt>x</tt>, <tt>y</tt>, <tt>z</tt>: integers (usually
+		position variables)</li>
+	</ul>
+	Two-letter variable names are often formed from initials of type
+	names, such as <tt>NickInfo *ni</tt>; see the source code for
+	examples.</li>
+</ul>
+
+<p class="backlink"><a href="#top">Back to top</a></p>
+
+<!------------------------------------------------------------------------>
+<hr/>
+
+<p class="backlink"><a href="index.html">Table of Contents</a></p>
+
+</body>
+</html>

docs/tech/index.html

@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Style-Type" content="text/css"/>
+<style type="text/css">@import "style.css";</style>
+<title>IRC Services Technical Reference Manual</title>
+</head>
+
+<body>
+<h1 class="title">IRC Services Technical Reference Manual</h1>
+
+<h2 class="section-title">Table of Contents</h2>
+
+<p class="toc">1. <a href="1.html">About this manual</a></p>
+
+<p class="toc">2. <a href="2.html">Core Services functionality</a></p>
+
+<p class="toc">3. <a href="3.html">Communication (socket) handling</a></p>
+
+<p class="toc">4. <a href="4.html">The module system</a></p>
+
+<p class="toc">5. <a href="5.html">IRC server interface</a></p>
+
+<p class="toc">6. <a href="6.html">Database handling</a></p>
+
+<p class="toc">7. <a href="7.html">Services pseudoclients</a></p>
+
+<p class="toc">8. <a href="8.html">Other modules</a></p>
+
+<p class="toc">9. <a href="9.html">The database conversion tool</a></p>
+
+<p class="toc">10. <a href="10.html">Compilation</a></p>
+
+<p class="toc">11. <a href="11.html">Future work</a></p>
+
+<p class="toc">Appendix A. <a href="a.html">Source tree reference</a></p>
+
+<p class="toc">Appendix B. <a href="b.html">Function index</a></p>
+
+<p class="toc">Appendix C. <a href="c.html">List of callbacks</a></p>
+
+<p class="toc">Appendix D. <a href="d.html">Coding style guidelines</a></p>
+
+<hr/>
+
+<p class="backlink" style="font-size: 100%"><a href="../index.html">Return to the user's manual</a></p>
+
+</body>
+</html>

docs/tech/style.css

@@ -0,0 +1,259 @@
+*.title {
+	font-size: 200%;
+	font-weight: bold;
+	text-align: center;
+}
+
+*.section-title {
+	font-size: 150%;
+	font-weight: bold;
+	text-align: center;
+}
+
+*.subsection-title {
+	font-size: 120%;
+	font-weight: bold;
+	text-align: center;
+}
+
+*.subsubsection-title {
+	font-size: 100%;
+	font-weight: bold;
+	text-align: left;
+}
+
+*.subsubsubsection-title {
+	font-size: 100%;
+	font-weight: bold;
+	text-align: left;
+}
+
+*.toc {
+	font-size: 120%;
+	font-weight: bold;
+}
+
+*.section-toc {
+	font-size: 100%;
+	font-weight: bold;
+}
+
+*.backlink {
+	font-size: 80%;
+	text-align: right;
+}
+@media print {
+	*.backlink { display: none; }
+}
+
+
+hr {
+	text-align: center;
+	margin-top: 1.5ex;
+	margin-bottom: 1.5ex;
+}
+
+li.spaced {
+	margin-top: 1.5ex;
+}
+
+dt {
+	margin-top: 1ex;
+	margin-left: 1em;
+}
+
+dt.cygnus {
+	font-family: monospace;
+	margin-left: 3ex;
+	text-indent: -3ex;
+}
+
+div.code {
+	margin-top: 1ex;
+	margin-bottom: 1ex;
+	margin-left: 3em;
+	margin-right: 3em;
+	font-family: monospace;
+	white-space: pre;
+}
+
+
+*.remotehost {
+	font-family: monospace;
+	font-size: 80%;
+}
+
+*.configure-test-name {
+	font-family: monospace;
+	font-weight: bold;
+}
+
+
+table.source-tree {
+	display: table;
+	border-collapse: collapse;
+	border: 4px ridge gray;
+	border-spacing: 0;
+}
+
+tr.source-tree-header {
+	display: table-row;
+	background: #E0E8FF;
+	border: 4px ridge gray;
+}
+
+tr.source-tree-directory {
+	display: table-row;
+	background: #E0FFE0;
+}
+
+tr.source-tree {
+	display: table-row;
+	background: #FFF8E0;
+}
+
+th.source-tree-file {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-weight: bold;
+	text-align: center;
+}
+
+th.source-tree-description {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-weight: bold;
+	text-align: center;
+}
+
+th.source-tree-referenced {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-weight: bold;
+	text-align: center;
+}
+
+td.source-tree-file {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-family: monospace;
+	text-align: left;
+	white-space: pre;
+}
+
+td.source-tree-description {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	text-align: left;
+}
+
+td.source-tree-referenced {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	text-align: center;
+}
+
+
+table.function-index {
+	display: table;
+	border-collapse: collapse;
+	border: 4px ridge gray;
+	border-spacing: 0;
+}
+
+tr.function-index-header {
+	display: table-row;
+	background: #E0E8FF;
+	border: 4px ridge gray;
+}
+
+tr.function-index-letter {
+	display: table-row;
+	background: #E0FFE0;
+}
+
+tr.function-index {
+	display: table-row;
+	background: #FFF8E0;
+}
+
+th.function-index-name {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-weight: bold;
+	text-align: center;
+	white-space: nowrap;
+}
+
+th.function-index-params {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-weight: bold;
+	text-align: center;
+	white-space: nowrap;
+}
+
+th.function-index-return {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-weight: bold;
+	text-align: center;
+	white-space: nowrap;
+}
+
+th.function-index-purpose {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-weight: bold;
+	text-align: center;
+	white-space: nowrap;
+}
+
+th.function-index-letter {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1ex;
+	font-size: 120%;
+	font-weight: bold;
+	text-align: center;
+}
+
+td.function-index-name {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+	font-family: monospace;
+}
+
+td.function-index-params {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+}
+
+td.function-index-return {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+}
+
+td.function-index-purpose {
+	display: table-cell;
+	border: 2px ridge gray;
+	padding: 1px 3px;
+}
+
+p.function-param {
+	margin: 0 0 0 1.5em;
+	text-indent: -1.5em;
+}

docs/upgrade.html

@@ -0,0 +1,328 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1">
+<title>IRC Services - Important information about upgrading</title>
+</head>
+
+<body>
+<a name=top></a>
+<h1 align=center>IRC Services Manual</h1>
+
+<h2 align=center>Important information for users upgrading from previous
+	versions of Services</h2>
+
+<p><a href="#4.5">Upgrading from version 4.5 and earlier to 5.0</a>
+<br><a href="#5.0">Upgrading from version 5.0 to 5.1</a>
+
+<p>Note that information for later versions is applicable to earlier
+versions as well, so please read through to the end of the document.
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a></font>
+
+<p><hr>
+
+<a name=4.5></a>
+<h2 align=center>Upgrading from version 4.5 and earlier</h2>
+
+<a name=4.5-1></a>
+<h3 align=center>1. Executable and configuration files</h3>
+
+<p>In previous versions of Services, the main executable file (program
+file) was called "<tt>services</tt>"; in version 5.0 it has been renamed to
+"<tt>ircservices</tt>" to match the package name.  Once you are satisfied
+that you don't need the old <tt>services</tt> executable file, you should
+delete it (<tt>make install</tt> will leave it alone).
+
+<p>Also, previous versions of Services (since 4.1.0) used a file called
+"<tt>services.conf</tt>" to control various aspects of the behavior of
+Services.  Services 5.0 also uses such a file, but it has been renamed to
+"<tt>ircservices.conf</tt>" and its format has changed from previous
+versions.  In particular, many of the options from previous versions are
+now module options, and must be placed in a separate file called
+"<tt>modules.conf</tt>".  Please see the manual, and the
+<tt>example-ircservices.conf</tt> and <tt>example-modules.conf</tt> files
+in the data directory, for details.
+
+<p align=center><hr width="50%">
+
+<a name=4.5-2></a>
+<h3 align=center>2. Running the <tt>configure</tt> script</h3>
+
+<p>The <tt>configure</tt> script has been redesigned to require as little
+input as possible; many of the options that previously required user input
+during the configuration process have been moved to the
+<tt>ircservices.conf</tt> file, and the script can now be completely
+automated if you provide the <tt>-prefix</tt> option or both of the
+<tt>-bindest</tt> and <tt>-datdest</tt> options to specify the pathnames
+for installation.  Run <tt>configure</tt> with the <tt>-help</tt> option
+for details on available command-line options.
+
+<p>The <tt>configure</tt> script also now accepts all options in the GNU
+long-option (two leading hyphens) style, so if you are used to the GNU
+autoconf-style <tt>configure</tt>, you can now type <tt>./configure
+--prefix=/usr</tt> (for example) to get the same effect with Services.
+
+<p align=center><hr width="50%">
+
+<a name=4.5-3></a>
+<h3 align=center>3. <tt>listnicks</tt> and <tt>listchans</tt></h3>
+
+<p>Earlier versions of Services provided two additional programs,
+"<tt>listnicks</tt>" and "<tt>listchans</tt>", to show nickname and
+channel data from the command line.  These programs have been removed in
+version 5.0 in favor of the new HTTP interface; the <tt>httpd/dbaccess</tt>
+module provides the same functionality and much, much more.  (It is still
+possible to retrieve data from the command line as well, using the
+<tt>-export</tt> option; see <a href="5.html#1">section 5-1</a> for
+details.)
+
+<p align=center><hr width="50%">
+
+<a name=4.5-4></a>
+<h3 align=center>4. Encrypted passwords</h3>
+
+<p>Unlike previous versions of Services, encryption is no longer an
+"on/off" setting; instead, encryption is enabled by specifying an
+encryption module in <tt>ircservices.conf</tt>.  See the manual
+(<a href="3.html#7">section 3-7</a>) for details.
+
+<p>If you are upgrading from version 4.4.x or earlier, and you use
+MD5-encrypted passwords, <b>your passwords will no longer work</b> due to a
+bug in those versions of Services.  Support is available in version 4.5 for
+reading the broken passwords and allowing them to be reset; if you want to
+give users a chance to change their passwords, you should first upgrade to
+the most recent 4.5.x release, then when most or all of the users have
+reset their passwords, upgrade to version 5.0.  For details, see the What's
+New notes for version 4.5.
+
+<p align=center><hr width="50%">
+
+<a name=4.5-5></a>
+<h3 align=center>5. Using the <tt>mail-auth</tt> module with existing
+databases</h3>
+
+<p>The <tt>mail-auth</tt> module is a new feature in version 5.0 which
+allows E-mail addresses to be checked for validity.  When enabled, all new
+nickname registrations and E-mail address changes will require the user to
+verify that the address provided is valid, by entering an authentication
+code mailed by Services to the address.  However, if you are upgrading from
+an earlier version of Services, some users may already have entered invalid
+E-mail addresses for their nicknames.
+
+<p>To correct this situation, the command-line option
+"<tt>-clear-nick-email</tt>" can be given (note that this option is only
+valid if NickServ is enabled).  When this option is used, Services will
+clear the E-mail address associated with all registered nicknames; all
+users will then be required to enter their E-mail address again and verify
+it with an authentication code before being allowed to identify for their
+nicknames.
+
+<p>If you intend to use the <tt>mail-auth</tt> module, it is recommended
+that you use this option once when starting up Services 5.0 for the first
+time.  This option only needs to be specified once to take effect.
+
+<p align=center><hr width="50%">
+
+<a name=4.5-6></a>
+<h3 align=center>6. Nickname linking system changes</h3>
+
+<p>The nickname linking system used in Services 5.0 is different from that
+used in previous versions.  Rather than a multiple-level "tree" of linked
+nicknames, nicknames are now organized into groups, and the <tt>LINK</tt>
+and <tt>UNLINK</tt> commands add nicknames to or remove nicknames from this
+group.  Functionally, there is little difference between this system and
+using only one level of links in the previous system.  However, the
+<tt>LINK</tt> and <tt>UNLINK</tt> commands work in the opposite direction
+from version 4.x, taking a nickname parameter and adding or removing that
+nickname (for example, "<tt>LINK OtherNick</tt>"), and nicknames to be
+linked must be <i>unregistered</i> nicknames, which is also a change from
+version 4.x; make sure your users are aware of these changes.
+
+<p>Related to these changes, it is also important to note that the
+behavior of the NickServ <tt>UNLINK</tt> and <tt>DROP</tt> commands has
+changed with respect to de-registration of nicknames; in particular, <b>the
+<tt>DROP</tt> command will now drop <i>all</i> linked nicknames!</b>  The
+syntax for the <tt>DROP</tt> command has changed as well, requiring a
+password to confirm the action, and the help message includes a warning,
+but be aware that users may simply append their password to the command
+without checking the help message, resulting in the unintended
+de-registration of all of the user's nicks.  The <tt>UNLINK</tt> command
+should be used to cancel single nicknames out of a group of links (a
+nickname which is unlinked is deregistered as well, similar to
+<tt>UNLINK</tt> followed by <tt>DROP</tt> in version 4.x).
+
+<p align=center><hr width="50%">
+
+<a name=4.5-7></a>
+<h3 align=center>7. Memo expiration</h3>
+
+<p>Version 5.0 of Services provides the ability to automatically delete
+(expire) memos after a certain period of time.  Since this feature was not
+present in previous versions and users may have important information saved
+in memos, Services will not expire any memos which were sent before
+upgrading to version 5.0; thus, it is safe to enable memo expiration without
+having to warn users about loss of saved memos or taking other preventative
+measures.  (However, it would be prudent to inform users that any future
+memos will expire after a certain period of time, if you choose to enable
+memo expiration.)
+
+<p align=center><hr width="50%">
+
+<a name=4.5-8></a>
+<h3 align=center>8. Channel access levels</h3>
+
+<p>Channel access levels have been rescaled in this version of Services to
+make better use of the available range of values; instead of a range of
+-9999 through 9999 where only values -2 through 10 are used, the range has
+been reduced to -999 through 999, and default levels now range from -100 to
+100 (all defaults have been increased by a factor of 10, with the exception
+of <tt>AUTODEOP</tt> and <tt>NOJOIN</tt>, which are no longer changeable in
+version 5.0 but are fixed internally at -1 and -100 respectively).  Level
+values from version 4.x databases will be properly converted to use the new
+range, so that all users will still have the same privileges as they did in
+previous versions.  However, be aware that in some cases involving two
+users with levels outside the range -50 through 50 in version 4.x, if the
+levels are different but close (<i>e.g.</i> 1001 and 1002), then the users
+will have the same access level in version 5.0.  The exact conversion
+function is stepwise linear, as follows (negative levels are converted to
+the negative of the conversion of the absolute value of the level):
+
+<div align=center><table border=0>
+<tr><th colspan=3>&nbsp;&nbsp;Old&nbsp;level&nbsp;(<i>o</i>)&nbsp;
+    <th colspan=3>&nbsp;New&nbsp;level&nbsp;(<i>n</i>)&nbsp;&nbsp;
+    <th>Conversion function
+<tr><td align=right>0<td>. . .<td>25
+    <td align=right>0<td>. . .<td>250
+    <td><i>n</i> = 10<i>o</i>
+<tr><td align=right>25<td>. . .<td>50
+    <td align=right>250<td>. . .<td>300
+    <td><i>n</i> = 2<i>o</i> + 200
+<tr><td align=right>50<td>. . .<td>100
+    <td align=right>300<td>. . .<td>320
+    <td><i>n</i> = 2<i>o</i>/5 + 280
+<tr><td align=right>100<td>. . .<td>1000
+    <td align=right>320<td>. . .<td>500
+    <td><i>n</i> = <i>o</i>/5 + 300
+<tr><td align=right>1000<td>. . .<td>2000
+    <td align=right>500<td>. . .<td>600
+    <td><i>n</i> = <i>o</i>/10 + 400
+<tr><td align=right>&nbsp;&nbsp;2000<td>. . .<td>9999&nbsp;
+    <td align=right>&nbsp;&nbsp;600<td>. . .<td>999&nbsp;&nbsp;&nbsp;
+    <td><i>n</i> = <i>o</i>/20 + 500
+</table></div>
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<a name=5.0></a>
+<h2 align=center>Upgrading from version 5.0</h2>
+
+<a name=5.0-1></a>
+<h3 align=center>1. Switching to the new database format</h3>
+
+<p>A new, more robust database file format has been developed for version
+5.1 which is incompatible with the format used in earlier versions.  To
+switch your databases to this format, ensure that the
+<tt>misc/xml-export</tt> and <tt>misc/xml-import</tt> modules are loaded by
+your <tt>ircservices.conf</tt>, and:
+<ol>
+<li>Shut down Services.
+<li>Export your databases to an XML file using the command:
+    <tt>ircservices&nbsp;-export=<i>database.xml</i></tt> (any filename can
+    be used).
+<li>Edit your <tt>ircservices.conf</tt> file and change the line reading
+    <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;LoadModule&nbsp;database/version4</tt>
+    <br>to
+    <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;LoadModule&nbsp;database/<b>standard</b></tt>
+    <br>Also enable the <tt>misc/xml-import</tt> module if it is commented
+    out.
+<li>Import the XML data from step 2 into the new database format using the
+    command: <tt>ircservices&nbsp;-import=<i>database.xml</i></tt>
+<li>Start up Services.
+</ol>
+
+<p>Note that switching to the new database format is not required; you can
+continue to use your 5.0 databases by leaving the <tt>LoadModule
+database/version4</tt> configuration line alone.  However, the new database
+format allows you to recover more data even if the database files get
+corrupted, so its use is recommended.  (It is also possible to switch back
+to the old format from the new one in a similar manner, though all
+5.1-specific data will be lost if the databases are used in an older
+version of Services.)
+
+
+<p align=center><hr width="50%">
+
+<a name=5.0-2></a>
+<h3 align=center>2. Channel memos</h3>
+
+<p>Version 5.1 includes a redesigned channel memo system which distributes
+channel memos to users of the channel (based on the channel access list)
+rather than storing the memos with the channel.  As a result of this
+change, all stored channel memos will be deleted when starting up version
+5.1.  Users should be instructed to save any needed information before the
+upgrade.
+
+<p align=center><hr width="50%">
+
+<a name=5.0-3></a>
+<h3 align=center>3. Encryption handling</h3>
+
+<p>Version 5.1 allows passwords encrypted with different ciphers (or not
+encrypted at all) to coexist in the same database, by keeping track of
+what cipher was used to encrypt the password; this allows for enabling or
+disabling encryption, or changing the encryption type used, without
+concerns of old passwords becoming unusable.
+
+<p>However, since this ability was not present in version 5.0 and earlier,
+Services has no way to know what encryption type was used in databases from
+those versions, and simply defaults to the cipher given in the
+<a href="a.html#EncryptionType"><tt>EncryptionType</tt></a> directive in
+<tt>ircservices.conf</tt> for all passwords.  Therefore, if you continue to
+use the <tt>database/version4</tt> database module in version 5.1, you must
+ensure that <tt>EncryptionType</tt> is set correctly when you first load
+the data; once you have saved the databases using version 5.1, such as with
+the OperServ <tt>UPDATE</tt> or <tt>SHUTDOWN</tt> commands, you can change
+<tt>EncryptionType</tt> freely.
+
+<p>This also applies, of course, to converting databases from 5.0 to the
+new <tt>database/standard</tt> module format; be certain that you do not
+change <tt>EncryptionType</tt> until after you have exported the databases
+to an XML file.
+
+<p align=center><hr width="50%">
+
+<a name=5.0-4></a>
+<h3 align=center>4. NickServ/ChanServ <tt>SENDPASS</tt></h3>
+
+<p>The NickServ and ChanServ <tt>SENDPASS</tt> commands have been removed
+in favor of the new NickServ <tt>REAUTH</tt> command, and the corresponding
+modules (<tt>nickserv/sendpass</tt> and <tt>chanserv/sendpass</tt>) have
+been deleted.  Make certain to remove these modules from your
+<tt>ircservices.conf</tt> file before starting Services 5.1.
+
+<p align=center><hr width="50%">
+
+<a name=5.0-5></a>
+<h3 align=center>5. NickServ <tt>SET</tt> and <tt>UNSET</tt></h3>
+
+<p>Services administrators should be aware that the NickServ <tt>SET</tt>
+and <tt>UNSET</tt> commands now require a "<tt>!</tt>" before the nickname;
+for example, instead of
+<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;/msg NickServ SET nick NOEXPIRE ON</tt>
+<br>type
+<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;/msg NickServ SET <b>!nick</b> NOEXPIRE ON</tt>
+<br>This is to avoid ambiguity where the nickname is the same as an option
+name.
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<p><hr>
+
+<p align=right><font size=-1><a href=index.html>Table of Contents</a> |
+<a href="#top">Top</a></font>
+
+</body>
+</html>