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           do not show channels the querying user is not on in WHOIS,
 151           and do not appear in /stats p.
 152         </para>
 153         <para>
 154           The exact effects of this umode are variable; no user or oper on
 155           an actual charybdis server can set it.
 156         </para>
 157       </sect2>
 158       <sect2>
 159         <title>+w, receive wallops</title>
 160         <para>
 161           <note>
 162             <para>
 163               This is a user umode, which anybody can set. It is not specific to operators.
 164             </para>
 165           </note>
 166           Users with the +w umode set will receive WALLOPS messages sent by opers.
 167           Opers with +w additionally receive WALLOPS sent by servers (e.g.
 168           remote CONNECT, remote SQUIT, many services packages).
 169         </para>
 170       </sect2>
 171       <sect2>
 172         <title>+z, receive operwall</title>
 173         <para>
 174           OPERWALL differs from WALLOPS in that the ability to receive such messages is
 175           restricted. Opers with +z set will receive OPERWALL messages.
 176         </para>
 177       </sect2>
 178     </sect1>
 179     <sect1 id="snomaskusage">
 180       <title>Snomask usage</title>
 181       <para>
 182         Usage is as follows:
 183       </para>
 184       <cmdsynopsis><command>MODE</command>
 185         <arg choice=plain><replaceable>nick</replaceable></arg>
 186         <arg choice=plain>+s</arg>
 187         <arg choice=plain><replaceable>+/-flags</replaceable></arg>
 188       </cmdsynopsis>
 189       <para>
 190         To set snomasks.
 191       </para>
 192       <cmdsynopsis><command>MODE</command>
 193         <arg choice=plain><replaceable>nick</replaceable></arg>
 194         <arg choice=plain>-s</arg>
 195       </cmdsynopsis>
 196       <para>
 197         To clear all snomasks.
 198       </para>
 199       <para>
 200         Umode +s will be set if at least one snomask is set.
 201       </para>
 202       <para>
 203         Umode +s is oper only by default, but even if you allow nonopers to
 204         set it, they will not get any server notices.
 205       </para>
 206     </sect1>
 207     <sect1 id="snomasklist">
 208       <title>Meanings of server notice masks</title>
 209       <sect2>
 210         <title>+b, bot warnings</title>
 211         <para>
 212           Opers with the +b snomask set will receive warning messages from the server when potential
 213           flooders and spambots are detected.
 214         </para>
 215       </sect2>
 216       <sect2>
 217         <title>+c, client connections</title>
 218         <para>
 219           Opers who have the +c snomask set will receive server notices when clients attach to the
 220           local server.
 221         </para>
 222       </sect2>
 223       <sect2>
 224         <title>+C, extended client connection notices</title>
 225         <para>
 226           Opers who have the +C snomask set will receive server notices when clients attach to the
 227           local server. Unlike the +c snomask, the information is displayed in a format intended
 228           to be parsed by scripts, and includes the two unused fields of the USER command.
 229         </para>
 230       </sect2>
 231       <sect2>
 232         <title>+d, debug</title>
 233         <para>
 234           The +d snomask provides opers extra information which may be of interest to debuggers.
 235           It will also cause the user to receive server notices if certain assertions fail inside the
 236           server. Its precise meaning is variable. Do not depend on the
 237           effects of this snomask as they can and will change without notice in later revisions.
 238         </para>
 239       </sect2>
 240       <sect2>
 241         <title>+f, full warning</title>
 242         <para>
 243           Opers with the +f snomask set will receive notices when a user
 244           connection is denied because a connection limit is exceeded
 245           (one of the limits in a class{} block, or the total per-server
 246           limit settable with /quote set max).
 247         </para>
 248       </sect2>
 249       <sect2>
 250         <title>+k, server kill notices</title>
 251         <para>
 252           Opers with the +k snomask set will receive server notices when
 253           services kill users and when
 254           other servers kill and save (forced nick change to UID) users.
 255           Kills and saves by this server are on +d or +s.
 256         </para>
 257       </sect2>
 258       <sect2>
 259         <title>+n, nick change notices</title>
 260         <para>
 261           An oper with +n set will receive a server notice every time a local user changes their nick,
 262           giving the old and new nicks.
 263           This is mostly useful for bots that track all users on a single server.
 264         </para>
 265       </sect2>
 266       <sect2>
 267         <title>+r, notices on name rejections</title>
 268         <para>
 269           Opers with this snomask set will receive a server notice when somebody tries to use an
 270           invalid username, or if a dumb HTTP proxy tries to connect.
 271         </para>
 272       </sect2>
 273       <sect2>
 274         <title>+s, generic server notices</title>
 275         <para>
 276           This snomask allows an oper to receive generic server notices.
 277           This includes kills from opers (except services).
 278         </para>
 279       </sect2>
 280       <sect2>
 281         <title>+u, unauthorized connections</title>
 282         <para>
 283           This snomask allows an oper to see when users try to connect who do not have an
 284           available auth{} block.
 285         </para>
 286       </sect2>
 287       <sect2>
 288         <title>+x, extra routing notices</title>
 289         <para>
 290           Opers who have the +x snomask set will get notices about servers
 291           connecting and disconnecting on the whole network. This includes
 292           all servers connected behind the affected link. This can get
 293           rather noisy but is useful for keeping track of all linked
 294           servers.
 295         </para>
 296       </sect2>
 297       <sect2>
 298         <title>+y, spy</title>
 299         <para>
 300           Opers with +y receive notices when users try to join RESV'ed (<quote>juped</quote>) channels.
 301           Additionally, if certain extension modules are loaded, they will
 302           receive notices when special commands are used and/or when they
 303           are whoised.
 304         </para>
 305       </sect2>
 306       <sect2>
 307         <title>+Z, operspy notices</title>
 308         <para>
 309           Opers with +Z receive notices whenever an oper anywhere on the
 310           network uses operspy.
 311         </para>
 312         <para>
 313           This snomask can be configured to be only effective for admins.
 314         </para>
 315       </sect2>
 316     </sect1>
 317   </chapter>
 318 <!-- Keep this comment at the end of the file
 319 Local variables:
 320 mode: sgml
 321 sgml-omittag:t
 322 sgml-shorttag:t
 323 sgml-namecase-general:t
 324 sgml-general-insert-case:lower
 325 sgml-minimize-attributes:nil
 326 sgml-always-quote-attributes:t
 327 sgml-indent-step:2
 328 sgml-indent-data:t
 329 sgml-parent-document: ("charybdis-oper-guide.sgml" "book")
 330 sgml-exposed-tags:nil
 331 fill-column: 105
 332 sgml-validate-command: "nsgmls -e -g -s -u charybdis-oper-guide.sgml"
 333 End:
 334 -->