| 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> |
