Jilles Tjoelker [Wed, 31 Mar 2010 23:16:16 +0000 (01:16 +0200)]
New custom channel mode API allowing reloading such modules.
Additionally, attempting to use too many modes or two times
the same letter is now detected and prevented.
Modules now request that a channel mode be added/orphaned,
instead of ugly manipulation from which that request had
to be guessed.
Slight changes are needed to modules that provide channel modes.
From the old API, one important function has been made static,
the other important function has been renamed, so loading old
modules should fail safely.
Jilles Tjoelker [Sun, 14 Mar 2010 16:21:20 +0000 (17:21 +0100)]
Add option general::use_propagated_bans to allow disabling new KLINE.
If this option is yes (default), KLINE by itself sets global (propagated) bans.
If this option is no, KLINE by itself sets a local kline following cluster{},
compatible with 3.2 and older versions.
William Pitcock [Mon, 8 Mar 2010 05:13:39 +0000 (23:13 -0600)]
Add propagation of MLOCK state for simple modes.
Special modes like +j can be tracked easily just by adding the necessary
code to parse them to set_channel_mlock(). This will cover propagation
as well.
Jilles Tjoelker [Fri, 5 Mar 2010 17:36:44 +0000 (18:36 +0100)]
Add propagated klines.
A KLINE command without the ON clause now sets a propagated
("global") ban. KLINE commands with the ON clause work as
before.
Propagated klines can only be removed with an UNKLINE command
without the ON clause, and this removes them everywhere.
In fact, they remain in a deactivated state until the latest
expiry ever used for the mask has passed.
Propagated klines are part of the netburst using a new BAN
message and capab. If such a burst has an effect, both the
server name and the original oper are shown in the server
notice.
No checks whatsoever are done on bursted klines at this time.
The system should be extended to XLINE and RESV later.
There is currently no way to list propagated klines,
but TESTLINE works normally.
Jilles Tjoelker [Wed, 3 Mar 2010 21:58:16 +0000 (22:58 +0100)]
bandb: Group writes in transactions to reduce load on heavy kline activity.
When a ban is added or removed, open a transaction and
close it after 3 seconds; any bans in the 3 seconds
will not trigger another transaction (= 4 fsyncs with
sqlite).
The transaction is also committed if ircd closes the
connection, but not if bandb itself is terminated with
a signal.
Jilles Tjoelker [Sat, 27 Feb 2010 23:46:56 +0000 (00:46 +0100)]
Store the creation time of klines and dlines as a time_t instead of as text.
The value 0 indicates the creation time is unknown (currently the case
for bandb).
Also store a creation time for xlines and resvs, but do not use it yet.
Stephen Bennett [Tue, 23 Feb 2010 22:35:58 +0000 (22:35 +0000)]
Use FLAGS_SENTUSER instead of 'user' being non-empty to decide whether to register a user on CAP END.
identd and SASL can cause source_p->user to be present without USER having been sent.
Without this change, that could cause a crash later on as localClient->fullcaps is not initialised.
William Pitcock [Thu, 18 Feb 2010 13:30:26 +0000 (07:30 -0600)]
Add ip_cloaking_4.0 module, which is the same cloaking as 3.2, but moves the usermode from +h to +x,
which allows us to start transitioning this usermode change.
Jilles Tjoelker [Mon, 15 Feb 2010 22:07:14 +0000 (23:07 +0100)]
Subject /invite to umodes +g and +R.
The behaviour is the same as /msg except that where
/msg would send RPL_UMODEGMSG to the user, the /invite
is instead let through. This counts as a notification
for caller_id_wait like RPL_UMODEGMSG.
Checks are on the target user's server, which means an
error message will appear after RPL_INVITING.
This must be because the accept list is not globally
known.
Jilles Tjoelker [Mon, 15 Feb 2010 00:07:07 +0000 (01:07 +0100)]
target change: Allow free replies.
When a user receives a private message, notice or RPL_UMODEGMSG,
add the source to a special set of 5 target slots.
These slots are checked in the normal way when sending messages,
allowing a reply without using up a free target.
This feature will not be very useful if a user is being messaged
by many different users; to help this, messages blocked entirely
by +g or +R do not affect the targets. CTCP replies also remain
free in terms of targets.