File: Operators

package info (click to toggle)
ircd 2.10.02-1
  • links: PTS
  • area: main
  • in suites: hamm
  • size: 2,228 kB
  • ctags: 2,087
  • sloc: ansic: 29,122; makefile: 664; sh: 307; perl: 18
file content (174 lines) | stat: -rw-r--r-- 5,589 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
Internet Relay Chat Operator Etiquette Guide

July, 1997

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:
========

To have your server linked to the Undernet, first you must apply.  Get the
server link application from ftp.undernet.org:/pub/irc/newlinks/newlinks and
fill it out completely.  Then send it in the body of the email (please, no
attachments) to routing-com@undernet.org.  In a few weeks, you should be
emailed back with the results of the review team's vote.

Kills 
=====

/kill is a special operator command.  The format is as follows:
	/KILL <nickname> <reason>
Comment can be a phrase of almost any length (within reason) and should be
used for specifying the reason of the kill.
Example:
	/kill Jonathan A ghost.

Routing commands
================

/SQUIT <server> [comment]

   /SQUIT isolates a specified server from the next closest server, when
you look at it along the trace path starting from your 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.  Note, that a primary reason to use squit is to reroute
traffic.

   Usage (and examples): 

      /squit E

     If the network looks like this initially (and you are on server A)

 
          A - B - C - D
                  |
              G - E - F - ... (rest of the network)
                          

    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 IRC 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 - ... (rest of network)


   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 4400, which is the default)

   /connect F 4400 E

   If the network initially looks like this:

             A - B - C - D
                     |
                 G - E   F - ... 

   Then after your CONNECT request the network topology will look like this:

             A - B - C - D
                     |
                 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
                      |
                  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.

   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 on operator channels.  That's what they are there
for!

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	Noah Friedman
<hrose@cs.bu.edu>	<ckd@cs.bu.edu>		<friedman@ai.mit.edu>

January, 1991


Updated by

Mauri Haikola
<mjh@stekt.oulu.fi>

May, 1992


Revised to become more a reflection of the current state of IRC by
Darren Reed
<avalon@coombs.anu.edu.au>

December 1994


Revised and updated by
David Rientjes
<david-r@wildstar.net>