2007-01-25 07:40:21 +01:00
<chapter id="config">
<title>Server config file format</title>
<sect1>
<title>General format</title>
<para>
The config file consists of a series of BIND-style blocks. Each block consists of a series
of values inside it which pertain to configuration settings that apply to the given block.
</para>
<para>
Several values take lists of values and have defaults preset inside
them. Prefix a keyword with a tilde (~) to override the default and
disable it.
</para>
<para>
A line may also be a .include directive, which is of the form <synopsis>.include "<replaceable>file</replaceable>"</synopsis>
and causes <replaceable>file</replaceable> to be read in at that point, before the rest of the current file is
processed.
Relative paths are first tried relative to PREFIX and then relative
to ETCPATH (normally PREFIX/etc).
</para>
<para>
Anything from a # to the end of a line is a comment. Blank lines are ignored. C-style comments are also supported.
</para>
</sect1>
<sect1 id="configlines">
<title>Specific blocks and directives</title>
<para>
Not all configuration blocks and directives are listed here, only the most common ones. More blocks and directives will
be documented in later revisions of this manual.
</para>
<sect2>
<title>loadmodule directive</title>
<synopsis>
loadmodule "<replaceable>text</replaceable>";</synopsis>
<para>
Loads a module into the IRCd. In charybdis 1.1, most modules are automatically loaded in. In future versions, it is
intended to remove this behaviour as to allow for easy customization of the IRCd's featureset.
</para>
</sect2>
<sect2>
<title>serverinfo {} block</title>
<synopsis>
serverinfo {
name = "<replaceable>text</replaceable>";
sid = "<replaceable>text</replaceable>";
description = "<replaceable>text</replaceable>";
network_name = "<replaceable>text</replaceable>";
network_desc = "<replaceable>text</replaceable>";
hub = <replaceable>boolean</replaceable>;
vhost = "<replaceable>text</replaceable>";
vhost6 = "<replaceable>text</replaceable>";
};</synopsis>
<para>
The serverinfo {} block defines the core operational parameters of the IRC server.
</para>
<variablelist>
<title>serverinfo {} variables</title>
<varlistentry>
<term>name</term>
<listitem>
<para>
The name of the IRC server that you are configuring. This
must contain at least one dot. It is not necessarily equal
to any DNS name. This must be unique on the IRC network.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>sid</term>
<listitem>
<para>
2007-09-06 22:30:22 +02:00
A unique ID which describes the server.
2007-01-25 07:40:21 +01:00
This consists of one digit and two characters which can be
digits or letters.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>description</term>
<listitem>
<para>
A user-defined field of text which describes the IRC server. This information is used in
/links and /whois requests. Geographical location information could be a useful use of
this field, but most administrators put a witty saying inside it instead.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>network_name</term>
<listitem>
<para>
The name of the IRC network that this server will be a member of.
This is used in the welcome message and NETWORK= in 005.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>network_desc</term>
<listitem>
<para>
A description of the IRC network that this server will be a member of.
This is currently unused.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>hub</term>
<listitem>
<para>
A boolean which defines whether or not this IRC server will be serving as a hub, i.e. have multiple servers connected to it.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>vhost</term>
<listitem>
<para>
An optional text field which defines an IP from which to connect outward to other IRC servers.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>vhost6</term>
<listitem>
<para>
An optional text field which defines an IPv6 IP from which to connect outward to other IRC servers.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>admin {} block</title>
<synopsis>
admin {
name = "<replaceable>text</replaceable>";
description = "<replaceable>text</replaceable>";
email = "<replaceable>text</replaceable>";
};</synopsis>
<para>
This block provides the information which is returned by the ADMIN command.
</para>
<variablelist>
<title>admin {} variables</title>
<varlistentry>
<term>name</term>
<listitem>
<para>The name of the administrator running this service.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>description</term>
<listitem>
<para>The description of the administrator's position in the network.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>email</term>
<listitem>
<para>A point of contact for the administrator, usually an e-mail address.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>class {} block</title>
<synopsis>
class "<replaceable>name</replaceable>" {
ping_time = <replaceable>duration</replaceable>;
number_per_ident = <replaceable>number</replaceable>;
number_per_ip = <replaceable>number</replaceable>;
number_per_ip_global = <replaceable>number</replaceable>;
cidr_bitlen = <replaceable>number</replaceable>;
number_per_cidr = <replaceable>number</replaceable>;
max_number = <replaceable>number</replaceable>;
sendq = <replaceable>size</replaceable>;
};</synopsis>
<synopsis>
class "<replaceable>name</replaceable>" {
ping_time = <replaceable>duration</replaceable>;
connectfreq = <replaceable>duration</replaceable>;
max_number = <replaceable>number</replaceable>;
sendq = <replaceable>size</replaceable>;
};</synopsis>
<para>
Class blocks define classes of connections for later use.
The class name is used to connect them to
other blocks in the config file (auth{} and connect{}).
They must be defined before they are used.
</para>
<para>
Classes are used both for client and server connections,
but most variables are different.
</para>
<variablelist>
<title>class {} variables: client classes</title>
<varlistentry>
<term>ping_time</term>
<listitem>
<para>The amount of time between checking pings for clients, e.g.: 2 minutes</para>
</listitem>
</varlistentry>
<varlistentry>
<term>number_per_ident</term>
<listitem>
<para>The amount of clients which may be connected from a single identd username on a per-IP basis, globally. Unidented clients all count as the same username.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>number_per_ip</term>
<listitem>
<para>The amount of clients which may be connected from a single IP address.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>number_per_ip_global</term>
<listitem>
<para>The amount of clients which may be connected globally from a single IP address.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>cidr_bitlen</term>
<listitem>
<para>The netblock length to use with CIDR-based client limiting for this class.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>number_per_cidr</term>
<listitem>
<para>The amount of clients which may be connected from a single netblock.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>max_number</term>
<listitem>
<para>The maximum amount of clients which may use this class at any given time.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>sendq</term>
<listitem>
<para>The maximum size of the queue of data to be sent to a client before it is dropped.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>class {} variables: server classes</title>
<varlistentry>
<term>ping_time</term>
<listitem>
<para>The amount of time between checking pings for servers, e.g.: 2 minutes</para>
</listitem>
</varlistentry>
<varlistentry>
<term>connectfreq</term>
<listitem>
<para>The amount of time between autoconnects. This must at least be one minute, as autoconnects are evaluated with that granularity.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>max_number</term>
<listitem>
<para>The amount of servers to autoconnect to in this class. More precisely, no autoconnects are done if the number of servers in this class is greater than or equal max_number</para>
</listitem>
</varlistentry>
<varlistentry>
<term>sendq</term>
<listitem>
<para>The maximum size of the queue of data to be sent to a server before it is dropped.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>auth {} block</title>
<synopsis>
auth {
user = "<replaceable>hostmask</replaceable>";
password = "<replaceable>text</replaceable>";
spoof = "<replaceable>text</replaceable>";
flags = <replaceable>list</replaceable>;
class = "<replaceable>text</replaceable>";
};</synopsis>
<para>
auth {} blocks allow client connections to the server, and set various properties concerning those connections.
</para>
<para>
Auth blocks are evaluated from top to bottom in priority, so put special blocks first.
</para>
<variablelist>
<title>auth {} variables</title>
<varlistentry>
<term>user</term>
<listitem>
2007-08-30 00:18:31 +02:00
<para>
A hostmask (user@host) that the auth {} block applies to.
It is matched against the hostname and IP address (using ::
shortening for IPv6 and prepending a 0 if it starts with
a colon) and can also use CIDR masks.
You can have multiple user entries.
</para>
2007-01-25 07:40:21 +01:00
</listitem>
</varlistentry>
<varlistentry>
<term>password</term>
<listitem>
<para>
An optional password to use for authenticating into this auth{}
block. If the password is wrong the user will not be able to
connect (will not fall back on another auth{} block).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>spoof</term>
<listitem>
<para>An optional fake hostname (or user@host) to apply to users authenticated to this auth{} block.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>flags</term>
<listitem>
<para>A list of flags to apply to this auth{} block. They are listed below.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>class</term>
<listitem>
<para>A name of a class to put users matching this auth{} block into.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>auth {} flags</title>
<varlistentry>
<term>encrypted</term>
<listitem>
<para>The password used has been encrypted.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>spoof_notice</term>
<listitem>
<para>Causes the IRCd to send out a server notice when activating a spoof provided by this auth{} block.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>exceed_limit</term>
<listitem>
<para>Users in this auth{} block can exceed class-wide limitations.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>dnsbl_exempt</term>
<listitem>
<para>Users in this auth{} block are exempted from DNS blacklist checks. However, they will still be warned if they are listed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>kline_exempt</term>
<listitem>
<para>Users in this auth{} block are exempted from DNS blacklists, k:lines, g:lines and x:lines, and will not be disconnected because of d:lines.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>gline_exempt</term>
<listitem>
<para>Users in this auth{} block are exempted from g:lines.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>spambot_exempt</term>
<listitem>
<para>Users in this auth{} block are exempted from spambot checks.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>shide_exempt</term>
<listitem>
<para>Users in this auth{} block are exempted from some serverhiding effects.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>jupe_exempt</term>
<listitem>
<para>Users in this auth{} block do not trigger an alarm when joining juped channels.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>resv_exempt</term>
<listitem>
<para>Users in this auth{} block may use reserved nicknames and channels.</para>
<note><para>The initial nickname may still not be reserved.</para></note>
</listitem>
</varlistentry>
<varlistentry>
<term>flood_exempt</term>
<listitem>
<para>
Users in this auth{} block may send arbitrary amounts of
commands per time unit to the server. This does not exempt
them from any other flood limits.
You should use this setting with caution.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>no_tilde</term>
<listitem>
<para>Users in this auth{} block will not have a tilde added to their username if they do not run identd.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>need_ident</term>
<listitem>
<para>Users in this auth{} block must have identd, otherwise they will be rejected.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>need_sasl</term>
<listitem>
<para>Users in this auth{} block must identify via SASL, otherwise they will be rejected.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>exempt {} block</title>
<synopsis>
exempt {
ip = "<replaceable>ip</replaceable>";
};</synopsis>
<para>
2007-05-18 22:31:33 +02:00
An exempt block specifies IP addresses which are exempt from D:lines
and throttling.
2007-01-25 07:40:21 +01:00
Multiple addresses can be specified in one block.
Clients coming from these addresses can still be K/G/X:lined or
banned by a DNS blacklist unless
they also have appropriate flags in their auth{} block.
</para>
<variablelist>
<title>exempt {} variables</title>
<varlistentry>
<term>ip</term>
<listitem>
<para>The IP address or CIDR range to exempt.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>operator {} block</title>
<synopsis>
operator "<replaceable>name</replaceable>" {
user = "<replaceable>hostmask</replaceable>";
password = "<replaceable>text</replaceable>";
rsa_public_key_file = "<replaceable>text</replaceable>";
umodes = <replaceable>list</replaceable>;
snomask = "<replaceable>text</replaceable>";
flags = <replaceable>list</replaceable>;
};</synopsis>
<para>
Operator blocks define who may use the OPER command to gain extended privileges.
</para>
<variablelist>
<title>operator {} variables</title>
<varlistentry>
<term>user</term>
<listitem>
<para>
A hostmask that users trying to use this operator {} block
must match. This is checked against the original host and IP
address; CIDR is also supported. So auth {} spoofs work in
operator {} blocks; the real host behind them is not checked.
Other kind of spoofs do not work in operator {} blocks; the
real host behind them is checked.
</para>
<para>
Note that this is different from charybdis 1.x where all
kinds of spoofs worked in operator {} blocks.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>password</term>
<listitem>
<para>
A password used with the OPER command to use this operator {} block.
Passwords are encrypted by default, but may be unencrypted if ~encrypted is present
in the flags list.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>rsa_public_key_file</term>
<listitem>
<para>
An optional path to a RSA public key file associated with the operator {} block.
This information is used by the CHALLENGE command, which is an alternative authentication
scheme to the traditional OPER command.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>umodes</term>
<listitem>
<para>A list of usermodes to apply to successfully opered clients.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>snomask</term>
<listitem>
<para>
An snomask to apply to successfully opered clients.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>flags</term>
<listitem>
<para>
A listing of privileges granted to operators using this block.
By default, the operwall and remoteban privileges are granted;
use ~operwall and ~remoteban to disable them if necessary.
</para>
<para>
In addition, a flag designating if the password is encrypted is here.
Privileges are documented elsewhere in this guide.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>connect {} block</title>
<synopsis>
connect "<replaceable>name</replaceable>" {
host = "<replaceable>text</replaceable>";
send_password = "<replaceable>text</replaceable>";
accept_password = "<replaceable>text</replaceable>";
port = <replaceable>number</replaceable>;
hub_mask = "<replaceable>mask</replaceable>";
leaf_mask = "<replaceable>mask</replaceable>";
class = "<replaceable>text</replaceable>";
flags = <replaceable>list</replaceable>;
aftype = <replaceable>protocol</replaceable>;
};</synopsis>
<para>
Connect blocks define what servers may connect or be connected to.
</para>
<variablelist>
<title>connect {} variables</title>
<varlistentry>
<term>host</term>
<listitem>
<para>The hostname or IP to connect to.</para>
<note><para>
Charybdis uses solely DNS for all hostname/address lookups
(no <filename>/etc/hosts</filename> or anything else).
Furthermore, if a hostname is used, it must have an A or AAAA
record (no CNAME) and it must be the primary
hostname for inbound connections to work.
2007-08-30 00:18:31 +02:00
</para><para>
IPv6 addresses must be in :: shortened form; addresses which
then start with a colon must be prepended with a zero,
for example 0::1.
2007-01-25 07:40:21 +01:00
</para></note>
</listitem>
</varlistentry>
<varlistentry>
<term>send_password</term>
<listitem>
<para>The password to send to the other server.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>accept_password</term>
<listitem>
<para>The password that should be accepted from the other server.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>port</term>
<listitem>
<para>The port on the other server to connect to.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>hub_mask</term>
<listitem>
<para>
An optional domain mask of servers allowed to be introduced
by this link. Usually, "*" is fine. Multiple hub_masks may be
specified, and any of them may be introduced.
Violation of hub_mask and leaf_mask restrictions will
cause the local link to be closed.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>leaf_mask</term>
<listitem>
<para>
An optional domain mask of servers not allowed to be
introduced by this link. Multiple leaf_masks may be specified,
and none of them may be introduced. leaf_mask has priority
over hub_mask.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>class</term>
<listitem>
<para>The name of the class this server should be placed into.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>flags</term>
<listitem>
<para>A list of flags concerning the connect block. They are listed below.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>aftype</term>
<listitem>
<para>The protocol that should be used to connect with, either ipv4 or ipv6. This defaults to ipv4 unless host is a numeric IPv6 address.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>connect {} flags</title>
<varlistentry>
<term>encrypted</term>
<listitem>
<para>The value for accept_password has been encrypted.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>autoconn</term>
<listitem>
<para>
The server should automatically try to connect to the server defined in this
connect {} block if it's not connected already and max_number
in the class is not reached yet.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>compressed</term>
<listitem>
<para>Ziplinks should be used with this server connection.
This compresses traffic using zlib, saving some bandwidth
and speeding up netbursts.</para>
<para>If you have trouble setting up a link, you should
turn this off as it often hides error messages.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>topicburst</term>
<listitem>
<para>Topics should be bursted to this server.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>listen {} block</title>
<synopsis>
listen {
host = "<replaceable>text</replaceable>";
port = <replaceable>number</replaceable>;
};</synopsis>
<para>
A listen block specifies what ports a server should listen on.
</para>
<variablelist>
<title>listen {} variables</title>
<varlistentry>
<term>host</term>
<listitem>
<para>An optional host to bind to. Otherwise, the ircd will listen on all available hosts.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>port</term>
<listitem>
<para>
A port to listen on. You can specify multiple ports via commas, and define a range by seperating
the start and end ports with two dots (..).
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>modules {} block</title>
<synopsis>
modules {
path = "<replaceable>text</replaceable>";
module = <replaceable>text</replaceable>;
};</synopsis>
<para>
The modules block specifies information for loadable modules.
</para>
<variablelist>
<title>modules {} variables</title>
<varlistentry>
<term>path</term>
<listitem>
<para>Specifies a path to search for loadable modules.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>module</term>
<listitem>
<para>
Specifies a module to load, similar to loadmodule.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>general {} block</title>
<synopsis>
modules {
<replaceable>values</replaceable>
};</synopsis>
<para>
The general block specifies a variety of options, many of which
were in <filename>config.h</filename> in older daemons.
The options are documented in <filename>reference.conf</filename>.
</para>
</sect2>
<sect2>
<title>channel {} block</title>
<synopsis>
modules {
<replaceable>values</replaceable>
};</synopsis>
<para>
The channel block specifies a variety of channel-related options,
many of which were in <filename>config.h</filename> in older daemons.
The options are documented in <filename>reference.conf</filename>.
</para>
</sect2>
<sect2>
<title>serverhide {} block</title>
<synopsis>
modules {
<replaceable>values</replaceable>
};</synopsis>
<para>
The serverhide block specifies options related to server hiding.
The options are documented in <filename>reference.conf</filename>.
</para>
</sect2>
<sect2>
<title>blacklist {} block</title>
<synopsis>
blacklist {
host = "<replaceable>text</replaceable>";
reject_reason = "<replaceable>text</replaceable>";
};</synopsis>
<para>
The blacklist block specifies DNS blacklists to check.
Listed clients will not be allowed to connect.
IPv6 clients are not checked against these.
</para>
<para>
Multiple blacklists can be specified, in pairs with first host
then reject_reason.
</para>
<variablelist>
<title>blacklist {} variables</title>
<varlistentry>
<term>host</term>
<listitem>
<para>The DNSBL to use.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>reject_reason</term>
<listitem>
<para>The reason to send to listed clients when disconnecting them.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>alias {} block</title>
<synopsis>
alias "<replaceable>name</replaceable>" {
target = "<replaceable>text</replaceable>";
};</synopsis>
<para>
Alias blocks allow the definition of custom commands.
These commands send PRIVMSG to the given target. A real
command takes precedence above an alias.
</para>
<variablelist>
<title>alias {} variables</title>
<varlistentry>
<term>target</term>
<listitem>
<para>
The target nick (must be a network service (umode +S)) or
user@server.
In the latter case, the server cannot be this server,
only opers can use user starting with "opers" reliably and
the user is interpreted on the target server only
so you may need to use nick@server instead).
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>cluster {} block</title>
<synopsis>
cluster {
name = "<replaceable>text</replaceable>";
flags = <replaceable>list</replaceable>;
};</synopsis>
<para>
The cluster block specifies servers we propagate things to
automatically.
This does not allow them to set bans, you need a separate shared{}
block for that.
</para>
<para>
Having overlapping cluster{} items will cause the command to
be executed twice on the target servers. This is particularly
undesirable for ban removals.
</para>
<para>
The letters in parentheses denote the flags in /stats U.
</para>
<variablelist>
<title>cluster {} variables</title>
<varlistentry>
<term>name</term>
<listitem>
<para>The server name to share with, this may contain wildcards
and may be stacked.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>flags</term>
<listitem>
<para>The list of what to share, all the name lines above this
(up to another flags entry) will receive these flags.
They are listed below.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>cluster {} flags</title>
<varlistentry>
<term>kline (K)</term>
<listitem>
<para>Permanent K:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>tkline (k)</term>
<listitem>
<para>Temporary K:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>unkline (U)</term>
<listitem>
<para>K:line removals</para>
</listitem>
</varlistentry>
<varlistentry>
<term>xline (X)</term>
<listitem>
<para>Permanent X:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>txline (x)</term>
<listitem>
<para>Temporary X:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>unxline (Y)</term>
<listitem>
<para>X:line removals</para>
</listitem>
</varlistentry>
<varlistentry>
<term>resv (Q)</term>
<listitem>
<para>Permanently reserved nicks/channels</para>
</listitem>
</varlistentry>
<varlistentry>
<term>tresv (q)</term>
<listitem>
<para>Temporarily reserved nicks/channels</para>
</listitem>
</varlistentry>
<varlistentry>
<term>unresv (R)</term>
<listitem>
<para>RESV removals</para>
</listitem>
</varlistentry>
<varlistentry>
<term>locops (L)</term>
<listitem>
<para>LOCOPS messages (sharing this with * makes LOCOPS rather
similar to OPERWALL which is not useful)</para>
</listitem>
</varlistentry>
<varlistentry>
<term>all</term>
<listitem>
<para>All of the above</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>shared {} block</title>
<synopsis>
shared {
oper = "<replaceable>user@host</replaceable>", "<replaceable>server</replaceable>";
flags = <replaceable>list</replaceable>;
};</synopsis>
<para>
The shared block specifies opers allowed to perform certain actions
on our server remotely.
These are ordered top down. The first one matching will determine
the oper's access.
If access is denied, the command will be silently ignored.
</para>
<para>
The letters in parentheses denote the flags in /stats U.
</para>
<variablelist>
<title>shared {} variables</title>
<varlistentry>
<term>oper</term>
<listitem>
<para>The user@host the oper must have, and the server they must
be on. This may contain wildcards.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>flags</term>
<listitem>
<para>The list of what to allow, all the oper lines above this
(up to another flags entry) will receive these flags.
They are listed below.</para>
</listitem>
</varlistentry>
</variablelist>
<note><para>
While they have the same names, the flags have subtly different
meanings from those in the cluster{} block.
</para></note>
<variablelist>
<title>shared {} flags</title>
<varlistentry>
<term>kline (K)</term>
<listitem>
<para>Permanent and temporary K:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>tkline (k)</term>
<listitem>
<para>Temporary K:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>unkline (U)</term>
<listitem>
<para>K:line removals</para>
</listitem>
</varlistentry>
<varlistentry>
<term>xline (X)</term>
<listitem>
<para>Permanent and temporary X:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>txline (x)</term>
<listitem>
<para>Temporary X:lines</para>
</listitem>
</varlistentry>
<varlistentry>
<term>unxline (Y)</term>
<listitem>
<para>X:line removals</para>
</listitem>
</varlistentry>
<varlistentry>
<term>resv (Q)</term>
<listitem>
<para>Permanently and temporarily reserved nicks/channels</para>
</listitem>
</varlistentry>
<varlistentry>
<term>tresv (q)</term>
<listitem>
<para>Temporarily reserved nicks/channels</para>
</listitem>
</varlistentry>
<varlistentry>
<term>unresv (R)</term>
<listitem>
<para>RESV removals</para>
</listitem>
</varlistentry>
<varlistentry>
<term>all</term>
<listitem>
<para>All of the above; this does not include locops or rehash</para>
</listitem>
</varlistentry>
<varlistentry>
<term>locops (L)</term>
<listitem>
<para>LOCOPS messages (accepting this from * makes LOCOPS rather
similar to OPERWALL which is not useful); unlike the other flags,
this can only be accepted from *@* although it can be
restricted based on source server.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>rehash (H)</term>
<listitem>
<para>REHASH commands; all options can be used</para>
</listitem>
</varlistentry>
<varlistentry>
<term>none</term>
<listitem>
<para>Allow nothing to be done</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2>
<title>service {} block</title>
<synopsis>
service {
name = "<replaceable>text</replaceable>";
};</synopsis>
<para>
The service block specifies privileged servers (services). These
servers have extra privileges such as setting login names on users
and introducing clients with umode +S (unkickable, hide channels, etc).
This does not allow them to set bans, you need a separate shared{}
block for that.
</para>
<para>
Do not place normal servers here.
</para>
<para>
Multiple names may be specified but there may be only one service{}
block.
</para>
<variablelist>
<title>service {} variables</title>
<varlistentry>
<term>name</term>
<listitem>
<para>The server name to grant special privileges. This may not
contain wildcards.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document: ("dancer-oper-guide.sgml" "book")
sgml-exposed-tags:nil
fill-column:105
sgml-validate-command: "nsgmls -e -g -s -u dancer-oper-guide.sgml"
End:
-->
