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

[Andrew Church]

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

     I don't consider this a bug (in fact, I think I had it that way at one
point and reversed it), but it seems reasonable enough.  Done.

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

     Added.

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

     I haven't been able to reproduce this, and can't fix it without more
information.

>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

     I can't reproduce this.

>5) Bug: The Network statistics link in the httpd module does not operate at
>all.

     This is known (see the FIXME in httpd/dbaccess.c).

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

     This is a HELP message (the /who is processed by the client's server).
I'll add it to the ignore list.

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

     I don't like the proliferation of log files that would create; if it
bothers you to have everything in one logfile, just write a script that
parses them out to separate files or something.  As for the other point, an
access-log-like thing is under consideration.

>8) Rehash produces an odd error message:
>
>Received SIGHUP, rehashing.
>sockets: select(): Interrupted system call

     This is because the signal interrupts select() which is waiting for
input from the remote server, and probably shouldn't be logged as it's
normal behavior.  Fixed.

>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

     Can you send me an example database that has this problem?

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/