[IRCServices Coding] Services 5.0 Miunor Bugs/glitches/suggestions

Mark Hetherington mark at mhetherington.demon.co.uk
Sun Feb 3 13:07:30 PST 2002


Version 5 is definitely coming together very well now.

Been running the latest version on a production network and the following
issues came up. All reported on a Network of Unreal servers running Services
5.0a18.

1) Bug: When the ChanServ and Nickserv LIST command is restricted to opers
only, it still displays in the list of standard commands available to all
users. It ought to be removed from the commands list when not available to a
user.

2) Suggestion: A configuration file directive to remove/disable GetPass
would be a welcome addition. The introduction of SendPass into the main
distribution removes the main need for GetPass (password recovery) so the
abiity to easily remove GetPass commands from the modules and references in
helpfiles would be useful.

3) Bug: Memoserv send does not always confirm that a memo has been sent even
though it has. This only seems to affect some users and I have yet to find
what it is about particular users that causes this.

4) Bug: Help responses which involve 2 pseudo client names do not appear to
display correctly. E.g. the /cs help register command will display the name
of the ChanServ client correctly, but seemingly a random string for the
NickServ client

-ChanServ- Syntax: SENDPASS channel
-ChanServ-
-ChanServ- Sends you an E-mail message containing the password for the
-ChanServ- given channel.  You must be the founder of the channel to
-ChanServ- use this command, and you must first identify for your
-ChanServ- nickname with the xxx.xxx.xxx.xxx.xxx IDENTIFY command.

(the xxx refers to a user's hostname masked for privacy which managed to
become the client name for NickServ during one services run. This same host
name was displayed in that place to all users on the network. Previous runs
had other strings which were sometimes "random" garbage.

5) Bug: The Network statistics link in the httpd module does not operate at
all. On our network we run an existing StatServ client, so the services one
is named StatServ2. I could not see anything in the code/setup that would
cause this to affect the httpd module but thought I should mention it in
case.

6) Another "unhandled" message for the list, services reports but is unable
to process /who 0 o commands (users trying to list online opers) generating:

unknown message from server (:nick 4 [Did a /who 0 o])

7) Suggestion: every hyperlink clicked in the httpd pages results in the
following log entry:

httpd/main: Accepted connection from xxx.xxx.xxx.xxx:nnnn

This suggestion is twofold, firstly a more defined log entry specifying the
access made and secondly, logging the httpd client messages to a seperate
log file. It might actually be useful to log each client to it's own log
file, with the central file reserved for messages related to overall
operation.

8) Rehash produces an odd error message:

Received SIGHUP, rehashing.
sockets: select(): Interrupted system call

Not sure how important this is but if it is important enough to log, it is
probably something that shouldn't be happening :)

9) Not sure if this is a known problem listed anywhere but I haven't found
it in the docs, Services 5 will not parse a Version 4.5.x exception.db file.
The following error appears in the log file:

database/version4: Read error on exception.db


I think that covers everything in today's findings that I haven't found in
known bugs or other comments :)

Mark.