the config file, without having to resort to things like mask %~asn:XXX;
Now you can just use:
ban user {
asn { 11111; 22222; 33333; 44444; }
soft yes;
reason "This ASN is not allowed. If you have an account you can still bypass";
}
Requested by nobody but sounds like a good idea :)
Previously these showed up as "name":"<match item>", now they show
up properly like this:
"match": {
"account": "Syzop"
},
(... and have no "name" item)
Also expand spamfilter::except while we are at it.
* I changed "state":"active" to "state":"monitoring" to make clear it is
not throttling at that moment but actively monitoring the situation.
* The config::except stuff was previously shown directly under config
and only 3 particular items (that are most popular). Now we expand to
sub-item "except" and use json_expand_security_group() to expand all
the mask items, in a consistent way, just like for security groups.
{
"jsonrpc": "2.0",
"method": "connthrottle.status",
"id": 123,
"result": {
"enabled": true,
"throttling_this_minute": false,
"throttling_previous_minute": false,
"state": "monitoring",
"start_delay_remaining": 0,
"reputation_gathering": false,
"counters": {
"local_count": 0,
"global_count": 0
},
"stats_last_minute": {
"rejected_clients": 0,
"allowed_except": 0,
"allowed_unknown_users": 0
},
"config": {
"local_throttle_count": 20,
"local_throttle_period": 60,
"global_throttle_count": 30,
"global_throttle_period": 60,
"start_delay": 180,
"except": {
"identified": true,
"reputation_score": 24
}
}
}
}
* Add some missing fields, such as destination, but mostly in the
exclude- area where a bunch were missing (some of those are a bit
far fetched, but hey, they exist, so should be shown if in use).
* Re-order fields to more closely match the struct (still not 100%)
* Extended fields, such as "account" and "country", now show up
directly under the security group, just like the other fields,
such as "reputation_score". This is also how they show up in the
config file, so hide the the fact that internally in the struct it
is stored differently.
* Add a comment in SecurityGroup struct in include/struct.h to make
it clear you have to add/update stuff at 7 places if you are adding
something new.
certificate or key. It added the cert/key to the list of certs, like a
"dual cert" approach.
This was caused by commit 877d151da4,
which indeed adds support for "dual cert" (or more).
I have now deferred setting the default to happen only if no
set::tls::certificate is specified, as you would expect.
We (already) used a similar delayed-initialization / deferred setting
approach in the ::tls-options inheritance code (for blocks like
listen, sni, link, etc.)
Just as a slightly related reminder, we do normally suggest keeping the
conf/tls/server.cert.pem and conf/tls/server.key.pem for server linking
and then use a cert from a trusted CA in the listen block for 6697 etc.
See https://www.unrealircd.org/docs/Using_Let's_Encrypt_with_UnrealIRCd
for more information (and the 'why').
New RPC methods:
- security_group.list: List all security groups
- security_group.get: Get details of a specific security group
- connthrottle.status: Get full connection throttle status, counters, and config
- connthrottle.set: Enable/disable connection throttling
- connthrottle.reset: Reset connection throttling counts
This also adds json_expand_mask_list(), json_expand_name_list(), and
json_expand_nvplist() to src/json.c for reuse by RPC modules.
A link to https://www.unrealircd.org/docs/JSON-RPC and such is nice.
And also explain that not all JSON-RPC modules will be in rpc/*.
Sometimes it makes more sense to just put everything in the same
module, such as connthrottle RPC stuff in the connthrottle module.
It should be perfectly fine if you choose not to load these modules but,
while optimizing / speeding up the find_user_mode() function, i made
it crash in case the hunted user mode does not exist. Oops.
We still propagate in a non-biglines way, no plan to change that atm.
This is just future-proofing. More testing/auditing needs to be done,
especially to see if buffers are sufficient.
delayjoin was setting +d if there are invisible users still,
but it should only do that if the channel was +D earlier and
not in all cases (like if some other module is dealing with
invisible users).
* We try to keep the dynconf variables the same name as in the conf
(well, with hyphens to underscores, and there are some exceptions)
* Remove unnecessary but otherwise harmless second safe_free()
* The URL could have been too long. It is now limited to 360 characters,
which should be plenty.
throw an error (JSON_RPC_ERROR_USERNOTINCHANNEL) if this is not the case.
Previously we returned success.
Also, if using DEBUGMODE (never on production servers), the server
would crash if the user is not in the channel.
This required two members on the same server and channel mode +H to be set
(or set::broadcast-channel-messages 'always', then also with -H).
The cause was a (normally harmless) optimization in
1473f52603 which meant we would loop
through remote servers for the case of +H.
And then the real cause a bug in the linecache system, which
caused servers to be seen as LCUT_NORMAL because locally
connected servers are MyConnect()->true.
And then on the wire (S2S) a message would look like..
:nick!user@host PRIVMSG ...
But nick!user@host is not valid in normal S2S traffic and on the receiving
server is seen as a nick@server message (and 'nick!user' is never found
on 'server' where server is actually a user host)... seems like an
old relic, but this aside.
This in turn, causing the message to be dropped (unknown source),
and the PRIVMSG handler is not called at all.
Bug reported by CrazyCat and then PeGaSuS managed to reproduce the
issue later on irc.unrealircd.org. Thanks!
As said, this only affects 6.1.2-rc2 and chmode +H.
Use extras/startup/unrealircd.service if you want a system-wide unit
file, which is normally what people tend to use. The benefit of this
is that it allows setting some security options.
Use extras/startup/unrealircd_user.service if you want a user unit
file. This works if you don't have root on the machine.
./unrealircd [start|stop|restart] commands if unrealircd is running
but without a pid, which will be the case if running through systemd.
The systemd example unit files will be in a future commit.
namely via "MODE #channel +F".
Enhance "MODE #channel +F" by explaining a bit more (like, actions a chanop
can do to change things).
Example of protection kicking in:
*** Channel CTCPflood detected (limit is 7 per 15 seconds), setting mode +C. Type "/MODE #test +F" to get more information on channel flood protection.
Then if you type "MODE #test +F":
Channel '#test' has effective flood setting '[7c#C15,30j#R10,10k#K15,40m#M10,8n#N15]:15' (flood profile 'normal')
-
You are currently using the default anti-flood profile normal.
If you want to change to a different anti-flood profile, for example because flood protection is kicking in too quickly
or too late, then you can use MODE #test +F <profile>. See the list of profiles below (ordered from lax to strict).
List of available flood profiles for +F:
off: []:0
very-relaxed: [7c#C15,60j#R10,10k#K15,90m#M10,10n#N15]:15
relaxed: [7c#C15,45j#R10,10k#K15,60m#M10,10n#N15]:15
normal: [7c#C15,30j#R10,10k#K15,40m#M10,8n#N15]:15
strict: [7c#C15,15j#R10,10k#K15,40m#M10,8n#N15]:15
very-strict: [7c#C15,10j#R10,10k#K15,30m#M10,5n#N15]:15
See also https://www.unrealircd.org/docs/Channel_anti-flood_settings
(And actually there is some bold text there too)
Indirectly suggested in https://bugs.unrealircd.org/view.php?id=6580
by rafaelgrether and PeGaSuS (being more clear to IRCOps what is happening).
(both AddressSanitizer and UndefinedBehaviorSanitizer)
This previously helped finding 8c26cec5fc
Also update the ./Config text a bit, eg about ASan not running OK on FreeBSD,
which only affects <14.2 as per https://bugs.unrealircd.org/view.php?id=6470#c23412
Bram Matthys