diff -uNr ircservices-5.0.46/Changes ircservices-5.0.47/Changes
--- ircservices-5.0.46/Changes	2005-02-21 21:39:03 +0900
+++ ircservices-5.0.47/Changes	2005-02-23 02:03:51 +0900
@@ -1,5 +1,11 @@
 Version 5.0
 -----------
+2005/02/23 .47	Channels no longer expire while an auto-op user is in the
+		    channel; expiration is delayed until the time specified
+		    by CSExpire after the last such user leaves the channel.
+		    Reported by Anton Wolkov <phan70m@gmail.com>
+2005/02/23	Added user IP addresses to the OperServ LISTUSER debug
+		    command as well.
 2005/02/21 .46	Fixed some warnings during compilation.
 2005/02/21	Fixed bug causing modified files to not be recompiled
 		    properly when compiling with GNU make 3.79.
diff -uNr ircservices-5.0.46/docs/3.html ircservices-5.0.47/docs/3.html
--- ircservices-5.0.46/docs/3.html	2004-09-03 14:51:03 +0900
+++ ircservices-5.0.47/docs/3.html	2005-02-23 02:57:56 +0900
@@ -21,7 +21,8 @@
 <br>3-2. <a href="#2">Channel management (ChanServ)</a>
 <br>&nbsp;&nbsp;&nbsp;&nbsp;3-2-1. <a href="#2-1">Core ChanServ features</a>
 <br>&nbsp;&nbsp;&nbsp;&nbsp;3-2-2. <a href="#2-2">Channel access lists</a>
-<br>&nbsp;&nbsp;&nbsp;&nbsp;3-2-3. <a href="#2-3">Miscellaneous functions</a>
+<br>&nbsp;&nbsp;&nbsp;&nbsp;3-2-3. <a href="#2-3">Channel expiration</a>
+<br>&nbsp;&nbsp;&nbsp;&nbsp;3-2-4. <a href="#2-4">Miscellaneous functions</a>
 <br>3-3. <a href="#3">Memo sending (MemoServ)</a>
 <br>&nbsp;&nbsp;&nbsp;&nbsp;3-3-1. <a href="#3-1">Core MemoServ features</a>
 <br>&nbsp;&nbsp;&nbsp;&nbsp;3-3-2. <a href="#3-2">Memos and channels</a>
@@ -279,7 +280,7 @@
 	Unless you have concerns about the security of your servers
 	themselves, this method can be considered 100% safe for all
 	practical purposes.
-<dt><b>User timestamp</b> (available in the <tt>dalnet</tt>,
+<dt><b>User timestamp</b> (available in the <tt>dalnet</tt>, <tt>hybrid</tt>,
 	<tt>ptlink</tt>, <tt>ts8</tt>, and <tt>undernet-p9</tt> modules)
 <dd>A number recorded by each server for each user, representing the time
 	at which the user connected to the server.  Since this value
@@ -349,9 +350,9 @@
 access lists.)
 
 <p>Note that the <tt>DROP</tt> command will drop <i>all</i> nicks linked to
-the current nick (as well as the current nick itself); the <tt>UNLINK</tt>
-command must be used to cancel a single linked nick while leaving the
-others intact.
+the current nick (as well as the current nick itself); to cancel a single
+linked nick while leaving the others intact, use the <tt>UNLINK</tt>
+command instead.
 
 <p>There is an additional module, <tt>nickserv/oldlink</tt>, that uses the
 same semantics for the <tt>LINK</tt>, <tt>UNLINK</tt>, and
@@ -442,11 +443,11 @@
 <a href="4.html#nick.clearauth"><tt>CLEARAUTH</tt></a> are available to
 Services administrators.  The <tt>SETAUTH</tt> command generates a new
 authentication code for the given nickname, requiring its owner to
