1 |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
2 |
<html> |
3 |
<head> |
4 |
<meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"> |
5 |
<title>IRC Services - Frequently Asked Questions (FAQ)</title> |
6 |
</head> |
7 |
|
8 |
<body> |
9 |
<a name=top></a> |
10 |
<h1 align=center>IRC Services Manual</h1> |
11 |
|
12 |
<h2 align=center>Frequently Asked Questions (FAQ)</h2> |
13 |
|
14 |
<p align=right><font size=-1><a href=index.html>Table of Contents</a></font> |
15 |
|
16 |
<!------------------------------------------------------------------------> |
17 |
<p><hr> |
18 |
|
19 |
<h2 align=center>Frequently Asked Questions (FAQ) concerning Services</h2> |
20 |
|
21 |
<p><hr width="50%"> |
22 |
|
23 |
<h2>Index:</h2> |
24 |
|
25 |
<h3>A. General questions</h3> |
26 |
<a href="#A1">A.1. What is Services (a.k.a. IRC Services or Services for |
27 |
IRC Networks)?</a> |
28 |
<br><a href="#A2">A.2. Where can I find Services?</a> |
29 |
<br><a href="#A3">A.3. Does Services run under Windows?</a> |
30 |
<br><a href="#A4">A.4. How about other operating systems?</a> |
31 |
|
32 |
<h3>B. Compiling and starting Services</h3> |
33 |
B.1. (deleted) |
34 |
<br><a href="#B1.5">B.1.5. Why does <tt>configure</tt> complain that my |
35 |
compiler has bugs in it? Can't you work around them?</a> |
36 |
<br><a href="#B2">B.2. <tt>configure</tt> reports that my system doesn't |
37 |
have the <tt>strtok()</tt> function. Isn't that a bug?</a> |
38 |
<br><a href="#B3">B.3. When I run "<tt>make</tt>", I get an error message like |
39 |
"<tt>missing separator</tt>", "<tt>Need an operator</tt>", |
40 |
"<tt>Unexpected end of line seen</tt>", etc.</a> |
41 |
<br><a href="#B3.5">B.3.5. I get an error like "<tt>Makefile.inc not |
42 |
found</tt>".</a> |
43 |
<br>B.4. (deleted) |
44 |
<br><a href="#B5">B.5. I need support for the XYZ protocol.</a> |
45 |
<br><a href="#B6">B.6. Whenever I start Services, I get a message on my IRC |
46 |
server saying "<tt>connection refused</tt>" or something similar, |
47 |
and Services gives an error message from the server saying |
48 |
"<tt>Closing Link: </tt>. . .".</a> |
49 |
<br><a href="#B7">B.7. My IRC server is giving me messages like "<tt>Connection |
50 |
to services.example.net[127.0.0.1] activated</tt>" and then |
51 |
"<tt>Access denied -- no N line</tt>". Why?</a> |
52 |
<br><a href="#B8">B.8. When I say "<tt>/connect services.*</tt>", it doesn't |
53 |
work!</a> |
54 |
<br><a href="#B9">B.9. Services complains in the logfile about being unable to |
55 |
load the default language, or gives messages like "<tt>Warning: bad |
56 |
number of strings (747, wanted 863) for language 0 (en_us)</tt>".</a> |
57 |
|
58 |
<h3>C. Running Services</h3> |
59 |
<a href="#C1">C.1. Services keeps giving errors saying that the data |
60 |
directory is locked and the databases won't be updated.</a> |
61 |
<br><a href="#C1.5">C.1.5. Services is giving "Can't create temporary |
62 |
database file" errors.</a> |
63 |
<br><a href="#C2">C.2. Services can't keep up with my network—it is |
64 |
eventually disconnected with "<tt>Max SendQ exceeded</tt>". What |
65 |
can I do about this?</a> |
66 |
<br><a href="#C3">C.3. Services starts up okay, but if I try to register a |
67 |
nickname, it replies with "<tt>Sorry, registration failed</tt>" or |
68 |
"<tt>Internal error - unable to process request.</tt>"</a> |
69 |
<br><a href="#C4">C.4. Services crashed with a segmentation fault.</a> |
70 |
<br><a href="#C5">C.5. Services' channel mode setting doesn't work. I can't |
71 |
set modes with OperServ, and every time ChanServ tries to set a |
72 |
mode, my server reverses the change.</a> |
73 |
<br><a href="#C5.5">C.5.5. But my U:lines are set correctly!</a> |
74 |
<br><a href="#C6">C.6. My server sometimes sends messages saying "<tt>Notice -- |
75 |
User on services.example.net remotely JOINing new channel</tt>".</a> |
76 |
<br><a href="#C7">C.7. How can I make Services send replies using |
77 |
<tt>PRIVMSG</tt> (<tt>/msg</tt>) instead of <tt>NOTICE</tt>?</a> |
78 |
<br><a href="#C8">C.8. Can I make ChanServ send channel modes all at once |
79 |
instead of one at a time?</a> |
80 |
<br><a href="#C9">C.9. I sometimes get errors in the log file about "user |
81 |
record not found", "non-existent nick", or "unknown channel". What |
82 |
are these?</a> |
83 |
<br><a href="#C10">C.10. Long messages from Services sometimes get a colon |
84 |
(":") inserted in the middle.</a> |
85 |
<br><a href="#C11">C.11. Services crashes when loading databases on SPARC |
86 |
systems.</a> |
87 |
<br><a href="#C12">C.12. When using Services with InspIRCd, the IRC server |
88 |
gives a warning about "nonstandard modes".</a> |
89 |
|
90 |
<h3>D. NickServ features</h3> |
91 |
<a href="#D1">D.1. Some people get nick collided when their nickname is |
92 |
changed to <tt>Guest###</tt>.</a> |
93 |
<br><a href="#D2">D.2. Trying to use <tt>REGISTER</tt> or <tt>SET EMAIL</tt> |
94 |
resulted in an "address is unauthenticated" message, but the user |
95 |
hasn't registered any nicknames before.</a> |
96 |
|
97 |
<h3>E. ChanServ features</h3> |
98 |
<a href="#E1">E.1. How do I make ChanServ join/stay in a channel?</a> |
99 |
<br><a href="#E2">E.2. Services ignored the <tt>SET SUCCESSOR</tt> setting and |
100 |
deleted a channel when the founder expired.</a> |
101 |
<br><a href="#E3">E.3. When ChanServ sets the topic for a channel, it always |
102 |
appends "<tt>(<i>nickname</i>)</tt>" to the end. How do I make it |
103 |
not do that?</a> |
104 |
<br><a href="#E4">E.4. The <tt>ACCESS</tt> command is confusing to some |
105 |
users. Can you add a channel option to select between the |
106 |
<tt>ACCESS</tt> and <tt>XOP</tt> commands?</a> |
107 |
<br><a href="#E5">E.5. Why can't you force users to register E-mail |
108 |
addresses with channels like you can with nicknames?</a> |
109 |
<br><a href="#E6">E.6. If I use <tt>SET MLOCK</tt> on a channel to set a |
110 |
key, then anyone who enters the channel when empty can see it! How |
111 |
do I avoid this?</a> |
112 |
<br>E.7. (deleted) |
113 |
<br><a href="#E8">E.8. If a channel operator sets mode <tt>-o+v</tt> on |
114 |
himself, ChanServ always sends <tt>-v</tt>.</a> |
115 |
<br><a href="#E9">E.9. ChanServ <tt>UNBAN</tt> doesn't work properly on |
116 |
Unreal.</a> |
117 |
<br><a href="#E10">E.10. Why are the <tt>STATUS</tt> error messages so |
118 |
strange? Why doesn't <tt>STATUS</tt> obey the language setting in |
119 |
NickServ?</a> |
120 |
<br><a href="#E11">E.11. Whenever a user enters an empty channel, I see |
121 |
messages about "channel TS", and the user loses and then gets |
122 |
channel ops again.</a> |
123 |
<br><a href="#E12">E.12. When a user is autokicked from a channel, |
124 |
sometimes Services doesn't ban them and they get stuck in a |
125 |
join/kick loop.</a> |
126 |
|
127 |
<h3>F. OperServ features</h3> |
128 |
<a href="#F1">F.1. Using the OperServ <tt>JUPE</tt> command results in server |
129 |
messages like "<tt>Server juped.server introduced by non-hub server |
130 |
services.example.net</tt>" or causes Services to be disconnected.</a> |
131 |
<br><a href="#F2">F.2. I can't use the <tt>ADMIN</tt> command to add |
132 |
Services administrators—it tells me "<tt>Permission |
133 |
denied.</tt>"</a> |
134 |
<br><a href="#F3">F.3. How can I set up multiple Services super-users?</a> |
135 |
<br><a href="#F4">F.4. When I add an autokill, the users matching it don't |
136 |
get killed.</a> |
137 |
<br><a href="#F5">F.5. Services reports (via <tt>/stats u</tt> or <tt>/msg |
138 |
OperServ STATS</tt>) a different number of users online than I get |
139 |
from doing <tt>/lusers</tt>.</a> |
140 |
<br><a href="#F6">F.6. Trying to use OperServ gives me "Access denied", but my |
141 |
nick is in the ServicesRoot directive and is registered, and I've |
142 |
identified for my nick.</a> |
143 |
<br><a href="#F7">F.7. I used the <tt>RAW</tt> command to do something, and |
144 |
then Services stopped working!</a> |
145 |
<br><a href="#F8">F.8. On Unreal, every time I use the <tt>/gline</tt> |
146 |
command, Services cancels the G:line.</a> |
147 |
<br><a href="#F9">F.9. Services doesn't add <tt>AKILL</tt>s/G:lines for |
148 |
users matching autokill masks.</a> |
149 |
<br><a href="#F10">F.10. Services doesn't kill users matching a newly-added |
150 |
autokill mask even if <tt>ImmediatelySendAutokill</tt> is set.</a> |
151 |
|
152 |
<h3>Z. Bug reporting and feature requests</h3> |
153 |
<i>(section deleted)</i> |
154 |
|
155 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
156 |
|
157 |
<!------------------------------------------------------------------------> |
158 |
<p><hr> |
159 |
|
160 |
<a name=A></a> |
161 |
<h3 align=center>A. General questions</h3> |
162 |
|
163 |
<a name=A1></a> |
164 |
<p><dl><dt><b>A.1. What is Services (a.k.a. IRC Services or Services for |
165 |
IRC Networks)?</b> |
166 |
<dd><p> |
167 |
Services is a software package providing various services such as |
168 |
nickname and channel registration for IRC networks. |
169 |
<a href=index.html>Read the documentation</a> for more information. |
170 |
</dl> |
171 |
|
172 |
<a name=A2></a> |
173 |
<p><dl><dt><b>A.2. Where can I find Services?</b> |
174 |
<dd><p> |
175 |
See <a href="1.html#3">section 1-3</a> of the manual. |
176 |
</dl> |
177 |
|
178 |
<a name=A3></a> |
179 |
<p><dl><dt><b>A.3. Does Services run under Windows?</b> |
180 |
<dd><p> |
181 |
Services has been reported to run when compiled under the |
182 |
<a href="http://sources.redhat.com/cygwin/">Cygwin</a> |
183 |
<font size=-1>[<tt>sources.redhat.com</tt>]</font> environment for |
184 |
Windows, but has not been tested extensively and is not supported |
185 |
by the author. |
186 |
<p> |
187 |
One user has reported success in running Services as a Windows |
188 |
service; however, the database files must be owned by the Windows |
189 |
user under which Services runs (<i>e.g.</i> Administrator), and the |
190 |
files' security properties must be changed to prevent the file |
191 |
owner from being altered. |
192 |
</dl> |
193 |
|
194 |
<a name=A4></a> |
195 |
<p><dl><dt><b>A.4. How about other operating systems?</b> |
196 |
<dd><p> |
197 |
Services was at one point reported to be usable under OS/2; |
198 |
however, it has not been tested recently and is not supported. |
199 |
The author has also heard reports of Services being used with |
200 |
moderate success on AmigaOS. |
201 |
</dl> |
202 |
|
203 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
204 |
|
205 |
<!------------------------------------------------------------------------> |
206 |
<p><hr> |
207 |
|
208 |
<a name=B></a> |
209 |
<h3 align=center>B. Compiling and starting Services:</h3> |
210 |
|
211 |
<a name=B1></a> |
212 |
<p><dl><dt><i>B.1. (deleted)</i> |
213 |
</dl> |
214 |
|
215 |
<a name=B1.5></a> |
216 |
<p><dl><dt><b>B.1.5. Why does <tt>configure</tt> complain that my |
217 |
compiler has bugs in it? Can't you work around them?</b> |
218 |
<dd><p> |
219 |
GCC versions earlier than 3.4 have bugs which cause the |
220 |
<tt>__builtin_apply()</tt> and <tt>__builtin_return()</tt> |
221 |
pseudofunctions to be miscompiled (see GCC Bugzilla, bugs |
222 |
<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8028">8028</a> and |
223 |
<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11151">11151</a> |
224 |
<font size=-1>[<tt>gcc.gnu.org</tt>]</font>, for details). |
225 |
Working around this problem requires the use of assembly language, |
226 |
so workarounds are platform-specific; Services has workarounds for |
227 |
these bugs on the Intel x86, SPARC, and PowerPC platforms, but on |
228 |
other systems, you will need to use GCC 3.4 or later, or the |
229 |
<tt>configure</tt> script will report an error and refuse to |
230 |
continue. |
231 |
</dl> |
232 |
|
233 |
<a name=B2></a> |
234 |
<p><dl><dt><b>B.2. <tt>configure</tt> reports that my system doesn't |
235 |
have the <tt>strtok()</tt> function. Isn't that a bug?</b> |
236 |
<dd><p> |
237 |
Many system libraries, including some versions of the libraries |
238 |
used with Linux and Solaris, have subtle bugs in their |
239 |
<tt>strtok()</tt> implementations which cause Services to perform |
240 |
improperly, or even crash in some cases. The <tt>configure</tt> |
241 |
script checks for these bugs, and reports <tt>strtok()</tt> as "not |
242 |
found" if one or more bugs are present. (In fairness, the |
243 |
definition of <tt>strtok()</tt> is vague in some respects, and |
244 |
developers of these libraries may have interpreted it differently |
245 |
than the way it is used in Services.) |
246 |
</dl> |
247 |
|
248 |
<a name=B3></a> |
249 |
<p><dl><dt><b>B.3. When I run "<tt>make</tt>", I get an error message like |
250 |
"<tt>missing separator</tt>", "<tt>Need an operator</tt>", |
251 |
"<tt>Unexpected end of line seen</tt>", etc.</b> |
252 |
<dd><p> |
253 |
Your <tt>make</tt> program isn't compatible with the Makefile for |
254 |
Services. The Makefile was designed to work with GNU |
255 |
<tt>make</tt>, version 3.79 or later, and may not work with older |
256 |
versions or other systems' "<tt>make</tt>" programs. In |
257 |
particular, the <tt>make</tt> programs bundled with SunOS/Solaris |
258 |
and FreeBSD have been reported not to work; you will need to use |
259 |
GNU <tt>make</tt> on these systems. See the |
260 |
<a href="2.html#1">system requirements section</a> for details. |
261 |
</dl> |
262 |
|
263 |
<a name=B3.5></a> |
264 |
<p><dl><dt><b>B.3.5. I get an error like "<tt>Makefile.inc not found</tt>".</b> |
265 |
<dd><p> |
266 |
You forgot to run the <tt>configure</tt> script first. See the |
267 |
<a href="2.html#3">installation directions</a>. |
268 |
</dl> |
269 |
|
270 |
<a name=B4></a> |
271 |
<p><dl><dt><i>B.4. (deleted)</i> |
272 |
</dl> |
273 |
|
274 |
<a name=B5></a> |
275 |
<p><dl><dt><b>B.5. I need support for the XYZ protocol.</b> |
276 |
<dd><p> |
277 |
Services can be made to support new IRC protocols with the addition |
278 |
of new protocol modules. You will need to write a protocol module |
279 |
to support the specific protocol you want to use; see the |
280 |
<a href="tech/index.html">technical manual</a> for details. |
281 |
</dl> |
282 |
|
283 |
<a name=B6></a> |
284 |
<p><dl><dt><b>B.6. Whenever I start Services, I get a message on my IRC |
285 |
server saying "<tt>connection refused</tt>" or something similar, |
286 |
and Services gives an error message from the server saying |
287 |
"<tt>Closing Link: </tt>. . .".</b> |
288 |
<dd><p> |
289 |
You need to configure your IRC server to accept Services as an IRC |
290 |
server. For IRC servers based on the irc2.x distribution, that |
291 |
involves adding two lines like the following to your |
292 |
<tt>ircd.conf</tt> file: |
293 |
<blockquote> |
294 |
<tt>C:127.0.0.1:password:services.whatever.net::99</tt> |
295 |
<br><tt>N:127.0.0.1:password:services.whatever.net::99</tt> |
296 |
</blockquote> |
297 |
See your IRC server's documentation for details about configuring |
298 |
your servers to accept connections from Services. |
299 |
<p> |
300 |
Note particularly that "no N:line" errors can mean any of several |
301 |
things: |
302 |
<p><ul> |
303 |
<li>Services' IP address or host name is different than that in the |
304 |
first parameter to the <tt>N:</tt> line. On some systems, |
305 |
using "<tt>localhost</tt>" in the <tt>RemoteServer</tt> |
306 |
configuration directive will not always get you the IP address |
307 |
<tt>127.0.0.1</tt>! To check what hostname or IP address the |
308 |
IRC server thinks you have, start up an IRC client on the same |
309 |
machine you are running Services on, connect to the server |
310 |
given in the <tt>RemoteServer</tt> directive, and do a |
311 |
<tt>/whois</tt> on yourself; the hostname in the <tt>/whois</tt> |
312 |
response should be used as the first <tt>N:</tt> line parameter. |
313 |
<p> |
314 |
<li>Your IRC server has been compiled to use encrypted <tt>N:</tt> |
315 |
line passwords but you gave a plaintext password as the second |
316 |
<tt>N:</tt> line parameter, or vice versa. |
317 |
<p> |
318 |
<li>The server name given as the third <tt>N:</tt> line parameter |
319 |
does not match the name given in the <tt>ServerName</tt> |
320 |
configuration directive. The third parameter is not the |
321 |
IP address or hostname of the remote server (Services in this |
322 |
case), but rather the server name presented in the server |
323 |
registration (<tt>SERVER</tt>) message; this is an important |
324 |
distinction that can be easily forgotten. |
325 |
</ul> |
326 |
</dl> |
327 |
|
328 |
<a name=B7></a> |
329 |
<p><dl><dt><b>B.7. My IRC server is giving me messages like "<tt>Connection |
330 |
to services.example.net[127.0.0.1] activated</tt>" and then |
331 |
"<tt>Access denied -- no N line</tt>". Why?</b> |
332 |
<dd><p> |
333 |
This is typically caused by including a port number in the C:line |
334 |
for Services, which tells your server to try to autoconnect to it. |
335 |
This is not what you want, because Services will connect to the |
336 |
server itself, but does not listen for servers to connect to it. |
337 |
The solution is to remove the port number from the C:line. |
338 |
</dl> |
339 |
|
340 |
<a name=B8></a> |
341 |
<p><dl><dt><b>B.8. When I say "<tt>/connect services.*</tt>", it doesn't |
342 |
work!</b> |
343 |
<dd><p> |
344 |
As described in answer B.7 above, Services does not listen for |
345 |
connections, so you cannot <tt>/connect</tt> to it. |
346 |
</dl> |
347 |
|
348 |
<a name=B9></a> |
349 |
<p><dl><dt><b>B.9. Services complains in the logfile about being unable to |
350 |
load the default language, or gives messages like "<tt>Warning: bad |
351 |
number of strings (747, wanted 863) for language 0 (en_us)</tt>".</b> |
352 |
<dd><p> |
353 |
You forgot to run "<tt>make install</tt>" after compiling Services. |
354 |
</dl> |
355 |
|
356 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
357 |
|
358 |
<!------------------------------------------------------------------------> |
359 |
<p><hr> |
360 |
|
361 |
<a name=C></a> |
362 |
<h3 align=center>C. Running Services:</h3> |
363 |
|
364 |
<a name=C1></a> |
365 |
<p><dl><dt><b>C.1. Services keeps giving errors saying that the data |
366 |
directory is locked and the databases won't be updated.</b> |
367 |
<dd><p> |
368 |
This can occur if Services was interrupted (<i>e.g.,</i> by a power |
369 |
failure) or crashed while writing the databases. Remove the file |
370 |
given in the warning message (this is the file specified by the |
371 |
<tt>ircservices.conf</tt> |
372 |
<a href="a.html#LockFilename"><tt>LockFilename</tt></a> directive, |
373 |
by default "<tt>.lock</tt>" in the Services data directory), then |
374 |
use the OperServ <a href="4.html#oper.update"><tt>UPDATE</tt></a> |
375 |
command to save the databases; alternatively, the <tt>FORCE</tt> |
376 |
option can be used with the OperServ <tt>UPDATE</tt> command to |
377 |
perform both steps at once. |
378 |
</dl> |
379 |
|
380 |
<a name=C1.5></a> |
381 |
<p><dl><dt><b>C.1.5. Services is giving "Can't create temporary database |
382 |
file" errors.</b> |
383 |
<dd><p> |
384 |
Make certain that (1) the disk on which the databases are stored is |
385 |
not full, and (2) that Services has permission to create files in |
386 |
the data directory (on Unix systems, this means that the user-ID that |
387 |
Services runs as must have write and execute permission on the data |
388 |
directory, as well as execute permission on all parent directories |
389 |
of the data directory). |
390 |
</dl> |
391 |
|
392 |
<a name=C2></a> |
393 |
<p><dl><dt><b>C.2. Services can't keep up with my network—it is |
394 |
eventually disconnected with "<tt>Max SendQ exceeded</tt>". What |
395 |
can I do about this?</b> |
396 |
<dd><p> |
397 |
If you have a really large network (tens of thousands of |
398 |
simultaneous users), Services in its default configuration may not |
399 |
be able to keep up with all the network traffic. Here are some |
400 |
possible ways to speed Services up: |
401 |
<p><ul> |
402 |
<li>Run it on a faster computer. (Services does <i>not</i> need to |
403 |
run on the same system as an IRC server! If you have several |
404 |
computers connected via Ethernet or another type of high-speed |
405 |
network, it's perfectly fine to have an ircd on one machine and |
406 |
Services on a separate machine.) |
407 |
<li>Remove all unneeded modules from <tt>ircservices.conf</tt>. |
408 |
<li>Configure Services with the <tt>-no-sorted-lists</tt> option |
409 |
and recompile. (This will speed up nickname and channel |
410 |
access, but commands like NickServ and ChanServ LIST will no |
411 |
longer return names in alphabetical order.) |
412 |
<li>Reduce the nickname and channel expiration periods. |
413 |
<li>Reduce the size of your autokill, S-line, and session limit |
414 |
exception lists as much as possible, or remove the relevant |
415 |
modules (<tt>operserv/akill</tt>, <tt>operserv/sline</tt>, and |
416 |
<tt>operserv/sessions</tt>) entirely. |
417 |
<li>Reduce the maximum number of autokicks per channel. (This will |
418 |
not have a direct effect, but it may keep the problem from |
419 |
getting worse.) |
420 |
<li>Increase the <tt>UpdateTimeout</tt> setting in |
421 |
<tt>ircservices.conf</tt>, to reduce the frequency of database |
422 |
synchronization. However, keep in mind that this will mean |
423 |
more potential data loss if/when Services falls off your |
424 |
network or crashes. |
425 |
<li><b>Don't</b> run in debug mode! |
426 |
</ul> |
427 |
<p>Services has been successfully used on networks as large as |
428 |
22,000 simultaneous users with 260,000 registered nicks. |
429 |
</dl> |
430 |
|
431 |
<a name=C3></a> |
432 |
<p><dl><dt><b>C.3. Services starts up okay, but if I try to register a |
433 |
nickname, it replies with "<tt>Sorry, registration failed</tt>" or |
434 |
"<tt>Internal error - unable to process request.</tt>"</b> |
435 |
<dd><p> |
436 |
Make sure you've selected the correct IRC protocol (IRC server) |
437 |
module in <tt>ircservices.conf</tt>, as described in |
438 |
<a href="2.html#4">section 2-4</a>. |
439 |
</dl> |
440 |
|
441 |
<a name=C4></a> |
442 |
<p><dl><dt><b>C.4. Services crashed with a segmentation fault.</b> |
443 |
<dd><p> |
444 |
Hopefully most of the bugs have been worked out of Services by now, |
445 |
but if you run into a problem like this, you may find the |
446 |
<tt>cron</tt> utility useful for dealing with such with it; the |
447 |
<tt>ircservices-chk</tt> script, installed in the same place as the |
448 |
<tt>ircservices</tt> executable, will check whether Services is |
449 |
running and restart it if not (see |
450 |
<a href="2.html#6-ircservices-chk">section 2-6</a> for details). |
451 |
</dl> |
452 |
|
453 |
<a name=C5></a> |
454 |
<p><dl><dt><b>C.5. Services' channel mode setting doesn't work. I can't |
455 |
set modes with OperServ, and every time ChanServ tries to set a |
456 |
mode, my server reverses the change.</b> |
457 |
<dd><p> |
458 |
If you're running the DALnet, Unreal, or Undernet IRC server, make |
459 |
sure <i>every</i> server on your network has a U:line for Services |
460 |
in <tt>ircd.conf</tt>; for example: |
461 |
<blockquote> |
462 |
<tt>U:services.whatever.net:*:*</tt> |
463 |
</blockquote> |
464 |
Services will report in a <tt>WALLOPS</tt> or <tt>GLOBOPS</tt> |
465 |
message the first time it discovers it cannot change modes. |
466 |
</dl> |
467 |
|
468 |
<a name=C5.5></a> |
469 |
<p><dl><dt><b>C.5.5. But my U:lines are set correctly!</b> |
470 |
<dd><p> |
471 |
If the <tt>ircd.conf</tt> file was created, edited, or copied from |
472 |
a Windows computer, then it may be corrupt (Windows inserts |
473 |
<tt>^M</tt> characters at the end of every line), which will cause |
474 |
the ircd to not recognize the U:line. Use a text editor such as vi |
475 |
or Emacs to remove the <tt>^M</tt> characters, or re-create the |
476 |
file from scratch. |
477 |
</dl> |
478 |
|
479 |
<a name=C6></a> |
480 |
<p><dl><dt><b>C.6. My server sometimes sends messages saying "<tt>Notice -- |
481 |
User on services.example.net remotely JOINing new channel</tt>".</b> |
482 |
<dd><p> |
483 |
This is normal, and happens whenever ChanServ kicks a user from a |
484 |
channel in which they were the first to enter (for example, a user |
485 |
without privileges entering a channel with the <tt>RESTRICTED</tt> |
486 |
setting active, or a user on the channel's autokick list). In this |
487 |
case, ChanServ joins the channel for a short period of time to |
488 |
prevent the user from joining again immediately after they've been |
489 |
kicked. If you are using the Bahamut or Unreal IRC servers, this |
490 |
will result in a message like the above; it can be safely ignored. |
491 |
</dl> |
492 |
|
493 |
<a name=C7></a> |
494 |
<p><dl><dt><b>C.7. How can I make Services send replies using |
495 |
<tt>PRIVMSG</tt> (<tt>/msg</tt>) instead of <tt>NOTICE</tt>?</b> |
496 |
<dd><p> |
497 |
You can't. RFC 1459 (the IRC protocol definition) requires that |
498 |
all automated clients send all replies using <tt>NOTICE</tt> rather |
499 |
than <tt>PRIVMSG</tt>, and Services follows that requirement. If |
500 |
you want to change how Services replies appear in your IRC client, |
501 |
change your client's settings. |
502 |
</dl> |
503 |
|
504 |
<a name=C8></a> |
505 |
<p><dl><dt><b>C.8. Can I make ChanServ send channel modes all at once |
506 |
instead of one at a time?</b> |
507 |
<dd><p> |
508 |
Yes; enable the <tt>MergeChannelModes</tt> directive in |
509 |
<tt>ircservices.conf</tt>. (Note that this has minor security |
510 |
implications—be sure to read the comments in the example |
511 |
configuration file.) |
512 |
</dl> |
513 |
|
514 |
<a name=C9></a> |
515 |
<p><dl><dt><b>C.9. I sometimes get errors in the log file about "user |
516 |
record not found", "non-existent nick", or "unknown channel". What |
517 |
are these?</b> |
518 |
<dd><p> |
519 |
These messages can appear when Services disconnects a user from the |
520 |
network or removes (kicks) a user from a channel, and are the |
521 |
result of time lag inherent in all networked systems. For example, |
522 |
if an autokilled user connects to the network and immediately sends |
523 |
a <tt>/join</tt> command to join a channel, the user's server may |
524 |
receive the <tt>/join</tt> before it receives the disconnection |
525 |
message from Services. Services will then receive the <tt>/join</tt> |
526 |
for what it thinks is a user who no longer exists, and reports that |
527 |
it received a message for a non-existent nickname. |
528 |
<p> |
529 |
These messages do not indicate a bug or other problem, and can be |
530 |
safely ignored. |
531 |
</dl> |
532 |
|
533 |
<a name=C10></a> |
534 |
<p><dl><dt><b>C.10. Long messages from Services sometimes get a colon |
535 |
(":") inserted in the middle.</b> |
536 |
<dd><p> |
537 |
This is caused by a bug in the "mIRC" IRC client for Windows |
538 |
computers; if you try to send a very long message using the |
539 |
<tt>/operserv</tt> (or <tt>/nickserv</tt>, etc.) command, such as a |
540 |
long global notice, then mIRC will insert a colon in the middle of |
541 |
it. There is nothing Services can do to fix this, since Services |
542 |
can't tell whether the colon was intentionally put there or not. |
543 |
If you experience this problem, try upgrading mIRC to the latest |
544 |
version or using another IRC client. Alternatively, as a |
545 |
workaround you can use <tt>/msg OperServ</tt> instead of |
546 |
<tt>/operserv</tt>. |
547 |
<p> |
548 |
See also <a href="http://trout.snt.utwente.nl/ubbthreads/ubbthreads.php?ubb=showflat&Number=117232&site_id=1#import">this thread</a> |
549 |
<font size=-1>[<tt>trout.snt.utwente.nl</tt>]</font> on the mIRC |
550 |
forums. |
551 |
</dl> |
552 |
|
553 |
<a name=C11></a> |
554 |
<p><dl><dt><b>C.11. Services crashes when loading databases on SPARC |
555 |
systems.</b> |
556 |
<dd><p> |
557 |
This is due to a bug in some versions of GCC running on SPARC |
558 |
systems. Services contains a temporary workaround for this |
559 |
problem, but it is very compiler- and environment-specific, and it |
560 |
may not work for you. The bug has been filed in the GCC bug |
561 |
database as |
562 |
<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11151">bug |
563 |
11151</a> <font size=-1>[<tt>gcc.gnu.org</tt>]</font>, and has been |
564 |
fixed as of GCC 3.4. |
565 |
</dl> |
566 |
|
567 |
<a name=C12></a> |
568 |
<p><dl><dt><b>C.12. When using Services with InspIRCd, the IRC server |
569 |
gives a warning about "nonstandard modes".</b> |
570 |
<dd><p> |
571 |
A message like the following: |
572 |
<blockquote><tt>WARNING: The server services.example.net is sending |
573 |
nonstandard modes: 'ChanServ MODE +r' where FMODE should be |
574 |
used, and may cause desyncs.</tt></blockquote> |
575 |
<p> |
576 |
is a side effect of the way Services works, and can be safely |
577 |
ignored; the "may cause desyncs" text does not apply to Services. |
578 |
</dl> |
579 |
|
580 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
581 |
|
582 |
<!------------------------------------------------------------------------> |
583 |
<p><hr> |
584 |
|
585 |
<a name=D></a> |
586 |
<h3 align=center>D. NickServ features:</h3> |
587 |
|
588 |
<a name=D1></a> |
589 |
<p><dl><dt><b>D.1. Some people get nick collided when their nickname is |
590 |
changed to <tt>Guest###</tt>.</b> |
591 |
<dd><p> |
592 |
Make sure you have <tt>Guest*</tt> (or whatever prefix you |
593 |
specified in <tt>ircservices.conf</tt>) listed in a Q:line in the |
594 |
<tt>ircd.conf</tt> file for <i>all</i> of your servers. For |
595 |
example: |
596 |
|
597 |
<blockquote> |
598 |
<tt>Q::Reserved for Services:Guest*</tt> |
599 |
</blockquote> |
600 |
|
601 |
This prevents people from using <tt>Guest###</tt> nicks and |
602 |
colliding people who get their nicks changed. Note that some IRC |
603 |
servers will generate messages whenever someone gets their nick |
604 |
changed to <tt>Guest###</tt> by Services and a configuration line |
605 |
like the above is used; you may want to modify your IRC client's |
606 |
configuration so it doesn't display the messages (or change the IRC |
607 |
server itself so it doesn't generate them). |
608 |
<p> |
609 |
Alternatively, if your IRC server supports SQlines, you can set an |
610 |
SQline on the same mask using the OperServ <tt>SQLINE ADD</tt> |
611 |
command (in the <tt>operserv/sline</tt> module), and Services will |
612 |
take care of making sure all servers have Q:lines for the nick. |
613 |
</dl> |
614 |
|
615 |
<a name=D2></a> |
616 |
<p><dl><dt><b>D.2. Trying to use <tt>REGISTER</tt> or <tt>SET EMAIL</tt> |
617 |
resulted in an "address is unauthenticated" message, but the user |
618 |
hasn't registered any nicknames before.</b> |
619 |
<dd><p> |
620 |
Another user may have set the same E-mail address on their |
621 |
nickname. Use the <tt>LISTEMAIL</tt> command to see what nicknames |
622 |
have the problem address associated with them. |
623 |
</dl> |
624 |
|
625 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
626 |
|
627 |
<!------------------------------------------------------------------------> |
628 |
<p><hr> |
629 |
|
630 |
<a name=E></a> |
631 |
<h3 align=center>E. ChanServ features:</h3> |
632 |
|
633 |
<a name=E1></a> |
634 |
<p><dl><dt><b>E.1. How do I make ChanServ join/stay in a channel?</b> |
635 |
<dd><p> |
636 |
You don't. Use a bot instead. |
637 |
</dl> |
638 |
|
639 |
<a name=E2></a> |
640 |
<p><dl><dt><b>E.2. Services ignored the <tt>SET SUCCESSOR</tt> setting and |
641 |
deleted a channel when the founder expired.</b> |
642 |
<dd><p> |
643 |
Normally, this is because the successor had too many channels |
644 |
registered; in this case, you will see an entry in the log file |
645 |
like the following: |
646 |
|
647 |
<blockquote> |
648 |
<tt>[date] Successor (SuccessorNick) of channel #somechannel owns |
649 |
too many channels, deleting channel #somechannel</tt> |
650 |
</blockquote> |
651 |
</dl> |
652 |
<a name=E3></a> |
653 |
<p><dl><dt><b>E.3. When ChanServ sets the topic for a channel, it always |
654 |
appends "<tt>(<i>nickname</i>)</tt>" to the end. How do I make it |
655 |
not do that?</b> |
656 |
<dd><p> |
657 |
This has nothing to do with Services, and is a feature of the IRC |
658 |
server itself which occurs when Services sets the topic on a |
659 |
channel. The "(nickname)" is not actually included in the topic, |
660 |
and the second and later users to join the channel will not see it. |
661 |
There is no way to disable it for the first user, unless you modify |
662 |
the IRC server itself. |
663 |
</dl> |
664 |
<a name=E4></a> |
665 |
<p><dl><dt><b>E.4. The <tt>ACCESS</tt> command is confusing to some |
666 |
users. Is there a way to select between the <tt>ACCESS</tt> and |
667 |
<tt>XOP</tt> commands?</b> |
668 |
<dd><p> |
669 |
No; just tell those users to not use the <tt>ACCESS</tt> command. |
670 |
(You can also disable the <tt>ACCESS</tt> command for the whole |
671 |
network by removing or commenting out the |
672 |
<tt>LoadModule chanserv/access-levels</tt> line in |
673 |
<tt>ircservices.conf</tt>, but this will prevent even users who |
674 |
understand the <tt>ACCESS</tt> command from using it.) |
675 |
</dl> |
676 |
<a name=E5></a> |
677 |
<p><dl><dt><b>E.5. Why can't you force users to register E-mail |
678 |
addresses with channels like you can with nicknames?</b> |
679 |
<dd><p> |
680 |
Such functionality is unneeded, because ChanServ requires users to |
681 |
register their nicknames before allowing them to register channels. |
682 |
As long as you require users to include E-mail addresses with |
683 |
nicknames, you can just look up the address for the channel |
684 |
founder's nickname if a problem arises with a particular channel. |
685 |
</dl> |
686 |
|
687 |
<a name=E6></a> |
688 |
<p><dl><dt><b>E.6. If I use <tt>SET MLOCK</tt> on a channel to set a |
689 |
key, then anyone who enters the channel when empty can see it! How |
690 |
do I avoid this?</b> |
691 |
<dd><p> |
692 |
Set the <tt>RESTRICTED</tt> option for the channel, as described in |
693 |
<a href="4.html#chan.set_mlock">the help for <tt>SET MLOCK</tt></a>, |
694 |
or use a bot to keep the channel open. |
695 |
</dl> |
696 |
|
697 |
<a name=E7></a> |
698 |
<p><dl><dt><i>E.7. (deleted)</i> |
699 |
</dl> |
700 |
|
701 |
<a name=E8></a> |
702 |
<p><dl><dt><b>E.8. If a channel operator sets mode <tt>-o+v</tt> on |
703 |
himself, ChanServ always sends <tt>-v</tt>.</b> |
704 |
<dd><p> |
705 |
This is a side effect of security measures which prevent non-autoop |
706 |
users from getting a <tt>+v</tt> in before Services deops them. |
707 |
Either do the <tt>+v</tt> before the <tt>-o</tt> or use the |
708 |
ChanServ <tt>VOICE</tt> command. |
709 |
</dl> |
710 |
|
711 |
<a name=E9></a> |
712 |
<p><dl><dt><b>E.9. ChanServ <tt>UNBAN</tt> doesn't work properly on |
713 |
Unreal.</b> |
714 |
<dd><p> |
715 |
In recent versions of Unreal, it is possible to set bans on a |
716 |
user's IP address. However, Unreal 3.2 servers do not send client |
717 |
IP address information to Services, so it is impossible to tell |
718 |
which IP-address bans match the user; thus the <tt>UNBAN</tt> |
719 |
command will fail to remove them. Unreal 3.2.1 and later do send |
720 |
IP addresses to Services, so if you upgrade all of your servers the |
721 |
problem will go away. |
722 |
</dl> |
723 |
|
724 |
<a name=E10></a> |
725 |
<p><dl><dt><b>E.10. Why are the <tt>STATUS</tt> error messages so |
726 |
strange? Why doesn't <tt>STATUS</tt> obey the language setting in |
727 |
NickServ?</b> |
728 |
<dd><p> |
729 |
The <tt>STATUS</tt> command is intended primarily for use by bots, |
730 |
to allow them to take advantage of access level information stored |
731 |
in Services. For this reason, the responses to the <tt>STATUS</tt> |
732 |
command, including error messages, need to have a fixed format that |
733 |
can be understood by a computer. |
734 |
</dl> |
735 |
|
736 |
|
737 |
<a name=E11></a> |
738 |
<p><dl><dt><b>E.11. Whenever a user enters an empty channel, I see |
739 |
messages about "channel TS", and the user loses and then gets |
740 |
channel ops again.</b> |
741 |
<dd><p> |
742 |
These messages and mode changes are harmless, and are caused by the |
743 |
<a href="a.html#protocol/(insert_protocol_name_here).CSSetChannelTime"><tt>CSSetChannelTime</tt></a> |
744 |
configuration option (see also <a href="3.html#2-1.channel-ts">the |
745 |
relevant part of section 3-2-1</a>). This functionality is |
746 |
implemented by sending a message to the network that Services has |
747 |
the "proper" timestamp (TS) and modes for the channel. |
748 |
Unfortunately, many IRC servers blindly cancel their own modes, |
749 |
including the channel ops of the user who initially joined the |
750 |
channel, before noticing that Services is not actually changing any |
751 |
modes; this results in the server sending out a "<tt>-o</tt>" mode |
752 |
change immediately followed by a "<tt>+o</tt>". Some servers also |
753 |
seem to think that the timestamp change is a bug (or hack attempt) |
754 |
and send out a warning to IRC operators about it. |
755 |
<p> |
756 |
All of these messages are harmless and can be safely ignored, but |
757 |
if they bother you, you may want to consider disabling the |
758 |
<tt>CSSetChannelTime</tt> option. |
759 |
</dl> |
760 |
|
761 |
|
762 |
<a name=E12></a> |
763 |
<p><dl><dt><b>E.12. When a user is autokicked from a channel, |
764 |
sometimes Services doesn't ban them and they get stuck in a |
765 |
join/kick loop.</b> |
766 |
<dd><p> |
767 |
If you are using the Unreal IRC server, this may be caused by |
768 |
"extended ban types", specifically third-party Unreal modules that |
769 |
add ban types beyond the standard types in Unreal 3.2 (<tt>q</tt>, |
770 |
<tt>n</tt>, <tt>c</tt>, and <tt>r</tt>); Services cannot support |
771 |
such ban types, since their behavior is undefined by the base |
772 |
Unreal protocol. Try disabling such modules and see if the problem |
773 |
persists. |
774 |
</dl> |
775 |
|
776 |
|
777 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
778 |
|
779 |
<!------------------------------------------------------------------------> |
780 |
<p><hr> |
781 |
|
782 |
<a name=F></a> |
783 |
<h3 align=center>F. OperServ features:</h3> |
784 |
|
785 |
<a name=F1></a> |
786 |
<p><dl><dt><b>F.1. Using the OperServ <tt>JUPE</tt> command results in server |
787 |
messages like "<tt>Server juped.server introduced by non-hub server |
788 |
services.example.net</tt>" or causes Services to be disconnected.</b> |
789 |
<dd><p> |
790 |
In all irc2.x-derived IRC servers (and possibly others), every |
791 |
server on the network must have an H:line for Services in the |
792 |
<tt>ircd.conf</tt> file, which looks something like: |
793 |
|
794 |
<blockquote> |
795 |
<tt>H:*::services.example.net</tt> |
796 |
</blockquote> |
797 |
</dl> |
798 |
|
799 |
<a name=F2></a> |
800 |
<p><dl><dt><b>F.2. I can't use the <tt>ADMIN</tt> command to add Services |
801 |
administrators—it tells me "<tt>Permission denied.</tt>"</b> |
802 |
<dd><p> |
803 |
Did you define yourself as the Services super-user? You need to |
804 |
insert your nickname in the |
805 |
<a href="a.html#operserv/main.ServicesRoot"><tt>ServicesRoot</tt></a> |
806 |
directive in the <tt>operserv/main</tt> section of |
807 |
<tt>modules.conf</tt>. Also make sure that you have registered and |
808 |
identified for your nickname, and that you have IRC operator |
809 |
privileges. |
810 |
</dl> |
811 |
|
812 |
<a name=F3></a> |
813 |
<p><dl><dt><b>F.3. How can I set up multiple Services super-users?</b> |
814 |
<dd><p> |
815 |
You can't. However, you can allow Services administrators to |
816 |
obtain Services super-user privilege by setting a password with the |
817 |
OperServ <a href="4.html#oper.set_supass"><tt>SET SUPASS</tt></a> |
818 |
command; Services admins can then use the |
819 |
<a href="4.html#oper.su"><tt>SU</tt></a> command to obtain Services |
820 |
super-user privilege. |
821 |
</dl> |
822 |
|
823 |
<a name=F4></a> |
824 |
<p><dl><dt><b>F.4. When I add an autokill, the users matching it don't get |
825 |
killed.</b> |
826 |
<dd><p> |
827 |
Services does not kill users when an autokill is added; it only |
828 |
kills them when they next connect. This is designed behavior, |
829 |
intended to reduce the possibility of a mistyped autokill causing |
830 |
the wrong users to get killed. (Suppose you typed "<tt>AKILL ADD |
831 |
*@*</tt>" and then accidentally hit Enter before finishing the host |
832 |
mask . . .) |
833 |
</dl> |
834 |
|
835 |
<a name=F5></a> |
836 |
<p><dl><dt><b>F.5. Services reports (via <tt>/stats u</tt> or <tt>/msg |
837 |
OperServ STATS</tt>) a different number of users online than I get |
838 |
from doing <tt>/lusers</tt>.</b> |
839 |
<dd><p> |
840 |
Services doesn't count its own pseudo-clients (NickServ, ChanServ, |
841 |
etc.) in its user count, so Services will normally report a number |
842 |
somewhat lower than /lusers. This number will vary depending on |
843 |
which pseudo-clients are loaded, and will also change as nickname |
844 |
enforcers are introduced and removed. |
845 |
<p> |
846 |
If you have a very large and/or busy network, there may be an |
847 |
additional offset, either positive or negative, caused by lag |
848 |
(1) between users signing on/off and Services recognizing them, or |
849 |
(2) between Services killing a user and the servers receiving the |
850 |
kill. On a network with under 500 simultaneous clients, this |
851 |
difference should typically not be more than one at any time, but |
852 |
it can increase quickly as the network grows in size. (If the |
853 |
difference is abnormally large, see <a href="#C2">question C.2</a> |
854 |
for ways to speed Services up.) |
855 |
<p> |
856 |
Finally, you may have encountered a bug in Services. If the |
857 |
difference in counts increases over time without a corresponding |
858 |
increase in the number of users online, then this is the most |
859 |
likely explanation. |
860 |
</dl> |
861 |
|
862 |
<a name=F6></a> |
863 |
<p><dl><dt><b>F.6. Trying to use OperServ gives me "Access denied", but my |
864 |
nick is in the <tt>ServicesRoot</tt> directive and is registered, |
865 |
and I've identified for my nick.</b> |
866 |
<dd><p> |
867 |
You need to be opered (<i>i.e.,</i> user mode <tt>+o</tt> from using |
868 |
<tt>/oper</tt>; this is different from channel operator mode) to |
869 |
access OperServ. |
870 |
</dl> |
871 |
|
872 |
<a name=F7></a> |
873 |
<p><dl><dt><b>F.7. I used the <tt>RAW</tt> command to do something, and |
874 |
then Services stopped working!</b> |
875 |
<dd><p> |
876 |
To quote from the help for the <tt>RAW</tt> command: |
877 |
|
878 |
<blockquote> |
879 |
<tt>This command is intended primarily for testing of Services |
880 |
and IRC servers; it has a very limited range of uses on a |
881 |
live network, and can wreak havoc on a network or cause |
882 |
Services to crash if used improperly. <b>DO NOT USE THIS |
883 |
COMMAND</b> unless you are absolutely certain you know |
884 |
what you are doing!</tt> |
885 |
</blockquote> |
886 |
|
887 |
In particular, Services does <i>not</i> process any messages sent |
888 |
with the <tt>RAW</tt> command; so if (for example) you use |
889 |
<tt>KILL</tt> to kill a user, Services will think the user is still |
890 |
online, and if they connect to the network again, Services may fail |
891 |
to recognize the new user or even crash. You should not use the |
892 |
<tt>RAW</tt> command without a detailed understanding of both the |
893 |
IRC protocol and the internal design of Services itself. |
894 |
</dl> |
895 |
|
896 |
<a name=F8></a> |
897 |
<p><dl><dt><b>F.8. On Unreal, every time I use the <tt>/gline</tt> command, |
898 |
Services cancels the G:line.</b> |
899 |
<dd><p> |
900 |
This is designed behavior. Use the OperServ |
901 |
<a href="4.html#oper.akill"><tt>AKILL</tt></a> command instead of |
902 |
the <tt>/gline</tt> command. |
903 |
</dl> |
904 |
|
905 |
<a name=F9></a> |
906 |
<p><dl><dt><b>F.9. Services doesn't add <tt>AKILL</tt>s/G:lines for users |
907 |
matching autokill masks.</b> |
908 |
<dd><p> |
909 |
If you have |
910 |
<a href="a.html#operserv/akill.EnableExclude"><tt>EnableExclude</tt></a> |
911 |
defined in the <tt>operserv/akill</tt> section of |
912 |
<tt>modules.conf</tt>, but your IRC server does not support |
913 |
autokill exclusions, then Services will not add <tt>AKILL</tt>s or |
914 |
G:lines, because doing so would prevent autokill exclusions from |
915 |
working properly. See <a href="3.html#4-3-exclude">section |
916 |
3-4-3</a> for details. |
917 |
</dl> |
918 |
|
919 |
<a name=F10></a> |
920 |
<p><dl><dt><b>F.10. Services doesn't kill users matching a newly-added |
921 |
autokill mask even if <tt>ImmediatelySendAutokill</tt> is set.</b> |
922 |
<dd><p> |
923 |
Services never kills users when a new autokill is added; the |
924 |
<a href="a.html#operserv/akill.ImmediatelySendAutokill"><tt>ImmediatelySendAutokill</tt></a> |
925 |
configuration directive only causes Services to send the autokill |
926 |
itself (that is, the user/host mask from which to prohibit new |
927 |
connections) to the IRC servers on your network. This is a safety |
928 |
feature intended to limit the damage caused by a mistyped autokill; |
929 |
see also <a href="#F4">answer F.4</a> above. |
930 |
<p> |
931 |
Note that some IRC servers will themselves kill users matching a |
932 |
newly-added autokill; this is unrelated to Services. |
933 |
</dl> |
934 |
|
935 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
936 |
|
937 |
<!------------------------------------------------------------------------> |
938 |
<p><hr> |
939 |
|
940 |
<a name=Z></a> |
941 |
<h3 align=center>Z. Bug reporting and feature requests:</h3> |
942 |
|
943 |
<p><i>(This section has been deleted since Services is no longer being |
944 |
maintained.)</i> |
945 |
|
946 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
947 |
|
948 |
<!------------------------------------------------------------------------> |
949 |
<p><hr> |
950 |
|
951 |
<p align=right><font size=-1><a href="index.html">Table of Contents</a></font> |
952 |
|
953 |
</body> |
954 |
</html> |