[irc/rqf/shadowircd.git] / doc / sgml / oper-guide / umodes.sgml

  <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>
      <sect2>
	<title>+Z, SSL user</title>
	<para>
	  This umode is set on clients connected via SSL/TLS.
	  It cannot be set or unset after initial connection.
	</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>+F, far client connection notices</title>
	<para>
	  <note>
	    <para>
	      This snomask is only available if the <filename>sno_farconnect.so</filename> extension is loaded.
	    </para>
	  </note>
	  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.
	</para>
	<para>
	  No notices are generated for netsplits and netjoins.
	  Hence, these notices cannot be used to keep track of all
	  clients on the network.
	</para>
	<para>
	  There is no far equivalent of the +C snomask.
	</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>+W, whois notifications</title>
	<para>
	  <note>
	    <para>
	      This snomask is only available if the <filename>sno_whois.so</filename> extension is loaded.
	    </para>
	  </note>
	  Opers with +W receive notices when a WHOIS is executed on them
	  on their server (showing idle time).
	</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.
	</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:
-->
Commit	Line	Data
212380e3	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>
e7d250a6	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.
212380e3	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>
32034871 JT	178	<sect2>
	179	<title>+Z, SSL user</title>
	180	<para>
	181	This umode is set on clients connected via SSL/TLS.
	182	It cannot be set or unset after initial connection.
	183	</para>
	184	</sect2>
212380e3	185	</sect1>
	186	<sect1 id="snomaskusage">
	187	<title>Snomask usage</title>
	188	<para>
	189	Usage is as follows:
	190	</para>
	191	<cmdsynopsis><command>MODE</command>
	192	<arg choice=plain><replaceable>nick</replaceable></arg>
	193	<arg choice=plain>+s</arg>
	194	<arg choice=plain><replaceable>+/-flags</replaceable></arg>
	195	</cmdsynopsis>
	196	<para>
	197	To set snomasks.
	198	</para>
	199	<cmdsynopsis><command>MODE</command>
	200	<arg choice=plain><replaceable>nick</replaceable></arg>
	201	<arg choice=plain>-s</arg>
	202	</cmdsynopsis>
	203	<para>
	204	To clear all snomasks.
	205	</para>
	206	<para>
	207	Umode +s will be set if at least one snomask is set.
	208	</para>
	209	<para>
	210	Umode +s is oper only by default, but even if you allow nonopers to
	211	set it, they will not get any server notices.
	212	</para>
	213	</sect1>
	214	<sect1 id="snomasklist">
	215	<title>Meanings of server notice masks</title>
	216	<sect2>
	217	<title>+b, bot warnings</title>
	218	<para>
	219	Opers with the +b snomask set will receive warning messages from the server when potential
	220	flooders and spambots are detected.
	221	</para>
	222	</sect2>
	223	<sect2>
	224	<title>+c, client connections</title>
	225	<para>
	226	Opers who have the +c snomask set will receive server notices when clients attach to the
	227	local server.
	228	</para>
	229	</sect2>
	230	<sect2>
	231	<title>+C, extended client connection notices</title>
	232	<para>
	233	Opers who have the +C snomask set will receive server notices when clients attach to the
	234	local server. Unlike the +c snomask, the information is displayed in a format intended
	235	to be parsed by scripts, and includes the two unused fields of the USER command.
	236	</para>
	237	</sect2>
	238	<sect2>
	239	<title>+d, debug</title>
	240	<para>
	241	The +d snomask provides opers extra information which may be of interest to debuggers.
	242	It will also cause the user to receive server notices if certain assertions fail inside the
	243	server. Its precise meaning is variable. Do not depend on the
	244	effects of this snomask as they can and will change without notice in later revisions.
	245	</para>
	246	</sect2>
	247	<sect2>
	248	<title>+f, full warning</title>
