This fixes a bug where if you run ./Config with 'auto' file descriptors,
and then have an unusually low 'ulimit -n' of like 150, you would end up
with a negative amount of file descriptors available for use.
This fix moves it from compile-time setting of reserved fd's to runtime
setting.
All this is wrong, by the way, but that is for another major overhaul,
at least this bug is fixed now :D
set::central-blocklist::spamreport and ::spamreport-enabled are now GONE.
We now require a normal spamreport block, just like for other spamreport
functionality. So, if you want to enable this feature, use:
spamreport unrealircd { type central-spamreport; }
See https://www.unrealircd.org/docs/Central_spamreport for all info.
You can use CBL with central spamreport or central spamreport without CBL.
All explained at that URL.
... in case you want to do fine-tuning.
Defaults to DOWNLOAD_CONNECT_TIMEOUT (15 seconds) and
DOWNLOAD_TRANSFER_TIMEOUT (20 seconds).
For example, the module manager uses a shorter timeout of 7 and 20.
(that was already the case, but now it uses the generic api so
it needed an option to set it to those values)
No longer url_start_async(a,b,c,d,e,f,g,...) but usings structs so
simply url_start_async(tehstruct);
makes it easy to add fields later without forcing all modules to
change the prototype.
Work in progress....
This will hide the *LINE reason to other users if the *LINE contains the
IP of the user. This to protect the privacy of the user for cases such
as a KLINE due to a blacklist with a DroneBL URL.
Other possible settings are `no` (never hide, the previous default) and
`yes` to always hide the *LINE reason. In all cases the user affected by
the server ban can still see the reason and IRCOps too.
https://bugs.unrealircd.org/view.php?id=6362
The `watch-check` function now has a new argument which can be used to pass data to watch_notify callbacks.
New `watch_add` and `watch_del` hooks are called whenever new entries are created or removed.
New `monitor_notification` hook is called whenever a RPL_MONONLINE or RPL_MONOFFLINE is being sent, so a module can add its own notification besides it.
This fixes the issue where +e/+I ~operclass:name gets cut off if the
name contains any digits.
Reported by BlackBishop in https://bugs.unrealircd.org/view.php?id=6353
Also, we previously allowed any characters in the operclass, which is not
a great idea.
This is quite a bit higher than client DNS lookups (1500ms first, on retry 3000ms)
and is because some DNSBL are reported to be quite a bit slower than ordinary DNS.
(Maybe just some, but.. the higher timeout does not hurt anyone anyway)
Note that all this has no effect on client handshake times, as DNSBL checks are
done in the background. Only side-effect is that if we do get a "late hit" then
you may now see a kill a few seconds after the client is online (which was actually
already possible before too for quick clients, but.. yeah...)
These settings can be overriden via set::dns, these are the defaults:
set {
dns {
client {
timeout 1500;
retry 2;
}
dnsbl {
timeout 3000;
retry 2;
}
}
}
When you REHASH we will check if the values are different than the current
c-ares settings and if so, reinitialize the resolver. Reinitializing the
resolver will destroy outstanding DNS requests, eg DNS lookups for clients
currently connecting, but so be it. Not a super-huge issue since changing
this is rare.
Requested by BlackBishop in https://bugs.unrealircd.org/view.php?id=6306
when they are only in channel(s) with very low member counts.
This because some typical bot/drone behavior is not to join any channels.
This kinda forces them to expose themselves a bit more (and if they don't,
they don't get more reputation).
The downside is for the unusual case where a legit chatter would be on
the network but not joining any channels, but that is rare. In any case,
this setting can be adjusted if that is typical or more normal behavior
on your network :D.
* The [reputation score](https://www.unrealircd.org/docs/Reputation_score)
of connected users (actually IP's) is increased every 5 minutes. We still
do this, but only for users who are at least in one channel that has 3
or more members. This setting is tweakable via
[set::reputation::score-bump-timer-minimum-channel-members](https://www.unrealircd.org/docs/Set_block#set::reputation).
Setting this to 0 means to bump scores also for people who are in no
channels at all, which was the behavior in previous UnrealIRCd versions.
action { set REPUTATION--; } and similar.
Also enhancement to reputation S2S traffic, to support decreasing:
*
+ * Since UnrealIRCd 6.0.2+ there is now also asterisk-score-asterisk:
+ * :server REPUTATION 1.2.3.4 *2*
+ * The leading asterisk means no reply will be sent back, ever, and the
+ * trailing asterisk will mean it is a "FORCED SET", which means that
+ * servers should set the reputation to that value, even if it is lower.
+ * This way reputation can be reduced and the reducation can be synced
+ * across servers, which was not possible before 6.0.2.
+ *
So if you are actually decreasing reputation, you need all servers on
6.0.2 or higher for it to work properly, otherwise the other servers
don't decrease it, and next connect the highest wins again, etc.
This is a mandatory module to load, and included in modules.default.conf.
This also meant that the crule_test() etc efunctions are available
before running config test routines, so we now have a flag for
early efuncs. I guess we could consider doing that for all efuncs
though, so not sure if this flag is really needed.
Often you have default values for the config, and then a subsequent config
parsing run would overwrite the return value (= memory leak), merging/appending
would make no sense either, so it would force a free in all code before
calling us, well... let's just deal with it ourselves instead then ;)
The spamfilter::action stop ill prevent processing other spamfilters.
This would normally be a bit unusual, and potentially dangerous when you
do exclude things this way, but can be useful in some circumstances.
Stopping only affects the same type of spamfilters (general or central
spamfilters), so they don't interfere.
The tkldb write DB bug had to do with that it was processing
central spamfilters, which should be skipped just like config
based spamfilters were already skipped.
to limit actions to limit-ban-action as the highest, and limit
ban times to limit-ban-time the highest, see
https://www.unrealircd.org/docs/Central_Spamfilter
This also changes highest_spamfilter_action() to highest_ban_action().
* This means we always run spamfilters, even if users are exempts
* This way we can gather hits for exempted users on individual
spamfilter entries, and possibly detect false positives
(which relies on the assumption that those users are innocent)
* The hit counters are shown in in RPL_STATSSPAMF and also
exposed via the JSON-RCP API.
* This commit also adds set::central-spamfilter::except but more
on that later since i still want to set a default for that in
a future commit.
* This also changes take_action() to take flags and adds the
option TAKE_ACTION_SIMULATE_USER_ACTION which i intended to
use but didn't in the end... not sure if i should keep it :D
This uses the RPC2 API. Tested with staging.
Note that there are likely some bugs here or there, like memory leaks,
but the functionality is there.
Also still need to implement various stuff, including spamreport::rate-limit
unreal_duplicate_masks()
duplicate_nvplist()
duplicate_name_list()
And use this for when proxy::type is web, to duplicate the
exact criteria to the ban exception as mentioned in previous
commit.
a function called start_dns_and_ident_lookup(). This can then
be easily called from other places as well, like the code k4be
did in src/modules/websocket.c to handle proxies.
Side-effect is that ident lookups would now be done, if we are
configured to do so, for forwarded webirc stuff (not that I
think many people use that feature at the moment...).
It is now possible to override some set settings per-security group by
having a set block with a name, like `set unknown-users { }`
* You could use this to set more limitations for unknown-users:
```
set unknown-users {
max-channels-per-user 5;
static-quit "Quit";
static-part yes;
}
```
* Or to set higher values (higher than the normal set block)
for trusted users:
```
security-group trusted-bots {
account { BotOne; BotTwo; }
}
set trusted-bots {
max-channels-per-user 25;
}
```
* Currently the following settings can be used in a set xxx { } block:
set::auto-join, set::modes-on-connect, set::restrict-usermodes,
set::max-channels-per-user, set::static-quit, set::static-part.
Bram Matthys