doc/operguide.txt

   1
   2 EFnet Oper Guide
   3 Last update: 02-21-2002
   4 Written and maintained by Riedel
   5 E-Mail: dennisv@vuurwerk.nl
   6
   7  1.  Commands you should know about
   8  2.  The client of your choice
   9  3.  Your primary responsibilities
  10  4.  Re-routing
  11  4.1 Re-routing other servers and remote connects
  12  5.  Kills and klines
  13  6.  Kill and K-Line requests
  14  7.  Happy birthday!
  15  8.  Security
  16  9.  Know who your friends are
  17 10.  The TCM bot
  18 11.  Services
  19 12.  G-Lines
  20
  21
  22 1. Commands you should know about
  23
  24   This is no longer covered here. IRCD-hybrid is changing too rapidly, so
  25   this section would be outdated in no time ;) For an up-to-date version,
  26   please download the latest hybrid at www.ircd-hybrid.org.
  27
  28
  29 2. The client of your choice
  30
  31   There are many IRC clients around for a wide variety of operating systems.
  32   Being an IRC Operator doesn't *require* you to use a UNIX client, however
  33   I personally prefer UNIX-based clients. If you're familiar with UNIX and
  34   use UNIX for opering, I suggest ircII / epic. There are a lot of scripts
  35   available for those two clients, and it's not that hard to write scripts
  36   yourself to suite your needs. It is important that you know how to operate
  37   your client, and familiarize yourself with the options and features. For
  38   whatever client you chose this goes for any of them: You should be in
  39   control of your client, instead of the client being in control of you.
  40
  41 Resources :
  42
  43   www.mirc.co.uk        - mIRC (MS-Windows)
  44   www.irchelp.org       - a variety of clients and scripts
  45   ftp.blackened.com     - several UNIX based clients available
  46
  47
  48 3. Your primary responsibilities
  49
  50   As an IRC Operator, you're responsible for maintaining the server on a
  51   real-time basis. You represent your server, and you represent the network.
  52   Irresponsible / rude / offensive / stupid behavior may discredit your server
  53   and the network. You should focus on the task you were chosen for...
  54   maintainance.  Sounds simple, no? It means getting rid of users that abuse
  55   the service, enforcing the server's policy and keeping the server linked.
  56   Users will ask you questions, and expect you to know all the answers.. after
  57   all, you're the oper!
  58
  59   Be prepared for users trying to fool you, sweet talk you into things you
  60   don't want, lie and deceive. Most users are handling in good faith...
  61   however, the abusers have learned how to manipulate opers. They have studied
  62   the alien creature 'oper' for ages like biologists study animals. Be
  63   paranoid, be curious and be suspicious. I can't stress the importancy of that
  64   often enough.
  65
  66   Second priority has the network. You were not chosen to maintain the network
  67   but you were chosen to maintain the server. However, you may want to be able
  68   to reroute servers. If you see something broken, don't be afraid to fix it.
  69   If you do, be sure you fix things and don't make it worse. Before you
  70   step into routing, be sure you've familiarized yourself with the network's
  71   topology, and be confident enough to perform such actions. (re)routing is
  72   covered in the next chapter.
  73
  74   Opers on the network depend on a trusting relationship. You can usually take
  75   the word from an oper. Other opers are considered -trusted-, however, there
  76   are exceptions. Sometimes even opers lie to opers to get things done. Don't
  77   be afraid to ask for proof of a certain statement, such as logs.
  78   This doesn't mean you distrust the oper in question, but -you- and you alone
  79   are responsible for your actions. You call the shots on your server, unless
  80   your admin says otherwise.
  81
  82
  83 4. Re-routing
  84
  85   Re-routing is not hard, and it's not scary but it is important that you do it
  86   right. The commands you'll use are SQUIT and CONNECT. First, a very simple
  87   example. Let's say your server, irc.yourserver.com is lagged to it's uplink,
  88   irc.uplink.com and you want to reroute your server. You have to think about
  89   where you want your server to be linked, and you have to time your reroute.
  90   An example topology :
  91
  92 irc.yourserver.com ---- irc.uplink.com
  93                         |      |      \
  94                         B      C      D
  95                        / \
  96                       E   F
  97                          / \
  98                         G   H --- O
  99                       / | \ | \
 100                      I  J K L  M
 101                                 \
 102                                  N
 103
 104   In this case, you're uplinked by irc.uplink.com
 105   irc.uplink.com also hubs B, C and D. Server B functions as hub for E and F;
 106   F hubs G and H; H hubs L, M and O. G hubs I, J and K. M hubs N.
 107   Your server is allowed to connect to server B, F and G. So you consider the
 108   servers you're able to connect to. Is the lag caused by a server that uplinks
 109   irc.uplink.com ? Use /stats ? irc.uplink.com to determine lag to the other
 110   servers. If irc.uplink.com does not respond, the lag is to your uplink. If
 111   so, you cannot be sure about the state of the other uplinks, so you'd have to
 112   get on a remote server and determine lag by using /stats ? and /trace. For
 113   example, you could connect to server N, and /trace yournick. Yournick, being
 114   the nick on your server. You'll see which route it takes, and what the
 115   problem server is. Example /trace output :
 116
 117 S:[SERVER-N       ] V:[2.8/hybrid] U:[SERVER-M            ]
 118 S:[SERVER-M       ] V:[2.8/hybrid] U:[SERVER-H            ]
 119 S:[SERVER-H       ] V:[2.8/hybrid] U:[SERVER-F            ]
 120 S:[SERVER-F       ] V:[2.8/hybrid] U:[SERVER-B            ]
 121 S:[SERVER-B       ] V:[2.8/hybrid] U:[irc.uplink.com      ]
 122 S:[irc.uplink.com ] V:[2.8/hybrid] U:[irc.yourserver.com  ]
 123
 124   The trace doesn't complete... server-b announces irc.uplink.com, and
 125   irc.uplink.com announces your server. Your server should return something
 126   like :
 127
 128 S:[irc.yourserver.] OPER [yournick!user@yourhost]
 129
 130   If it doesn't, we know the lag is only between yourserver and uplink.
 131   Usually if there is lag between your server and your uplink, the send-queue
 132   rises. This is not always the case. Sometimes your server can write perfectly
 133   to your uplink, but not reverse. That is called one sided lag.
 134
 135   We pick server B to link to. It means we have to SQUIT and CONNECT.
 136   To unlink from irc.uplink.com and connect to SERVER_B we'd type:
 137   /quote SQUIT irc.uplink.com :reroute
 138   /connect SERVER_B
 139
 140   we *DON'T* SQUIT irc.yourserver.com... and I'll try to explain why:
 141   If we wanted to remove hub M from the network, and with it N, we'd issue
 142   a SQUIT M. An SQUIT follows a path, relays the SQUIT request to each server
 143   in that path. Finally it reaches server H, which is the hub for M. Server H
 144   sees the SQUIT and drops the link to M.
 145
 146   Now a different situation, we want to separate yourserver, uplink, C and D
 147   from the rest of the network, in order to reroute. We'd have to SQUIT server
 148   B, since we want the -uplink- of server B (being irc.uplink.com) to drop the
 149   link to server B.
 150
 151   If you'd SQUIT irc.yourserver.com, you ask yourserver.com to drop the link to
 152   itself, which is impossible. If you SQUIT irc.uplink.com, you ask yourserver
 153   to drop the link to uplink, which is what we want to do.
 154
 155   After the SQUIT and CONNECT, the new situation looks like this :
 156
 157                         irc.uplink.com
 158                         |      |      \
 159   irc.yourserver.com -- B      C      D
 160                        / \
 161                       E   F
 162                          / \
 163                         G   H --- O
 164                       / | \ | \
 165                      I  J K L  M
 166                                 \
 167                                  N
 168
 169   If yourserver is a Hub, it makes the situation more complex, since your
 170   actions have more impact.
 171
 172
 173 4.1 - Re-routing other servers and remote connects
 174
 175 Example topology :
 176
 177                         irc.uplink.com
 178                         |      |      \
 179   irc.yourserver.com -- B      C      D
 180                        / \
 181                       E   F
 182                          / \
 183                         G   H --- O
 184                       / | \ | \
 185                      I  J K L  M
 186                                 \
 187                                  N
 188
 189   Let's say, hub H is way lagged to F, but G to F is fine... we want to reroute
 190   H, and stick H to G.
 191
 192   We'd do :
 193
 194   /quote SQUIT serverh :re-routing you babe
 195   /connect serverh 6667 serverg
 196
 197   A global wallops will be sent :
 198   !serverg! Remote CONNECT serverh 6667 from ItsMe
 199
 200   When re-routing, always give the server some time to prevent nick collides.
 201   When there is lag, people will connect to another server. When you SQUIT and
 202   CONNECT to fast, a lot of those clients will be collided. Also, stick to your
 203   territory. How enthusiastic you may be, you cannot route the world. If you're
 204   an oper on the US side, stick to the US side when re-routing. Needless to
 205   say, if you're EU, keep it to EU ;)
 206
 207
 208 5. Kills and klines
 209
 210   As an oper, you're given the incredible power *cough* of KILL and KLINE.
 211   /kill nick reason  disconnects a client from IRC with the specified reason.
 212   A /quote kline *evil@*.dude.org :reason here  bans the user from your server.
 213   Abusive kills and klines may draw attacks to your server, so always consider
 214   if a kline or kill is deserved. If the server gets attacked after a valid
 215   kill or kline, well.. tough luck. You should never be 'afraid' to kline
 216   anyone on your server. If it's a good reason, make it so. Even if you know
 217   it may cause the server to be attacked. Maybe good to think about is this:
 218   - if /ignore solves the problem rather than a kick, /ignore
 219   - kick if a ban is unneeded
 220   - ban if a /kill is unwarranted for
 221   - kill rather than kline if that solves the problem
 222   - kline when a server ban is really needed.
 223
 224   You kline a user when you absolutely don't want this user to use the service
 225   your server is providing.
 226
 227   Crosskills (killing users on another server) are another issue. Some admins
 228   don't care if users get /kill'ed off their server, for any reason or no
 229   reason at all... and other admins are very anal about it. A good way to go
 230   (IMO) is to issue a KILL if there is an absolute need for the target user to
 231   be disconnected. If there are active opers on that server, let them handle
 232   it.  They'll be upset if you /kill a user off their server, without
 233   contacting them.  /stats p irc.server.here shows the active opers on a
 234   particular server. Some opers have multiple o-lines and are not watching all
 235   sessions. If you can't find an active oper on a server, you can
 236   /quote operwall a request for opers from that server.
 237
 238   Ghost KILLs are another story, an often misunderstood one.
 239   When you see a /KILL from an oper with the reason 'ghosted' they usually
 240   KILL a client that's about to ping timeout. That is not what a ghost is!
 241   To quote Dianora: "a ghost happens because a client misses being killed when
 242   it should be. Its a race condition due to nick chasing". In other words,
 243   Server X thinks client A has been KILLed, while server Y missed the KILL
 244   for that client.
 245
 246
 247 6. Kill and K-Line requests
 248
 249   As previously mentioned, if an oper from another server contacts you and
 250   requests a kill or a kline for a local client with a good reason, you can
 251   usually trust this request. Opers depend on a trusting relationship. However,
 252   since you're responsible for the kill or kline, it is not rude to ask for
 253   proof. It depends on the oper making the request how thats interpreted, but
 254   the way they respond to asking for proof tells more about them than about
 255   you.
 256
 257   The more and longer you oper, how better you get to know the other opers.
 258   You know who is honest, you'll know who are lying and deceiving. Before
 259   you acquire this knowledge, you can merely rely on common sense and
 260   instincts.  You'll probably make mistakes occasionally, and thats nothing to
 261   be ashamed of.  Opers are - despite contrary believes - human.
 262
 263   Users occasionally will ask you to kill or kline a user/bot too. Some
 264   requests are straight-forward and clear, others require you to be cautious. I
 265   recommend to always investigate such requests, and when you're confident the
 266   request is valid, issue the kill or kline.
 267
 268
 269 7. Happy birthday!
 270
 271   It is a custom on EFnet to birthday /kill opers of whom it is his/her
 272   birthday.  Not all opers like this, but typically those opers don't let
 273   others know about their birthday. You'll notice that the KILLS say a lot
 274   about who likes who and who is friends with who.  Whether you want to
 275   participate, is entirely up to you.
 276
 277
 278 8. Security
 279
 280   As with any privilege, you have to handle it cautiously and responsibly.
 281   Be sure that your o/O line doesn't get compromised! Oper only from secure
 282   hosts. You and only you should know your password. Don't share your oper
 283   account, and make your oper password a UNIQUE one. If your o/O line gets
 284   compromised, nasty things may/will happen. Imagine an oper with crosskill
 285   capabilities who's operline gets 'hacked'... the results are often
 286   disastrous and you will lose respect and trust from others. It can cause
 287   your oper privileges to be revoked, or even the server to be (temporarily)
 288   delinked.
 289
 290
 291 9. Know who your friends are
 292
 293   As an oper you will get a lot of users that want to be 'friends' with you.
 294   Users offer you free* access to their *nix servers, ops in channels,
 295   unlimited leech access to the biggest and fastest warez sites *gasp* and
 296   more. They want favors in return. They say they don't but they truly want
 297   something in return. They -expect- something in return. You could either
 298   don't respond to such offers, or use them. The last option creates an even
 299   more distorted image of opers and doesn't do any good for the user <-> oper
 300   relationship.  Your *real* friends are usually the persons who were your
 301   friends _before_ you acquired the extra privileges.
 302
 303
 304 10. The TCM Bot
 305
 306   A TCM bot can be a valuable tool for opers. It keeps record of all connected
 307   clients, flags clients with multiple connections and has all sorts of other
 308   useful commands. There are three different kind of TCM's in use on EFnet,
 309   being OOMon, TCM-Dianora and TCM-Hybrid. Every one of them requires you to
 310   log in to be able to access the privileged commands. On OOMon you DCC chat
 311   the TCM bot and do '.auth yournick yourpass' where yournick is your oper
 312   name in your o/O line. In TCM-Dianora and TCM-Hybrid you register with:
 313   '.register yourpass', where yourpass is your password ;)
 314   All TCM commands start with a period. If you forget the period, the text goes
 315   into the 'partyline', where it is echoed to all connected opers.
 316
 317   Resources :   http://toast.blackened.com/oomon/help
 318                 http://www.db.net/~db/tcm.html
 319
 320
 321 11. Services
 322
 323   A recent addition to EFNet is Channel Fixer, aka ChanFix. This is an
 324   automated service that re-ops clients on opless channels. There are a few
 325   restrictions.  First, the channel has to be of significant size for ChanFix
 326   to store it in its database. Second, it only logs static addresses.
 327
 328   How does it work? Periodically it stores information about the channel state
 329   in its database, for every channel in there. On every 'run', a channel
 330   operator gets one point. These scores make a top-5 of 'most frequent opped
 331   clients'.  When a channel becomes opless, ChanFix will join and op the top-5
 332   opped clients CURRENTLY IN THE CHANNEL.
 333
 334   Chanfix can be invoked manually by server administrators. /msg ChanFix
 335   chanfix #channel is the command to do it. ChanFix will join, and treat the
 336   channel as if it were opless. It lowers TS by one (resulting in a deop of
 337   the entire channel) and re-ops the top-5 clients currently in the channel.
 338   The Channel Fixer won't log or actively fix channels when there's a split of
 339   significant size.  Needless to say, the chanfix command must be used with
 340   caution.
 341
 342
 343 12. G-Lines
 344
 345   Oh yes! A G-Line section. Currently, a part of EFNet (EU-EFnet) has G-Lines
 346   enabled. This was decided by the EU admin community and is now mandatory
 347   within EU-EFnet. In order for a G-Line to be activated, three opers from
 348   three different servers need to issue the _exact_ same G-Line. The reason
 349   is not counted.
 350
 351   G-Lines work best when the EU side of EFNet is not fragmented. G-Lines
 352   will, however, propogate through a Hybrid 6 hub (but not a CSr hub) even
 353   if the hub server has G-Lines disabled. This propogation allows two halves
 354   of EU-EFnet to have concurrent G-Lines set even when split by US hub servers.
 355
 356
 357   Questions / Comments / Suggestions are welcome.
 358   You can e-mail me: dennisv@vuurwerk.nl
 359
 360 Best regards,
 361 --
 362 Dennis "Riedel" Vink       ___~___  Email - dennisv@vuurwerk.nl
 363 Unix System Administrator  \  |  /  Phone - +31 23 5111111
 364 Vuurwerk Internet           '|.|'   PGP   - 0xD68A7AAB
 365
 366 And on the seventh day, He exited from append mode.
 367
 368 # $Id: operguide.txt 26 2006-09-20 18:02:06Z spb $