doc/sgml/oper-guide/umodes.sgml

   1   <chapter id="umodes">
   2     <title>Umodes</title>
   3     <sect1 id="umodelist">
   4       <title>Meanings of user modes</title>
   5       <sect2>
   6         <title>+a, server administrator</title>
   7         <para>
   8           This vanity usermode is used to denote a server administrator in WHOIS output.
   9           All local <quote>admin</quote> privileges are independent of it, though services
  10           packages may grant extra privileges to +a users.
  11         </para>
  12       </sect2>
  13       <sect2>
  14         <title>+D, deaf</title>
  15         <para>
  16           <note>
  17             <para>
  18               This is a user umode, which anybody can set. It is not specific to operators.
  19             </para>
  20           </note>
  21           Users with the +D umode set will not receive messages sent to
  22           channels. Joins, parts, topic changes, mode changes, etc are
  23           received as normal, as are private messages.
  24         </para>
  25         <para>
  26           Support of this umode is indicated by the DEAF token in
  27           RPL_ISUPPORT (005); the parameter indicates the letter
  28           of the umode. Note that several common IRCD implementations have
  29           an umode like this (typically +d) but do not have the token in 005.
  30         </para>
  31       </sect2>
  32       <sect2>
  33         <title>+g, Caller ID</title>
  34         <para>
  35           <note>
  36             <para>
  37               This is a user umode, which anybody can set. It is not specific to operators.
  38             </para>
  39           </note>
  40           Users with the +g umode set will only receive private messages from users on a
  41           session-defined whitelist, defined by the /accept command. If a user who is not
  42           on the whitelist attempts to send a private message, the target user will receive a rate-limited notice saying that the user
  43           wishes to speak to them.
  44         </para>
  45         <para>
  46           Network operators are not affected by the callerid whitelist system in the event
  47           that they need to speak to users who have it enabled.
  48         </para>
  49         <para>
  50           Support of this umode is indicated by the CALLERID token in
  51           RPL_ISUPPORT (005); the optional parameter indicates the letter
  52           of the umode, otherwise +g.
  53         </para>
  54       </sect2>
  55       <sect2>
  56         <title>+i, invisible</title>
  57         <para>
  58           <note>
  59             <para>
  60               This is a user umode, which anybody can set. It is not specific to operators.
  61             </para>
  62           </note>
  63           Invisible users do not show up in WHO and NAMES unless you can see them.
  64         </para>
  65       </sect2>
  66       <!-- not planned (jilles)
  67       <sect2>
  68         <title>+I, refuse invite</title>
  69         <para>
  70           <note>
  71             <para>
  72               This is a user umode, which anybody can set. It is not specific to operators.
  73             </para>
  74           </note>
  75           If you have the +I umode set, nobody will be able to issue an INVITE to let you
  76           in to a channel.
  77         </para>
  78         <para>
  79           This mode is not yet implemented. It will be implemented in Charybdis 1.1.
  80         </para>
  81       </sect2>
  82       -->
  83       <sect2>
  84         <title>+l, receive locops</title>
  85         <para>
  86           LOCOPS is a version of OPERWALL that is sent to opers on a single
  87           server only. With cluster{} and shared{} blocks they can optionally
  88           be propagated further.
  89         </para>
  90         <para>
  91           Unlike OPERWALL, any oper can send and receive LOCOPS.
  92         </para>
  93       </sect2>
  94       <sect2>
  95         <title>+o, operator</title>
  96         <para>
  97           This indicates global operator status.
  98         </para>
  99       </sect2>
 100       <sect2>
 101         <title>+Q, disable forwarding</title>
 102         <para>
 103           <note>
 104             <para>
 105               This is a user umode, which anybody can set. It is not specific to operators.
 106             </para>
 107           </note>
 108           This umode prevents you from being affected by channel forwarding.
 109           If enabled on a channel, channel forwarding sends you to another
 110           channel if you could not join. See channel mode +f for more
 111           information.
 112         </para>
 113       </sect2>
 114       <sect2>
 115         <title>+R, reject messages from unauthenticated users</title>
 116         <para>
 117           <note>
 118             <para>
 119               This is a user umode, which anybody can set. It is not specific to operators.
 120             </para>
 121           </note>
 122           If a user has the +R umode set, then any users who are not authenticated
 123           will receive an error message if they attempt to send a private
 124           message or notice to the +R user.
 125         </para>
 126         <para>
 127           Opers and accepted users (like in +g) are exempt.
 128           Unlike +g, the target user is not notified of failed messages.
 129         </para>
 130       </sect2>
 131       <sect2>
 132         <title>+s, receive server notices</title>
 133         <para>
 134           This umode allows an oper to receive server notices.
 135           The requested types of server notices are specified as a
 136           parameter (<quote>snomask</quote>) to this umode.
 137         </para>
 138       </sect2>
 139       <sect2>
 140         <title>+S, network service</title>
 141         <para>
 142           <note>
 143             <para>
 144               This umode can only be set by servers named in a service{}
 145               block.
 146             </para>
 147           </note>
 148           This umode grants various features useful for services. For example,
 149           clients with this umode cannot be kicked or deopped on channels,
 150           can send to any channel, do not show channels in WHOIS,
 151           can be the target of services aliases and do not appear in /stats p.
 152           No server notices are sent for hostname changes by services clients;
 153           server notices about kills are sent to snomask +k instead of +s.
 154         </para>
 155         <para>
 156           The exact effects of this umode are variable; no user or oper on
 157           an actual charybdis server can set it.
 158         </para>
 159       </sect2>
 160       <sect2>
 161         <title>+w, receive wallops</title>
 162         <para>
 163           <note>
 164             <para>
 165               This is a user umode, which anybody can set. It is not specific to operators.
 166             </para>
 167           </note>
 168           Users with the +w umode set will receive WALLOPS messages sent by opers.
 169           Opers with +w additionally receive WALLOPS sent by servers (e.g.
 170           remote CONNECT, remote SQUIT, various severe misconfigurations,
 171           many services packages).
 172         </para>
 173       </sect2>
 174       <sect2>
 175         <title>+z, receive operwall</title>
 176         <para>
 177           OPERWALL differs from WALLOPS in that the ability to receive such messages is
 178           restricted. Opers with +z set will receive OPERWALL messages.
 179         </para>
 180       </sect2>
 181       <sect2>
 182         <title>+Z, SSL user</title>
 183         <para>
 184           This umode is set on clients connected via SSL/TLS.
 185           It cannot be set or unset after initial connection.
 186         </para>
 187       </sect2>
 188     </sect1>
 189     <sect1 id="snomaskusage">
 190       <title>Snomask usage</title>
 191       <para>
 192         Usage is as follows:
 193       </para>
 194       <cmdsynopsis><command>MODE</command>
 195         <arg choice=plain><replaceable>nick</replaceable></arg>
 196         <arg choice=plain>+s</arg>
 197         <arg choice=plain><replaceable>+/-flags</replaceable></arg>
 198       </cmdsynopsis>
 199       <para>
 200         To set snomasks.
 201       </para>
 202       <cmdsynopsis><command>MODE</command>
 203         <arg choice=plain><replaceable>nick</replaceable></arg>
 204         <arg choice=plain>-s</arg>
 205       </cmdsynopsis>
 206       <para>
 207         To clear all snomasks.
 208       </para>
 209       <para>
 210         Umode +s will be set if at least one snomask is set.
 211       </para>
 212       <para>
 213         Umode +s is oper only by default, but even if you allow nonopers to
 214         set it, they will not get any server notices.
 215       </para>
 216     </sect1>
 217     <sect1 id="snomasklist">
 218       <title>Meanings of server notice masks</title>
 219       <sect2>
 220         <title>+b, bot warnings</title>
 221         <para>
 222           Opers with the +b snomask set will receive warning messages from the server when potential
 223           flooders and spambots are detected.
 224         </para>
 225       </sect2>
 226       <sect2>
 227         <title>+c, client connections</title>
 228         <para>
 229           Opers who have the +c snomask set will receive server notices when clients attach to the
 230           local server.
 231         </para>
 232       </sect2>
 233       <sect2>
 234         <title>+C, extended client connection notices</title>
 235         <para>
 236           Opers who have the +C snomask set will receive server notices when clients attach to the
 237           local server. Unlike the +c snomask, the information is displayed in a format intended
 238           to be parsed by scripts, and includes the two unused fields of the USER command.
 239         </para>
 240       </sect2>
 241       <sect2>
 242         <title>+d, debug</title>
 243         <para>
 244           The +d snomask provides opers extra information which may be of interest to debuggers.
 245           It will also cause the user to receive server notices if certain assertions fail inside the
 246           server. Its precise meaning is variable. Do not depend on the
 247           effects of this snomask as they can and will change without notice in later revisions.
 248         </para>
 249       </sect2>
 250       <sect2>
 251         <title>+f, full warning</title>
 252         <para>
 253           Opers with the +f snomask set will receive notices when a user
 254           connection is denied because a connection limit is exceeded
 255           (one of the limits in a class{} block, or the total per-server
 256           limit settable with /quote set max).
 257         </para>
 258       </sect2>
 259       <sect2>
 260         <title>+F, far client connection notices</title>
 261         <para>
 262           <note>
 263             <para>
 264               This snomask is only available if the <filename>sno_farconnect.so</filename> extension is loaded.
 265             </para>
 266           </note>
 267           Opers with +F receive server notices when clients connect or
 268           disconnect on other servers. The notices have the same format
 269           as those from the +c snomask, except that the class is ? and
 270           the source server of the notice is the server the user is/was on.
 271         </para>
 272         <para>
 273           No notices are generated for netsplits and netjoins.
 274           Hence, these notices cannot be used to keep track of all
 275           clients on the network.
 276         </para>
 277         <para>
 278           There is no far equivalent of the +C snomask.
 279         </para>
 280       </sect2>
 281       <sect2>
 282         <title>+k, server kill notices</title>
 283         <para>
 284           Opers with the +k snomask set will receive server notices when
 285           services kill users and when
 286           other servers kill and save (forced nick change to UID) users.
 287           Kills and saves by this server are on +d or +s.
 288         </para>
 289       </sect2>
 290       <sect2>
 291         <title>+n, nick change notices</title>
 292         <para>
 293           An oper with +n set will receive a server notice every time a local user changes their nick,
 294           giving the old and new nicks.
 295           This is mostly useful for bots that track all users on a single server.
 296         </para>
 297       </sect2>
 298       <sect2>
 299         <title>+r, notices on name rejections</title>
 300         <para>
 301           Opers with this snomask set will receive a server notice when somebody tries to use an
 302           invalid username, or if a dumb HTTP proxy tries to connect.
 303         </para>
 304       </sect2>
 305       <sect2>
 306         <title>+s, generic server notices</title>
 307         <para>
 308           This snomask allows an oper to receive generic server notices.
 309           This includes kills from opers (except services).
 310         </para>
 311       </sect2>
 312       <sect2>
 313         <title>+u, unauthorized connections</title>
 314         <para>
 315           This snomask allows an oper to see when users try to connect who do not have an
 316           available auth{} block.
 317         </para>
 318       </sect2>
 319       <sect2>
 320         <title>+W, whois notifications</title>
 321         <para>
 322           <note>
 323             <para>
 324               This snomask is only available if the <filename>sno_whois.so</filename> extension is loaded.
 325             </para>
 326           </note>
 327           Opers with +W receive notices when a WHOIS is executed on them
 328           on their server (showing idle time).
 329         </para>
 330       </sect2>
 331       <sect2>
 332         <title>+x, extra routing notices</title>
 333         <para>
 334           Opers who have the +x snomask set will get notices about servers
 335           connecting and disconnecting on the whole network. This includes
 336           all servers connected behind the affected link. This can get
 337           rather noisy but is useful for keeping track of all linked
 338           servers.
 339         </para>
 340       </sect2>
 341       <sect2>
 342         <title>+y, spy</title>
 343         <para>
 344           Opers with +y receive notices when users try to join RESV'ed (<quote>juped</quote>) channels.
 345           Additionally, if certain extension modules are loaded, they will
 346           receive notices when special commands are used.
 347         </para>
 348       </sect2>
 349       <sect2>
 350         <title>+Z, operspy notices</title>
 351         <para>
 352           Opers with +Z receive notices whenever an oper anywhere on the
 353           network uses operspy.
 354         </para>
 355         <para>
 356           This snomask can be configured to be only effective for admins.
 357         </para>
 358       </sect2>
 359     </sect1>
 360   </chapter>
 361 <!-- Keep this comment at the end of the file
 362 Local variables:
 363 mode: sgml
 364 sgml-omittag:t
 365 sgml-shorttag:t
 366 sgml-namecase-general:t
 367 sgml-general-insert-case:lower
 368 sgml-minimize-attributes:nil
 369 sgml-always-quote-attributes:t
 370 sgml-indent-step:2
 371 sgml-indent-data:t
 372 sgml-parent-document: ("charybdis-oper-guide.sgml" "book")
 373 sgml-exposed-tags:nil
 374 fill-column: 105
 375 sgml-validate-command: "nsgmls -e -g -s -u charybdis-oper-guide.sgml"
 376 End:
 377 -->