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 Manual - Appendix D. Known issues</title> |
6 |
</head> |
7 |
|
8 |
<body> |
9 |
<a name=top></a> |
10 |
<h1 align=center>IRC Services Manual</h1> |
11 |
|
12 |
<h2 align=center>Appendix D. Known issues</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 |
<p>There are a few issues which have been reported as bugs in the past or |
20 |
discovered by the author, but which either are not consistently |
21 |
reproduceable or are a consequence of the way Services works and not easily |
22 |
avoidable. These issues are listed below.</p> |
23 |
|
24 |
<h3>Nickname and NickServ issues</h3> |
25 |
|
26 |
<p><ul><li>When setting NickServ options for other users as a Services |
27 |
administrator, NickServ will incorrectly respond with "Your (option name) |
28 |
has been changed" or similar messages, as though the Services admin's |
29 |
nickname settings had been changed. (The target nickname's settings are |
30 |
in fact correctly modified, while the admin's settings are left alone.) |
31 |
|
32 |
<p><li>If you disable one or more of the <tt>nickserv/access</tt>, |
33 |
<tt>nickserv/autojoin</tt>, <tt>memoserv/main</tt>, and |
34 |
<tt>memoserv/ignore modules</tt>, delete a nickgroup, create a new |
35 |
nickgroup that has the same ID, and re-enable the module(s), the new |
36 |
nickgroup will keep any data from those module(s) that belonged to the old |
37 |
nickgroup. Since nickgroup IDs are assigned randomly, this should be a |
38 |
rare occurrence. |
39 |
|
40 |
</ul> |
41 |
|
42 |
<h3>Channel and ChanServ issues</h3> |
43 |
|
44 |
<p><ul><li>Services appears to incorrectly detect "mode bouncing" (<i>i.e.,</i> |
45 |
the IRC server reversing Services' mode changes) in some cases. When this |
46 |
occurs, commands like <tt>KICK</tt> and <tt>TOPIC</tt> as well as auto-ops |
47 |
and mode locking will no longer work on that channel. If this problem |
48 |
occurs, appropriate messages will be written to the log file; the problem |
49 |
can be worked around by either clearing the channel (removing all users |
50 |
from the channel) or restarting Services. Adding the |
51 |
<a href="a.html#NoBouncyModes"><tt>NoBouncyModes</tt></a> directive in |
52 |
<tt>ircservices.conf</tt> will prevent this problem from occurring, but |
53 |
will cause mode floods if you have an incorrectly configured server on your |
54 |
network. |
55 |
|
56 |
<p><li>If a user without auto-op privileges enters a registered, empty |
57 |
channel and sends a MODE command to change the channel modes before |
58 |
Services removes the user's channel operator privileges, the changed modes |
59 |
will remain in effect on the channel. On some IRC servers, such as |
60 |
InspIRCd and ircd-ratbox, this can be avoided by setting the |
61 |
<a href="a.html#protocol/(insert_protocol_name_here).CSSetChannelTime"><tt>CSSetChannelTime</tt></a> |
62 |
option in <tt>modules.conf</tt>. |
63 |
|
64 |
<p><li>When kicking users from forbidden channels (or in other cases when a |
65 |
user tries to join an empty channel and is kicked), Services will generate |
66 |
debug log messages about "<tt>MODE +b for unknown channel</tt>". These are |
67 |
a side effect of the order in which Services processes the operations |
68 |
involved in the kickban; they are harmless and can be safely ignored. The |
69 |
same or similar messages can also appear during a netburst when modes are |
70 |
sent for a channel after all the users in the channel have been kicked, or |
71 |
when joins and modes are sent for a user who gets autokilled. |
72 |
|
73 |
<p><li>If you try to enter an empty channel and get kicked and banned by |
74 |
ChanServ, you cannot get in with <tt>UNBAN</tt> or <tt>INVITE</tt> even if |
75 |
you would normally have privileges to do so because ChanServ reports that |
76 |
the channel does not exist. This is because ChanServ does not keep track |
77 |
of channels that it is currently residing in after a kickban in the same |
78 |
way that it does for ordinary users. |
79 |
|
80 |
<p><li>When using protocols that support ban exceptions, users can get |
81 |
around the "ban" part of a kickban in an empty channel by sending a ban |
82 |
exception quickly enough that the server processes it before Services is |
83 |
able to kick the user, allowing the user to repeatedly rejoin the channel |
84 |
(and get immediately kicked again). This is a side effect of Services not |
85 |
tracking empty channels in which ChanServ is residing, but if your IRC |
86 |
server's flood protection is set up properly, this will not be a problem in |
87 |
practice (there are many ways for users to generate more network traffic |
88 |
than a join/part loop). |
89 |
|
90 |
<p><li>There appear to be some cases in which channel modes (<tt>+k</tt> |
91 |
and <tt>+o</tt> have been reported) are set twice in succession for the |
92 |
same channel. This naturally has no effect on the channel itself, but some |
93 |
users have reported it as annoying. Services attempts to detect and |
94 |
correct this, but it may still occur in some cases. |
95 |
|
96 |
</ul> |
97 |
|
98 |
<h3>Administration and other issues</h3> |
99 |
|
100 |
<p><ul><li>If you are not using encrypted passwords, then all passwords will |
101 |
be truncated to be at most 32 characters (or <tt>PASSMAX</tt> characters, |
102 |
if you change the value of <tt>PASSMAX</tt> in the <tt>defs.h</tt> source |
103 |
file) long. As a result, any password with the same initial sequence of |
104 |
characters will be treated as a match, even if it is not exactly the same |
105 |
password initially set. |
106 |
|
107 |
<p><li>When setting another nickname's password or a channel's password as |
108 |
a Services administrator, NickServ (or ChanServ) will send out the |
109 |
"<tt><i>ADMIN</i> used SET PASSWORD as Services admin for <i>TARGET</i></tt>" |
110 |
global message even if the password change is rejected due to length or |
111 |
similarity with the target nickname or channel name. This is difficult to |
112 |
fix cleanly in the current code structure (which is one reason the message |
113 |
was written as "used SET PASSWORD" instead of "changed password"). Since |
114 |
this is expected to be a rare occurrence, clarity of code was given |
115 |
preference over adding special-case processing for this case. Note that |
116 |
setting the |
117 |
<a href="a.html#NoAdminPasswordCheck"><tt>NoAdminPasswordCheck</tt></a> |
118 |
option in <tt>ircservices.conf</tt> will disable all password checks for |
119 |
Services administrators, thus avoiding this problem. |
120 |
|
121 |
<p><li>When using the Bahamut protocol, Services will log warnings about |
122 |
missing IP addresses each time an opermasked client connects to the network |
123 |
or rejoins after a netsplit. This is unavoidable on Services' part, since |
124 |
the Bahamut protocol does not seem to provide a way to differentiate between |
125 |
opermasked clients and servers which do not send IP addresses at all. |
126 |
|
127 |
<p><li>It has been reported that using the OperServ <tt>JUPE</tt> command |
128 |
on a Bahamut-based network for a server two or more hops away from the |
129 |
Services uplink server can cause Services to be dropped from the network. |
130 |
|
131 |
<p><li>If you compile on a Macintosh (OSX) system using dynamic modules, |
132 |
the <tt>encryption/unix-crypt</tt> module may fail to load. If this |
133 |
happens, compile using static modules instead (<tt>./configure |
134 |
-use-static-modules</tt>). |
135 |
|
136 |
</ul> |
137 |
|
138 |
<p align=right><font size="-1"><a href="#top">Back to top</a></font> |
139 |
|
140 |
<!------------------------------------------------------------------------> |
141 |
<p><hr> |
142 |
|
143 |
<p align=right><font size=-1><a href="index.html">Table of Contents</a></font> |
144 |
|
145 |
</body> |
146 |
</html> |