-authenticate the nick before continuing to use it; <tt>GETAUTH</tt> command
-retrieves the authentication code stored for the given nickname, if any;
-and the <tt>CLEARAUTH</tt> command clears any stored authentication code
-and allows the nickname's owner to use the nick normally, as if they had
-authenticated it with the <tt>AUTH</tt> command.
+authenticate the nick before continuing to use it; the <tt>GETAUTH</tt>
+command retrieves the authentication code stored for the given nickname,
+if any; and the <tt>CLEARAUTH</tt> command clears any stored authentication
+code and allows the nickname's owner to use the nick normally, as if they
+had authenticated it with the <tt>AUTH</tt> command.
 
 <p>Finally, NickServ recognizes the command-line option
 "<tt>-clear-nick-email</tt>"; when this option is given, all nicknames'
@@ -600,8 +601,8 @@
 <tt>modules.conf</tt>.  Also by default, channels will expire in 14 days
 (changeable via the <a href="a.html#chanserv/main.CSExpire"><tt>CSExpire</tt></a>
 option in <tt>modules.conf</tt>) if they are not "used" for that period of
-time; for this purpose, "used" means that a user with auto-op privileges
-(see <a href="#2-2">section 3-2-2</a>) has entered the channel.
+time; see <a href="#2-3">section 3-2-3</a> for detailed information on how
+channel expiration is performed.
 
 <p>When a user registers a channel, that user is recorded in Services'
 databases as the channel's <i>founder</i>.  The founder of a channel will
@@ -621,22 +622,22 @@
 automatically dropped.  However, if a <i>successor</i> is set with the
 <a href="4.html#chan.set_successor"><tt>SET SUCCESSOR</tt></a> command,
 then the nickname designated as the successor will become the new founder
-of the channel, and the channel will not be dropped.  (However, if the
-successor nickname has already registered channels up to the registration
-limit, the channel will be dropped as usual.)  A channel's successor can be
-cleared with the <tt>UNSET SUCCESSOR</tt> command.
+of the channel, and the channel will not be dropped (unless the successor
+nickname has already registered channels up to the registration limit, in
+which case the channel will be dropped as usual.)  A channel's successor
+can be cleared with the <tt>UNSET SUCCESSOR</tt> command.
 
 <p>The <a href="4.html#chan.set_mlock"><tt>SET MLOCK</tt></a> command
-allows a channel's founder to have Services always set certain modes on the
-channel.  This command is used similarly to the IRC <tt>/mode</tt> command,
-with a list of mode characters interspersed with <tt>+</tt> and <tt>-</tt>
-characters possibly followed by mode parameters (such as a channel key or
-user limit for the <tt>+k</tt> or <tt>+l</tt> modes).  The important
-difference is that modes specified here are always forced by Services to be
-as specified; for example, if a mode lock of <tt>+s</tt> is set on a
-channel, Services will always set <tt>+s</tt> on that channel when it is
-first joined by a user, and will not allow anyone to set <tt>-s</tt> on
-the channel.  Any modes not specified in the mode lock are not forced
+allows a channel's founder to have Services always set or clear certain
+modes on the channel.  This command is used similarly to the IRC
+<tt>/mode</tt> command, with a list of mode characters interspersed with
+<tt>+</tt> and <tt>-</tt>, possibly followed by mode parameters (such as a
+channel key or user limit for the <tt>+k</tt> or <tt>+l</tt> modes).  The
+important difference is that modes specified here are always forced by
+Services to be as specified; for example, if a mode lock of <tt>+s</tt> is
+set on a channel, Services will always set <tt>+s</tt> on that channel when
+it is first joined by a user, and will not allow anyone to set <tt>-s</tt>
+on the channel.  Any modes not specified in the mode lock are not forced
 either on or off, so in the previous example of a mode lock of <tt>+s</tt>,
 the <tt>+i</tt> mode could be set or unset freely by channel operators.
 The default mode lock for a new channel is <tt>+nt</tt>.
@@ -1063,7 +1064,57 @@
 <p align=right><font size="-1"><a href="#top">Back to top</a></font>
 
 <a name=2-3></a>
