philippelh/ircu2.9.32
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
Philippe L'Heureux
2023-12-26 16:40:53 -05:00
commit ab64084f63
93 changed files with 40857 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

156
doc/US-Admin/Networking Normal file
View File

@@ -0,0 +1,156 @@
/************************************************************************
* IRC - Internet Relay Chat, doc/NETWORKING
* Copyright (C) 1994, Helen Rose <hrose@kei.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 1, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
Author: Helen Rose
hrose@kei.com
Date: 3 March, 1994
*** Please read this before doing any connecting or writing to ask for
connections. The information contained in this section is crucial to the
way IRC is run.
Note that any old documentation referring to ANet vs EFnet is out of date
and no longer applies. ANet died so long ago that nobody can remember
*when* it died.
To qualify for a link on the irc network, several criteria must be
met. These criteria include (but are not limited to):
* A well established local irc userbase. A total of 100-150 local irc
users. An average of 15-20 irc users over a 24 hour period is also
acceptable. Note, these user counts are *unique, local* users. So
one person running fifteen clients doesn't count, and one local
person plus fifteen offsite people doesn't count. These are not
arbitrary numbers, it takes at least this many users to equate the
traffic of adding another server to the irc network.
* A userbase that uses irc *all the time* (15 users on at once but
just for a 3 hour period per day is not sufficient).
* A good, fast, internet link. Absolutely *NO* SLIP lines. 56k lines
are marginal, they usually cause more trouble than they are worth,
so we recommend a T1 or better.
It is well established that having a local irc server does not attract
local irc users. Often, your best bet is to set up a local client that is
accessible by everyone at your site, connect it to a nearby offsite
server, and then see if the usage level goes up. (See appendix for list of
open-client servers).
To see how many users you have, on irc do /m x@monitor.us show site.name
where site.name is your two-part domain name (eg "kei.com" or "bu.edu" or
"mit.edu"). monitor will tell you how many users you have. Once this
number gets over 125 or so, put the level it has reached in your note to
operlist-request@kei.com.
If you are in the United States and need a link, please mail to
"operlist-request@kei.com" supplying the information listed below.
(1) Find out if your system has /etc/ping (sometimes /usr/etc/ping) and
ping the following hosts:
server/machine name IP address Geographical Location
csa.bu.edu 129.197.10.3 Boston, MA
irc-2.mit.edu 18.180.0.2 Cambridge, MA
polaris.ctr.columbia.edu 128.59.68.10 New York, NY
poe.acc.virginia.edu 128.143.83.132 Charlottesville, VA
irc.iastate.edu 129.186.150.1 Ames, IA
dewey.cc.utexas.edu 128.83.135.3 Austin, TX
irc.netsys.com 198.175.9.8 Palo Alto, CA
w6yx.stanford.edu 36.55.0.50 Stanford, CA
goren.u.washington.edu 140.142.63.1 Seattle, WA
These are results of the typical /etc/ping command:
(note that the machine I am running this from runs SunOS so I have to use
ping -s ):
3:59pm hrose@csa : ~ % ping -s polaris.ctr.columbia.edu
PING polaris.ctr.columbia.edu: 56 data bytes
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=0. time=137. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=1. time=163. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=2. time=110. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=3. time=111. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=4. time=78. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=5. time=82. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=7. time=83. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=8. time=91. ms
64 bytes from polaris.ctr.columbia.edu (128.59.68.10): icmp_seq=9. time=159. ms
[...]
^^ ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ ^^ ^^^^^^^
Size of packet hostname IP address packet number trip time
----polaris.ctr.columbia.edu PING Statistics----
25 packets transmitted, 25 packets received, 0% packet loss
round-trip (ms) min/avg/max = 78/136/327
When you send pings to operlist-request, please only send the results
(the above three lines)--we *don't* need each packet's time.
Guidelines:
Avg Time Connection is
======== =============
0-20ms Optimal
20-40ms Excellent
40-70ms Very Good
70-90ms Average
90-110ms Acceptable
110ms-150ms Below Average
150ms-200ms Bad
200ms-300ms You're on a very slow link and it is unlikely you will be
able to support a server successfully.
** *** WHERE TO FIND HELP!!! ***
**
** If you have any other questions about connecting to an irc server, please
** mail to operlist-request@kei.com. If you have problems mailing there,
** try mailing hrose@kei.com.
**
** *** WHERE TO FIND HELP!!! ***
Appendix
========
Open client servers.
USA:
csa.bu.edu
irc.colorado.edu
irc.uiuc.edu
Canada:
ug.cs.dal.ca
Europe:
irc.funet.fi
cismhp.univ-lyon1.fr
disuns2.epfl.ch
irc.nada.kth.se
sokrates.informatik.uni-kl.de
bim.itc.univie.ac.at
Australia:
jello.qabc.uq.oz.au

253
doc/US-Admin/Operators Normal file
View File

@@ -0,0 +1,253 @@
Internet Relay Chat Operator Etiquette Guide
January, 1991
Welcome! You've either been selected to be an IRC Operator or you have set
up your server and thus have taken on the dual task of IRC Server
Administrator and IRC Operator. Your future days will be filled with hours
of fun chatting on IRC, and then wondering why everyone you talked to went
away, because the links had apparently broken.
Linking:
========
You will be assigned links from the IRC Routing Coordinators. Please use
these links and these links ONLY. The links have been designed to maximize
efficiency and make delays in chatting minimal. You will be given two
links, one to each regional backbone site. Connect to the primary site
first and then to the secondary site. You should not need to connect to any
other sites. You will be informed if this policy changes.
Kills and Walls:
===============
/kill and /wall are special operator commands. You should use them with
care, and only if absolutely needed. The format are as follows:
/kill USERNAME comment. comment can be a phrase of almost any length
(within reason) and should be used for specifying the reason of the kill.
example: /kill Trillian She's a Ghost
IRC Ghosts are created after a net split has occured and the net has yet to
relink.
/wall PHRASE. This is used for an emergency command like the net is about
to split into little pieces, and everyone should reconfigure their links
as soon as possible. You will see a WALL when it happens, an operators
nickname will appear with # signs around it.
#Trillian# Server bucsd.bu.edu coming down for upgrade. Prepare to
reconfigure links.
/wallops PHRASE This is used to talk to ALL operators at once. It is not
often warranted, but is useful. Often, when there is an important IRC
situation that requires all the operators attention, /wallops is used. The
form for wallops is a nickname with ! signs around it.
!Trillian! Australia should leaf off of eris, not carry all the US traffic.
/TRACE command
/TRACE is useful to know what servers are connected to what. Sometimes
/trace can be confusing, especially you are using it for the first time.
Here is an example of a trace from bucsd.bu.edu to betwixt.cs.caltech.edu.
/TRACE betwixt.cs.caltech.edu
IRC log started Mon Aug 26 17:04
*** Link eff.org<2.6.1a> ==> h.ece.uiuc.edu
-bucsd.bu.edu- *** Link bucsd.bu.edu<2.6.1a> ==> h.ece.uiuc.edu
-h.ece.uiuc.edu- *** Serv Class[3] h.ece.uiuc.edu ==> ucsu.colorado.EDU
-h.ece.uiuc.edu- *** Serv Class[2] h.ece.uiuc.edu ==> bucsd.bu.edu
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> silver.ucs.indiana.edu
-h.ece.uiuc.edu- *** Serv Class[11] h.ece.uiuc.edu ==> monitor.ece.uiuc.edu[h.ece.uiuc.edu]
-h.ece.uiuc.edu- *** User Class[0] h.ece.uiuc.edu ==> Razorbone[uxa.cso.uiuc.edu]
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> MHD54.MOORHEAD.MSUS.EDU[134.29.97.1]
-h.ece.uiuc.edu- *** Serv Class[4] h.ece.uiuc.edu ==> *.umich.edu[mingin.engin.umich.edu]
-h.ece.uiuc.edu- *** User Class[0] h.ece.uiuc.edu ==> BooServ[sunc4.cs.uiuc.edu]
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> nic.stolaf.edu
-h.ece.uiuc.edu- *** Oper Class[0] h.ece.uiuc.edu ==> SodaPop[h.ece.uiuc.edu]
-h.ece.uiuc.edu- *** Serv Class[4] h.ece.uiuc.edu ==> oddjob.uchicago.edu
-h.ece.uiuc.edu- *** User Class[0] h.ece.uiuc.edu ==> Deviant[isca01.isca.uiowa.edu]
-h.ece.uiuc.edu- *** Serv Class[10] h.ece.uiuc.edu ==> *.uc.edu[hilbert.che.uc.edu]
-h.ece.uiuc.edu- *** Class 0 Entries linked: 4
-h.ece.uiuc.edu- *** Class 11 Entries linked: 1
-h.ece.uiuc.edu- *** Class 10 Entries linked: 4
-h.ece.uiuc.edu- *** Class 4 Entries linked: 2
-h.ece.uiuc.edu- *** Class 3 Entries linked: 1
-h.ece.uiuc.edu- *** Class 2 Entries linked: 1
This shows that from eff.org (running version 2.6.1a to h.ece.uiuc.edu,
routing goes through bucsd.bu.edu before reaching h.ece.uiuc.edu.
"h" is connected to ucsu.colorado.edu, silver.ucs.indiana.edu,
monitor.ece.uiuc.edu (which resolves to [h.ece.uiuc.edu], hence the
square brackets), mhd54.moorhead.msus.edu, *.umich.edu (which resolves
to mingin.engin.umich.edu), nic.stolaf.edu, oddjob.uchicago.edu,
*.uc.edu (which resolves to hilbert.che.uc.edu), and bucsd.bu.edu, which
is known as its "uplink". It is quite normal for a server to have
several "uplinks" if it is busy. An uplink is the link towards the top
of the tree which carries alot of traffic. "h" also has several users on
it, RazorBone, BooServ, and Deviant. SodaPop is also an active operator
on h.ece.uiuc.edu. You can tell each host from what each person is
logged into by looking just past their nickname. For example, Deviant is
logged in from isca01.isca.uiowa.edu.
/SQUIT server {comment}
/squit isolates a specified link from the next closest uplink server.
This is usually used in conjunction with CONNECT (explained later) to
reroute traffic. This will be described in detail in the section
"routing", preceding CONNECT.
SQUIT can be used in one of two ways. It can be used on a local
server, which would cause the server name specified to be unlinked
relative to your path; or you can send a message to another server
instructing it to issue an SQUIT to that server, in which case the
break will be relative to the remote server.
Usage (and examples):
/squit E
If the network looks like this initially (and you are on server A)
A <---> B <---> C <---> D
^
|
v
G <---> E <---> F <---> ... (rest of the net)
Then after issuing the previous /squit the network would look like this:
A <---> B <---> C <---> D
G <---> E <---> F <---> ...
/squit E {comment}
It usually helps to give a reason why you are sending a
SQUIT for a server. This can be accomplished by sending
the command "/squit server This link is making the US route
through Finland". The SQUIT will then be sent out, and the
server sending the squit will WALLOP sending the comment
so all operators can see it.
/CONNECT server {portnum server2}
/connect is used to establish a link between two servers. These
connections must be authorized by each server's ircd.conf file, but
any operator can issue a CONNECT between authorized servers. This
command is most often used in conjunction with SQUIT to reroute
traffic.
If only one argument is given, this command causes the server you
are on to attempt to connect to the server specified. For example,
"/connect B" (in the previous example) would cause your server (A) to
connect to B.
Suppose you wanted to reconnect server F to server E? You cannot
contact server F since it is no longer part of your network. However,
you can tell server E to connect to it. A remote CONNECT can be issued
to server E.
Examples (assume you are on server A):
/connect B
If the network initially looks like this:
A B <---> ... (rest of network)
Then afterwards (if the connection succeeds) the network will look
like this:
A <---> B <---> ...
In the example where you wanted to reconnect server E to F, the
following syntax would be appropriate (note: we are assuming that
F's irc socket port is 6667, which is the default)
/connect F 6667 E
If the network initially looks like this:
A <---> B <---> C <---> D
^
|
v
G <---> E F <---> ...
Then after your CONNECT request the network topology will look like this:
A <---> B <---> C <---> D
^
|
v
G <---> E <---> F <---> ...
Be careful when connecting servers that you know which command to
use! If you simply issued "/connect F" from your server, the
network would look like this:
... <---> F <---> A <---> B <---> C <---> D
^
|
v
G <---> E
which for various reasons (discussed below) might be very
undesirable.
Routing
=======
When and how should you do rerouting? This depends on where your
server is topologically located and whether you route traffic. If you
are a leaf node (i.e. only connect to one server at a time) then
chances are you won't need to do any routing at all. Your ircd.conf
file should be written to connect to the best possible servers first
before trying alternates. At the most, you may decide to squit an
alternate server and connect to your primary if/when it goes back up.
This only involves local squits, however.
If you are operating a backbone site, you may find yourself
rerouting things quite often. If the EFnet servers (see the file
doc/networking) badger.ugcs.caltech.edu (Pasadena, CA),
irc.mit.edu (Boston, MA), minnie.cc.utexas.edu (Austin, TX) and
ucsu.colorado.edu (Boulder, CO) were routing traffic in the following way:
... <---> minnie <---> badger <---> bucsd <---> ucsu <---> ...
It would make sense to either squit ucsu and reconnect it to minnie,
or disconnect minnie from badger and connect to ucsu, because
topologically (and geographically) ucsu and minnie are rather close.
There are occasions when US traffic for some reasons winds up being
routed through Australia. This is another case where traffic should
definitely be rerouted. However, there are sometimes occasions when
routing is going through "backdoor" methods. If you see something
totally outrageous (like the east coast and the west coast being
connected by eff.org) please /WALLOPS and ask before you send any
squits, because chances are, it's like that for a reason.
Of course, any operator can remotely squit or connect servers, so
if you see a problem and you're sure you know how to fix it, it's a
good idea to do so. If the operator of a server which is is being
routed poorly is online, it's probably best to contact him/her first,
though.
Chances are that hub operators will be more familiar with the
general topology of the network and which servers connect to which
(which is why most of the manual routing is left to them), so if you
have any problems, talk to the other operators via /wallops. That's
what it's there for!
Also, be aware that servers will notify all the operators online of
remote SQUITs and CONNECTs via WALLOPS.
Please let us know if there should be any additions to this guide. Again,
this is not MANDATORY, this is just a GUIDE. Please conduct yourself as
an IRC Operator would...you are looked upon for assistance, both emotional
and mental.
Helen Rose Christopher Davis
<hrose@cs.bu.edu> <ckd@cs.bu.edu>
Noah Friedman
<friedman@ai.mit.edu>
January, 1991