0
0
Fork 0
mirror of https://github.com/matrix-construct/construct synced 2024-11-27 01:02:46 +01:00
construct/doc/sgml/oper-guide/umodes.sgml
jilles e7d250a693 [svn] Merge old trunk r2059
Clarifications to the descriptions of umode +Q and cmode +F,
suggested by Ariadne@SorceryNet.
2007-03-28 08:30:56 -07:00

334 lines
10 KiB
Text

<chapter id="umodes">
<title>Umodes</title>
<sect1 id="umodelist">
<title>Meanings of user modes</title>
<sect2>
<title>+a, server administrator</title>
<para>
This vanity usermode is used to denote a server administrator in WHOIS output.
All local <quote>admin</quote> privileges are independent of it, though services
packages may grant extra privileges to +a users.
</para>
</sect2>
<sect2>
<title>+D, deaf</title>
<para>
<note>
<para>
This is a user umode, which anybody can set. It is not specific to operators.
</para>
</note>
Users with the +D umode set will not receive messages sent to
channels. Joins, parts, topic changes, mode changes, etc are
received as normal, as are private messages.
</para>
<para>
Support of this umode is indicated by the DEAF token in
RPL_ISUPPORT (005); the parameter indicates the letter
of the umode. Note that several common IRCD implementations have
an umode like this (typically +d) but do not have the token in 005.
</para>
</sect2>
<sect2>
<title>+g, Caller ID</title>
<para>
<note>
<para>
This is a user umode, which anybody can set. It is not specific to operators.
</para>
</note>
Users with the +g umode set will only receive private messages from users on a
session-defined whitelist, defined by the /accept command. If a user who is not
on the whitelist attempts to send a private message, the target user will receive a rate-limited notice saying that the user
wishes to speak to them.
</para>
<para>
Network operators are not affected by the callerid whitelist system in the event
that they need to speak to users who have it enabled.
</para>
<para>
Support of this umode is indicated by the CALLERID token in
RPL_ISUPPORT (005); the optional parameter indicates the letter
of the umode, otherwise +g.
</para>
</sect2>
<sect2>
<title>+i, invisible</title>
<para>
<note>
<para>
This is a user umode, which anybody can set. It is not specific to operators.
</para>
</note>
Invisible users do not show up in WHO and NAMES unless you can see them.
</para>
</sect2>
<!-- not planned (jilles)
<sect2>
<title>+I, refuse invite</title>
<para>
<note>
<para>
This is a user umode, which anybody can set. It is not specific to operators.
</para>
</note>
If you have the +I umode set, nobody will be able to issue an INVITE to let you
in to a channel.
</para>
<para>
This mode is not yet implemented. It will be implemented in Charybdis 1.1.
</para>
</sect2>
-->
<sect2>
<title>+l, receive locops</title>
<para>
LOCOPS is a version of OPERWALL that is sent to opers on a single
server only. With cluster{} and shared{} blocks they can optionally
be propagated further.
</para>
<para>
Unlike OPERWALL, any oper can send and receive LOCOPS.
</para>
</sect2>
<sect2>
<title>+o, operator</title>
<para>
This indicates global operator status.
</para>
</sect2>
<sect2>
<title>+Q, disable forwarding</title>
<para>
<note>
<para>
This is a user umode, which anybody can set. It is not specific to operators.
</para>
</note>
This umode prevents you from being affected by channel forwarding.
If enabled on a channel, channel forwarding sends you to another
channel if you could not join. See channel mode +f for more
information.
</para>
</sect2>
<sect2>
<title>+R, reject messages from unauthenticated users</title>
<para>
<note>
<para>
This is a user umode, which anybody can set. It is not specific to operators.
</para>
</note>
If a user has the +R umode set, then any users who are not authenticated
will receive an error message if they attempt to send a private
message or notice to the +R user.
</para>
<para>
Opers and accepted users (like in +g) are exempt.
Unlike +g, the target user is not notified of failed messages.
</para>
</sect2>
<sect2>
<title>+s, receive server notices</title>
<para>
This umode allows an oper to receive server notices.
The requested types of server notices are specified as a
parameter (<quote>snomask</quote>) to this umode.
</para>
</sect2>
<sect2>
<title>+S, network service</title>
<para>
<note>
<para>
This umode can only be set by servers named in a service{}
block.
</para>
</note>
This umode grants various features useful for services. For example,
clients with this umode cannot be kicked or deopped on channels,
do not show channels the querying user is not on in WHOIS,
and do not appear in /stats p.
</para>
<para>
The exact effects of this umode are variable; no user or oper on
an actual charybdis server can set it.
</para>
</sect2>
<sect2>
<title>+w, receive wallops</title>
<para>
<note>
<para>
This is a user umode, which anybody can set. It is not specific to operators.
</para>
</note>
Users with the +w umode set will receive WALLOPS messages sent by opers.
Opers with +w additionally receive WALLOPS sent by servers (e.g.
remote CONNECT, remote SQUIT, many services packages).
</para>
</sect2>
<sect2>
<title>+z, receive operwall</title>
<para>
OPERWALL differs from WALLOPS in that the ability to receive such messages is
restricted. Opers with +z set will receive OPERWALL messages.
</para>
</sect2>
</sect1>
<sect1 id="snomaskusage">
<title>Snomask usage</title>
<para>
Usage is as follows:
</para>
<cmdsynopsis><command>MODE</command>
<arg choice=plain><replaceable>nick</replaceable></arg>
<arg choice=plain>+s</arg>
<arg choice=plain><replaceable>+/-flags</replaceable></arg>
</cmdsynopsis>
<para>
To set snomasks.
</para>
<cmdsynopsis><command>MODE</command>
<arg choice=plain><replaceable>nick</replaceable></arg>
<arg choice=plain>-s</arg>
</cmdsynopsis>
<para>
To clear all snomasks.
</para>
<para>
Umode +s will be set if at least one snomask is set.
</para>
<para>
Umode +s is oper only by default, but even if you allow nonopers to
set it, they will not get any server notices.
</para>
</sect1>
<sect1 id="snomasklist">
<title>Meanings of server notice masks</title>
<sect2>
<title>+b, bot warnings</title>
<para>
Opers with the +b snomask set will receive warning messages from the server when potential
flooders and spambots are detected.
</para>
</sect2>
<sect2>
<title>+c, client connections</title>
<para>
Opers who have the +c snomask set will receive server notices when clients attach to the
local server.
</para>
</sect2>
<sect2>
<title>+C, extended client connection notices</title>
<para>
Opers who have the +C snomask set will receive server notices when clients attach to the
local server. Unlike the +c snomask, the information is displayed in a format intended
to be parsed by scripts, and includes the two unused fields of the USER command.
</para>
</sect2>
<sect2>
<title>+d, debug</title>
<para>
The +d snomask provides opers extra information which may be of interest to debuggers.
It will also cause the user to receive server notices if certain assertions fail inside the
server. Its precise meaning is variable. Do not depend on the
effects of this snomask as they can and will change without notice in later revisions.
</para>
</sect2>
<sect2>
<title>+f, full warning</title>
<para>
Opers with the +f snomask set will receive notices when a user
connection is denied because a connection limit is exceeded
(one of the limits in a class{} block, or the total per-server
limit settable with /quote set max).
</para>
</sect2>
<sect2>
<title>+k, server kill notices</title>
<para>
Opers with the +k snomask set will receive server notices when
services kill users and when
other servers kill and save (forced nick change to UID) users.
Kills and saves by this server are on +d or +s.
</para>
</sect2>
<sect2>
<title>+n, nick change notices</title>
<para>
An oper with +n set will receive a server notice every time a local user changes their nick,
giving the old and new nicks.
This is mostly useful for bots that track all users on a single server.
</para>
</sect2>
<sect2>
<title>+r, notices on name rejections</title>
<para>
Opers with this snomask set will receive a server notice when somebody tries to use an
invalid username, or if a dumb HTTP proxy tries to connect.
</para>
</sect2>
<sect2>
<title>+s, generic server notices</title>
<para>
This snomask allows an oper to receive generic server notices.
This includes kills from opers (except services).
</para>
</sect2>
<sect2>
<title>+u, unauthorized connections</title>
<para>
This snomask allows an oper to see when users try to connect who do not have an
available auth{} block.
</para>
</sect2>
<sect2>
<title>+x, extra routing notices</title>
<para>
Opers who have the +x snomask set will get notices about servers
connecting and disconnecting on the whole network. This includes
all servers connected behind the affected link. This can get
rather noisy but is useful for keeping track of all linked
servers.
</para>
</sect2>
<sect2>
<title>+y, spy</title>
<para>
Opers with +y receive notices when users try to join RESV'ed (<quote>juped</quote>) channels.
Additionally, if certain extension modules are loaded, they will
receive notices when special commands are used and/or when they
are whoised.
</para>
</sect2>
<sect2>
<title>+Z, operspy notices</title>
<para>
Opers with +Z receive notices whenever an oper anywhere on the
network uses operspy.
</para>
<para>
This snomask can be configured to be only effective for admins.
</para>
</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: ("charybdis-oper-guide.sgml" "book")
sgml-exposed-tags:nil
fill-column: 105
sgml-validate-command: "nsgmls -e -g -s -u charybdis-oper-guide.sgml"
End:
-->