-<h4>3-2-3. Miscellaneous functions</h4>
+<h4>3-2-3. Channel expiration</h4>
+
+<p>Channel expiration is a somewhat complex issue.  The major problem in
+determining when to expire a channel is:  How do you determine whether the
+channel is "in use"?
+
+<p>One simple idea is to measure from the last time any user was in the
+channel.  However, this is overly protective in some circumstances.  For
+example, suppose user A has registered channel <tt>#mychannel</tt>, but no
+longer uses it.  One day before the channel is set to expire, user B comes
+onto the network, wanting to use <tt>#mychannel</tt> herself but not
+knowing that it has already been registered.  When user B enters the
+channel, ChanServ tells her that it is registered--and updates the
+last-used time, forcing her to wait much longer than one day before the
+channel is finally released.
+
+<p>Clearly, Services needs some way to determine whether a user should be
+considered a user of the registered channel, as opposed to an unrelated
+user who just happened to enter the channel.  The wide variety of channel
+management styles makes this difficult, but since most channels will take
+advantage of the auto-op channel privilege (as described in
+<a href="#2-2">section 3-2-2</a>), Services uses this privilege as a basis
+for determining who to count as a user of the registered channel.
+
+<p>Thus, the rule for channel expirations is:  <b>A channel's expiration
+timer starts counting from the last time a user with auto-op privileges was
+in the channel,</b> and the channel will expire if no auto-op users enter
+the channel during the time specified by the <tt>CSExpire</tt>
+configuration directive.  As a corollary, <b>channels will not expire as
+long as a user with auto-op privileges is in the channel.</b>
+
+<p>If you only use the <tt>XOP</tt> commands to modify the channel list,
+this is easy to understand--anyone on the <tt>AOP</tt> and <tt>SOP</tt>
+lists, as well as the channel founder, will cause the channel's last-used
+time to be updated. Likewise, with the <tt>ACCESS</tt> command, any user
+with access level 50 or above will reset the expiration countdown.
+However, if you use the <tt>LEVELS</tt> command to alter the auto-op
+privilege level, then this no longer holds; in particular, <b>if you
+disable the auto-op channel privilege, then you will not be able to stop
+the channel from expiring!</b>
+
+<p>Also, for the purpose of these checks, Services uses each user's
+<i>current</i> channel privileges on the channel.  Even if the channel
+founder remains in the channel, he will not be counted as a channel user
+unless he has identified for his nickname (or the nickname and channel
+<tt>SECURE</tt> options are disabled).
+
+<p align=right><font size="-1"><a href="#top">Back to top</a></font>
+
+<a name=2-4></a>
+<h4>3-2-4. Miscellaneous functions</h4>
 
 <p>One additional ChanServ module is available: the
 <tt>chanserv/sendpass</tt> module, which provides a
@@ -1426,16 +1477,16 @@
 Services administrator list (with the
 <a href="4.html#oper.admin"><tt>ADMIN</tt></a> command) and setting of the
 super-user password (with the <a href="4.html#oper.set_supass"><tt>SET
-SUPASS</tt></a>).  However, one other command is limited to the Services
-super-user (or Services administrators with super-user privilege): the
-<a href="4.html#oper.raw"><tt>RAW</tt></a> command, which allows any
+SUPASS</tt></a> command).  However, one other command is limited to the
+Services super-user (or Services administrators with super-user privilege):
+the <a href="4.html#oper.raw"><tt>RAW</tt></a> command, which allows any
 arbitrary data to be sent directly to the server to which Services is
 connected. This can be used to achieve certain kinds of "special effects"
 or to aid in development or debugging of an IRC server or Services module.
 As mentioned earlier, however, this command is <i>very dangerous,</i> and
 improper use can easily cause Services or your network's IRC servers (or
 both) to crash or corrupt data.  For this reason, the <tt>RAW</tt> command
-is unavailable unless the
+is unavailable even to the Services super-user unless the
 <a href="a.html#operserv/main.AllowRaw"><tt>AllowRaw</tt></a> option is set
 in <tt>modules.conf</tt> (it is disabled by default).
 
@@ -1653,9 +1704,9 @@
 <p>One other way of preventing undesired clients from connecting to the
 network is via <i>session limiting</i>, provided by the
 <tt>operserv/sessions</tt> module.  When session limiting is active
-(<i>i.e.,</i> the module is loaded), Services will keep track of the number
-of clients connected from each host, and issue <tt>KILL</tt> messages for
-any clients exceeding the limit set by the
+(<i>i.e.,</i> when the module is in use), Services will keep track of the
+number of clients connected from each host, and issue <tt>KILL</tt> messages
+for any clients exceeding the limit set by the
 <a href="a.html#operserv/sessions.DefSessionLimit"><tt>DefSessionLimit</tt></a>
 configuration option in <tt>modules.conf</tt> (or specific limits for the
 host as set by session exceptions, described below).  Before actually
