IRC Operators Guide    Aaron Brinton (aaronb [aaronb@telanis.com])  v1 8/97
===========================================================================

	The objective of this document is to provide some basic operator notes
from my perspective.  I've found that asking opers questions usually
results in nothing more than smart-ass answers, which I think is a little
sad.  I'm a relatively new operator (under two years), so please understand
that I'm not an ordained expert on this material, and that some of the
information may only apply to my network (EFnet).  If you find errors in
here, either typographical or conceptual, please let me know.

Note:  There will be personal views in here, but I'll try to keep them to a
minimum.


===========================================================================

Contents

   I. Interacting with Users and Other Operators
  II. Using KILL and KLINE
 III. Bots and Bothunting
  IV. Cloners, Flooders, and Spoofing
   V. Why Operators (Usually) Don't Get Involved In Channel Affairs
  VI. Dealing with "How Does One Become an IRC Operator?"
 VII. IRCD and Associated Files
VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)
  IX. Server Routing and Connectivity
   X. Other Server Commands (REHASH, RESTART, and DIE)
  XI. Operator Communications (WALLOPS and OPERWALL)
 XII. Linking New Servers
XIII. Attitude and Perspective


===========================================================================

I. Interacting With Users and Other Operators

	This is the most important aspect of "opering".  It will make or break
you as an operator.  There are a lot of politics that go on in the irc
operator community and, whether you like it or not, these politics are here
to stay.  Fighting this and complaining about it will get you nowhere.

	From what I've seen, most opers look down on users, make fun of them,
and ignore them.  Try to avoid this ego trip side of opering.  Answer
private messages, unless it is someone just sending you a hate message.
Opers would get a lot less crap from users if they would be a little less
egotistical.  Something I might suggest is that you spend an hour or two
every couple of weeks helping the newbies out in #irchelp or whatever
equivalent you may find.

	One thing to be wary of is that users will frequently try to manipulate
you into helping them takeover channels.  Very rarely will a user simply
report a bot without a reason.  Generally this will be because a bot
tookover a channel or a user is flooding them.  Fairly regularly you'll get
these requests from users who want someone killed off the server so they
can take control of a channel. Because of this, request the channel in
addition to the nickname so you can see what's going on before you kill or
K-line.

	Frequently, you will get requests from other operators to kill or
K-line a user.  Opers should be trusted unless you've had problems with
someone in the past.  You should always require a reason before killing or
placing the K-line.  If it's in the least bit questionable, add "requested
by <oper>" or something similar to the K-line reason.

	If you are being harassed by a user on the network, handle it like a
user should handle it, not like an oper has the capability of handling it.
The temptation of killing a user for flooding you is something that pretty
much all of us give into on occasion, but it's generally not the right
response.  If we are going to expect regular users to simply /ignore
flooders, then we should do the same.  Though I have to admit, a user must
be pretty stupid to flood an oper...

	On occasion, opers have their disagreements.  There is a bit of a
pecking order that exists in the oper ranks, usually with hub admins and
opers being more "powerful" than leaf admins and opers.  It's generally not
a good idea to try to win an argument with the people who are providing
your connectivity to the IRC network.  For that matter, it's generally not
a good idea to try to win any argument at all.  If you do have a serious
problem with another oper, and can't resolve it directly with him/her, go
to your admin about it.  Your admin can then approach the issue with the
other oper's admin, and if that goes nowhere, with their uplink admin.
This is a quick way to make enemies, so make sure it's important to you
before doing it.


===========================================================================

II. Using KILL and KLINE

The KILL and KLINE commands are as follows:

	KILL nick :reason
	KLINE nick :reason
	KLINE username@hostmask :reason

	In my K-lines, I always use "reason [aaronb MM/DD/YY]" so that the user
knows when and by whom they were K-lined, and also so that I am accountable
for my K-lines.

	Generally, whatever you do on your local server really is not a big
deal.  Different servers have different policies on using KILL and KLINE,
but if you are doing global kills (killing a user on a different server),
you need to make sure you understand what the IRC network's guidelines are.

	Users tend to have one of two reactions to kills.  Occasionally you'll
get the user to cool off and realize that they need to fix whatever they
are doing.  More often, they will want to argue the point with you.  Try to
explain it to them, but if they don't seem to be willing to follow the
server guidelines, just K-line them.  After they get K-lined from a few
servers, they'll figure it out.

	You probably want to avoid K-lining users unless it's really necessary.