249	<para>
250	Opers with the +f snomask set will receive notices when a user
251	connection is denied because a connection limit is exceeded
252	(one of the limits in a class{} block, or the total per-server
253	limit settable with /quote set max).
254	</para>
255	</sect2>
c2c2491a JT	256	<sect2>
	257	<title>+F, far client connection notices</title>
	258	<para>
	259	<note>
	260	<para>
	261	This snomask is only available if the <filename>sno_farconnect.so</filename> extension is loaded.
	262	</para>
	263	</note>
	264	Opers with +F receive server notices when clients connect or
	265	disconnect on other servers. The notices have the same format
	266	as those from the +c snomask, except that the class is ? and
	267	the source server of the notice is the server the user is/was on.
	268	</para>
	269	<para>
	270	No notices are generated for netsplits and netjoins.
	271	Hence, these notices cannot be used to keep track of all
	272	clients on the network.
	273	</para>
	274	<para>
	275	There is no far equivalent of the +C snomask.
	276	</para>
	277	</sect2>
212380e3	278	<sect2>
	279	<title>+k, server kill notices</title>
	280	<para>
	281	Opers with the +k snomask set will receive server notices when
	282	services kill users and when
	283	other servers kill and save (forced nick change to UID) users.
	284	Kills and saves by this server are on +d or +s.
	285	</para>
	286	</sect2>
	287	<sect2>
	288	<title>+n, nick change notices</title>
	289	<para>
	290	An oper with +n set will receive a server notice every time a local user changes their nick,
	291	giving the old and new nicks.
	292	This is mostly useful for bots that track all users on a single server.
	293	</para>
	294	</sect2>
	295	<sect2>
	296	<title>+r, notices on name rejections</title>
	297	<para>
	298	Opers with this snomask set will receive a server notice when somebody tries to use an
	299	invalid username, or if a dumb HTTP proxy tries to connect.
	300	</para>
	301	</sect2>
	302	<sect2>
	303	<title>+s, generic server notices</title>
	304	<para>
	305	This snomask allows an oper to receive generic server notices.
	306	This includes kills from opers (except services).
	307	</para>
	308	</sect2>
	309	<sect2>
	310	<title>+u, unauthorized connections</title>
	311	<para>
	312	This snomask allows an oper to see when users try to connect who do not have an
	313	available auth{} block.
	314	</para>
	315	</sect2>
c2c2491a JT	316	<sect2>
	317	<title>+W, whois notifications</title>
	318	<para>
	319	<note>
	320	<para>
	321	This snomask is only available if the <filename>sno_whois.so</filename> extension is loaded.
	322	</para>
	323	</note>
	324	Opers with +W receive notices when a WHOIS is executed on them
	325	on their server (showing idle time).
	326	</para>
	327	</sect2>
212380e3	328	<sect2>
	329	<title>+x, extra routing notices</title>
	330	<para>
	331	Opers who have the +x snomask set will get notices about servers
	332	connecting and disconnecting on the whole network. This includes
	333	all servers connected behind the affected link. This can get
	334	rather noisy but is useful for keeping track of all linked
	335	servers.
	336	</para>
	337	</sect2>
	338	<sect2>
	339	<title>+y, spy</title>
	340	<para>
	341	Opers with +y receive notices when users try to join RESV'ed (<quote>juped</quote>) channels.
	342	Additionally, if certain extension modules are loaded, they will
c2c2491a	343	receive notices when special commands are used.
212380e3	344	</para>
	345	</sect2>
	346	<sect2>
	347	<title>+Z, operspy notices</title>
	348	<para>
	349	Opers with +Z receive notices whenever an oper anywhere on the
	350	network uses operspy.
	351	</para>
	352	<para>
	353	This snomask can be configured to be only effective for admins.
	354	</para>
	355	</sect2>
	356	</sect1>
	357	</chapter>
	358	<!-- Keep this comment at the end of the file
	359	Local variables:
	360	mode: sgml
	361	sgml-omittag:t
	362	sgml-shorttag:t
	363	sgml-namecase-general:t
	364	sgml-general-insert-case:lower
	365	sgml-minimize-attributes:nil
	366	sgml-always-quote-attributes:t
	367	sgml-indent-step:2
	368	sgml-indent-data:t
	369	sgml-parent-document: ("charybdis-oper-guide.sgml" "book")
	370	sgml-exposed-tags:nil
	371	fill-column: 105
	372	sgml-validate-command: "nsgmls -e -g -s -u charybdis-oper-guide.sgml"
	373	End:
	374	-->