@@ -1829,7 +1880,7 @@
 allocated.  In the worst case, the latter will require approximately 4/3 of
 the value given for <tt>RequestBufferSize</tt>.  Thus, the maximum amount
 of memory used by the HTTP server module can be calculated as approximately
-<blockquote><tt>MaxConnections * RequestBufferSize * 2.5</tt></blockquote>
+<tt>MaxConnections * RequestBufferSize * 2.5</tt>.
 
 <p align=right><font size="-1"><a href="#top">Back to top</a></font>
 
@@ -2108,7 +2159,7 @@
 <p><hr>
 
 <a name=8></a>
-<h3>E-mail sending</h3>
+<h3>3-8. E-mail sending</h3>
 
 <p>Services has the ability to send E-mail to users outside of the IRC
 protocol.  This ability is used, for example, by the NickServ E-mail
@@ -2149,9 +2200,9 @@
 <p>The configuration setting
 <a href="a.html#mail/sendmail.SendmailPath"><tt>SendmailPath</tt></a> (in
 <tt>modules.conf</tt>) should be set to the pathname of your
-<tt>sendmail</tt> program.  Typical locations are <tt>/usr/lib/sendmail</tt>
-or <tt>/usr/sbin/sendmail</tt>; if you do not know the proper setting for
-your system, ask your system administrator.
+<tt>sendmail</tt> program.  Typical locations on Unix systems are
+<tt>/usr/lib/sendmail</tt> or <tt>/usr/sbin/sendmail</tt>; if you do not
+know the proper setting for your system, ask your system administrator.
 
 <p><li><b><tt>mail/smtp</tt></b>:  Uses the SMTP protocol to send E-mail
 through an SMTP relay server.  The server to use is specified by the
diff -uNr ircservices-5.0.46/docs/faq.html ircservices-5.0.47/docs/faq.html
--- ircservices-5.0.46/docs/faq.html	2005-02-21 22:12:25 +0900
+++ ircservices-5.0.47/docs/faq.html	2005-02-23 03:26:50 +0900
@@ -515,8 +515,8 @@
 	of luck; if you like, you can report it anyway, but chances are it
 	won't get fixed if it can't be reproduced.  If you do have such a
 	problem, you may find the <tt>cron</tt> utility useful for dealing
-	with it, by making a script to check whether Services is running
-	and restart it if not.
+	with it; see the section regarding the <tt>ircservices-chk</tt> in
+	<a href="2.html#5">section 2-5</a>.
 </dl>
 
 <a name=C5></a>
@@ -576,7 +576,7 @@
 <dd><p>
 	Yes; enable the <tt>MergeChannelModes</tt> directive in
 	<tt>ircservices.conf</tt>.  (Note that this has minor security
-	implications; be sure to read the comments in the example
+	implications--be sure to read the comments in the example
 	configuration file.)
 </dl>
 
@@ -622,15 +622,15 @@
 <a name=C11></a>
 <p><dl><dt><b>C.11. Services crashes when loading databases on SPARC
 	systems.</b>
-<dd><p>This is due to a bug in some versions of GCC running on SPARC
+<dd><p>
+	This is due to a bug in some versions of GCC running on SPARC
 	systems.  Services contains a temporary workaround for this
 	problem, but it is very compiler- and environment-specific, and it
 	may not work for you.  The bug has been filed in the GCC bug
 	database as
 	<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11151">bug
-	11151</a> <font size=-1>[<tt>gcc.gnu.org</tt>]</font>; until it is
-	fixed, you may need to run Services on a non-SPARC system if
-	Services crashes for you.
+	11151</a> <font size=-1>[<tt>gcc.gnu.org</tt>]</font>, and has been
+	fixed as of GCC 3.4.
 </dl>
 
 <!------------------------------------------------------------------------>
@@ -661,7 +661,7 @@
 	server itself so it doesn't generate them).
 	<p>
 	Alternatively, you can set an SQline on the same mask using the
