IRC Services Manual

Appendix A. List of all configuration directives

A-1. Core configuration directives (ircservices.conf)
A-2. Module configuration directives (modules.conf)
    protocol/*
    mail/main
    mail/sendmail
    mail/smtp
    operserv/main
    operserv/akill
    operserv/news
    operserv/sessions
    operserv/sline
    nickserv/main
    nickserv/access
    nickserv/autojoin
    nickserv/link
    nickserv/mail-auth
    nickserv/sendpass
    chanserv/main
    chanserv/sendpass
    memoserv/main
    memoserv/forward
    memoserv/ignore
    statserv/main
    httpd/main
    httpd/auth-ip
    httpd/auth-password
    httpd/dbaccess
    httpd/debug
    httpd/redirect
    httpd/top-page
    misc/devnull
    misc/helpserv

Table of Contents

Core configuration directives (`ircservices.conf`)

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.
Example: 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.
Example: LocalAddress host.name.here
Example: 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.
Example: ServerName "services.example.net"

ServerDesc text [REQUIRED]
Specifies the text which should appear as the server's information in /whois and similar queries.
Example: ServerDesc "Services for IRC Networks"

ServiceUser usermask [REQUIRED]
Specifies the user@host mask which should be used by the Services pseudoclients.
Example: 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.
Example: RunGroup services
Example: 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.
Example: Umask 077 # Disallows access to all but file owner # (recommended when RunGroup is not set)
Example: 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.
Example: 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.
Example: PIDFilename ircservices.pid

MOTDFilename filename [REQUIRED]
Specifies the name of the Message of the Day file.
Example: 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.
Example: 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!
Example: 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.
Normally, it's 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 and compatible networks, Services takes advantage of an IRC server feature to assign each user a permanent ID number, which enhances the security of this check; on such networks, you should almost always leave this directive commented out.
Example: 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.
Example: 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.
Example: 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.
Example: 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.
Example: BadPassWarning 5

UpdateTimeout time [REQUIRED]
Sets the delay between automatic database updates. This timer is reset by the OperServ UPDATE command.
Example: UpdateTimeout 5m

ExpireTimeout time [REQUIRED]
Sets the delay between checks for expired nicknames and channels. The OperServ UPDATE command will also cause a check for expiration and reset this timer.
Example: ExpireTimeout 30m

WarningTimeout time [REQUIRED]
Sets the interval between sending warning messages for program errors via WALLOPS/GLOBOPS.
Example: 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.
Example: 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.
Example: 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.
Example: 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.
Example: 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.
Example: 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.
Example: 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.
Example: 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:
Example: DefTimeZone PST8PDT

LogMaxUsers [OPTIONAL]
Causes Services to write a message to the log every time a new user maximum is reached.
Example: LogMaxUsers

EnableGetpass [OPTIONAL]
Allows use of the NickServ and ChanServ GETPASS commands.
Example: EnableGetpass

WallGetpass [OPTIONAL]
Causes Services to send a WALLOPS/GLOBOPS on use of the NickServ or ChanServ GETPASS command.
Example: 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.
Example: WallSetpass

Modules to load

LoadModule module-name
Causes Services to load the specified module.
Example: LoadModule nickserv/main

Module configuration directives (`modules.conf`)

Protocol module settings

Enter the protocol name here, then uncomment the appropriate directives.

protocol/(insert protocol name here)

NetworkDomain domain [RECOMMENDED]
Protocols: bahamut, dalnet, dreamforge, monkey, rfc1459, trircd, ts8, undernet-p9
Specifies the common domain, if any, shared by all servers on your IRC network; this is required for global notices to function properly. Make sure you do not include a "." before the domain name. If you do not specify this, some or all users may not receive global notices.
Example: NetworkDomain "example.net"

CSSetChannelTime [OPTIONAL]
Protocols: bahamut, monkey, unreal
When enabled, causes Services to set the "creation time" (the time at which the first user joined the channel) of a registered channel to the time at which the channel was registered. This can help prevent spurious mode changes and "op hacking" when a split server reconnects to the network. When using Unreal, however, the first user to join the channel when it is empty gets set -o and +o in quick succession due to limitations of the IRC server; if this bothers you, do not enable this option. Also, some servers (such as Bahamut) generate server notices each time a channel's timestamp is changed, which can be safely ignored.
Example: CSSetChannelTime

ServerNumeric numeric [RECOMMENDED]
Protocols: unreal
Makes Services send a numeric to the remote server on connect. This must be a value between 1 and 254, and must not be in use by any other IRC server on the network. If you do not want to use a numeric for Services, comment the directive out.
Example: ServerNumeric 1

SetServerTimes [time] [RECOMMENDED]
Protocols: unreal
Causes Services to synchronize all servers' internal clocks with its own; this can help avoid potential problems with users improperly gaining chanops, particularly during netsplits. If a time parameter is given, Services will repeatedly synchronize the servers clocks at that interval, otherwise synchronization will only be performed at startup.
Example: SetServerTimes
Example: SetServerTimes 12h

Mail module configuration

mail/main

FromAddress email [REQUIRED]
Specifies the E-mail address to be used on outgoing mail. Make sure you enter the correct address here before uncommenting the directive.
Example: FromAddress services@example.net

FromName name [OPTIONAL]
Specifies the "real name" to be used on outgoing mail. Make sure to include quotes if this is a multi-word string.
Example: FromName "ExampleNet Services"

mail/sendmail (Sendmail-based low-level module)

SendmailPath path [REQUIRED]
Specifies the full path to the "sendmail" program to be used to send mail. This program must accept a command-line option "-t" to extract recipient addresses from a mail message given on standard input (the standard "sendmail" program does this). The program will be executed with the same environment as Services itself is run with.
Example: SendmailPath /usr/lib/sendmail

mail/smtp (SMTP-based low-level module)

RelayHost hostname [REQUIRED]
Specifies the host to which all mail will be sent, e.g. your local mail server.
Example: RelayHost mail.example.net

SMTPName hostname [REQUIRED]
Specifies the hostname Services will use in the HELO command to the remote server. Normally, this should be set to the same as the hostname of the machine Services runs on.
Example: SMTPName services.example.net

MaxSockets count [REQUIRED]
Specifies the maximum number of sockets to the mail server which can be open at once.
Example: MaxSockets 100

OperServ configuration

operserv/main

OperServName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the OperServ pseudoclient.
Example: OperServName "OperServ" "Operator Server"

GlobalName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the global-noticer pseudoclient. This client is used to send messages from the OperServ GLOBAL command and news messages.
Example: GlobalName "Global" "Global Noticer"

OperServDB name [REQUIRED]
Specifies the name of the OperServ database. When using the standard database module, this is the name of the file in which the data is stored.
Example: OperServDB "oper.db"

ServicesRoot nick [REQUIRED]
Specifies the Services "super-user". The super-user, or "root" as in Unix terminology, is the only user who can add or delete Services admins.
This is commented out by default; make sure you insert the correct nick before uncommenting it.
Example: ServicesRoot SuperUser

KillClonesAutokill expiry-time [RECOMMENDED]
Causes Services to add an autokill for hosts killed using the KILLCLONES command, to prevent the clients from immediately reconnecting. The expiry-time parameter sets the expiry time for the autokill.
If the autokill module (operserv/akill) is not loaded, this directive has no effect.
Example: KillClonesAutokill 30m

AllowRaw [DISCOURAGED]
Enables use of the OperServ RAW command. This command can be used for testing IRC server features and other limited uses, but can also wreak havoc on a network if used improperly; use with extreme caution.
Example: AllowRaw

WallOper [OPTIONAL]
Causes Services to send a WALLOPS/GLOBOPS when a user becomes an IRC operator. Note that this can cause WALLOPS floods when Services first connects to the network.
Example: WallOper

WallBadOS [OPTIONAL]
Causes Services to send a WALLOPS/GLOBOPS if a non-IRC-operator tries to use OperServ.
Example: WallBadOS

WallOSChannel [OPTIONAL]
Cause Services to send a WALLOPS/GLOBOPS on use of any of the MODE, KICK, CLEARMODES, and CLEARCHAN commands.
Example: WallOSChannel

WallSU [OPTIONAL]
Causes Services to send a WALLOPS/GLOBOPS whenever a Services admin successfully obtains Services super-user privileges with the SU command. Note that Services will always send a WALLOPS/GLOBOPS when an incorrect password is given to the SU command or a user without Services admin privileges attempts to use the SU command.
Example: WallSU

operserv/akill (Autokill module settings)

AutokillDB name [REQUIRED]
Specifies the name of the autokill database. When using the standard database module, this is the name of the file in which the data is stored.
Example: AutokillDB "akill.db"

AutokillReason reason [REQUIRED]
The reason to use when sending out KILLs for autokills and with the actual AKILL/GLINE commands. Some servers show this reason to users if their connection is rejected because they match an autokill. If you include a "%s" in the reason, it will be replaced by the reason given with the autokill itself.
Example: AutokillReason "You are banned from this network"
Example: AutokillReason "Autokilled: %s"

AutokillExpiry time [RECOMMENDED]
Sets the default expiry time for autokills. If not defined, autokills will not expire by default.
Example: AutokillExpiry 30d

OperMaxExpiry time [OPTIONAL]
Sets the maximum expiry time usable by Services operators. If not defined, Services operators can set any expiry time, just as Services administrators can. If this is set to a value lower than AutokillExpiry, autokills entered without an expiry time will use this setting instead of AutokillExpiry.
Example: OperMaxExpiry 7d

EnableExclude [OPTIONAL]
Causes autokill exclusions to be usable. If not given, the EXCLUDE command will be unavailable, and any autokill exclusions previously added will be ignored.
NOTICE: On IRC servers without autokill exclusion functionality (such as that in trircd version 5), this will cause autokills to not be sent to the server; instead, Services will issue a KILL for each user that matches an autokill and does not match any autokill exclusions. This is necessary to allow Services to apply exclusions to users before they are disconnected.
Example: EnableExclude

ExcludeReason reason [REQUIRED if EnableExclude set]
The reason to use when sending out EXCLUDE commands on servers which support them. If you include a "%s" in the reason, it will be replaced by the reason given with the exclusion itself.
Example: ExcludeReason "IRC operator host"
Example: ExcludeReason "Excluded from autokills: %s"

ExcludeExpiry time [OPTIONAL]
Sets the default expiry time for autokill exclusions. If not defined, autokill exclusions will not expire by default.
Example: ExcludeExpiry 30d

ImmediatelySendAutokill [OPTIONAL]
Causes OperServ to inform all servers of a new autokill or autokill exclusion the moment it is added, rather than waiting for someone to match it first.
Example: ImmediatelySendAutokill

WallOSAkill [OPTIONAL]
Cause Services to send a WALLOPS/GLOBOPS on use of the AKILL or EXCLUDE command to add or delete autokills or exclusions.
Example: WallOSAkill

WallAutokillExpire [OPTIONAL]
Causes Services to send a WALLOPS/GLOBOPS whenever an autokill or autokill exclusion expires.
Example: WallAutokillExpire

operserv/news (News module settings)

NewsDB name [REQUIRED]
Specifies the name of the news database. When using the standard database module, this is the name of the file in which the data is stored.
Example: NewsDB "news.db"

operserv/sessions (Sessions module settings)

ExceptionDB name [REQUIRED]
Specifies the name of the exception database. When using the standard database module, this is the name of the file in which the data is stored.
Example: ExceptionDB "exception.db"

DefSessionLimit limit [RECOMMENDED]
Default session limit per host. Once a host reaches its session limit, all clients attempting to connect from that host will be killed. A value of zero (or omitting the option entirely) means an unlimited session limit.
Example: DefSessionLimit 3

MaxSessionLimit limit [OPTIONAL]
The maximum session limit that may be set for a host in an exception.
Example: MaxSessionLimit 100

ExceptionExpiry time [RECOMMENDED]
Sets the default expiry time for exceptions. If not set, exceptions will not expire by default.
Example: ExceptionExpiry 1d

SessionLimitExceeded message [OPTIONAL]
The message that will be NOTICE'd to a user just before they are removed from the network because their host's session limit has been exceeded. It may be used to give a slightly more descriptive reason for the impending kill as opposed to simply "Session limit exceeded". If this is commented out, nothing will be sent.
Example: SessionLimitExceeded "The session limit for your host %s has been exceeded."

SessionLimitDetailsLoc message [OPTIONAL]
Same as above, but should be used to provide a website address where users can find out more about session limits and how to go about applying for an exception. If this is commented out, nothing will be sent.
This option has been intentionally commented out in an effort to remind you to change the URL it contains. It is recommended that you supply an address/URL where people can get help regarding session limits.
Example: SessionLimitDetailsLoc "Please visit http://your.website.url/ for more information about session limits."

SessionLimitAutokill max-kill-interval num-kills expiry reason [OPTIONAL]
With this option, Services will add an automatic autokill when the same host's session limit is exceeded repeatedly in a short period of time. If not given, autokills will not be automatically added (Services will just keep killing users from the host as they come on). Note that the autokill module (operserv/akill) must be loaded for this to work.
max-kill-interval sets the maximum interval which can elapse between kills before the kill counter is reset.
num-kills sets the number of kills before an autokill is added.
expiry sets the expiration time for the autokill.
reason sets the reason for the autokill.
Example: SessionLimitAutokill 10s 5 30m "Exceeding session limit"

WallOSException [OPTIONAL]
Cause Services to send a WALLOPS/GLOBOPS on use of the EXCEPTION command to add or delete a session exception.
Example: WallOSException

WallExceptionExpire [OPTIONAL]
Causes Services to send a WALLOPS/GLOBOPS whenever a session limit exception expires.
Example: WallExceptionExpire

operserv/sline (S-line module settings)

SlineDB name [REQUIRED]
Specifies the name of the S-line database. When using the standard database module, this is the name of the file in which the data is stored.
Example: SlineDB "sline.db"

SGlineReason reason [REQUIRED]
The reason to use when sending out KILLs and SGLINE commands. Some servers show this reason to users if their connection is rejected because they match an SGline. If you include a "%s" in the reason, it will be replaced by the reason given with the SGline entry itself.
Example: SGlineReason "Invalid real name" #SGlineReason "Invalid real name: %s"

SQlineReason reason [REQUIRED]
The reason to use when sending out KILLs and SQLINE commands. Some servers show this reason to users if their connection is rejected because they match an SQline. If you include a "%s" in the reason, it will be replaced by the reason given with the SQline entry itself.
Example: SQlineReason "Reserved nickname" #SQlineReason "Reserved nickname: %s"

SZlineReason reason [REQUIRED]
The reason to use when sending out KILLs and SZLINE commands. Some servers show this reason to users if their connection is rejected because they match an SZline. If you include a "%s" in the reason, it will be replaced by the reason given with the SZline entry itself.
Example: SZlineReason "You are banned from this network"
Example: SZlineReason "Z-lined: %s"

ImmediatelySendSline [OPTIONAL]
Causes OperServ to inform all servers of a new S-line the moment it is added, rather than waiting for someone to match it first.
Example: ImmediatelySendSline

SGlineExpiry time [OPTIONAL]
Sets the default expiry time for SGlines. If not defined, SGlines of that type will not expire by default.
Example: SGlineExpiry 30d

SQlineExpiry time [OPTIONAL]
Sets the default expiry time for SQlines. If not defined, SQlines of that type will not expire by default.
Example: SQlineExpiry 30d

SZlineExpiry time [OPTIONAL]
Sets the default expiry time for SZlines. If not defined, SZlines of that type will not expire by default.
Example: SZlineExpiry 30d

WallOSSline [OPTIONAL]
Cause Services to send a WALLOPS/GLOBOPS on use of the SGLINE, SQLINE, or SZLINE commands to add or delete S-lines.
Example: WallOSSline

WallSlineExpire [OPTIONAL]
Causes Services to send a WALLOPS/GLOBOPS whenever an autokill expires.
Example: WallSlineExpire

SQlineIgnoreOpers [OPTIONAL]
Allows IRC operators to use nicknames that match an SQline. (Note that this may not function properly if the IRC server does not allow IRC operators to use such nicknames.)
Example: SQlineIgnoreOpers

SQlineKill [OPTIONAL]
Normally, users whose nickname matches an SQline will have their nickname changed (on servers which support forced nickname changing) instead of being killed. Setting this option causes such users to be killed even on such servers, which may be helpful for dealing with clone attacks.
Note that if this option is set, Services will not send SQlines to the IRC network; if it did, the IRC servers would step in and send the user an "invalid nickname" message before Services had a chance to kill the user.
Example: SQlineKill

NickServ configuration

nickserv/main

NickServName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the NickServ pseudoclient.
Example: NickServName "NickServ" "Nickname Server"

NickServDB name [REQUIRED]
Specifies the name of the nickname database. When using the standard database module, this is the name of the file in which the data is stored.
Example: NickServDB "nick.db"

NSEnableRegister [OPTIONAL]
Allows the REGISTER command to be used. This is usually a good thing, but if you don't want your users to be able to register nicknames, remove (or comment out) this directive. Note that you will need to at least enable this to register the Services super-user nick (defined in the operserv/main ServicesRoot directive), or you will not be able to use any privileged OperServ functions!
Example: NSEnableRegister

NSRegEmailMax count [OPTIONAL]
Sets the maximum number of nicknames that can be registered to a single E-mail address; this affects both ordinary registration as well as changing the address using SET EMAIL, and also nickname linking (if the appropriate module module is loaded). If not given, there is no limit.
This option is most useful in combination with NSRequireEmail, below.
Example: NSRegEmailMax 20

NSRequireEmail [OPTIONAL]
Makes an E-mail address required at registration time. Users also will not be able to clear the address once registered, though they can change it. If not set, an E-mail address is not required (but may still be given), and the address may be cleared later on.
Example: NSRequireEmail

NSRegDelay time [RECOMMENDED]
Sets the minimum length of time between consecutive uses of the REGISTER command. If not given, this restriction is disabled.
WARNING: Not setting NSRegDelay, or setting it too low, will not only allow "registration flooding", but, if the mail-auth module is also loaded, will also allow users to abuse this command to send large quantities of mail (mailbombs) to arbitrary users!
Example: NSRegDelay 5m

NSDef... [OPTIONAL]
Sets the default options for newly registered nicks. Note that changing these options will have no effect on nicks which are already registered. Options not listed here will be unset on new nicks.
If both NSDefKill and NSDefKillQuick are given, NSDefKillQuick takes precedence. KILL IMMED cannot be specified as a default.
Example: NSDefKill
Example: NSDefKillQuick
Example: NSDefSecure
Example: NSDefPrivate
Example: NSDefHideEmail
Example: NSDefHideUsermask
Example: NSDefHideQuit
Example: NSDefMemoSignon
Example: NSDefMemoReceive

NSExpire time [RECOMMENDED]
Sets the length of time before a nick registration expires. If not set, nicknames will not expire.
Example: NSExpire 30d

NSExpireWarning time [OPTIONAL]
Sets the length of time before nick expiration during which warnings are sent to the user when the user is online (and not identified). If not set, no warnings will be sent; however, a message will still be sent when the nickname actually expires.
Example: NSExpireWarning 3d

NSSuspendExpire time grace-period [RECOMMENDED]
Sets the default expiry time and recovery grace period for nickname suspensions. (The expiry time can be set individually for each suspension; the grace period cannot.) The recovery grace period is the length of time a nick must exist for, after being unsuspended, before it is allowed to expire. This gives the owner a chance to reclaim the nick. It is enforced, if necessary, by adjusting the "last seen time" value when the nick is unsuspended. If set to zero, nicknames that are suspended for longer than "NSExpire" will be expired (dropped) during the next check for nickname expiration, giving the owners very little time to identify for their nicknames and prevent their expiry.
If not specified, nickname suspensions will not expire by default, and there will be no grace period for recovering the nick.
Example: NSSuspendExpire 25d 5d

NSShowPassword [OPTIONAL]
Causes the user's password to be sent back to them in a NOTICE at registration time, as a reminder.
Example: NSShowPassword

NSEnforcerUser user[@host] [REQUIRED]
Sets the username (and possibly hostname) used for the fake user created when NickServ collides a user. Should be in user@host format. If the host is not given, the one from ServicesUser is used.
Example: NSEnforcerUser enforcer
Example: NSEnforcerUser enforcer@localhost.net

NSForceNickChange [OPTIONAL]
When enabled, makes NickServ change a user's nick to a "Guest######" nick instead of killing them when enforcing a "nick kill". (The actual nickname used is determined by the GuestNickPrefix setting in ircservices.conf.)
This setting has no effect with IRC servers that do not support forcibly changing a client's nickname, and a warning will be written to the log file if this option is used in such a case.
Example: NSForceNickChange

NSReleaseTimeout time [REQUIRED]
Sets the delay before a NickServ-collided nick is released.
Example: NSReleaseTimeout 1m

NSAllowKillImmed [OPTIONAL]
When given, allows the use of the IMMED option with the NickServ SET KILL command.
Example: NSAllowKillImmed

NSListOpersOnly [OPTIONAL]
When enabled, limits use of the NickServ LIST and LISTEMAIL commands to IRC operators.
Example: NSListOpersOnly

NSListMax count [REQUIRED]
Specifies the maximum number of nicks to be returned for a NickServ LIST or LISTEMAIL command.
Example: NSListMax 50

NSSecureAdmins [RECOMMENDED]
When enabled, prevents the use of the DROP, GETPASS, and SET PASSWORD commands by Services admins on other Services admins or the Services root.
Example: NSSecureAdmins

NSHelpWarning [OPTIONAL]
When enabled, displays a "do not abuse NickServ" warning at the end of the NickServ HELP output similar to previous versions of Services. Otherwise, the warning is not displayed.
Example: NSHelpWarning

nickserv/access (Access list module)

NSAccessMax count [REQUIRED]
Sets the maximum number of entries allowed on a nickname access list.
Example: NSAccessMax 32

NSFirstAccessEnable [OPTIONAL]
When enabled, causes an access entry based on the registering user's username and hostname to be automatically added to the access list of a newly-registered nickname. When disabled, newly-registered nicknames will have an empty access list.
Example: NSFirstAccessEnable

NSFirstAccessWild [OPTIONAL]
When enabled, causes the first access list entry added to a newly registered nickname to use a wildcard in the hostname when appropriate. When disabled, the first access list entry consists of the registering user's username and hostname as-is, without wildcards. This directive has no effect if NSFirstAccessEnable is disabled.
Example: NSFirstAccessWild

nickserv/autojoin (Autojoin module)

NSAutojoinMax count [REQUIRED]
Sets the maximum number of entries allowed on an autojoin list. There is little point in setting this higher than the maximum number of channels a client is allowed to join by the server (usually 10).
Example: NSAutojoinMax 10

nickserv/link (Link module)

NSLinkMax count [REQUIRED]
Sets the maximum number of links allowed for a single nickname group.
Example: NSLinkMax 20

nickserv/mail-auth (Authorization module)

NSNoAuthExpire time [OPTIONAL]
Sets the period of time after which a newly registered nickname will expire if it is not authorized. If not specified, the standard nickname expiration time (NSExpire) is used.
Example: NSNoAuthExpire 12h

NSSendauthDelay time [RECOMMENDED]
Sets the minimum length of time between consecutive uses of the SENDAUTH command for the same nick group. If not specified, this restriction is disabled.
WARNING: Not setting NSSendauthDelay, or setting it too low, will allow users to abuse this command to send large quantities of mail (mailbombs) to arbitrary users!
Example: NSSendauthDelay 1d

nickserv/sendpass (SENDPASS module)

NSSendpassDelay time [RECOMMENDED]
Sets the minimum length of time between consecutive uses of the SENDPASS command for the same nick group. If not specified, this restriction is disabled.
WARNING: Not setting NSSendpassDelay, or setting it too low, will allow users to abuse this command to send large quantities of mail (mailbombs) to arbitrary users!
Example: NSSendpassDelay 1d

ChanServ configuration

chanserv/main

ChanServName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the ChanServ pseudoclient.
Example: ChanServName "ChanServ" "Channel Server"

ChanServDB name [REQUIRED]
Specifies the name of the channel database. When using the standard database module, this is the name of the file in which the data is stored.
Example: ChanServDB "chan.db"

CSEnableRegister [OPTIONAL]
Allows the REGISTER command to be used. This is usually a good thing, but if you don't want your users to be able to register channels, remove (or comment out) this directive. Note, however, that Services administrators and the Services super-user will still be able to use the REGISTER command even if this directive is not given.
Example: CSEnableRegister

CSMaxReg count [RECOMMENDED]
Limits the number of channels which may be registered to a single nickname. In the case of linked nicks, this limit applies to the entire set of linked nicks.
Example: CSMaxReg 20

CSDef... [OPTIONAL]
Sets the default options for newly registered channels. Note that changing these options will have no effect on channels which are already registered. Options not listed here will be unset on new channels.
Example: CSDefKeepTopic
Example: CSDefSecureOps
Example: CSDefPrivate
Example: CSDefTopicLock
Example: CSDefLeaveOps
Example: CSDefSecure
Example: CSDefOpNotice
Example: CSDefEnforce
Example: CSDefHideEmail
Example: CSDefHideTopic
Example: CSDefHideMlock

CSExpire time [RECOMMENDED]
Sets the length of time before a channel expires. If not set, channels will not expire.
Example: CSExpire 14d

CSSuspendExpire time [RECOMMENDED]
Sets the default expiry time and recovery grace period for channel suspensions. If not set, channel suspensions will not expire by default and there will be no recovery grace period.
Example: CSSuspendExpire 12d 2d

CSShowPassword [OPTIONAL]
If specified, causes the user's password to be sent back to them in a NOTICE at registration time, as a reminder.
Example: CSShowPassword

CSAccessMax count [REQUIRED]
Sets the maximum number of entries on a channel's access list. Channel access lists may contain only registered nicknames; therefore, checking each entry on the list requires only a single scalar comparison instead of a wildcard match, and this limit may be safely set much higher than (for example) the nickname access list size limit without impacting performance significantly.
Example: CSAccessMax 1024

CSAutokickMax count [REQUIRED]
Sets the maximum number of entries on a channel's autokick list.
Example: CSAutokickMax 32

CSAutokickReason text [REQUIRED]
Sets the default reason for an autokick if none is given.
Example: CSAutokickReason "User has been banned from the channel"

CSInhabit time [REQUIRED]
Sets the length of time ChanServ stays in a channel after kicking a user from a channel s/he is not permitted to be in. This only occurs when the user is the only one in the channel.
Example: CSInhabit 15s

CSRestrictDelay time [OPTIONAL]
When enabled, causes ChanServ to permit users to join channels with the RESTRICTED option set if they would be permitted to join after identifying for their nick, and to not remove mode +o (ops) from users who would be auto-opped if identified for their nick, for the given period of time after Services starts up. This gives such users time to identify to NickServ before being kicked out of restricted channels or getting deopped.
Example: CSRestrictDelay 15s

CSListOpersOnly [OPTIONAL]
When enabled, limits use of the ChanServ LIST command to IRC operators.
Example: CSListOpersOnly

CSListMax count [REQUIRED]
Specifies the maximum number of channels to be returned for a ChanServ LIST command.
Example: CSListMax 50

CSForbidShortChannel [OPTIONAL]
When enabled, treats the channel "#" as a forbidden channel, not allowing any users to join it. When not enabled, the channel "#" can be used normally, although ChanServ functions cannot be used with it.
Example: CSForbidShortChannel

chanserv/sendpass (SENDPASS module)

CSSendpassDelay time [RECOMMENDED]
Sets the period of time which must elapse between SENDPASS commands for the same channel. If not specified, the SENDPASS command may be used at any time.
NOTE: Since users can only send passwords to nicks they have identified for, the potential for E-mail attacks via this command is minimal; however, setting this limit too low (or not setting it at all) can allow users to slow down Services through frequent SENDPASS requests.
Example: CSSendpassDelay 1h

MemoServ configuration

memoserv/main

MemoServName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the MemoServ pseudoclient.
Example: MemoServName "MemoServ" "Memo Server"

MSMaxMemos count [RECOMMENDED]
Sets the maximum number of memos a user is allowed to keep by default. Normal users may set the limit anywhere between zero and this value; Services admins can change it to any value or disable it. If not given, the limit is disabled by default, and normal users can set any limit they want.
Example: MSMaxMemos 20

MSExpire time [OPTIONAL]
Sets the length of time after a memo is sent until it expires and is automatically deleted. If not set, memos will not expire. Note that memos sent while MSExpire is disabled will not expire even if MSExpire is later enabled.
Example: MSExpire 3d

MSExpireUnread [OPTIONAL]
If specified, unread memos will be expired after the delay given in the MSExpire directive just like other memos; normally, unread memos do not expire. If MSExpire is not set, this directive is ignored.
Example: MSExpireUnread

MSSendDelay time [RECOMMENDED]
Sets the delay between consecutive uses of the MemoServ SEND command. This can help prevent spam as well as denial-of-service attacks from sending large numbers of memos and filling up disk space (and memory). A 3-second wait means a maximum average of 150 bytes of memo per second per user under the current IRC protocol.
Example: MSSendDelay 3s

MSNotifyAll [OPTIONAL]
Should we notify all appropriate users of a new memo? This applies in cases where a memo is sent to a nick which has other nicks linked to it and multiple users are using two or more of the linked nicks. Enabling this option will cause MemoServ to check all users who are currently online to see whether any have nicks which are linked to the target of the memo, and if so, notify all of them. This can take a good deal of CPU time on larger networks, so you may want to disable it.
Example: MSNotifyAll

memoserv/forward (FORWARD module)

MSAllowForward [OPTIONAL]
If given, allows the FORWARD command to be used (the SET FORWARD command is always available). While the FORWARD command can be useful particularly for users first setting the FORWARD option on, a large number of users using the FORWARD ALL command can place a significant load on Services.
Example: MSAllowForward

MSForwardDelay time [RECOMMENDED if MSAllowForward is set]
Sets the minimum length of time between consecutive uses of the FORWARD command. If not given, this restriction is disabled. (Note that this can allow users to place a significant load on Services and/or your mail server!)
If MSAllowForward is not set, this directive is ignored.
Example: MSForwardDelay 10s

memoserv/ignore (IGNORE module)

MSIgnoreMax [REQUIRED]
Sets the maximum number of entries a user can have for their nickname group's memo ignore list.
Example: MSIgnoreMax 32

StatServ configuration

statserv/main

StatServName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the StatServ pseudoclient.
Example: StatServName "StatServ" "Statistics Server"

StatServDB name [REQUIRED]
Specifies the name of the StatServ database. When using the standard database module, this is the name of the file in which the data is stored.
Example: StatServDB "stats.db"

SSOpersOnly [OPTIONAL]
Limits the use of StatServ to IRC operators only.
Example: SSOpersOnly

HTTP server modules

httpd/main

ListenTo address:port [REQUIRED]
Specifies the address and port number on which the HTTP server will listen for incoming requests. address may be specified as an IP address (first example below), a hostname (second example), or the special string "*", which means "any IP address" (third example).
When a hostname is given, as in the second example below, Services will look up the address(es) associated with the hostname at startup time, and bind to every IP address found. This can be useful, for example, with dynamic DNS, in which the server's IP address changes periodically; however, the hostname lookup can take time—especially if there is no DNS server on the local network—and is susceptible to network or DNS server outages, so IP addresses or "*" should be used whenever possible.
Example: ListenTo 127.0.0.1:12701
Example: ListenTo services.example.net:8080
Example: ListenTo *:80

ListenBacklog [REQUIRED]
Specifies the maximum number of connections that can be received by the operating system without being accepted by Services (the second parameter, `backlog', to the listen() system call). If you start seeing refused or delayed connections on a busy server, try increasing this value.
If you don't understand the above, leave this setting alone.
Example: ListenBacklog 5

RequestBufferSize bytes [REQUIRED]
Specifies the size of the buffer allocated for each HTTP request. Note that this buffer is allocated for every connection, and an additional amount of memory will be allocated for header pointers (in the pathological case this extra amount could reach 4/3 of the value given for this directive). If a client sends a request (including POST data) exceeding this value, an error will be returned and the connection terminated.
If you don't understand the above, leave this setting alone.
Example: RequestBufferSize 4096

MaxConnections count [RECOMMENDED]
Specifies the maximum number of simultaneous connections allowed. If not given, no limit is placed on the number of connections; however, the operating system may impose its own limits, which are not under the control of Services.
Example: MaxConnections 10

MaxRequests count [RECOMMENDED]
Specifies the maximum number of requests that can be made over a single connection before the server disconnects it. If not given, no limit is placed on the number of requests per connection; note that this may allow malicious users to interfere with Services' normal operations by sending large numbers of requests over a single connection.
Example: MaxRequests 20

IdleTimeout time [RECOMMENDED]
Specifies the length of time a connection can be idle (not sending data) before it will be automatically closed. If not given, connections will never be closed automatically.
Example: IdleTimeout 30s

LogConnections [OPTIONAL]
If given, a log message will be written for each connection to the server.
Example: LogConnections

httpd/auth-ip (IP address authorization module)

AllowHost path address [OPTIONAL]
DenyHost path address [OPTIONAL]

Specifies which hosts will be allowed (or not allowed) to access resources provided by the HTTP server. The path parameter is a URL path (not including the "http://host.name"), and matches any URL which begins with the same string; for example, "/dir" matches both "/dir/file" and "/dirty". The address can be an IP address, a hostname (as with ListenTo in the main server module, all addresses associated with the hostname will be allowed or denied), the string "*" (which means all addresses), or the special format "IP-address/mask", where mask is an integer from 1 to 31 giving the number of bits in the subnet address, which indicates that the entire subnet of addressess specified should be allowed or denied; for example, "192.168.1.64/26" represents the range of addresses from 192.168.1.64 to 192.168.1.127.

Examples:

Directive Meaning
AllowHost /debug 127.0.0.1 Allow all requests from localhost to the debug page
AllowHost / 192.168.0.0/24 Allow any host in the 192.168.0.* network access to the entire server
DenyHost / shell.example.org Deny connections from any address associated with shell.example.org

Multiple AllowHost or DenyHost directives for the same path may be used to specify multiple addresses to allow or deny. Each condition will be checked in the order they are listed here, and the first matching one will be used. For example, these lines:

AllowHost / 192.168.0.1
DenyHost / 192.168.0.0/24

deny access to all hosts in the 192.168.0.* network except 192.168.0.1. However, the reverse:

DenyHost / 192.168.0.0/24
AllowHost / 192.168.0.1

simply blocks all hosts in the 192.168.0.* network, since the first rule matches 192.168.0.1 and the second is never checked.

Access to the entire server can be allowed or denied by using the path "/", which matches every URL (since all URLs begin with a slash). It is good practice to include such a rule after all others to explicitly indicate what should be done with requests that do not match any other rule. (If a request does not match any rules at all, it is implicitly allowed, but this behavior may change in the future and should not be relied on.) For example:

AllowHost / *

or:

DenyHost / *

WARNING: Hostnames are resolved only once at startup; any changes in a host's IP address will not be seen by Services.

Note: These directives are listed as "optional" only because the module will still load even if no directives are listed; however, unless AllowHost/DenyHost directives are given, the module will not have any effect.

Example: AllowHost / *

httpd/auth-password (Password authorization module)

AuthName name [REQUIRED]
Specifies the name to be used by the user's browser when asking for a password (as in "Enter username and password for name:").
Example: AuthName "IRC Services"

Protect path user:pass [OPTIONAL]
Sets the URLs (paths) which will be protected by password authorization, and the username and password for each path. The username and password can be different for each path. The path given will match any URL beginning with that string, as with the auth-ip module.
Examples:
Protect /debug "debug:debug"
Protect /~ "nickuser:nickpass"

Note: This directive is listed as "optional" only because the module will still load even if no directives are listed; however, unless Protect directives are given, the module will not have any effect. Use a path of "/" to apply password protection to the entire server.

httpd/dbaccess (Database access module)

NOTICE: This module allows complete access to all Services data; be certain to protect it from unauthorized access using authorization modules or other means.

Prefix path [REQUIRED]

Sets the URL (path) at which database access will be accessible. If this does not end with a slash, one will be appended automatically. Access is provided using the following directory tree:

path/ Main menu
path/operserv/ OperServ data and menu
path/operserv/akill/ Autokill list
path/operserv/news/ News item list
path/operserv/sessions/ Session and exception lists
path/operserv/sline/ S-line lists
path/nickserv/ Nickname list and information
path/chanserv/ Channel list and information
path/statserv/ Network statistics XML-format database download

Categories for which the relevant module is not loaded will not be accessible.

WARNING: These functions, particularly the XML export function, can cause Services to stop for a significant period of time while they are processed!

This is commented out by default; make sure you implement proper access protection (see above) before uncommenting it.

Example: Prefix "/dbaccess"

httpd/debug (Debug page module)

DebugURL path [REQUIRED]
Sets the URL (path) at which the debug page will be accessible. This must begin with a slash.
Example: DebugURL "/debug"

httpd/redirect (Nick/channel redirect module)

NicknamePrefix path [OPTIONAL]
Sets the URL (path) at which nickname redirects will be accessible; all characters after this prefix, up to the next slash, will be taken as the nickname. This must begin with a slash. The default value, "/~", emulates the traditional home page URL of "http://www.example.net/~username/". If you use a directory name instead, it must end with a slash, for example: "/nickname/". See also ChannelPrefix, below.
If not set, nickname redirects will not be done.
Example: NicknamePrefix "/~"

ChannelPrefix path [OPTIONAL]
Sets the URL (path) at which channel redirects will be accessible; all characters after this prefix, up to the next slash, will be taken as the channel name (without the leading "#", which cannot be used in URLs). The path must begin with a slash. The default value, "/channel/", gives URLs like "http://services.example.net/channels/channelname/" for channel "#channelname".
If not set, channel redirects will not be done.
Note: If a URL could be interpreted as both a nickname URL and a channel URL, the nickname will take precedence, even if it is not registered or does not have a URL associated with it.
Example: ChannelPrefix "/channel/"

httpd/top-page (Top page module)

Filename path [content-type] [OPTIONAL]
Sets the name of a file to be delivered as the server's top page. If this does not begin with a slash, then it is taken as relative to the Services data directory. The second parameter specifies the MIME content type of the file; if not given, it defaults to text/html.
Example: Filename "Top Page.txt" text/plain
Example: Filename /var/www/html/ircservices/top-page.html

Redirect URL [OPTIONAL]
Sets a URL to be provided as a redirect to a client accessing the top page. This must be a full URL, beginning with "http://" (or some other protocol specifier). If both Filename and Redirect are given, Redirect takes precedence.
Example: Redirect http://www.example.net/ircservices/

Miscellaneous modules

misc/devnull (DevNull settings)

DevNullName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the DevNull pseudoclient.
Example: DevNullName "DevNull" "/dev/null -- message sink"

misc/helpserv (HelpServ settings)

HelpServName nick string [REQUIRED]
Specifies the nickname (first parameter) and "real" name (second parameter) used by the HelpServ pseudoclient.
Example: HelpServName "HelpServ" "Help Server"

HelpDir dirname [REQUIRED]
Specifies the name of the subdirectory containing help files for HelpServ.
Example: HelpDir helpfiles

This module has no configurable settings.

OnNicknameCollision action [OPTIONAL]
Specifies the action to be taken when a nickname in the data to import is already registered. The string must be one of either "skipgroup" (skip over the nickname group containing the nickname in the imported data), "skipnick" (skip only the colliding nickname), or "abort" (do not import any data). Note that when "abort" is selected, the entire XML input is still checked for errors, but Services will abort before actually merging any data. If not specified, defaults to "skipgroup".
Example: OnNicknameCollision skipgroup

OnChannelCollision action [OPTIONAL]
Specifies the action to be taken when a channel in the data to import is already registered. The string must be one of either "skip" (skip over the channel in the imported data) or "abort" (do not import any data). Note that when "abort" is selected, the entire XML input is still checked for errors, but Services will abort before actually merging any data. If not specified, defaults to "skip".
Example: OnChannelCollision skip

VerboseImport [OPTIONAL]
Causes a detailed list of imported nicknames, channels, and other data to be printed to standard output.
Example: VerboseImport

Table of Contents | Top