# 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)
# under 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.
#
# [DEPRECATED]
#     Indicates a directive which will disappear in a future version of
#     Services, usually because its functionality has been either
#     superseded by that of other directives or incorporated into the main
#     program.

###########################################################################
#
# Remote server configuration
#
###########################################################################

# RemoteServer <hostname> <port> <password>  [REQUIRED]
#     Specifies the remote server hostname and port.  The hostname may
#     either be 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 7000 "XXXXXX"

# 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	"noob.rc6.org"

# ServerDesc <text>  [REQUIRED]
#     Specifies the text which should appear as the server's information in
#     /whois and similar queries.

ServerDesc	"Services for rc6.org"

# ServiceUser <usermask>  [REQUIRED]
#     Specifies the user@host mask which should be used by the Services
#     pseudoclients.

ServiceUser	"services@rc6.org"

###########################################################################
#
# 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
#     in the future will probably check other things as well.

StrictPasswords

# 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

# UpdateTimeout <time>  [REQUIRED]
#     Sets the delay between automatic database updates.  This timer is
#     reset by the OperServ UPDATE command.

UpdateTimeout	5m

# ExpireTimeout <time>  [DEPRECATED]
#     Formerly used to set the delay between checks for expired nicknames
#     and channels.  As expiration is now checked for whenever a nickname
#     or channel is accessed, this directive now serves no function, and
#     is therefore deprecated; it will be removed in the next version of
#     Services.

#ExpireTimeout	30m

# 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
#     config.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.

# 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"

# 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

# 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

# WallGetpass  [OPTIONAL]
#     Causes Services to send a WALLOPS/GLOBOPS on use of the NickServ
#     or ChanServ GETPASS command.

WallGetpass

# WallSetpass  [OPTIONAL]
#     Causes Services to send a WALLOPS/GLOBOPS whenever a Services
#     admin sets a password for a nickname or channel s/he does not
#     normally have privileges to set.

WallSetpass

###########################################################################
#
# 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 (version 4.4.15+)
#         protocol/monkey       Chunky Monkey IRCD, version 1.0 and later
#      [*]protocol/ptlink       PTlink IRC server, version 6.0 and later
#         protocol/rfc1459      RFC1459-compliant servers
#         protocol/trircd       Trircd server, version 4.0 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.0 and later
#     Modules marked with [*] are still in an experimental stage and may
#     not be stable.

LoadModule protocol/unreal

###########################################################################

# Encryption module  [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).
#     If you do not load an encryption module, passwords will not be
#     encrypted.
#
#     WARNING: Depending on the encryption module 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)

#LoadModule encryption/md5

###########################################################################

# Database access module  [REQUIRED]
#     These modules provide access to permanent storage for data used by
#     various Services modules, and MUST be loaded before any other module
#     (except protocol and encryption modules).  Select the module
#     corresponding to the type of database you want to use:
#         database/version4     Database files compatible with version
#                                   4.5.x of Services

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.
#             NOTE: This module cannot be used at the same time as the
#                   "nickserv/oldlink" module.
#
#         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.
#
#         nickserv/oldlink  [DEPRECATED]
#             Provides LINK, UNLINK, and LISTLINK commands that mimic the
#             the behavior of links in version 4.x of Services.  This
#             module is intended to ease the transition to version 5.x,
#             and will likely be removed in a future version.
#             NOTE: This module cannot be used at the same time as the
#                   "nickserv/link" module.
#
#         nickserv/sendpass  [OPTIONAL]
#             Provides a SENDPASS command which allows users to have
#             NickServ send their nickname password to the E-mail address
#             they have registered for the nickname.
#             NOTE: This module requires the "nickserv/mail-auth" module.
#
#     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
#LoadModule nickserv/oldlink
LoadModule nickserv/sendpass

###########################################################################

# 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.
#
#         chanserv/sendpass  [OPTIONAL]
#             Provides a SENDPASS command which allows channel founders to
#             have ChanServ send the password for a channel to the E-mail
#             address they have registered for their nickname.
#             NOTE: This module requires the "nickserv/mail-auth" module.
#
#     The "operserv/main" and "nickserv/main" modules are REQUIRED for all
#     ChanServ modules.

LoadModule chanserv/main
LoadModule chanserv/access-levels
#LoadModule chanserv/access-xop
LoadModule chanserv/sendpass

###########################################################################

# 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

###########################################################################

# HTTP server 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