]>
Commit | Line | Data |
---|---|---|
212380e3 | 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 |