A K-line means that you don't want that user on your server, for whatever
reason.  Depending on the server, K-lines may be cleared after a week or
two, a few months, or maybe never.  It might be wise to have a "permanent"
section of K-lines, and then the rest can stay or go at anyone else's
discretion.  For clearing K-lines, generally it's a good idea to talk to
the person who placed it before doing so.  With access to ircd.conf (to
remove K-lines), you can be a lot less cautious about placing them.

	The best guideline for doing global kills is to ask yourself "is this
really necessary?"  You can usually find an oper on the server the user is
on to handle an issue for you instead.  If an oper on the server won't do
it, then probably they wouldn't like you killing the user off their server
either.

	Frequently it seems that opers are just looking for a reason to kill.
Probably if you are in that mood, it would be a good time to deoper and go
find something else to do for a while.  Killing like that looks bad for
both you and for your server.

	It's a wise idea to keep logs of everything you do.  I have yet to see
a client that doesn't have the capability of logging.  If a user or another
oper challenges your kill (usually to your admin, since they typically
don't have the guts to talk to you), you can provide them.  You will most
likely be accused of abusing your O-line, and threatened by users to get it
taken away, on a regular basis.  Logs are your best defense.


===========================================================================

III. Bots and Bothunting

	A "bot" generally refers to any automated program or client that
doesn't have a person sitting behind it, not just a program that is called
one.  If a client is idle for several hours and is behaving like a bot,
it's usually considered one.

	There are a couple of reasons why bots are frequently considered to a
problem.  First, they take up resources on IRC that could be used for
regular client connections.  The primary reason, though, is because bots
are frequently used to flood and harass users.  You'll want to check what
your server's policies are regarding bots, but an abusive bot should never
be tolerated.

	Finding bots generally isn't that difficult.  Many have ctcp responses
that don't match what you would expect, or have bogus idle times (in their
ctcp finger response).  Also, there are a couple of good portscanners that
can help you check hosts for bots (eggdrop bots usually listen on a port
for incoming telnet connections).

	You probably aren't going to find all the bots being run by hardcore
botrunners.  They generally find out quickly about whatever new bothunting
methods we come up with and spread the word.  With these, your best bet is
to wait until someone complains about it, and then monitor its behavior.

	Here is a short description of a few of the bots out there, and a
couple of tips for finding them:

	* eggdrop - this is the most common bot that you'll run into.
Typically you'll see "/msg botnick hello" in the gecos field (the
description line in the whois information) if the bot is poorly configured.
Additionally, by default, these bots PRIVMSG #lamest for invite/ops.  They
also join #botcentral by default.

	* johbot - these bots PRIVMSG blahb1ah on a regular basis.  If you
change your nickname to that, you can sit and wait for them to find you.
Additionally, if you enter the channel a suspected johbot is in, and do a
fake netsplit quit (/quit irc.blah.com irc.something.net), the johbot will
automatically change its nickname.

	* combot - these are a comstud creation.  I have never found one
myself, which either means there aren't many around, or they just hide
really well.  I've heard that doing a /ctcp botnick source will generate a
reply with "Combot" followed by the version.

	There are other methods of finding bots, but they change far too
regularly for this document.  Also, we don't need to be giving the masses
out there all of our secrets.  Keep in touch with other opers on this
stuff.


===========================================================================

IV. Cloners, Flooders, and Spoofing

	Clones are multiple clients from the same person.  Most servers define
this as multiple connections from the same hostmask (matching
user@*host.tld).  If it's obvious someone is running multiple clients from
different domains, they are also considered clones.

	Generally, cloning itself is not all that bad (just taking up
connections).  Frequently when you see clones, however, they are being used
to flood users or takeover channels.

	The best approach to take with clones is to kill them, and see if they
return.  If you do this a couple of times, and the user insists on keeping
them on, it's time for a K-line.  Unless a user is consistently a problem,
clone K-lines should be relatively temporary (a few weeks is sufficient).

	You'll see two forms of flooding on IRC.  The first is CTCP flooding,
which attempts to get a user to flood the server with CTCP responses,
tripping the server's flood protection, and terminating the user with the
message "Excess Flood".  Many bot networks ("fludnets") use this type of
flood.  Flood protection scripts may prevent this from being very
effective, but the real problem is the impact on the network.  If 20 bots
flood a user for 10 seconds, sending five 100 byte CTCP requests per
second, that is 20 * 100 * 5 = 10k/sec, or 100k of data total over the 10
seconds.  When a network that is maintaining 30000 users, this sort of
activity is not at all acceptable.

	The second type of flooding, which is not related to IRC (but is
frequently the result of conflicts on IRC), is ICMP flooding.  This is
usually done from a reasonably fast link (ISDN or higher) and consists of
flooding a user or server with ICMP packets (such as ping).  This is
considered a "Denial Of Service" attack, and is against the law.

	There are many flooding scripts out there right now, and a couple of
