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
misc/xml-export
misc/xml-import
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"
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
Specifies the IRC server name which Services should use when it connects to the network.
Example: ServerName "services.example.net"
Specifies the text which should appear as the server's information in /whois and similar queries.
Example: ServerDesc "Services for IRC Networks"
Specifies the user@host mask which should be used by the Services pseudoclients.
Example: ServiceUser "services@example.net"
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
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)
NOTE: All filenames are relative to the Services data directory.
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
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
Specifies the name of the Message of the Day file.
Example: MOTDFilename ircservices.motd
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
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
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.
Example: NoSplitRecovery
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
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
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
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
Sets the delay between automatic database updates. This timer is reset by the OperServ UPDATE command.
Example: UpdateTimeout 5m
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.
Example: ExpireTimeout 30m
Sets the interval between sending warning messages for program errors via WALLOPS/GLOBOPS.
Example: WarningTimeout 4h
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
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
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
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
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
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
These are settings which don't belong anywhere else, or which would be module settings but apply to multiple modules.
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"
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
Causes Services to write a message to the log every time a new user maximum is reached.
Example: LogMaxUsers
Allows use of the NickServ and ChanServ GETPASS commands.
Example: EnableGetpass
Causes Services to send a WALLOPS/GLOBOPS on use of the NickServ or ChanServ GETPASS command.
Example: WallGetpass
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
Causes Services to load the specified module.
Example: LoadModule nickserv/main
Enter the protocol name here, then uncomment the appropriate directives.
protocol/(insert protocol name here)
Protocols: bahamut, dalnet, dreamforge, monkey, ptlink, 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"
Protocols: bahamut, monkey, trircd, 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
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
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
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
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)
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)
Specifies the host to which all mail will be sent, e.g. your local mail server. This directive may be given multiple times to specify backup servers; the servers will be tried in the order listed.
Example: RelayHost mail.example.net
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
Specifies the maximum number of sockets to the mail server which can be open at once.
Example: MaxSockets 100
Specifies the nickname (first parameter) and "real" name (second parameter) used by the OperServ pseudoclient.
Example: OperServName "OperServ" "Operator Server"
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"
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"
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
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
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
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
Causes Services to send a WALLOPS/GLOBOPS if a non-IRC-operator tries to use OperServ.
Example: WallBadOS
Cause Services to send a WALLOPS/GLOBOPS on use of any of the MODE, KICK, CLEARMODES, and CLEARCHAN commands.
Example: WallOSChannel
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)
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"
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"
Sets the default expiry time for autokills. If not defined, autokills will not expire by default.
Example: AutokillExpiry 30d
Sets the default expiry time for autokills added by an AKILLCHAN command.
Example: AkillChanExpiry 7d
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 or AkillChanExpiry, autokills entered without an expiry time will use this setting instead of the relevant default.
Example: OperMaxExpiry 7d
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
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"
Sets the default expiry time for autokill exclusions. If not defined, autokill exclusions will not expire by default.
Example: ExcludeExpiry 30d
Causes OperServ to inform all servers of a new autokill the moment it is added, rather than waiting for someone to match it first. (Note that autokill exclusions are always sent to the server immediately; this is to avoid an autokill being triggered by a non-excluded match before the exclusion has been sent, resulting in the excluded users being autokilled as well.)
Example: ImmediatelySendAutokill
Cause Services to send a WALLOPS/GLOBOPS on use of the AKILL or EXCLUDE command to add or delete autokills or exclusions.
Example: WallOSAkill
Causes Services to send a WALLOPS/GLOBOPS whenever an autokill or autokill exclusion expires.
Example: WallAutokillExpire
operserv/news (News module settings)
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)
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"
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
The maximum session limit that may be set for a host in an exception.
Example: MaxSessionLimit 100
Sets the default expiry time for exceptions. If not set, exceptions will not expire by default.
Example: ExceptionExpiry 1d
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."
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."
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"
Cause Services to send a WALLOPS/GLOBOPS on use of the EXCEPTION command to add or delete a session exception.
Example: WallOSException
Causes Services to send a WALLOPS/GLOBOPS whenever a session limit exception expires.
Example: WallExceptionExpire
operserv/sline (S-line module settings)
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"
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"
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"
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"
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
Sets the default expiry time for SGlines. If not defined, SGlines of that type will not expire by default.
Example: SGlineExpiry 30d
Sets the default expiry time for SQlines. If not defined, SQlines of that type will not expire by default.
Example: SQlineExpiry 30d
Sets the default expiry time for SZlines. If not defined, SZlines of that type will not expire by default.
Example: SZlineExpiry 30d
Cause Services to send a WALLOPS/GLOBOPS on use of the SGLINE, SQLINE, or SZLINE commands to add or delete S-lines.
Example: WallOSSline
Causes Services to send a WALLOPS/GLOBOPS whenever an autokill expires.
Example: WallSlineExpire
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
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
Specifies the nickname (first parameter) and "real" name (second parameter) used by the NickServ pseudoclient.
Example: NickServName "NickServ" "Nickname Server"
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"
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
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
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
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
Sets the minimum length of time the user must be connected before using the REGISTER command for the first time. If not given, this restriction is disabled. This option can be helpful in preventing malicious bots from flooding your network with registrations.
Example: NSInitialRegDelay 30s
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
Sets the length of time before a nick registration expires. If not set, nicknames will not expire.
Example: NSExpire 30d
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
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, as well as the AUTH timeout when the mail-auth module is in use, 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
Causes the user's password to be sent back to them in a NOTICE at registration time, as a reminder.
Example: NSShowPassword
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
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
Sets the delay before a NickServ-collided nick is released.
Example: NSReleaseTimeout 1m
When given, allows the use of the IMMED option with the NickServ SET KILL command.
Example: NSAllowKillImmed
When enabled, limits use of the NickServ LIST and LISTEMAIL commands to IRC operators.
Example: NSListOpersOnly
Specifies the maximum number of nicks to be returned for a NickServ LIST or LISTEMAIL command.
Example: NSListMax 50
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
Allows the DROPEMAIL command to be used. This command can help recover from mass-registration attacks, but can also destroy your database if used improperly.
Example: NSEnableDropEmail
Sets the maximum length of time allowed between a DROPEMAIL command and the corresponding DROPEMAIL-CONFIRM command.
Example: NSDropEmailExpire 10m
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)
Sets the maximum number of entries allowed on a nickname access list.
Example: NSAccessMax 32
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
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)
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
Sets the maximum number of links allowed for a single nickname group.
Example: NSLinkMax 20
nickserv/mail-auth (Authentication module)
Sets the period of time after which a newly registered nickname will expire if it is not authenticated. If not specified, the standard nickname expiration time (NSExpire) is used.
Example: NSNoAuthExpire 12h
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)
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
Specifies the nickname (first parameter) and "real" name (second parameter) used by the ChanServ pseudoclient.
Example: ChanServName "ChanServ" "Channel Server"
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"
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
Treats unregistered channels as if they were forbidden, disallowing access by ordinary users to any channels not explicitly registered with ChanServ. IRC operators will be allowed to enter such channels, as they are for ordinary forbidden channels. Note that this directive operates independently from the CSEnableRegister directive; if CSEnableRegister is commented out, non-Services-admin IRC operators will be able to join unregistered channels but will not be permitted to register them.
Example: CSRegisteredOnly
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
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
Sets the length of time before a channel expires. If not set, channels will not expire.
Example: CSExpire 14d
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
If specified, causes the user's password to be sent back to them in a NOTICE at registration time, as a reminder.
Example: CSShowPassword
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
Sets the maximum number of entries on a channel's autokick list.
Example: CSAutokickMax 32
Sets the default reason for an autokick if none is given.
Example: CSAutokickReason "User has been banned from the channel"
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
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
When enabled, limits use of the ChanServ LIST command to IRC operators.
Example: CSListOpersOnly
Specifies the maximum number of channels to be returned for a ChanServ LIST command.
Example: CSListMax 50
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. If CSRegisteredOnly is enabled, this directive has no effect (the "#" channel will be treated as forbidden along with all other unregistered channel).
Example: CSForbidShortChannel
chanserv/sendpass (SENDPASS module)
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
Specifies the nickname (first parameter) and "real" name (second parameter) used by the MemoServ pseudoclient.
Example: MemoServName "MemoServ" "Memo Server"
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
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
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
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
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)
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
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)
Sets the maximum number of entries a user can have for their nickname group's memo ignore list.
Example: MSIgnoreMax 32
Specifies the nickname (first parameter) and "real" name (second parameter) used by the StatServ pseudoclient.
Example: StatServName "StatServ" "Statistics Server"
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"
Limits the use of StatServ to IRC operators only.
Example: SSOpersOnly
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.
Note that many systems restrict low port numbers to the system administrator; in particular, Unix-like systems allow only the root user (UID 0) to use ports less than 1024.
Example: ListenTo 127.0.0.1:12701
Example: ListenTo services.example.net:8080
Example: ListenTo *:80
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
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
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
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
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
If given, a log message will be written for each connection to the server.
Example: LogConnections
httpd/auth-ip (IP address authorization module)
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.1deny access to all hosts in the 192.168.0.* network except 192.168.0.1. However, the reverse:
DenyHost / 192.168.0.0/24
DenyHost / 192.168.0.0/24simply blocks all hosts in the 192.168.0.* network, since the first rule matches 192.168.0.1 and the second is never checked.
AllowHost / 192.168.0.1
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)
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"
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.
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 |
| path/xml-export/ | XML-format database download |
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)
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)
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 "/~"
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)
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
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/
misc/devnull (DevNull settings)
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)
Specifies the nickname (first parameter) and "real" name (second parameter) used by the HelpServ pseudoclient.
Example: HelpServName "HelpServ" "Help Server"
Specifies the name of the subdirectory containing help files for HelpServ.
Example: HelpDir helpfiles
misc/xml-export (XML export settings)
This module has no configurable settings.
misc/xml-import (XML import settings)
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), "overwrite" (drop the existing 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.
When using "overwrite", if a nickname group has only one nickname and that nickname is overwritten, the nickname group will be dropped as well. As a consequence, any channels owned by such a nickname will be dropped (or shifted to their successors) as well. All nicknames and channels overwritten or droppde in this manner will be displayed on standard error.
If not specified, defaults to "skipgroup".
Example: OnNicknameCollision skipgroup
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), "overwrite" (drop the existing channel), 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
Causes a detailed list of imported nicknames, channels, and other data to be printed to standard output.
Example: VerboseImport