set::oper-auto-join or tld::channel was broken. It worked for the
very first user since boot or rehash, but after that only the
first channel was joined. Reported by PeGaSuS in
https://bugs.unrealircd.org/view.php?id=5535
useful in the future. This would download a specific patch from
the unrealircd.org site, apply it, recompile, and then:
if it's a hot-patch it would rehash
if it's a cold-patch it would print a message that you should restart
the irc server.
spamfilter (F, not f) and qline (Q, not q).
2) Error out when invalid ban exception types are given, so such errors
don't go undetected anymore. Eg it will now print:
"ERROR: bantype 'f' is unrecognized (in 'fgkz'). Note that the bantypes are case sensitive. Type /ELINE to see a list of all possible bantypes."
Reported by westor and Mi_01 in https://bugs.unrealircd.org/view.php?id=5528
Also, when at it:
3) Remove type 't' from ELINE syntax docs, which is in fact 'c'
(which is already present in the list)
Remove old option set::ban-include-username and replace it with a more
generic option which defines what target a ban should apply to.
Also add some parts of set::manual-ban-target which will follow soon.
Although not entirely true, exempting a user from 'd' when using
an extended server ban or IP or ident is not recommended.
The information needed to exempt the user may not be available
at the time of the flood. Better to reject it than have it partially work.
See https://www.unrealircd.org/docs/Extended_server_bans
Examples with ELINE:
/ELINE ~a:TrustedAccount kg 0 This user can bypass kline/gline when using SASL
/ELINE ~S:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef kgf 0 Trusted user with this certificate fingerprint
It also works with bans, although this would be less common:
/GLINE ~a:EvilAccount
A more useful purpose would be to use ~r (realname):
/GLINE ~r:*some*stupid*real*name*
(Although you could already ban realnames via spamfilter 'u')
For third party module coders:
If you have an extban in group 3 (a "matcher"-extban) then you
can opt-in to support this. You do so at extban registration time:
req.options = EXTBOPT_TKL;
or, if you already had another flag set, like for +I, then:
req.options = EXTBOPT_INVEX|EXTBOPT_TKL;
In any case, you set the .options before you call ExtbanAdd().
Note that if you do indicate support then your is_ok function
will be called like:
extban->is_ok(client, NULL, mask, EXBCHK_PARAM, MODE_ADD, EXBTYPE_TKL);
Important here is the NULL channel (since there is none)
Similarly your is_banned function will be called with BANCHK_CONNECT:
extban->is_banned(client, NULL, banstr, BANCHK_JOIN, &msg, &errmsg);
Here too, it is important to note that channel is NULL.
Add new config option "exempt-webirc yes;" in set::restrict-commands::<commandname> in order to give exceptions in all WEBIRC user. This closes one of the 3 suggestions in https://bugs.unrealircd.org/view.php?id=5506
1) Fix issue if HOOKTYPE_IS_HANDSHAKE_FINISHED rejects the user
2) Fix authprompt issue. We now allow adding the TKL in
place_ban_host() for soft-kline/etc. Previously all the
soft-kline/gline/zline/gzline acted like soft-kill.
3) The blacklist module did not allow clients in with action 'warn',
reported by westor in https://bugs.unrealircd.org/view.php?id=5501
In the configuration item you can now achieve the same via:
except ban { mask 1.2.3.4; type maxperip; }
Or even:
except ban { mask { 1.2.3.4; 8.8.8.8; }; type maxperip; }
etc.
Suggested by The_Myth in https://bugs.unrealircd.org/view.php?id=5507
Also, fixed an issue where the IRCd was counting servers as
clients for maxperip, which doesn't make much sense in practice,
so it only counts users now.
MLOCK restrictions when services are down (set::services-server).
Suggested by westor in https://bugs.unrealircd.org/view.php?id=5273
By default all opers with the *-with-override privilege have this,
which sounds OK to me.
Bram Matthys