9pfs/solanum-vs-hackint-and-charybdis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
solanum-vs-hackint-and-char.../doc/oper-guide/umodes.rst
Antoine Beaupré 2874f74c81
convert SGML guide to RST 
the rationale behind switching away from SGML/Docbook is the following:

 * SGML is hard to edit for humans
 * the output is not much prettier
 * the toolchain is not well supported and missing from the build
 * the build is not hooked into anywhere, no automation

the reason why RST was chosen:

 * it allows for a strong structure like Docbook
 * the theme from Read The Docs is pretty
 * it also supports mobile devices
 * sphinx can easily output to PDF and ePUB formats
 * RST is plaintext that can be easily edited and diff'd
 * RST can be automatically built by ReadTheDocs and the toolchain is
   readily available
 * the output is also parsed by Github so documentation can be read
   straight from GH

the reason why Markdown was not chosen:

 * the current strong structure would be hard to replicate
 * markdown is not standardized and output varies according to the
   implementation

the docs were converted with Pandoc, using the following commands:

    mkdir oper-guide
    for source in sgml/oper-guide/*.sgml; do
        pandoc --toc -s -f docbook -t rst $source -o oper-guide/$(basename $source .sgml).rst
    done
    cd oper-guide
    sphinx-quickstart
    git add *.rst make.bat conf.py
    git add -f Makefile
    git rm -r ../sgml
2017-03-25 10:51:01 -04:00

301 lines
8.5 KiB
ReStructuredText
Raw Blame History

.. contents::
:depth: 3
..
Umodes
======
Meanings of user modes
======================
+a, server administrator
------------------------
This vanity usermode is used to denote a server administrator in WHOIS
output. All local “admin” privileges are independent of it, though
services packages may grant extra privileges to +a users.
+D, deaf
--------
**Note**
This is a user umode, which anybody can set. It is not specific to
operators.
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.
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.
+g, Caller ID
-------------
**Note**
This is a user umode, which anybody can set. It is not specific to
operators.
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.
Network operators are not affected by the callerid whitelist system in
the event that they need to speak to users who have it enabled.
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.
+i, invisible
-------------
**Note**
This is a user umode, which anybody can set. It is not specific to
operators.
Invisible users do not show up in WHO and NAMES unless you can see them.
+l, receive locops
------------------
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.
Unlike OPERWALL, any oper can send and receive LOCOPS.
+o, operator
------------
This indicates global operator status.
+Q, disable forwarding
----------------------
**Note**
This is a user umode, which anybody can set. It is not specific to
operators.
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.
+R, reject messages from unauthenticated users
----------------------------------------------
**Note**
This is a user umode, which anybody can set. It is not specific to
operators.
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.
Opers and accepted users (like in +g) are exempt. Unlike +g, the target
user is not notified of failed messages.
+s, receive server notices
--------------------------
This umode allows an oper to receive server notices. The requested types
of server notices are specified as a parameter (“snomask”) to this
umode.
+S, network service
-------------------
**Note**
This umode can only be set by servers named in a service{} block.
This umode grants various features useful for services. For example,
clients with this umode cannot be kicked or deopped on channels, can
send to any channel, do not show channels in WHOIS, can be the target of
services aliases and do not appear in /stats p. No server notices are
sent for hostname changes by services clients; server notices about
kills are sent to snomask +k instead of +s.
The exact effects of this umode are variable; no user or oper on an
actual charybdis server can set it.
+w, receive wallops
-------------------
**Note**
This is a user umode, which anybody can set. It is not specific to
operators.
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, various severe misconfigurations, many services
packages).
+z, receive operwall
--------------------
OPERWALL differs from WALLOPS in that the ability to receive such
messages is restricted. Opers with +z set will receive OPERWALL
messages.
+Z, SSL user
------------
This umode is set on clients connected via SSL/TLS. It cannot be set or
unset after initial connection.
Snomask usage
=============
Usage is as follows:
MODE
nick
+s
+/-flags
To set snomasks.
MODE
nick
-s
To clear all snomasks.
Umode +s will be set if at least one snomask is set.
Umode +s is oper only by default, but even if you allow nonopers to set
it, they will not get any server notices.
Meanings of server notice masks
===============================
+b, bot warnings
----------------
Opers with the +b snomask set will receive warning messages from the
server when potential flooders and spambots are detected.
+c, client connections
----------------------
Opers who have the +c snomask set will receive server notices when
clients attach to the local server.
+C, extended client connection notices
--------------------------------------
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.
+d, debug
---------
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.
+f, full warning
----------------
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).
+F, far client connection notices
---------------------------------
**Note**
This snomask is only available if the ``sno_farconnect.so``
extension is loaded.
Opers with +F receive server notices when clients connect or disconnect
on other servers. The notices have the same format as those from the +c
snomask, except that the class is ? and the source server of the notice
is the server the user is/was on.
No notices are generated for netsplits and netjoins. Hence, these
notices cannot be used to keep track of all clients on the network.
There is no far equivalent of the +C snomask.
+k, server kill notices
-----------------------
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.
+n, nick change notices
-----------------------
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.
+r, notices on name rejections
------------------------------
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.
+s, generic server notices
--------------------------
This snomask allows an oper to receive generic server notices. This
includes kills from opers (except services).
+u, unauthorized connections
----------------------------
This snomask allows an oper to see when users try to connect who do not
have an available auth{} block.
+W, whois notifications
-----------------------
**Note**
This snomask is only available if the ``sno_whois.so`` extension is
loaded.
Opers with +W receive notices when a WHOIS is executed on them on their
server (showing idle time).
+x, extra routing notices
-------------------------
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.
+y, spy
-------
Opers with +y receive notices when users try to join RESV'ed (“juped”)
channels. Additionally, if certain extension modules are loaded, they
will receive notices when special commands are used.
+Z, operspy notices
-------------------
Opers with +Z receive notices whenever an oper anywhere on the network
uses operspy.
This snomask can be configured to be only effective for admins.
Reference in a new issue View git blame Copy permalink