these have supposedly "random" nicknames they use for CTCP flooding.  A
trick to use is to set a couple of those nicks in your notify.  Some
flooding scripts also have the clones join specific channels (e.g.
#srfloodclones).

	DNS spoofing is a relatively new hit these days on IRC.  You'll
generally find spoofs one of two ways - you're watching the connections
(usermode +c) and an unusual hostmask appears, or a user reports one.  The
first thing to do is to get the user's IP address (/stats L nick), and
check to see if the DNS lookup matches the IP address.  If it doesn't, you
know you have a spoof.  With this information, you can KILL the spoof, and
when it reconnects, see where the real host is and issue a K-line (which
won't stop them from spoofing again, but will prevent them from signing on
*without* spoofing).  Some servers have the capability of D-lines, which
allow you to ban by ip mask.  A D-line will prevent the client from
connecting at all, regardless of whether they try DNS spoofing or not.  If
the server supports the DLINE command, you can do /dline ipmask :reason.


===========================================================================

V. Why Operators (Usually) Don't Get Involved In Channel Affairs

	The primary function of opers is to maintain the servers and the
network, not to deal with channels.  The main reason the general policy is
for opers not to get involved is because it is frequently difficult to
determine who really should be controlling a channel.  There are a lot of
deceitful users out there that will ask you to help them get their channel
back when it is not their channel in the first place.  Even if you do know
who the regular ops are, oper involvement is questioned and challenged, so
many opers will ignore channel issues entirely just to save the grief.

	In practice, you'll find opers defend their own channels, and turn
their backs on others.  It's a little pathetic, but after you get harassed
enough by users saying "why are you getting involved?  I thought opers
weren't supposed to get involved in channel affairs" you'll start to
understand the cynicism.


===========================================================================

VI. Dealing with "How Does One Become an IRC Operator?"

	Most users have no comprehension of what opering involves, and really
have no place becoming one.  This does not mean, however, that they deserve
an abusive answer or to be blown off when asking how to become an operator.
It's easy to set up a simple alias to provide an automated response to this
question.

	For example, use an alias like "Becoming an IRC Operator requires not
only a strong working knowledge of IRC and this IRC network, but also a
working relationship with hub admins and other opers.  Opers are selected
when there is a need, and never given based on who is asking for it."

	The thing to remember is that there are always going to be more people
that want to be an operator than there are openings.  If you really want to
help the network, the best way to do it is by answering new user questions
on channels like #irchelp and #help.


===========================================================================

VII. IRCD and Associated Files

	IRCD is the server daemon process.  The large IRC networks will only
allow unix-based servers, because they are the only ones proven to perform
adequately on a large network (and because the current set of operators are
mostly unix bigots... including myself to some degree).  EFnet uses
modifications of the 2.8.2 version; IRCnet uses modification of the 2.9.x
versions.

	The installed file structure varies from server to server, but you
should have at least these two primary files:

	ircd			the IRC server daemon (main program)
	ircd.conf		the server configuration file

	The configuration file has various configuration items in it, which are
in a format beginning with a letter and a colon.  This file is read and
processed backwards, so when you do STATS commands (described later),
you'll see the information in the reverse order of the entries in
ircd.conf.	This file has the following configuration lines in it:

A:Company/Institute Name:Server Description:Admin Name <email@address.com>

	This configures the administrative functionality of the server, which
is returned when a user does /admin on your server.  The fields are
completely up to the administrator of the server, but what I put above
seems fairly standard.  This is a mandatory field.

B:hostmask::nick::

	This line indicates a permitted bot.  The server has built-in bot
checking for certain known instances of bots, and will refuse the
connection if it detects one.  If the bot matches this line in ircd.conf,
the server will not refuse the connection.

C:server hostname:password:server name:port:connection class
N:server hostname:password:server name:hostmask:connection class

	C/N-lines are connections to other servers.  The C-line defines what
servers your server can connect to, and the N-line defines what servers
your server allows incoming connections from.  I have never seen one
without the other, and according to the sample ircd.conf, they must be used
in pairs.  The server hostname, password, and servername are fairly self
explanatory.  The port is used to identify which port your server will try
to connect to automatically; if the port field is blank, your server will
not automatically attempt to connect to that server.  I have never seen the
hostmask used (nor do I really understand what it does).  The connection
class is numeric, and defined in the Y-lines.

D:ipmask:reason:

	This line is used to ban a block of IP addresses.  If a system
administrator has control over several domains, he/she may attempt to avoid
bans by changing the reverse DNS lookup on the host (a perfect example of
this is smartec.com, who has several domains and several machines all on
one Class C).  With a D:line, you can ban 205.230.73.* (smartec) and nobody
from that address space can connect, regardless of DNS lookup.

E:hostmask::username

	The E-line protects certain users from server bans (K-lines).
Generally operators use them to protect themselves from accidental K-lines,
but in some cases, a server run by an ISP will also use them to protect
their customers.

H:remote servers permitted::hub server

	This defines a hub server, which is a server that may have other
servers connected behind it.  The "remote servers permitted" is usually "*"
or may have a hostmask to limit the remote connected servers to within that
mask.

I:address mask:password:domain mask::connection class

	I-lines define what clients are allowed to connect to your server.
Additionally, they define what connection class (defined by Y-lines) the
client is placed in.  The password is usually left blank.

K:hostmask:time:username

	Most people already know what a K-line is, but for the record, it's
simply a ban from the server.  I have never seen a K:line with a time
field, but it allows you to define what times a client is allowed on the
server.  Generally, K-lines are added with the KLINE command on the server,
and the reason is stored as a comment in the config file.

L:restricted servers::connected server:depth

	This is used to identify leaf depth behind a server.  The restricted
servers field is a hostmask for what servers to not allow behind the
connected server (usually this is blank).  The depth is what depth of
servers may be connected behind it.

M:hostname:*:server description:default port

	This line sets the basic information for your server.  The fields are
pretty self-explanatory.  This is a mandatory field.

N: <see C:>

O:ident@hostname:password:nickname:connection class
o:ident@hostname:password:nickname:connection class

	These lines define the operators on the server.  The lower case o-line
identifies a local operator, who can do local server KILLs and KLINE, as
well as SQUIT and CONNECT their server from/to an uplink server.  The upper
case O-line is a global operator, who can additionally do global KILLs
(killing users off other servers) and SQUIT and CONNECT any server on the
network.  The connection class is as specified in the Y-lines.

P:hostmask:::port

	These are the ports that your server listens for connections on (in
addition to the default port set in the M-line).  The hostmask is an
optional field that allows you to specify which users may connect to that
port.

Q::reason:server

	The Q-line specifies a server that will not be allowed to link to the
network at all (all servers must have identical Q-lines according to the
sample config file).  I have never seen this used.

R:hostmask:program path:username

	Allows you to process access control through an external program
(provided by the server admin).  Whenever a client connects, the server
calls this external program with the user information.  The program then
responds based on whether or not the user should be granted access to the
server.  I've never seen this used either, and is probably impractical for
any server with a large client base.

Y:class id:ping frequency:connect frequency:max connections:max sendq

	The Y-line defines a connection class.  The class id is a number that
identifies the class, and is used in I-lines and C/N-lines to identify
which Y-line to use.  The ping frequency is the time (in seconds) between
ping requests (to verify that the connection is still alive).  Connect
frequency is the time between automatic connection attempts for server
connections (should be zero for client connection classes).  Max
connections is self explanatory.  The "sendq" is the amount of data (in
bytes) that is allowed to be pending going out to a connection in that
class before the server will close it (with a message such as "Sendq
exceeded").
	On the 2.9.x versions of ircd, the connect frequency is replaced with
an identifier to handle cloning.  If it is a positive number, it identifies
how many clients can connect from the same hostmask.  If negative, it
identifies how many clients can connect from the same username@hostmask.


	I would recommend reading the example.conf file in the ircd
distribution.  It has samples of most of these, as well as descriptions
that are probably better than mine.


===========================================================================

VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)

	There are a few commands that you can use to get information from a
server to help with opering:

TRACE [server|nick]

	The TRACE command is used to trace the path from your current server to
the specified server or user.

	When the destination is a server, TRACE will also return information
about current server and operator connections, incoming connections (with
negative class numbers), and the number of users in each class.  The oper
connections contain the connection class, the nickname, and user@hostmask
for the oper.  For server connections, it shows the connection class, the
number of servers behind it (followed by "S"), the number of clients on and
behind it (followed by "C"), the server name, and what was responsible for
connecting it.

	When the destination is a user, TRACE shows the connection class,
nickname and user@hostmask for that user.

STATS [letter]

	The STATS command returns server information.  These tend to vary by
server version, and are sometimes case sensitive.  Here are a few that I
know or use regularly:

	?	Server connection statistics
	b	B-lines
	c	C/N-lines
	d	D-lines
	e	E-lines
	h	H/L-lines
	i	I-lines
	k	K-lines
	l	Data transfer statistics by connection
		The numeric fields are as follows:
			sendQ (outgoing message queue)
			sendM (protocol messages sent)
			sendK (total kilobytes sent)
			receiveM (protocol messages received)
			receiveK (total kilobytes received)
			time in seconds since the connection was created
	L	Same as STATS l, except shows IP address instead of host
	m	Command statistics
	o	O/o-lines
	p	Current opers online
	t	General server statistics
	u	Server uptime
	v	Server link information
	y	Y-lines
	z	More server statistics

	If you are not currently an oper, I don't recommend going through and
testing thes all at once.  Multiple STATS requests are usually viewed as a
threat to the server (some people have been known to flood a server with
STATS requests to fill up the server's sendq and cause network splits).

LINKS [server mask]

	This shows the structure of the irc network, and is a bit useless if
you don't have a script or client that formats it for you.  Each line
contains the server name, its uplink name, the number of hops from your
server to the server, and the server description.

HTM

	The HTM command is used to view and set the high-transfer mode
threshold.  Additionally, it shows the incoming data rate, which is useful
when monitoring how you are doing when relinking to the network.


===========================================================================

IX. Server Routing and Connectivity

	I'll qualify this section by saying that I am not presently a hub
operator, and have done very little in the way of connecting and
disconnecting remote server connections.  However, I have researched this
quite a bit.

	For my description, let's assume a network that looks something like
this:

		A-----B----C----D
		      |         |
		E-----F         G----H
		|     |         |
		I     J----K    L----M

	Usually when there is a problem, you first notice it by the decrease in
response time from other users.  Then you try pinging a few users and
notice that ping times are outrangeously high.  Usually with a channel-wide
ping and LINKS, you can identify where the problem connection is.  Assuming
you are on server A, you notice ping times are fine up to server C, but
everything from D and beyond is lagged.  The first thing you do is a STATS
l on server C (/stats l irc.c.com) to see what the outgoing sendq is to
server D.  Looking at just the server entry for server D, it might look
like this:

	211 irc.d.com[123.231.132.213] 1621588 9780 559 469469 24111 5862

	The sendq is the first number after the IP address, or 1621588 in this
case.  If we do a STATS y on server C (/stats y irc.c.com), we can see what
the max sendq allowed is.  Look for the connection class with something
aside from 0 in the connect frequency field (600 in this case):

	218 Y:0:120:600:10:4000000

	So if that number reaches 4000000, server C will disconnect server D,
and you'll see everyone on the other side quit with the message "*** Quit:
nick (irc.c.com irc.d.com)" or whatever.

	Now, if you were on server L, you would do STATS l on server D (/stats
l irc.d.com) and look for the entry for server C.  In this scenerio, you
might see

	211 irc.c.com[132.213.123.231] 142 8841 512 485915 21058 1234

	Since the sendq going from irc.d.com to irc.c.com is only 142 bytes, it
looks like a one-way lag situation (server irc.d.com is having trouble
receiving data from irc.c.com).

	Let's say you continue to monitor the sendq from irc.d.com to irc.c.com
(with /stats l irc.d.com from your position on server A), and it rises from
the previous 1621588 bytes to 3140419 bytes.  You could wait it out and see
if it splits or catches back up, but we'll decide to reroute it now
instead.

	Before you do anything, you have your clone over on server L do a STATS
c on server D (/stats c irc.d.com) to see where it can reconnect to.  Let's
say an alernative link is server F.  You now have a place to put it, but
then you need to find a port.  From your client on server L, you do a STATS
l on server D (/stats l irc.d.com) and look at what ports it has open.
Here's a couple of STATS l response lines that we are interested in:

	211 irc.d.com  0 30844455 1978134 15372958 794195 156641 156641 -
	211 irc.d.com[@*@*.6665]  0 702234 48662 118794 5963 156641 156641 -
	211 irc.d.com[@*@*.6666]  0 1750847 130878 547336 22204 156641 156641 -
	211 irc.d.com[@*@*.6668]  0 568644 38618 100102 4626 156641 156641 -
	211 irc.d.com[@*@*.6669]  0 701079 48973 121065 5271 156641 156641 -

	The first line is the default port (6667), and looks like it's been
pretty busy, so let's use port 6665 to relink on instead.

	Now, we want to disconnect server D from server C, and then tell server
F to connect to server D on port 6665.  We will do all this from server A.
We start with the SQUIT command, which has the following format:

	SQUIT server :reason

So we do this:

	/squit irc.d.com :reroute

	At this point, it's a good idea to wait a minute for the servers to
process the change, and then we can relink using CONNECT, with the
following format:

	CONNECT server port link_server

So we do this:

	/connect irc.d.com 6665 irc.f.com

	You can monitor the reconnect status with STATS l on irc.f.com, though
in most cases, a good connect will take less than a minute.


	If you are opering from a leaf server (like I do now), then you will
generally only SQUIT and CONNECT locally to your uplink.  So you have the
following network:

	A----B----C
	          |
	     D----E

	And you are on server A, with real lag to the network, then you can
reroute yourself to server D with:

	/squit irc.b.com :reroute
	/connect irc.d.com [port]

	My previous discussion should carry over to help with evaluation of the
connection between server A and server B.


	One last issue regarding server connectivity is "juping".  When a
server is having problems or has been compromised, and an admin for the
server is not available, the server can be prevented from relinking by
putting a fake server connection to the network in its place.  When the
server attempts to link, the network sees it as already being connected and
rejects the server connection.


===========================================================================

X. Other Server Commands (REHASH, RESTART, and DIE)

	These are a few commands you won't use often unless you are responsible
for administration of the server or need to handle an emergency.

REHASH

	The REHASH command simply tells the server to reload its configuration
file.  This must be done for changes to ircd.conf to take effect.

RESTART

	This command completely shuts down the server and restarts it.  All
connections will be closed (including yours).

DIE

	This shuts the server down.  Generally this is done when restarting the
system the server is running on.


===========================================================================

XI. Operator Communications (WALLOPS and OPERWALL)

	The WALLOPS (and OPERWALL) command is used to send a broadcast message
to all operators across the network.  Oper wallops were originally
publically visible and intended to be used for disaster announcements and
the like, but have been abused to the point where now they are operator
only.

The format for both commands are:

	WALLOPS :message text
	OPERWALL :message text

	When you do a remote CONNECT or SQUIT, the server sends out an
automatic WALLOPS announcing your action.


===========================================================================

XII. Linking New Servers

	Everyone seems to want to link a new server, mostly because of the ego
boost of being a server admin on a large irc network, and occasionally
because they want to provide it as a service to a customer base.

These are some of the issues that face new servers:

Link Speed

	The minimum link speed to get a link is usually T1 (1.544 mbps) to a
major backbone provider.  Even this is often considered inadequate.

Server Requirements

	The server must be running some flavor of Unix.  Unix was designed
around networking and generally can handle far more than other operating
systems can.  Whether this is true or not isn't the issue - it's completely
based on the opinions of existing hub admins (which I happen to agree with
on this issue).

	The ircd process generally can take between 30 and 60 megs of memory
when running on EFnet, so 64 megs is probably the minimum there.  No other
real processes should be running on the machine.

Existing IRC Users

	To get a link, you should probably be averaging about 30 users at any
given time from your domain.  This can vary, and may not be a serious
requirement if you have excellent connectivity.

Operators

	Your list of potential operators can affect your ability to link.  If
you have known abusers as operators on your server, you probably won't get
a link.

Politics

	What it all really comes down to is whether or not you know and are
liked by the hub admins.  If they don't like you, I'd recommend pursuing
golf as a hobby instead. :)


===========================================================================

XIII. Attitude and Perspective

	The fact is, this is IRC.  It's a chat network - a social gathering.
Don't build your self image based on what other people think of you, on or
off IRC.  If you come on IRC because it's more important to you than blood,
you should probably invest some money in counseling.  Don't get all
emotional over what happens on here.


===========================================================================

	I hope that this document has helped someone out there.  I wrote it to
appeal to the average user, not to other operators.  If you can think of
anything more I should cover, or if you want to send me hatemail (or maybe
even a nice comment), please feel free.


Aaron Brinton
aaronb@telanis.com
EFnet Operator (irc.ionet.net, irc.uci.edu)

Special thanks to Ruth Mullen (hershey@ircnet.org) for many suggestions and
saving me from some grossly embarrassing grammatical mistakes. :)