-	OperServ <tt>SQLINE ADD</tt> (in the <tt>operserv/sline</tt>
+	OperServ <tt>SQLINE ADD</tt> command (in the <tt>operserv/sline</tt>
 	module), and Services will take care of making sure all servers
 	have Q:lines for the nick.
 </dl>
@@ -670,7 +670,7 @@
 <p><dl><dt><b>D.2. Trying to use <tt>REGISTER</tt> or <tt>SET EMAIL</tt>
 	resulted in an "address is unauthenticated" message, but the user
 	hasn't registered any nicknames before.</b>
-<dd>
+<dd><p>
 	Another user may have set the same E-mail address on their
 	nickname.  Use the <tt>LISTEMAIL</tt> command to see what nicknames
 	have the problem address associated with them.
@@ -680,7 +680,7 @@
 <p><dl><dt><b>D.3. Why can't I use the <tt>SENDPASS</tt> module
 	(<tt>nickserv/sendpass</tt>) without the mail-authentication module
 	(<tt>nickserv/mail-auth</tt>)?</b>
-<dd>
+<dd><p>
 	Because allowing users to send mail (using <tt>SENDPASS</tt>)
 	without first confirming that the address is actually valid can
 	allow malicious users to send spam via Services.  Consider the
@@ -758,8 +758,8 @@
 	<tt>ACCESS</tt> and <tt>XOP</tt> commands?</b>
 <dd><p>
 	No.  Just tell your users to not use the <tt>ACCESS</tt> command.
-	(You can also disable the ACCESS command for the whole network by
-	removing or commenting out the
+	(You can also disable the <tt>ACCESS</tt> command for the whole
+	network by removing or commenting out the
 	<tt>LoadModule&nbsp;chanserv/access-levels</tt> line in
 	<tt>ircservices.conf</tt>, but this will prevent even users who
 	understand the <tt>ACCESS</tt> command from using it.)
@@ -771,7 +771,7 @@
 	Such functionality is unneeded, because ChanServ requires users to
 	register their nicknames before allowing them to register channels.
 	As a result, as long as you require users to include E-mail
-	addresses with nickname, you can just look up the address for the
+	addresses with nicknames, you can just look up the address for the
 	channel founder's nickname if a problem arises with a particular
 	channel.
 </dl>
diff -uNr ircservices-5.0.46/modules/chanserv/main.c ircservices-5.0.47/modules/chanserv/main.c
--- ircservices-5.0.46/modules/chanserv/main.c	2005-02-21 22:20:52 +0900
+++ ircservices-5.0.47/modules/chanserv/main.c	2005-02-23 03:31:49 +0900
@@ -323,6 +323,21 @@
 
 /*************************************************************************/
 
+/* Callback for users leaving channels.  Update the channel's last used
+ * time if the user was an auto-op user.
+ */
+
+static int do_channel_part(Channel *c, User *u, const char *reason)
+{
+    if (c->ci && check_access(u, c->ci, CA_AUTOOP)) {
+	c->ci->last_used = time(NULL);
+	put_channelinfo(c->ci);
+    }
+    return 0;
+}
+
+/*************************************************************************/
+
 /* Callback for channels being deleted. */
 
 static int do_channel_delete(Channel *c)
@@ -870,6 +885,21 @@
 	notice_lang(s_ChanServ, u, INTERNAL_ERROR);
     } else {
 
+	/* Update last used time if the channel is currently in use. */
+	if (ci->c) {
+	    struct c_userlist *cu;
+	    LIST_FOREACH (cu, ci->c->users) {
+		if (check_access(cu->user, ci, CA_AUTOOP)) {
+		    if (debug >= 2)
+			module_log("debug: updating last used time for %s"
+				   " (INFO)", ci->name);
+		    ci->last_used = time(NULL);
+		    put_channelinfo(ci);
+		    break;
+		}
+	    }
+	}
+
         /* Only show all the channel's settings to sadmins and founders. */
 	can_show_all = (is_founder(u, ci) || is_servadmin);
 
@@ -1866,6 +1896,7 @@
      || !add_callback(NULL, "channel create", do_channel_create)
      || !add_callback(NULL, "channel JOIN check", do_channel_join_check)
      || !add_callback(NULL, "channel JOIN", do_channel_join)
+     || !add_callback(NULL, "channel PART", do_channel_part)
      || !add_callback(NULL, "channel delete", do_channel_delete)
      || !add_callback(NULL, "channel mode change", do_channel_mode_change)
      || !add_callback(NULL, "channel umode change", do_channel_umode_change)
diff -uNr ircservices-5.0.46/modules/chanserv/util.c ircservices-5.0.47/modules/chanserv/util.c
--- ircservices-5.0.46/modules/chanserv/util.c	2005-02-21 22:20:52 +0900
+++ ircservices-5.0.47/modules/chanserv/util.c	2005-02-23 03:31:49 +0900
@@ -100,14 +100,29 @@
 /*************************************************************************/
 
 /* Check whether the given channel (or its suspension) should be expired,
- * and do the expiration if so.  Return 1 if the nickname was deleted, else 0.
+ * and do the expiration if so.  Return 1 if the channel was deleted, else 0.
  */
 
 EXPORT_FUNC(check_expire_channel)
 int check_expire_channel(ChannelInfo *ci)
 {
     time_t now = time(NULL);
-    Channel *c;
+    Channel *c = ci->c;
+
+    /* Don't bother updating last used time unless it's been a while */
+    if (c && CSExpire && now >= ci->last_used + CSExpire/2) {
+	struct c_userlist *cu;
+	LIST_FOREACH (cu, c->users) {
+	    if (check_access(cu->user, ci, CA_AUTOOP)) {
+		if (debug >= 2)
+		    module_log("debug: updating last used time for %s",
+			       ci->name);
+		ci->last_used = time(NULL);
+		put_channelinfo(ci);
+		break;
+	    }
+	}
+    }
 
     if (CSExpire
      && now >= ci->last_used + CSExpire
@@ -115,7 +130,7 @@
      && !ci->suspendinfo
     ) {
 	module_log("Expiring channel %s", ci->name);
-	if (chanmode_reg && (c = get_channel(ci->name))) {
+	if (chanmode_reg && c) {
 	    c->mode &= ~chanmode_reg;
 	    /* Send this out immediately, no set_cmode() delay */
 	    send_cmode_cmd(s_ChanServ, ci->name, "-%s",
diff -uNr ircservices-5.0.46/modules/operserv/main.c ircservices-5.0.47/modules/operserv/main.c
--- ircservices-5.0.46/modules/operserv/main.c	2005-02-21 22:20:52 +0900
+++ ircservices-5.0.47/modules/operserv/main.c	2005-02-23 03:31:50 +0900
@@ -1461,10 +1461,11 @@
 	snprintf(buf, sizeof(buf), "%04X", u->ni->status & 0xFFFF);
     else
 	strcpy(buf, "-");
-    notice(s_OperServ, source, "%s!%s@%s %s +%s %ld %u %s %s :%s",
+    notice(s_OperServ, source, "%s!%s@%s %s %s +%s %ld %u %s %s :%s",
 	   u->nick, u->username, u->host, u->fakehost ? u->fakehost : "-",
-	   mode_flags_to_string(u->mode, MODE_USER), (long)u->signon,
-	   u->servicestamp, u->server->name, buf, u->realname);
+	   u->ipaddr, mode_flags_to_string(u->mode, MODE_USER),
+	   (long)u->signon, u->servicestamp, u->server->name, buf,
+	   u->realname);
     buf[0] = 0;
     s = buf;
     LIST_FOREACH (c, u->chans)
diff -uNr ircservices-5.0.46/version.sh ircservices-5.0.47/version.sh
--- ircservices-5.0.46/version.sh	2005-02-21 21:39:19 +0900
+++ ircservices-5.0.47/version.sh	2005-02-23 03:14:14 +0900
@@ -6,7 +6,7 @@
 # $PROGRAM is the string returned as the first part of a /VERSION reply,
 # and must not contain spaces.  It is not used anywhere else.
 PROGRAM=ircservices
-VERSION=5.0.46
+VERSION=5.0.47
 
 # Increment Services build number
 if [ -f version.c ] ; then