home *** CD-ROM | disk | FTP | other *** search
/ Hacks & Cracks / Hacks_and_Cracks.iso / hackersguides-&-software / kill16v3.zip / PACK1.PRG / KILLER16 / DOCS / IRCOPS.TXT < prev   
Text File  |  1995-11-09  |  7KB  |  191 lines
  1. (This is the complete and unchanged file that IRC operators recieve when they 
  2. reach the esteemed level.  Cripton inc.)
  3.  
  4. Internet Relay Chat Operator Etiquette Guide
  5.  
  6. May, 1992
  7.  
  8. Welcome! You've either been selected to be an IRC Operator or you have set
  9. up your server and thus have taken on the dual task of IRC Server
  10. Administrator and IRC Operator. Your future days will be filled with hours
  11. of fun chatting on IRC, and then wondering why everyone you talked to went
  12. away, because the links had apparently broken. 
  13.  
  14. 2 and a Half years later, December 1994.
  15.  
  16. Linking:
  17. ========
  18.  
  19. Currently, there is no policy of any sort in operation on EFnet except for
  20. Europe (see EBIC documents).  If you want links, find an operator or server
  21. admin, become friends with them, build a case, run lots of bots to make it
  22. look like you have lots of users and away you go.  It doesn't matter what
  23. speed your link is or where you get it (regardless of what people say, they
  24. don't actually follow their own preeching).
  25.  
  26. Kills 
  27. =====
  28.  
  29. /kill is a special operator command.  The format is as follows:
  30.     /kill NICKNAME comment.
  31. Comment can be a phrase of almost any length (within reason) and should be
  32. used for specifying the reason of the kill.
  33. Example:
  34.     /kill jonathan hey, this is fun!
  35.  
  36.  
  37. /SQUIT server {comment}
  38.    /squit isolates a specified server from the next closest server, when
  39. you look at it along the trace path starting from your server. 
  40. This is usually used in conjunction with CONNECT (explained later) to
  41. reroute traffic. This will be described in detail in the section
  42. "routing", preceding CONNECT.  Note, that a primary reason to use squit
  43. is to isolate your server (to become a leaf) if you want chanop or someone
  44. else wants chanop and you want to help them.
  45.  
  46.    Usage (and examples): 
  47.  
  48.       /squit E
  49.  
  50.      If the network looks like this initially (and you are on server A)
  51.  
  52.  
  53.           A <---> B <---> C <---> D
  54.                           ^
  55.                           |
  56.                           v
  57.                   G <---> E <---> F <---> ... (rest of the net)
  58.                           
  59.  
  60.     Then after issuing the previous /squit the network would look like this:
  61.  
  62.           A <---> B <---> C <---> D
  63.                           
  64.                           
  65.                   G <---> E <---> F <---> ...
  66.  
  67.  
  68.     /squit E {comment}
  69.  
  70.     It usually helps to give a reason why you are sending a
  71.     SQUIT for a server. This can be accomplished by sending
  72.     the command "/squit server This link is making the US route
  73.     through Finland". The SQUIT will then be sent out, and the 
  74.     server sending the squit will WALLOP sending the comment
  75.     so all operators can see it. 
  76.  
  77. /CONNECT server {portnum server2}
  78.    /connect is used to establish a link between two servers. These
  79. connections must be authorized by each server's ircd.conf file, but
  80. any operator can issue a CONNECT between authorized servers. This
  81. command is most often used in conjunction with SQUIT to reroute
  82. traffic. 
  83.    If only one argument is given, this command causes the server you
  84. are on to attempt to connect to the server specified. For example,
  85. "/connect B" (in the previous example) would cause your server (A) to
  86. connect to B. 
  87.    Suppose you wanted to reconnect server F to server E? You cannot
  88. contact server F since it is no longer part of your network. However,
  89. you can tell server E to connect to it. A remote CONNECT can be issued
  90. to server E. 
  91.  
  92.    Examples (assume you are on server A):
  93.  
  94.    /connect B
  95.  
  96.    If the network initially looks like this:
  97.  
  98.          A      B <---> ... (rest of network)
  99.  
  100.    Then afterwards (if the connection succeeds) the network will look
  101.    like this:
  102.  
  103.         A <---> B <---> ... 
  104.  
  105.  
  106.    In the example where you wanted to reconnect server E to F, the
  107.    following syntax would be appropriate (note: we are assuming that
  108.    F's irc socket port is 6667, which is the default)
  109.  
  110.    /connect F 6667 E
  111.  
  112.    If the network initially looks like this:
  113.  
  114.          A <---> B <---> C <---> D
  115.                          ^
  116.                          |
  117.                          v
  118.                  G <---> E      F <---> ... 
  119.  
  120.    Then after your CONNECT request the network topology will look like this:
  121.  
  122.          A <---> B <---> C <---> D
  123.                          ^
  124.                          |
  125.                          v
  126.                  G <---> E <---> F <---> ... 
  127.  
  128.     Be careful when connecting servers that you know which command to
  129.     use! If you simply issued "/connect F" from your server, the
  130.     network would look like this:
  131.  
  132.  
  133.     ... <---> F <--->  A <---> B <---> C <---> D
  134.                                        ^
  135.                                        |
  136.                                        v
  137.                                G <---> E 
  138.  
  139.     which for various reasons (discussed below) might be very
  140.     undesirable. 
  141.  
  142. Routing
  143. =======
  144.  
  145.    When and how should you do rerouting? This depends on where your
  146. server is topologically located and whether you route traffic. If you
  147. are a leaf node (i.e. only connect to one server at a time) then
  148. chances are you won't need to do any routing at all.  Your ircd.conf
  149. file should be written to connect to the best possible servers first
  150. before trying alternates. At the most, you may decide to squit an
  151. alternate server and connect to your primary if/when it goes back up.
  152. This only involves local squits, however.
  153.  
  154.    Chances are that hub operators will be more familiar with the
  155. general topology of the network and which servers connect to which
  156. (which is why most of the manual routing is left to them), so if you
  157. have any problems, talk to the other operators on operator channels
  158. (#twilight_zone, #eu-opers etc.) That's what they are there for!
  159.  
  160.    Don't bother wasting your time with #twilight_zone.  There are many
  161. operators on many hub servers (including many found in this channel) which
  162. purport to know something but in fact know nothing.  They will most likely
  163. ignore you, make fun of you, abuse you, dump your private messages to the
  164. channel, etc.  In general, many operators (especially true of those on
  165. #twilight_zone) are not the sort of people you'd want to do this as a
  166. paid job and won't do anything unless it serves them in some way.
  167.  
  168. Please let us know if there should be any additions to this guide. Again,
  169. this is not MANDATORY, this is just a GUIDE. Please conduct yourself as 
  170. an IRC Operator would...you are looked upon for assistance, both emotional
  171. and mental. 
  172.  
  173. Helen Rose        Christopher Davis    Noah Friedman
  174. <hrose@cs.bu.edu>    <ckd@cs.bu.edu>        <friedman@ai.mit.edu>
  175.  
  176. January, 1991
  177.  
  178.  
  179. Updated by
  180.  
  181. Mauri Haikola
  182. <mjh@stekt.oulu.fi>
  183.  
  184. May, 1992
  185.  
  186. Revised to become more a reflection of the current state of IRC by
  187. Darren Reed
  188. <avalon@coombs.anu.edu.au>
  189.  
  190. December 1994