# 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
