Services -- a system of IRC services for IRC networks
-----------------------------------------------------

Services is copyright (c) 1996-1997 Andrew Church.  Services may be freely
redistributed; see the GNU General Public License (in the file "COPYING")
for details.


1. INTRODUCTION

     Services is a system of services (as the name implies) 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, enabling them to change modes in any channel and
place network-wide bans, among other things.

     Services is designed to use the RFC 1459 IRC protocol, with four extra
commands borrowed from the DALnet IRC server: AKILL, RAKILL, GLOBOPS, and
GOPER.  These are discussed at the end of this document.


2. COMPILATION AND INSTALLATION

     Compiling Services is a fairly easy task.  Most of the details are
taken care of by the "configure" script, though it may fail on some systems
(if it fails on yours, please send reports of what you had to do to make it
work).  Run the script by typing "sh configure" or "./configure" at your
shell prompt.  The script will ask you a few questions, then work for a bit
as it learns about your system.  Finally, it will create two files,
sysconf.h and Makefile.inc, containing the results of auto-configuration.

     Before trying to actually compile Services, edit the Makefile and look
at the top section (labeled "Configuration section").  The comments should
make this section straightforward.

     Another thing to check before trying to compile is the config.h file.
This contains all of the basic definitions for Services -- uplink server,
data directory, etc.  Most of these can be changed with command-line
options (see below), but you may find it more convenient to set them as
defaults.

     If Services fails to compile on your system, let me know what went
wrong so I can try and incorporate a fix into the configure script or the
main code.

     Once Services is compiled, type "make install" to copy the programs
and data files to their destinations.  Care should be taken that only
authorized people have access to these files; passwords are NOT
encrypted at present, so unauthorized access to the file could be a big
problem!

     There is a test suite available for Services ("make test"); however,
it is still under construction and does not test very many things yet.


3. OPERATION

     This section does not (yet) detail the operation of the individual
pieces of Services; that information can be found in the online help files
("/msg *Serv help" or read lib/*serv/index).  It only describes how to
start Services itself.

     Normally, Services can be run simply by invoking the "services"
executable.  Services will then use the defaults specified in the config.h
file, and connect to the specified uplink server.  Alternatively, any of
the following command-line options can be specified to change the default
values:
	-remote server[:port]	Connect to the specified server
	-name servername	Our server name (e.g. services.esper.net)
	-desc string		Description of us (e.g. EsperNet Services)
	-user username		Username for Services' nicks (e.g. services)
	-host hostname		Hostname for Services' nicks (e.g. esper.net)
	-dir directory		Directory containing Services' data files
				    (e.g. /usr/local/lib/services)
	-log filename		Services log filename (e.g. services.log)
	-tz timezone		Name of Services' timezone (e.g. EST)
	-update secs		How often to update databases, in seconds
	-debug			Enable debugging mode--more info sent to log

     Upon starting, Services will parse its command-line parameters, open
its logfile, then (assuming all went well) detach itself and run in the
background.  If Services cannot connect to its uplink server, it will
terminate immediately; otherwise, it will run until the connection is
terminated (or a QUIT command is sent; see OperServ's help texts).

     If Services is compiled with the READONLY compile-time option, it can
serve as a "backup" to the full version of Services.  A "full" version of
Services (without READONLY defined) will automatically reintroduce its
pseudo-clients (NickServ, ChanServ, etc.), while a "backup" Services will
not, thus allowing full Services to be brought up at any time without
disrupting the network.

     Two additional programs available in addition to the main executable:
"listnicks" and "listchans", both installed as hard links to the main
executable.  The programs will list all registered nicknames and channels,
respectively; or, if given the -c option, will display the number of
registered nicknames or channels.


4. OVERVIEW OF SERVICES CLIENTS

     This is a brief introduction to the various clients available from
Services.  All *Serv clients can be /msg'd with "help" for a general
introduction.

     NickServ is the nickname server; it allows users to register and
control nicknames, and will (at the user's choice) /kill any unauthorized
user who tries to use that nick after a warning.

     ChanServ is the channel server; as NickServ, it allows users to
register and control channels.  There is a much wider array of controls
available via ChanServ than NickServ, since there are considerably more
features available.  These include automatic mode setting, topic
retention (active by default, this will cause the channel's topic to be
saved while the channel is empty and restored when a user joins it again),
and automatic opping (and kicking) of selected users.

     MemoServ allows users to send short messages to other users, which can
be stored and retrieved at the recipient's convenience.

     HelpServ is Services' help system; it will, on request, send a help
text to a user.  Other Services clients also call on HelpServ for their
own help functions.  (So, for example, "/msg ChanServ help register" is the
same as "/msg HelpServ chanserv register".

     IrcIIHelp is HelpServ under another name, and allows ircII users to
simply type "/help <topic>" to get help on the ircII client.

     OperServ provides services to IRC operators, including the ability to
change the mode of any channel, kick any user from a channel, and add and
remove network-wide bans (similar to classic K:lines, but applying to all
servers on the network).  A certain set of operators can be defined (in
operserv.c) as Services operators, and can perform additional functions,
such as manually updating Services' databases or shutting Services down.
Obviously, all these functions should be used with care.

     DevNull is just like its Unix equivalent /dev/null: it ignores
anything sent to it.  It can be removed without affecting the rest of
Services in any way.

     EsperNet is the global noticer: when Services is instructed to send a
notice to all clients on the network, this nickname sends the message.
Obviously, you should change it to the name of your network (or some other
useful name)!  See operserv.c for the name definition.


5. IRC PROTOCOL ADDITIONS

AKILL

    Syntax: AKILL <hostmask> <usermask> <reason>

    Adds an AutoKill to the network; this is like a K:line, but is
    propogated to all servers.  Any user matching the usermask and
    hostmask will not be allowed to connect.

    Example:  :services.esper.net AKILL *.lame.com lamer :Flooding
        Disallows any client matching "lamer@*.lame.com" from connecting
        to the network.

RAKILL

    Syntax: RAKILL <hostmask> <usermask>

    Removes an AutoKill line from all servers.

    Example:  :services.esper.net RAKILL *.lame.com lamer
        Removes the AutoKill described in the previous example.

GLOBOPS

    Syntax: GLOBOPS <message>

    Sends a message to all users with user mode +og.

    Example:  :Alcan GLOBOPS :Watch out for flooders from *.lame.com.

GOPER

    Syntax: GOPER <message>

    Sends a message to all IRC operators, regardless of other user modes.

    Example:  :services.esper.net GOPER :WARNING -- clones detected from
                      ppp1-9.lame.com


6. REACHING THE AUTHOR

     I can be reached via E-mail at achurch@dragonfire.net.  Please feel
free to send comments, suggestions, problem reports, diffs, or whatever.
