|
| |
The MicroSwift IRC Network Operator Manual
Last updated on 03-24-2008. THIS IS A WORK IN PROGRESS. Dustin will be updating it soon, especially for services.
TABLE OF CONTENTS
=================
Introduction
PART I - TECHNICAL INFORMATION
Chapter 1 - Terminology
Services..................................................................... 1.1.1
Opers, Admins, CSOPs, etc.................................................... 1.1.2
Globals, Globops, Wallops, Chatops and Locops................................ 1.1.3
Server Lines................................................................. 1.1.4
K:Lines and Akills........................................................... 1.1.5
Ircd......................................................................... 1.1.6
Synchs....................................................................... 1.1.7
Jupes........................................................................ 1.1.8
SendQ, RecvQ (RcveQ)......................................................... 1.1.9
TOU.......................................................................... 1.1.10
"Nuking", Denial of Service Attacks.......................................... 1.1.11
Chapter 2 - IRC Technical Operation and Network Structure
IRC Technical Operation...................................................... 1.2.1
IRC Protocol Commands........................................................ 1.2.2
IRC Operator Server Commands................................................. 1.2.3
/OPER...................................................................... 1.2.3.1
/GLOBOPS, /WALLOPS, /LOCOPS and /CHATOPS................................... 1.2.3.2
/KILL...................................................................... 1.2.3.3
/MKILL..................................................................... 1.2.3.4
/KLINE and /UNKLINE........................................................ 1.2.3.5
/REHASH.................................................................... 1.2.3.6
/RESTART................................................................... 1.2.3.7
/DIE....................................................................... 1.2.3.8
/CLOSE..................................................................... 1.2.3.9
/SAMODE & /SAJOIN.......................................................... 1.2.3.10
/ZLINE and /UNZLINE........................................................ 1.2.3.11
/HUSH and /UNHUSH.......................................................... 1.2.3.12
/UNBANME................................................................... 1.2.3.13
Routing...................................................................... 1.2.4
Leaf....................................................................... 1.2.4.1
Hub........................................................................ 1.2.4.2
/SQUIT..................................................................... 1.2.4.3
/CONNECT................................................................... 1.2.4.4
Connection Error Messages.................................................... 1.2.5
Think Before You Act......................................................... 1.2.6
Chapter 3 - Some IRC Features From an Operator's View
Network Status............................................................... 1.3.1
/LINKS..................................................................... 1.3.2
/STATS..................................................................... 1.3.3
/VERSION................................................................... 1.3.4
/LUSERS.................................................................... 1.3.5
/TRACE..................................................................... 1.3.6
/TRACE <nick>............................................................ 1.3.6.1
/TRACE <server>.......................................................... 1.3.6.2
Uses for /TRACE.......................................................... 1.3.6.3
Other Commands............................................................... 1.3.7
/HELP and /HELPOP.......................................................... 1.3.7.1
/NOTICE and /MSG........................................................... 1.3.7.2
/WHO....................................................................... 1.3.7.3
/MOTD and /ADMIN........................................................... 1.3.7.4
/NICK...................................................................... 1.3.7.5
Usermodes and Server Messages................................................ 1.3.8
Usermode +o................................................................ 1.3.8.1
Usermode +s................................................................ 1.3.8.2
Usermode +w................................................................ 1.3.8.3
Usermode +g................................................................ 1.3.8.4
Usermode +c................................................................ 1.3.8.5
Usermode +k................................................................ 1.3.8.6
Usermode +f................................................................ 1.3.8.7
Usermode +h................................................................ 1.3.8.8
Usermode +a................................................................ 1.3.8.9
Usermode +A................................................................ 1.3.8.10
Usermode +b................................................................ 1.3.8.11
Usermode +d................................................................ 1.3.8.12
Usermode +j................................................................ 1.3.8.13
Usermodes +C and +R........................................................ 1.3.8.14
PART II - NICE TO KNOW
Chapter 1 - How to deal with...
Desynchs..................................................................... 2.1.1
Lag.......................................................................... 2.1.2
User requests................................................................ 2.1.3
Masking...................................................................... 2.1.4
Chapter 2 - Useful information
The Complaints Team.......................................................... 2.2.1
The Kline Team............................................................... 2.2.2
The Web Team................................................................. 2.2.3
The Coders Team.............................................................. 2.2.4
Links........................................................................ 2.2.5
Credits...................................................................... 2.2.6
Introduction
============
The purpose of this document is to give a full explanation of all the IRC commands
available to operators of The MicroSwift IRC Network. This document will not describe
when a certain command is called for - refer to the Terms of Use (TOU) for that.
If your admin tells you something that conflicts with the contents of this document,
do as your admin says - I can't stress that enough.
It should be understandable for everyone who has some IRC experience and even though
you are an experienced oper, reading it might do you good.
Any comments regarding this document should be sent directly to Dustin.
==============================
Part 1 - TECHNICAL INFORMATION
==============================
This part of the document (chapters 1 to 3) will explain about new IRC operator commands,
give you a basic knowledge of how IRC works, and describe in detail the IRC
features important to an IRC operator.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Chapter 1. TERMINOLOGY
=======================
This chapter will focus on terminology that is used mostly by IRC operators and
that you might not have heard before. Some of the other terms will get a new
meaning with explanations of IRC features and functionality that follows in
later chapters.
1.1.1 SERVICES
--------------
Services is a single program that connects to the network just like any other
server would. It is, however, not connectable by other clients, but holds it own
"bots" which are of great importance to the network. They are ChanServ, NickServ,
MemoServ, HelpServ, StatServ and OperServ.
The commands associated with Services will not be described in this document, refer
to Services help documents for that.
1.1.2 OPERS, ADMINS, CSOPS, ETC.
--------------------------------
Here's a brief explanation of the MicroSwift staff positions and hierachy.
- An IRC operator (also referred to as oper, IRC op, IRCop etc.) is someone who has
been granted IRC operator status on one or more servers. They are assigned by the
server admin, and have several duties. Their main task is to make sure the server
the are operators on runs smoothly and is properly connected to the main network.
They also serve other duties, such as helping users and making sure no one abuses
the server and network.
- A server admin is a person who runs (administrates) a server and is responsible
for it. Admins select the operators for their server.
Services also has a number of administrative staff positions. Those who have extended
Services access (see explanation) also have extended responsibility. Therefore, you
must be an IRC operator before you can become a services administrator. Again, the
different administrative positions will only be explained briefly in this document.
- Services Administrators (or SAs)have access to a few extra Services commands,
to help deal with abusive users or other problem situations. Most notably,
SAs can add and remove akills.
- Service Operators (CSops, NickServ/ChanServ Admins) have the same access as
Service Admins, but are also able to deal with nickname and channel
ownership issues (lost passwords, etc.).
- Services root administrators (SRAs) are the ones who actually manage and run
Services. They have access to several Services features not available to
anyone else, in addition to all CSop features.
1.1.3 GLOBALS, GLOBOPS, WALLOPS, CHATOPS AND LOCOPS
---------------------------------------------------
A global (short from "global notice") is a notice sent by an operator to all
users who are using the network. Globals can also technically be done with
normal messages instead of notices, but in practice that is never done for
a number of reasons.
Notices may also be sent to a limited group of users, either based on which
servers they are using, or what their address is. If the notice is sent to
the clients on only one server, it's usually called a server notice.
A globop is a message sent by an operator or a server to all IRC operators
who have set the usermode +g (more on this in chapter 3). Globops are a
means for opers to discuss important network issues without users seeing. For
extended discussions, joining a channel is strongly recommended. Some people
might refer to globops as "globals" too, but this is not proper usage and is
discouraged. Globops should not be used for idle chat, see chatops (below)
for that.
A wallop is a message sent by an operator to all users who have the usermode
+w set (more on this in chapter 3). Only IRCops can send them, but they
are visible to anyone who sets the usermode.
Many curious users set themselves +w in order to see interesting operator
messages. The best current use for them is for announcing network issues to
the "interested users", especially in cases when a global is not proper.
Chatops are technically identical to globops. The corresponding usermode is
+b (see chapter 3). Unlike globops, there are no automatically generated
chatops messages. Chatops have been added purely as a free chat medium for IRC
operators in order to let globops be used for strictly network related issues.
IRC servers all have a configuration file which controls various aspects of
the server, usually called ircd.conf. This file consists of various "lines",
which are all named after the first character in that line. Thus there are
O:lines, K:lines, C/N:lines, etc. Some of these lines can be viewed with the
/stats command on IRC.
1.1.4 SERVER LINES
------------------
Here's a brief explanation of what each line does:
A:line -- Specifies what information is seen with the /admin command.
C:lines -- Specify which servers the server can connect to.
D:lines -- Connect rules for all connects.
d:lines -- Connect rules for autoconnects only.
H:lines -- Specify which servers are to be considered hubs.
I:lines -- Define which clients are authorized to connect to the server, and
what connection class they should use (see Y:lines).
K:lines -- Define which clients are prohibited access to the server (banned).
k:lines -- Define which clients are prohibited access to the server
temporarily (settable by server opers).
L:lines -- Specify which servers are to be considered leafs.
M:line -- Specifies the server name, description and the port number it
should "listen" to.
N:lines -- Specify which servers are allowed to connect to the server.
O:lines -- Define which clients can access operator commands on the server.
o:lines -- OBSOLETE, however the term "local o" is still in use. Define
which clients can access local operator commands (restricted set
of operator commands; eg. /kill will only work on users on the
same server).
P:lines -- Set which additional ports the server may listen to. (Also select
IP addresses to use if the computer has more than one.)
Q:lines -- Set which nicknames cannot be used on that server.
q:lines -- Set which server names are not allowed on the network (need to
be set on all servers for things to work properly).
R:lines -- OBSOLETE. A more strident system of checking for user access
than K:lines. Requires an external program and some #define changes
in /include/config.h.
U:lines -- Define which servers are authorized to make changes to user and
channel mode settings regardless of actual user status
(restricted to services.MicroSwift.net on MicroSwift).
Y:lines -- Specify how the server accepts and treats connections by setting
up "connection classes".
Z:lines -- Define which hosts (based on IP address) are not allowed to
connect to the server at all.
z:lines -- Define which hosts (based on IP address) are not allowed to
connect to the server at all (settable by opers).
1.1.5 K:LINES AND AKILLS
------------------------
A K:line is a ban for a user or group of users on an IRC server. K:lining
means adding a K:line, or in general terms banning a user from a server or
the entire network. Permanent K:lines are added to the server's configuration
file by the server's admin. Temporary k:lines (a lower case k is used for
them) may be added by that server's operators on IRC, and it stays until the
server goes down or an oper uses /rehash or /unkline.
Akill is a Services feature to automatically kill any user whose address
matches a mask in the autokill list. Additionally, Services adds a temporary
k:line (shown with an "A:" heading with a "/stats k" command) on the server
the user was using. Akills can be set and removed by Service Admins and CSops,
while the akill list is viewable by all opers. Akills are the key feature
in keeping abusive people out of the network.
1.1.6 IRCD
----------
ircd is the name of the IRC server program (it comes from "Internet Relay
Chat Daemon", but spelled all lowercase according to unix tradition). It is
used when talking of the actual server program, while "server" usually refers
to the whole entity that a server running on MicroSwift Net is: the admin, server
operators, link permission, etc.
1.1.7 SYNCHS
------------
Synch is short from "synchronization". On IRC the term is used to
describe the act of exchanging data between two servers in order to synchronize
the databases, so that both of the servers hold the same information about what
users are online and which channels have been formed (known as "synching").
It's also used when describing the status of two connected servers which have
finished synching and when they are working together seamlessly (known as
"synched").
A resynch is when two servers connect to each other and synch after a
netsplit.
A desynch occurs when the servers on a network do not agree about the state
of some nickname or channel. For example, a single desynched server might hold
that a user has ops, while all the other servers see him/her as just a normal
channel member. This means that the desynched user is able to kick and ban
others seemingly without ops on the channel, for example. The best way of fixing
a desynched nick or channel is to /kill the user or clearmode the channel.
1.1.8 JUPES
-----------
There are two types of jupes, a nick jupe and a server jupe. Basically they work
the same way, namely by taking something else's name/place. This means, both for
nicks and servers that the "real" one is unable to connect to the network. It is
an effective way of blocking unwanted servers and nicks, but should only be used as
a last resort.
Nick jupes cannot be set/removed from IRC however, they are defined with Q:lines in
the ircd.conf as described earlier.
Server jupes are set through Services, which then "pretends" to have a server connected
to it, without actually having it. Juped servers can not be SQUIT'ed and must also be
removed through services.
Jupes act differently on other networks though. For example, on Undernet, nick jupes are
set via the servers' U:lines and server jupes are just servers which has the first four
characters in it's info field set to 'JUPE'.
1.1.9 SENDQ, RECVQ (RCVEQ)
--------------------------
The 'Q' in these comes from "queue". The sendQ is used by the server to
buffer the outgoing (send) data, while the recvQ (receive queue, also sometimes
written as rcveQ) stores incoming (receive) data from a client or server.
There is a separate sendQ and recvQ for each client and server connection.
Also, for server connections, the sendQ sizes may be different on each server,
eg. server A's sendQ for the connection to server B may be different from the
sendQ that server B has for its connection to server A.
For clients, exceeding the receive queue is a possible sign of flooding,
while exceeding the send queue is likely due to using a command which generated
a lot of output (such as /list).
For servers, exceeding the sendQ is a common symptom when a connection is
broken, but the server doesn't receive an actual notification of the fact.
The server will keep trying to send data through the link to the other server,
until the sendQ overflows, and the connection is closed.
1.1.10 "NUKING", DENIAL OF SERVICE ATTACKS
------------------------------------------
Although denial of service attacks (DoS) does not travel through IRC, you
will be confronted with users claiming to have been nuked 'off IRC'
I will not give a technical description of these attacks here; it can be found
all over the Internet. Very basically, nuking is a way to eliminate a person's
internet connection, which consequently will remove the user from IRC as well.
In order to nuke someone, you need their IP address, and since it is so easily
obtained from an IRC server, it is a common problem for IRC users.
This means that using MicroSwift servers for this malicious act, is naturally
disallowed and should be punished severely. Furthermore, it can be mentioned that
denial of service attacks are against the law in most countries, and can (should)
be reported to the local authorities.
Opers should inform attacked users about the possibility to set themselves +d
which will hide their real IP from other normal users. DoS attacks should also
be logged and send to the attacker's ISP.
1.1.11 TOU
----------
The TOU, or Terms of Use, is the ultimate law on the MicroSwift IRC Network.
Read it, memorize it and follow it :)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Chapter 2 - IRC TECHNICAL OPERATION AND NETWORK STRUCTURE
=========================================================
From the user end, technical specifics about IRC are nearly impossible to
speculate on. However, as an IRC server operator you should know the
underlying workings of IRC. Things can be confusing when you start, so this
section is meant to explain the basic structure of an IRC network.
1.2.1 IRC TECHNICAL OPERATION
-----------------------------
IRC, as you might already know, stands for Internet Relay Chat. IRC relies on
a system similar to most all Internet communications relationships. A program
called a client connects to another program called a server to send and receive
information. For IRC, many clients have been developed for various platforms
(Windows, unix, Macintosh, VMS). To list a few, ircII, BitchX, SmallIRC, and
TinyIRC for UNIX; Zircon for X-windows (X11); mIRC, pIRCh, CuteChat, Netscape
Chat, WSIRC, and irc4win for Windows; and Ircle, Homer, and Global Chat for
Macintosh. The server is a program called ircd. All MicroSwift servers run on
the unix operating system, although it is possible to run an IRC server on a
Windows system too.
An IRC network is composed of servers that are connected to each other, some
directly, some through other servers which are in between and relay the
messages. The messages transmitted between clients and servers are described
the document 'RFC1459'.
1.2.2 IRC PROTOCOL COMMANDS
---------------------------
It might be necessary for you to know how to send "raw" IRC commands to the
IRC server you are using. This is because not all clients support all the
server commands, and in such cases the command has to be sent directly to the
server.
Most IRC clients allow sending direct server command by prefixing them with
the "/quote" or "/raw" command. In that case, the server command does not have the /
placed in front. For example, to send a message to Nick, the server format
would be "PRIVMSG Nick :message text", and the actual command to type would be:
/quote PRIVMSG Nick :message text here or
/raw PRIVMSG Nick :message text here
Note the `:' right before the message text. If it is not omitted, only the first
word of the text will be transmitted to the user. When sending commands directly
to the server, this is important to have in mind.
It is usually possible to add an alias or script for these kinds of commands,
and that is recommended.
1.2.3 IRC OPERATOR SERVER COMMANDS
----------------------------------
This section lists and explains the IRC commands that an IRC operator may
use. It is possible for server admins to limit and choose to some extent which
commands and usermode are allowed for an oper, by specifying the appropriate
O:line flags. The most common setups are "local operator" (ie. the oper
cannot affect things outside his or her server, aka. "small o:line") and
"global operator" who has access to all the commands (aka. "big O:line"),
except those which require SA access (the +a usermode) to use. Your admin
should let you know about any limitations there are in your O:line -- if you
are unsure, ask.
1.2.3.1 /OPER
-------------
/oper is the basic command for assuming IRC operator status. The syntax for
the command is:
/oper <nick> <password>
The nick you should give after the command should be your IRC operator nickname
(or more technically, whatever was used in the O:line in the server's
configuration file). The password is your operator password (for that O:line,
passwords can vary from server to server and even depend on the address you
are using).
Some clients (notably ircII) or scripts allow to use a format where you only
give the nickname. You will then be prompted for your operator password.
This second format is recommended if your client/script supports it, because it
is less prone to accidentally revealing operator passwords (for example,
consider the difference between "/oper mynick" and "/oper mynick mypass", if
the "/" is accidentally left out).
It is not advisable to put your operator password in any scripts, as that
increases the risk of accidentally giving it away (for example, when sending
someone a copy of your script).
When you oper successfully, the server will set the usermode +o for you,
which means you are now an IRC operator. While you have the +o usermode set,
anyone who does a /whois on you will see the text "* Nick is an IRC operator"
(or whatever the message looks like on his/her server, it is possible for a
server's admin to change it). Also, in any /who or /names list an asterisk
("*") will be shown after your nickname. You may remove the oper status by
removing the +o mode with the "/mode <YourNick> -o" command, and some clients
also provide the "/deop" command.
In addition of the +o, the /oper command will also add the +s, +w, +g and +f
usermodes for you. It is also possible to set the +h,+b and +c usermodes,
which are not available to normal users.
1.2.3.2 /GLOBOPS, /WALLOPS, /LOCOPS AND /CHATOPS
------------------------------------------------
/globops is the command for sending globops-messages, which are only visible
to other IRC operators. /wallops is the command for sending wallops-messages,
which are visible to any user who is set usermode +w . /locops is exactly like
/globops, except it only sends the message to local operators (those operators
using the same server). /chatops is similar to /globops, except it goes only to
those opers who have the +b usermode set. Normally, to send a globops,
wallops, chatops or locops, you will use:
/globops <message text...>
/wallops <message text...>
/locops <message text...>
/chatops <message text...>
Globops can be used to let other opers know about something or to ask a
question or for an opinion. Globops should not be used to send messages which
have nothing to do with the network. Asking for help with network related
problems from other operators is ok, as is discussing things such as "Anyone
dealing with clonebots from evil@site?". If someone else asks a question or
makes a comment in globops and you want to reply, consider whether what you
have to say is something that every other operator needs to see -- if not, make
your reply in a private message. Longer discussions, especially those not
directly relating to network status or use should be taken to a channel.
Wallops are an alternative to globops. When using them you should keep in
mind that they can be seen by users, in particular avoid any security-related
topics. Users who are interested in "what's going on in the net" will likely
have +w set. While globops require that an oper is opered to see them, wallops
do not. Thus, wallops messages are a good way to make small "announcements"
and the like. They could be used to announce rerouting, a server going down,
etc.
Locops are the same as globops, but the message will only be sent to opers on
your server. Most of what applies to globops applies to LocOps too (the server format is
"LOCOPS :message text"). The appropriate use of it on each server is up to
the admin.
Chatops are a free chat medium for operators, created in order to free the
globops from idle chat and other inappropriate use. You need to have the
usermode +b set in order to send and receive chatops. There are no specific
established rules for chatops, but same good behaviour guidelines as for
channels do apply.
1.2.3.3 /KILL
-------------
A /kill will disconnect another user from the IRC network. The format of the
command is
/kill <nick> <reason...>
Unlike with the /kick command, you must give a reason. It should be
matter-of-fact and describe why the user was disconnected, for both the user
getting disconnected and other operators and users who might see it. A kill
will "track" a user if the user has recently (within 90 seconds) changed
nicknames, this is known as "kill chasing".
The appropriate use of /kill, as well as other oper-commands, is stated in
the TOU.
1.2.3.4 /MKILL
--------------
/mkill (short for masskill) is an effective tool when dealing with clones.
It will issue normal /kills for each user matching the address specified. The
syntax for this command is
/mkill <address> <reason>
or
/mkill <nickname> <reason>
/mkill will NOT kill IRC Operators.
1.2.3.5 /KLINE AND /UNKLINE
---------------------------
IRC operators may temporarily K:line a user or user mask from a particular
server. This is the last resort and is one of the most powerful defensive system
available to any IRCop without the help of Services in protecting the network
from repeat offenders or harmful bots. A k:line will both stop new connects from
the specified mask as well as disconnect all users matching that mask (on that
server).
The server needs to see a message of the form
"KLINE <nickname> :<optional reason...>" or "KLINE <user@host mask> :<optional
reason>". If you give a nickname, the server will set up a mask for the k:line
based on the user's current address. As a note, you specifically can NOT kline
a full nick!user@host mask. To ensure no mistakes are made when adding the k:line,
it is preferred to apply the user@host instead of a nickname.
The /unkline command can be used to remove temporary k:lines. The format
is exactly the same as above, with "unkline" replacing "kline", and no reason
given. The removal will only work if the mask is exactly the same which was
used when the k:line was added, use /stats k to view the addresses.
The key limitation in a local K:line (or, in this case, k:line) is that it's
server specific -- the user in question may freely connect to another server
even though they are K:lined on another. Thus in most cases an akill is
much more effective.
A relatively new feature is the ability to set k:lines on remote servers.
The syntax for adding remote k:lines is:
/kline <user@host:servername> :reason.
This command is limited to +a opers.
In some cases it may be better to use a temporary z:line instead, for
example if there is a flood of connections coming to the server from the
same host which are all getting stopped by a K:line.
You can view the current list of K:line with the command /stats k. Lines
beginning with a capital K are permanent K:lines (added by the admin), lines
beginning with a small-case k are temporary k:lines, and lines beginning with
an A are autokill-K:lines, added by Services. If the server has any Z:lines
or z:lines (temporary Z:lines), they will be shown also. Doing a /rehash will
remove all temporary and autokill K:lines and temporary z:lines on that server.
Note that adding local k:lines doesn't need to be reported to the Kline Team.
1.2.3.6 /REHASH
---------------
This command makes ircd reload its configuration file. This needs to be done
whenever the server admin changes information in the file and needs to reflect
these changes within the running server. Rehashing will clear any temporary
and autokill K:line's not permanently set within ircd.conf. /rehash is used
without any extra parameters.
Services administrators (+a) can also remotely rehash a server. The syntax is
/rehash servername.
1.2.3.7 /RESTART
----------------
/restart restarts ircd. This command is similar to /rehash because it
updates any changes that are made in the configuration file, except it reloads
the program too. Like with the /die command (below), all users (and servers
too) are disconnected.
Normally you do not need to use this command, like /die (below).
It is possible that the server admin has set up additional password to use
this command (via an X:line). If so, you will need to place the password
after the command for it to work.
1.2.3.8 /DIE
------------
/die stops the server. Sweet and simple, DO NOT USE THIS COMMAND.
It is possible that the server admin has set up additional password to use
this command (via an X:line). If so, you will need to place the password
after the command for it to work.
If your client supports aliases, I STRONGLY RECOMMEND you replace DIE with an
alias so that you don't accidentally use the command.
Should the server admin not be available for consulting on an emergency
situation, you may be forced to use this command to stop your server from
continuing to malfunction (should it be badly afflicting the network). However,
under normal circumstances, unless you are asked by your own admin to use this
command, do not use it (in all likelihood, the admin of the server will use it
himself if not kill the process from his shell prompt instead). /die will
disconnect all users using the server (including you) from IRC, you will have
to reconnect to another server.
1.2.3.9 /CLOSE
--------------
The /close command closes all "unknown connections" to the server. It's
useful only in very rare occasions, mainly if someone is using unregistered
(not properly logged on) clients with malicious intent, such as filling up the
server.
Many clients have another /close feature implemented, since the server command
CLOSE is used so rarely. Therefore, you might need to "/quote close".
This command can be suffixed with a hostname (opt. wildcards) to narrow the range.
See the /trace command for a way to list the unknown connections.
1.2.3.10 /SAMODE & /SAJOIN
----------------
The /samode (SA mode) is the ircd counterpart to the OperServ's mode command,
which is available to Service Admin and higher access. It can be used to set
any mode on a any channel. The command is used like the normal /mode for channels,
however channel ops or even presence on a channel is not needed to change its mode.
The /sajoin command is a force-entry method for IRCops to enter channels that
maybe +ilk or such. MicroSwift respects the privacy of its users, however many times
there are channels that must be entered for security purposes.
Only opers set as Services Administrators may use these command.
These commands will issue global notices of their useage.
1.2.3.11 /ZLINE AND /UNZLINE
----------------------------
The /zline and /unzline commands can be used to add and remove temporary
Z:lines, much like /kline and /unkline do with temporary K:lines. The
difference is that Z:lines only work for IP-addresses, not hostnames. You
also cannot use a username (ident).
The usage of /zline is "ZLINE <IP-address mask> :comment text". You may also
specify a username part, but this will get always changed into a "*" in the
mask.
The /unzline command is used to remove temporary z:lines. The usage is
predictably "UNZLINE <IP-address mask>", where the mask has to be exactly the
same as given in the original /zline command.
Use the "/stats k" command to see the current list of z:lines on the server.
Adding z:lines is mostly useful in cases where there is a huge number of
repeated connect attempts from some host, which are all stopped by a local
K:line on the server. Adding a z:line will make these connection attempts
invisible and make ircd do the least amount of work when dropping these
connections. Especially since z:lines also blocks server connections matching
the IP, caution should be used when adding them.
/zline and /unzline is only available to Services Administrators.
1.2.3.12 /HUSH AND /UNHUSH
--------------------------
The /hush command will prevent the affected user from sending some commands to
the server. Hushed users are still able to use informative commands, such as
/whois, /admin /motd etc.
Hushes are timed, and the user will receive a server notice when hushed, and when
the hush is removed.
Furthermore, doing a /whois on a hushed user will also report
"Nick is hushed (Oper (reason))"
The syntax is
/hush <nickname> <duration in seconds> :<reason>
and
/unhush <nickname> will remove the hush on the user.
Hushing for a long period of time is not preferable, since it will probably just
result in the user reconnecting.
1.2.3.13 /UNBANME
-----------------
This command will unban you from the channel specified. The syntax is
/unbanme #channel
which will make the server remove all bans on the channel that matches you.
1.2.4 ROUTING
-------------
Opers have the ability to reroute servers. This means decide which leaf
servers should be connected to what hub. Normally, it is not necessarry to
change the structure of the network, but in cases of bad lag and/or missing
servers, you might have to use the commands /squit and /connect.
1.2.4.1 LEAF
------------
A leaf server is a server which can *only* be connected to one other server
at the time (even though it may have multiple C/N line pairs.) Attempting to
connect more than one server to a leaf will result in the "I'm a leaf, not
a hub !" message (see connection error messages below).
1.2.4.2 HUB
-----------
Hub servers are allowed to be connected to more than one server. This means
that if a hub server suddenly gets disconnected, many leaf servers will also
lose their connection to the network, and something must be done FAST. Usually
the servers has autoconnection lines, so they will automatically attempt to
reconnect themselves. Sometimes though, opers have to /connect the missing leaf
servers to another hub.
1.2.4.3 /SQUIT
--------------
/squit'ing a server will disconnect it from the server it is currently
connected to. It is almost only used with /connect, when a server for some
reason is connected to a wrong hub. The format of this command is
/squit <servername> [reason]
Although it is optional, a reason should always be specified.
You can use wildcards in the servername, and if more than one server match
the mask, the one closest to you will be squit'ed.
1.2.4.4 /CONNECT
----------------
/connect will make a hub server attempt to connect to a missing server.
If the connection fails, one of the messages below will be given. The format
of this command is
/connect <server1> PORT <server2>
where server1 is the missing server and server2 is the hub you want it
connected to. The port number should always be 5550 when connecting MicroSwift
servers.
1.2.5 CONNECTION ERROR MESSAGES
-------------------------------
NO C/N LINES
This may happen if either the originating server is missing a C:line (in
which case you get a "host not listed in ircd.conf" error), or if the target
server has no N:line for the connecting server (the error would be "no N:line"
then). Two servers need to have exchanged C/N:lines in order to be able to
connect to each other.
NO RESPONSE
No response is the a very common error, usually due to bad Internet routing,
or because the server computer is down. It means that there wasn't any kind of
response to the connect attempt.
WRITE ERROR
A "write error" means that the target computer is up, but it didn't accept
the connection to the specified port.
There are two common reasons for this error: either ircd is not running, or
the remote server thinks that the connecting server already exists on the
network.
This error could also be the result of a wrong IP-number in the connecting
server's C:line. In this case, the connection gets attempted to the wrong
computer entirely! That computer is not likely to have an IRC server running,
so attempts to connect to the ircd port will fail.
WRONG IP
If the target server's N:line has a wrong IP-address listed for the
connecting server, it will refuse the connection.
If the C:line has a wrong IP-number, then the error is likely a "no response"
or "write error" (see above).
BAD PASSWORD
In addition to other security measures, in order for two servers to be able
to connect to each other, their respective C/N:lines must have matching
passwords. The connection will fail with "password mismatch" or "bad password"
if the passwords don't match.
I'M A LEAF NOT A HUB !
The "I'm a leaf not a hub!" error means that a non-hub server would have
ended up with more than one server connection. Because this is not allowed for
leafs, the connection is rejected. This might happen, for example, if a leaf
hasn't noticed yet that its uplink connection to the hub has split, and another
hub tries to connect to it.
SERVER EXISTS
Another common error, especially in times of bad routing, is "server exists".
This means that the target server thinks that the connecting server already
exists on the network (as seen from its point of view). This happens typically
when a connection gets split but one server doesn't notice it as soon as
another, and then the other tries to reconnect back. It might also happen if
some other connection is lagged, in which case the message about the split is
lagged too and takes time to reach the "other side of the network".
1.2.6 THINK BEFORE YOU ACT
--------------------------
When dealing with routing, it is urgent to do some checking before SQUIT'ing.
This is, of course, because disconnection of servers is inconvinient for users
but it is also worth to consider the amount of bandwith used every time the net
needs to resynch.
This means that every time you want to move a leaf server to another hub, ALWAYS
assure that the leaf has the proper C/N lines for the new hub and vice versa
(use /stats x for that - see chapter 3 for info on the /stats command).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Chapter 3 - SOME IRC FEATURES FROM AN OPERATOR'S VIEW
=====================================================
This chapter discusses some old and familiar commands which gain a new
significance for operators. All of these commands are available for all
users of IRC, however they may not yield any interesting information for
non-operators. Some of them have extended usages available only for opers.
1.3.1 NETWORK STATUS
--------------------
The following commands are very useful in determining the network's current
status.
1.3.2 /LINKS
------------
The /links command is the fundamental tool in determining how the network is
currently set up, which servers are connected where, etc. It is available to
all users, even though it's only meaningful to those who are interested in the
current network layout. The command (in the basic form, without scripts) shows
every server-server connection on the network.
The output of the command varies between different clients. Additionally,
you can get scripts to modify how the output is shown. Therefore it is very
difficult to give an explanation here of how to read the list shown with the
command.
1.3.3 /STATS
------------
Stats is a command for retrieving server status and configuration
information. Despite the name, there is more than statistical information
available with this command. The available information is divided to two
categories, server configuration information (the various server "lines")
and server state information. For both of these the basic usage of the
command is the same:
/stats <letter> [server]
The <letter> is a single letter which determines what kind of information is
shown, see below for a reference table. You may specify a remote server from
which the information is shown. (Note that the info will then be requested
from that server, so the output is affected by lag and other network
conditions.) If you leave out the server, the current server is assumed.
You may also specify a nickname instead of the server, in which case the
information comes from the server which has that nickname's connection. There
is a special case with the "/stats l <nick>" and "/stats L <nick>" commands,
which actually show connection statistics for that client connection.
Server configuration lines:
/stats c -- C:lines, N:lines
/stats d -- D:lines, d:lines
/stats h -- H:lines
/stats i -- I:lines
/stats k -- K:lines, k:lines, autokill k:lines (shown as A:lines), Z:lines
/stats n -- C:lines, N:lines (same as /stats c)
/stats o -- O:lines, o:lines (these may not be shown for non-opers)
/stats Q -- Q:lines (note, capital Q only)
/stats U -- U:lines (note, capital U only)
/stats y -- Y:lines
Note that there might be no response if there are no such lines, especially if
the client hides the "end of /stats report" messages.
Server statistics:
/stats l -- connection stats (with user's resolved hostname if available)
/stats L -- connection stats (with user's username, IP address, and also
the connection port if opered)
/stats m -- command usage counts / data received for each
/stats q -- Q:lines introduced by Services
/stats u -- server uptime and highest connection count
/stats t -- debugging statistics
/stats w -- usage statistics
/stats x -- shows missing servers (based on the server's C:lines, use on
hubs, eg. "/stats x hubserver.*")
/stats z -- internal ircd memory usage statistics
This is a table explaining the l/L report output fields (in the order they
appear on the line). It's a bit hard to read in the raw format, so getting a
script to present it in a nicer and more readable format is recommended. In
any case, the most important number in each line is usually the sendQ, which
appears right after the connection name.
link name -- server name/nickname, with IP/hostname inside []
sendQ -- current sendQ size for the connection, in bytes
sent messages -- number of sent (IRC protocol) messages
sent kilobytes -- amount of data sent, in kilobytes
received messages -- number of received (IRC protocol) messages
received kilobytes -- amount of data received, in kilobytes
time connected -- time the connection has been up, in seconds
time idle -- time since a message was last received, in seconds
(this is the same number as seen with /whois, so
it doesn't count notices and other commands)
The only difference between "/stats l" and "/stats L" is in the link name
field, which shows slightly different information.
The l/L information is perhaps the most useful report, so here are a few tips
on using it:
1. It is very important for routing purposes, when used to view server
connections. It shows each connection's sendQ value which can be used to
determine if a link is failing or not, and monitoring the progress of a
resynch. The idle time also shows "dead" links, since server connections
should always have very low idle times, if not 0.
2. The "/stats l <nick>" report shows both the idle time as well as the
number of received messages and amount of received data. If the user is
not idle and is sending out a lot of messages or a lot of data, this could
be an indication that he/she is flooding.
3. The "/stats L <nick>" report shows the real IP address of the user, in
case he/she is DNS-spoofing. This can be used to trace the user later.
Make sure to get an exact timestamp of when the user was online, so the
ISP can determine which user was doing it.
The m, t and w reports are here, but since they aren't very important and
rarely used, it is not necessary for you to read it.
The output for "/stats m" looks like this:
*** PRIVMSG : 343262185 540850796
*** NICK : 20727440 1353933315
... and so on.
The first number is simply the usage count for the command, and the second is
the total amount of data that has been received with these commands. After 4GB
the counter will wrap, which is why in that example the figure for PRIVMSG's
seems so low, only 540MB. :)
The output for "/stats t" looks like this (the explanations are mixed in):
*** accepts 4876 refused 3368
This lists the number of accepted/refused connections.
*** unknown commands 1012 prefixes 142735
This lists the number of unknown commands and commands with unknown prefixes.
*** nick collisions 15102 unknown closes 3869
This lists the number of nickname collisions and connections which have been
closed while they still were unknown (before "registering" as a user/server).
*** wrong direction 62862 empty 0
Number of "Fake Directions" and completely empty messages.
*** numerics seen 8235520 mode fakes 0
Number of numerics and hacked mode changes.
*** auth successes 1465 fails 3676
Number of successful/failed ident lookups.
*** local connections 0 udp packets 0
*** local connections 0 udp packets 0
Local connection information (never really used nowadays).
*** Client Server
The following lines have two entries, one for client connections and one for
server connections (this is the header line).
*** connected 805 571
Number of client/server connections since server startup.
*** bytes sent 583143.566K 69452344.481K
Total amount of bytes sent to client/server connections.
*** bytes recv 71013.1003K 30203172.317K
Total amount of bytes received from client/server connections.
*** time connected 15209310 14566469
Total amount of accumulated connection time, in seconds.
1.3.4 /VERSION
--------------
The /version command shows the client and server version information. You
can also do this command "remotely" on a server, by giving the server name or
a suitable mask (usually, "server.*") after the command.
When used remotely it's possible to use this command to check for lag between
you and the specified server, because the reply message gets sent from the
other server. If you use the command and there is delay before you get a reply
(or there is no reply at all), it is an indication of lag. You may use
multiple /version commands to different servers to try to pinpoint which link
is the lagged one. Also do more than just a single check for lag, so you can
tell if the situation is getting better or worse.
1.3.5 /LUSERS
-------------
/lusers (short from "login users" or "list users") will show the current
number of users on the network and on your local server, the current number of
channels, the number of operators and the current number of servers connected
to the network and the local server.
This information can be very useful to an oper at times. First, the number
of servers is a good indication of whether there is a netsplit or not. Second,
if you do a few /lusers commands and the user count is rapidly rising, that
might mean there is currently a resynch in progress. If it's rapidly
decreasing, it might mean there's a netsplit in progress. Third, for IRCops on
hub servers, the number of servers connected to the local server can be very
useful in estimating its load.
1.3.6 /TRACE
------------
There are two different uses for the /trace command.
1.3.6.1 /TRACE <NICK>
---------------------
The more important use for /trace is when you specify a nickname after the
command, in which case you will be shown a "route" of all the servers between
you and the user whose nickname you gave. The usage is in this case:
/trace <nickname>
All the lines you will see originate from different servers (from each server
along the route), which means that this command is very useful when trying to
pinpoint lag. Unfortunately different clients show the command's output
differently, so the example output given here might differ from what's shown
on your client.
The nickname tracing functionality is available to all users, not just
IRC operators.
1.3.6.2 /TRACE <SERVER>
-----------------------
The second form of the command is used to list connections to a specified
server. Operators can see all connections, while normal users only see
operator connections (current opers on that server who aren't set invisible).
If you do not give any arguments, the local server is assumed. When used in
this way, the command's usage is:
/trace <server>
As usual, you may use "server.*" instead of the server's full name. This
method will show all the connections to the specified server, including
servers, operators, users and "unknown" connections.
Here's what the output (for opers) is composed of:
*** User <class> Nick[user@host] <sendQ>
*** Operator <class> Nick[user@host] <sendQ>
*** Server <class> <servers>S <clients>C <server[ip]> <connector> <sendQ>
Normal users see just the operator connections (invisible (+i) opers are not
shown, though).
Unless you have a script to filter out user connections, this form of /trace
is not very useful, except when used on hub-only servers which do not have
many clients.
1.3.6.3 USES FOR /TRACE
-----------------------
The uses of /trace might not be readily apparent from the description. The
more often used function is with the first form, when used on a nickname.
Since each of the lines you see are sent by each server along the "route", this
is an effective way to pinpoint lag.
The other uses of /trace are not needed so often. By using the server-form
and listing all the connections on a server, you can see all the unknown
connections to a server. Unknown connections are (usually) clients which
haven't yet registered (sent a nickname and user info). However, if there are
a lot of them and from the same host/IP address, it can be a sign of malicious
activity against the server.
Another thing to remember is that you can see the sendQ values for the
nickname/server when doing a /trace, and this is a way to monitor them.
Usually using "/stats l" is better, though.
Finally, non-opered clients may use "/trace <server>" to list all the
operators on that server. This is one way of finding IRC operators. However,
it's generally preferred that the /who command would be used instead (for
example, "/who 0 o", "/who ** o", "/who -oper" or "/who <server> o", depending
on your client and what exactly you want to see).
1.3.7 OTHER COMMANDS
--------------------
The following commands have extended use for opers beyond what normal users
can use or see.
1.3.7.1 /HELP AND /HELPOP
-------------------------
The /help command is part of the HelpOp system.
The only difference between /help and /helpop, is that using /help with no
parameters will give a list of all the commands known to the server.
The HelpOp system is being designed to provide better help for users. Any
user may use the /helpop command to send a help request. These requests are
passed to all helpops (users with the +h usermode set) currently online.
The +h usermode is available to all opers but also to non-oper members of the
help team with special services access to get +h.
1.3.7.2 /NOTICE AND /MSG
------------------------
MicroSwift's ircd supports extra formats for sending notices (and messages) to
channel ops, and channel ops and voices. To send a notice to only the ops of
a channel, use the format:
/notice @#channel message text
And for both ops and voiced members:
/notice @+#channel message text
These are strongly recommended to be used rather than any client-side solution,
as those may result in the user triggering the ircd flood- and spam-message
limitations. There is no danger when using these new notice/message formats.
These can also be aliased/scripted on most popular clients, and this is
recommended.
IRC operators have the additional possibility of sending global notices (and
messages, but that is not usually done). The recipient group can be specified
by either as users on certain servers or users with a certain address.
To send a notice which goes to all users on servers which match a given mask,
use the format
/notice $<server-mask> <message>
So, in order to send a full global notice to all users online, you can use:
/notice $*.MicroSwift.net <message>
Or to send a message to users of a particular server (for example,
MicroSwift.oh.us.MicroSwift.net), you can use:
/notice $MicroSwift.oh.us.MicroSwift.net <message>
To send a notice which goes to all users whose address matches a given mask,
use the format
/notice #<address-mask> <message>
Users who receive a global cannot usually tell that it is a global notice
or a server/domain notice (as opposed to a private one), so you should indicate
this in the message. You should also politely request that no replies are
sent, or you might get flooded with replies.
A good possible alternative to globals is using wallops.
In addition to global notices, it is very easy to send server notices. These
can be used if the information is relevant only to the users of one, single
server.
1.3.7.3 /WHO
------------
When opered, you will be able to see the normally invisible users (clients
which have the +i usermode set) with the /who command. Such users will have
the percent sign ("%") shown after their nickname in the /who list. Usually
someone being invisible means that they do not want to disturbed. Be discreet
and do not approach anyone +i unless you could have "found" them by other means
(for example, you are in the same channel with them), or unless you are going
to talk to them in your role of IRC operator. Never reveal information about
such users to anyone, except to other opers (in the case of abusive users).
This access is only given to opers so they can detect clonebots and abusive
users who set themselves +i and change nicks in order to escape attention from
opers. It should not be used to, for example, spy on anyone, or to find people
in hiding for their "friends".
If you've not used the /who command a lot before, here's some advice:
You can use wildcards with the command, and it will look for a match in EACH
of nickname, username, hostname, ircname ("real name") and servername. So if
you give a command such as "/who user@someisp.net", it will not show any users
because there is no user who has "user@someisp.net" in their username or
hostname. If someone's email address would be that, and he/she had placed that
in the ircname field, then that person's information would be shown though.
To look for users from a particular site, you would use a command such as
"/who *someisp.com". You could also give an exact hostname, without the
wildcard. A command of "/who *joe*" will list all users who have "joe"
anywhere in their nickname, username, hostname, ircname or in the servername.
A "/who *.net" would list ALL users on MicroSwift.net, not just those coming from
".net" addresses, because all the server names end in ".net"!
1.3.7.4 /MOTD AND /ADMIN
------------------------
The /motd command is useful for finding information about a server, its staff
and special policies it might have. MOTD stands for "Message Of The Day",
although it's rarely updated daily. Used alone it will show the MOTD info for
the local server. If you add a server name (full name, or a "server.*" mask)
after the command, the MOTD for that server is shown.
There is nothing new in /motd for opers, but it deserves mention as a
possible tool for opers to get information about a server.
The /admin command works similarly. The only difference is the text shown,
the server admin's contact information.
/admin <optional server>
1.3.7.5 /NICK
-------------
You may wonder what new features such a familiar command as /nick has.
Well, it really doesn't -- but when you are opered, you may also switch to
Q:lined (juped) nicknames, like "Management".
1.3.8 USERMODES AND SERVER MESSAGES
-----------------------------------
As you might already know, on IRC each user may have "modes" set, just like
with channels. Some of these usermodes are available to all users, while
others on MicroSwift are reserved only to IRC operators. Usermodes can be thought
of as "settings" for the user, and remain even if the nickname is changed.
Usermodes can be changed with the /mode command:
To set /mode <Your Nick> +<modes>
To remove /mode <Your Nick> -<modes>
If you set the usermodes mentioned in the following it means that you will
see additional information (sometimes a lot of it) not usually seen by normal
users. It is a good idea to set up a separate "operator window" with all the
operator messages going there, instead of getting them mixed with regular IRC
messages.
1.3.8.1 USERMODE +o
-------------------
IRC operator status is actually designated by the +o usermode. Unlike other
usermodes, it is set by using the /oper command successfully (you need to be on
a server with an O:line for you, and use the right nickname and password as
well as your current address must match the mask specified in the O:line). You
cannot use the normal form "/mode <Your Nick> +o". The +o is otherwise a
normal usermode, and as such will remain with you even if you change nicks.
You may "deoper" (remove the IRC operator status) by using the normal "/mode
<Your Nick> -o" command.
While you have the +o usermode set, anyone who does a /whois on you will see
the text "* Nick is an IRC operator" (or whatever the message looks like on
his/her server). Also, in any /who or /names list an asterisk ("*") will be
shown after your nickname.
1.3.8.2 USERMODE +s
-------------------
The usermode +s indicates that the client will receive server messages.
There are many varied server messages, too many and different to list here.
This is the basic "administrative information" usermode on IRC, since it
controls seeing most normal server and network status or information messages.
A lot of the messages (for example, many of the Services kills) might not be
something you really want to see, and which just make the things you are
interested in seeing that much harder to see. It is possible to come up with
"filters" for limiting the type of messages you see, and indeed many operators
use such scripts. However, you should be careful not to filter out any
important messages.
The +s usermode is available to all users, but opers will see some
additional messages with this mode.
1.3.8.3 USERMODE +w
-------------------
The usermode +w means that you will see wallops-messages.
The +w usermode is available to all users. It is assumed that users who are
interested in "what's going on in the net" will likely have +w set, while other
users won't. As an oper it's a very good idea to have the +w usermode set
always when on MicroSwift Net, even when not opered.
Wallops are means of "announcing" network/server matters to
interested users (those who have set themselves +w) and communicating about
these issues between opers. When using them you should keep in mind that they
can be seen by normal users, in particular avoid any security-related topics
(discuss these in globops instead). Wallops should not be used for chatting
among operators, join a channel for that.
1.3.8.4 USERMODE +g
-------------------
When you have the +g usermode set, you will see the globops messages. Many
server/network messages are sent as globops, in particular server connection
status notices (connection broken, connection established, etc.). For those
people who both have the +g usermode set and are opered, the oper-only globops
messages will be displayed.
The +g usermode is available to all users. It is a good idea to have the +g
usermode set at all times, so that you can monitor network activity as well as
see the globops sent by other operators when opered.
Globops are a secure means of communication for IRC operators. They are
meant for discussing any network issue, although extended chats should be taken
to a channel or discussed on a mailing list. Personal messages such as
greetings are not allowed.
1.3.8.5 USERMODE +c
-------------------
The +c usermode means that you will see client connect and exit notices for
your server. These can be monitored for suspicious connects or exits, for
example clonebots connecting or users disconnecting with the "Excess flood"
message which indicates a possible flooder. The mode is also sometimes useful
for debugging purposes.
The +c usermode is only available to opers. If you deoper, this mode will
be turned off. Unless the server only has few client connections, monitoring
them will be next to useless..
1.3.8.6 USERMODE +k
-------------------
The usermode +k controls whether you will see server originating kills or
not. These include mostly nickname collision kills and the like, and some
kills done by Services.
The +k usermode is available to all users.
1.3.8.7 USERMODE +f
-------------------
The +f usermode allows you to see anyone who quits with the "Excess flood"
disconnect message. You will see a message which resembles:
*** Flood -- bleh!bah@148.210.116.224 (9110) exceeds 8000 recvQ
In this example, 9110 is the actual size of the queue, and 8000 is the limit.
This means that the client has sent more than the allowed amount of data
during a short period. When you see this message, the user has already been
disconnected. However, it might be a good idea to look for other clients from
the same address. For instance, the client might have been a flooding
clonebot. Repeated flood disconnects of users from the same address is another
sure warning sign.
The +f usermode is only available to opers. If you deoper, this mode will
be turned off.
1.3.8.8 USERMODE +h
-------------------
The usermode +h turns you into a HelpOp. A new line will be added to the
information shown about you with the /whois command that resembles:
*** YourNick looks very helpful.
This allows you to see messages which are sent via the /help command. The
HelpOp messages are sent by users who need help with something.
Any /help messages you send while set +h are also shown to other HelpOps,
which is useful for discussing and coordinating the answers to the help
requests.
The +h usermode is normally only available to opers. However, you may keep
this usermode even after you deoper.
Non-oper members of the help team without olines on a server have special
service access that allows them to attain the +h usermode.
1.3.8.9 USERMODE +a
-------------------
Usermode +a means that the user is a Services Administrator. When set +a,
you can use Services Administrator commands.
When you have the +a usermode set, your /whois reply will show
*** YourNick is an IRC Operator (Services Administrator)
instead of the of the normal "is an IRC Operator" line.
This mode is only available for specified operators.
1.3.8.10 USERMODE +A
--------------------
The +A usermode signifies a server admin.
When you have this usermode set, your /whois reply will show
*** YourNick is a Server Administrator
instead of the of the normal "is an IRC Operator" line.
Like the +a usermode, whether this usermode is available is defined in the
O:line. Naturally, it is not available at all for non-opers. When deopering
this mode will be removed.
1.3.8.11 USERMODE +b
--------------------
usermode +b, enables chatops. When set on, you will see any chatops messages
sent by other operators. You will also be able to use the /chatops command to
send chatops.
The +b usermode is only available to opers. However, you may keep this
usermode even after you deoper.
1.3.8.12 USERMODE +d
--------------------
Usermode +d enables you to conceal your hostmask to users.
An example is as follows (not real conversion):
nick!ident@user123-23089.isp.net --> nick!ident@aje4394kd.isp.net
This prevents other users from seeing the users real IP, however IRCops can see
the true IP of a user by doing /whois on the user.
1.3.8.13 USERMODE +j
--------------------
Usermode +j enables you to see 'JunkOps' server messages. There is no reason to
have this usermode except when a member of the ircd coding team is diagnosing ircd
erros. Usually, this will just flood you with useless junk.
1.3.8.14 USERMODES +C and +R
-----------------------------
The +C usermode makes you CSOP and the +R is for Services Root Administrators.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
=====================
Part 2 - NICE TO KNOW
=====================
This part will give you some advice that can be useful in some occasions.
Although this section will ie. recommend that you use OperServ to clear
modes on a channel, it doesn't mean you are justified to do so in every
similar occasion - that is completely up to the TOU.
Chapter 1 - HOW TO DEAL WITH...
===============================
2.1.1 DESYNCHS
--------------
First, make sure it's REALLY a desynch. Connect to different servers and
look at the situation from many different "viewpoints". Check whether the
info appears the same or different, and that there is not a split or synch in
progress.
Desynchs are rather rare, but they do happen occasionally. They mostly
happen in times of bad lag and splits (ie. bad network conditions overall on
the Internet), and when things get better the desynch usually disappears too.
There are various means to clear a desynch. These vary depending on whether
it's a channel or a nickname which has been desynched. Channel desynchs can
be cleared by clearing a channel completely. If available, you may also
attempt to use the OperServ mode command. For nicknames, issuing a kill for
the nickname or (for ghost nicks) using that nick on some other server might
clear the desynch. Disconnecting a desynched server and reconnecting it back
is another option. Sometimes the problem might be that a resynch never really
finishes, in this case the server will split eventually again.
Desynchs are elusive by nature, and it's impossible to say what exactly will
clear something. Squitting and reconnecting the desynched server(s) should
always fix it though, as it forces the servers to start synching their
databases from scratch. Also getting an oper on the desynched server to look
into the thing from the "other side" is a very good action to take. Sometimes
desynchs can only be effectively fixed from one side.
2.1.2 LAG
---------
Lag is one of the most common problems on IRC. As an IRC operator, you can
actually attempt to fix it -- however, you should take care to investigate the
situation and make sure that you don't make the situation worse. The solution
to lag is to reroute, and that means actually breaking a connection, so it
should only be tried if the lag doesn't seem to get better with time. Under
most circumstances, lag will either disappear with time or break the connection
anyway, so operator interference is not usually needed.
If you notice lag and want to see if it can be fixed, the first thing you
should do is try to pinpoint what is causing it. Make sure it's not your OWN
connection to the server (ping yourself, if this takes a long time then you are
lagged to the server). If that is not the problem, then you should try to use
pings, /traces and /version commands to try to figure out the lagging link.
You will also need to use /links to find out the current network layout.
After you have found out the lagging link, and are sure that it's not going
to improve on its own, you can attempt to reroute that connection. Be SURE to
contact other opers before doing this.
2.1.3 USER REQUESTS
-------------------
IRC Operators are expected to have great knowledge about IRC, the netiquette and
the features/services available on the network. Some normal users don't, and in those
cases, operators are expected to provide the necessary explanations and answers, which
is what this section is all about.
When helping users, it is important to be patient and friendly. This network has no use
for arrogant opers.
Sometimes an oper cannot (or will not) help a user. In those cases, the only right thing
for the oper to do, is to politely ask that user to find another person to ask (if necessary,
also instructions on how to do that). Scenarios like:
<User> Hey, how do I remove someone from my silence list?
<Oper> Buzz off lamah, I'm busy
only shows one thing: that oper should never have had an O:line on a MicroSwift server.
Remember that one of this networks' key priorities is to provide H-E-L-P to users.
Naturally, the reply in this case should have been something like
"I don't have the time to help you right now, try in #MicroSwift".
Fortunately, 99% knows and follows this, so I won't make a bigger deal out of it.
Answering questions is the easy part; When users request that you fx. /kill another
user or reop him/her in a channel, you have to think and investigate.
Depending on the situation, there are a few useful methods to determine whether or not
the user is actually telling the [whole] truth (and what to do about it).
FLOODING
If a user claims to have been flooded, you should ask for nicknames of those involved
and logs. Examine the logs and do a /who, /whois or /whowas on the claimed flooders.
Also, use /stats l nickname to view the sendq and recvq of a certain person.
Generally, if the results from the /stats l are unnaturally high, and/or you find clones
from the hostname of the claimed flooder, the reporting user was most likely flooded, and
the appropriate action towards the offender should be taken.
OPLESS CHANNELS
As a rule of thumb, you should not use /samode or OperServ mode to op regular users - the
channel administration should take care of the opping, through ChanServ. In case noone with
ChanServ access is present and someone is abusing the channel (ie. flooding it), a good idea
would be to op yourself in the channel, deal with the abusers and leave the channel again.
Naturally, if there is no abuse on a channel, there is no need for opers.
WAREZ
Generally speaking, warez trading is disallowed (and illegal) but it is often very hard to
determine whether or not two users are actually trading or just talking about the subject.
This means that it is often hard to do anything about it when users complain about warez
trading. It can of course be investigated by joining the channel and have a look around.
Although some opers may think warez trading is ok, keep in mind that it is not allowed
according to the TOU which must followed at all times.
NUKING/DOS
This is a tricky one because there is no way to determine whether or not a user is telling the
truth. Of course a user's firewall might have logged a nuking attempt, but they can (like IRC
logs) easily be faked. If several people report the same user or you get nuked yourself, perhaps
there will be enough "evidence" to take actions. Sometimes, a lamer might even try to nuke off a
server. Either way, anyone who gets "caught" nuking somebody else should be punished severely,
especially when the target is a server. You should also advice the user to report the incident to
the local authorities and/or the offenders ISP.
Since firewalls can protect users from being nuked, recommending to install one might be a good
idea also (free ones can be found on the Internet).
CLONES
IRC operators are normally able to see invisible (+i) users (it is a server configuration issue)
and because of that, finding clones isn't very hard (/who hostname). Actually I only wrote this
section to remind you that when you set akills in order to get rid of clones, you have to inform
the Kline Team about it. (see chapter 2 for email addresses.)
Apart from that, it might also be a good idea to write a nice letter to the offenders ISP to
complain and asking them to take further actions against him/her. If it is a repeated problem from
the same person or several persons from the same ISP, your letter should include a warning stating
that if more of their users are found to be abusive, the entire domain will be banned.
There are no certain ways to determine anything in the situations mentioned above. Do what you feel
is right and don't hesitate to ask other opers for their opinion. Remember that you will be held
responsible if you suddenly akill someone without a proper reason :ž
If a user reports something that is not directly abuse but still not allowed on the specific server
(bots on a non-bot server is an example), you should pass that matter on to IRC operators on that
specific server.
You will most likely experience situations more serious than those mentioned above. A few years
back a user reported to me (on another network) that she had recieved msgs from someone who
threatened her and her two real-life kids. That is not so much out of the ordinary, except that for
some reason, this guy knew where she lived.
In cases like this one, /kill'ing around won't solve anything, and the only thing you can do is to
tell the user to report the incident to the police (or another proper authority).
What I'm trying to say here is that when you encounter things that can't be handled through IRC,
contact the offenders ISP or the police if it is against the law.
2.1.4 MASKING
-------------
When it comes to setting k:lines and akills, it is important to use the most fitting masks.
You should already know this, if not from k:lines, then from ignores and channel bans. However,
when setting server bans, the need for a correct set mask becomes more obvious. It is important
to keep in mind that server bans are only intended to affect one person or a small group, very
rarely an entire ISP.
When being on IRC a user can have either a dynamic or a static hostname, and it is important to
distinguish between those two types.
A static hostname (or IP) does as the name suggests not change. Typically it is easy to know a
static hostname from a dynamic one. Static hosts usually consists of "normal", readable words
followed by the second and top level domain. Examples of static hosts are:
irclink.superlink.net
silver.MicroSwift.net
marvin.hitchhiker.net
Behemoth.uk.eu.MicroSwift.net
Users with a dialup ISP account are normally assigned what is known as a dynamic hostname or IP,
which will change to something else if the user reconnects to his ISP. This means that the lowest
level domain usually will be automatically generated and consist of both letters and numbers.
Examples are:
ip5412.slnxr.ras.tele.dk
ppp0254651.dialup.netins.net
isl90001.image.dk
But why is it so important to know the host type when setting akills and k:lines? Simply because
banning fx. *@static.domain.com is entirely different from banning *@dynamic.domain.com.
First off, the risk that many users use the same static host is much higher than the risk that many
users share the same dynamic host. This means that banning *@something.static.com is more likely
to affect innocent users than banning *@37854df.lamers.net would be. Solution? When akilling a user
with a static domain, try to use either of these two bantypes:
*username@something.static.com or
*username@*.static.com
in order to narrow down the number of affected users.
The latter should be used with caution because depending on the domain, you might block a lot of
potential users who happen to have the same username. Banning *ask@*.aol.com for instance, wouldn't
be very smart.
This rises a problem however, because depending on various things, the user might be able to switch
to another username very easily. In those cases, where an abusive user keeps changing username, you
will have no other choice but to ban the entire static domain and write a complaint to the user's
ISP, also informing them about the ban.
If an abusive user has a dynamic host/ip you can in most cases safely assume that he/she is the only
person with that exact hostname, which allows you to ban
*@54g56f4.dynamic.com or
*username@54g56f4.dynamic.com
The first one is preferred, because it forces the affected user to reconnect to his/her ISP in order
to get back on the network. Of course there are cases where several machines share the same dynamic
host, where you should add the username as well.
Again, it can be hard to tell if any innocent, potential users will be affected by a ban and in
some cases you will just have to use your common sense. Always remember to do a /who <banmask>
before you actually set the ban.
Chapter 2 - USEFUL INFORMATION
==============================
This chapter will briefly describe the MicroSwift teams which you definately will encounter,
and a list of useful email addresses and http links.
2.2.1 THE COMPLAINTS TEAM
-------------------------
This team, handles all complaints from users and opers, ie. complaints about oper abuse and the such.
Please visit http://www.hyrule.net should you need to contact the complaints department.
2.2.2 THE KLINE TEAM
--------------------
The KLINE team is responsible for all global AKILLS, i.e. not local klines - which is an admin duty
to review. Should a user or oper have an issue regarding some AKILL, this is the team to turn to; to
appeal AKILLS.
The Akill will be reviewed and MAYBE (depeding on the judgement of KLINE) over-turned. You will be
contacted when a judgement has been made.
Further discussion can be had @ http://www.hyrule.net - however kline-team reports are not accepted
there and will be deleted.
2.2.3 THE WEBTEAM
-----------------
That would be me, Dustin. =P
2.2.4 THE CODERS TEAM
---------------------
Dustin codes everything. =P
2.2.5 EMAIL ADDRESSES
---------------------
Contact an oper on the chat or Dustin on Hyrule.net
2.2.6 LINKS
-----------
MicroSwift: http://www.microswift.com
Stats: http://irc.microswift.com/stats/
Hyrule: http://wwww.hyrule.net/
2.2.7 CREDITS
-------------
Some parts taken, with permission, from "The New Dalnet Opermanual," by Mikko Hänninen, Wizzu @
DALnet. This document was originally composed for the MicroSwift IRC Network in 1999 by Soren S.
Nielsen, formerly known as Gizmo. Also from contributions from Charles.
|
