Post-handshake this was working fine, but before register_user() it was
always using nick!user@host, never using the ident and never ~ prefixing.
Now it just uses the usual rules that we have, which are: prefixing
with a ~ if ident lookups are enabled and failed, and without a ~
prefix if ident lookup succeeded or set::options::identd-check is off.
Reported by k4be.
This so you can match a literal * or ? via \* and \?
And do the same for allow channel { }.
This can break current configs if you have a deny channel for a channel
with a slash in it, since a \ which already sortof needed to be \\ in
the config file, now needs to be \\\\ (doesn't that look great?).
Fortunately slashes are not really common in channel names, let alone
deny channel { } configuration.
Since 10k+ fd's available is the common situation, this means we then have
250 fd's reserved for non-clients, such as HTTPS callbacks and other things.
Previously:
<1024: reserve 4 fd's
1024+: reserve 8 fd's
Now:
<1024: reserve 8 fd's
1024-2047: reserve 16 fd's
2048-10000: reserve 32 fd's
10000+: reserve 250 fd's
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
With error messages about it possibly but also possibly not (silently failing).
This is actually quite bad because when the ircd is running, you could
happily add spamfilters with UTF8 like stuff, REHASH fine, but if you
then restart the IRCd would fail to boot due to a config error.
Reported by BlackBishop.
If you make a parser mistake in the config file, like a missing semicolon,
then under some circumstances the server may crash. Not always, it seems,
which explains why this bug is not reported that much.
For config-based spamfilters, the reason was not escaped, meaning that
spaces and underscores did not work as expected.
For example, in "STATS spamfilter" the spaces were displayed as-is
which means that the numeric output was not really parsable.
Apparently this bug exists since UnrealIRCd 5 already...
For example, because of a different version of PCRE2, or because of the switch
from non-UTF8 to UTF8 (or vice versa) which disallows certain byte sequences.
This happens when !, || or && are used, though the exact requirements
for the crash may also require a function with arguments.
Reported by BlackBishop.
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.
even when multiple modules were upgraded.
Actually not sure about the cause and how this is possible, but running
'make install' only once at the end is the solution, which is something
that should be done that way anyway.
Reported by westor in https://bugs.unrealircd.org/view.php?id=5919
In the config file, when not using quotes, a slash at the beginning of a
variable name or value was silently discarded (eg `file /tmp/xyz;` resulted
in a file `tmp/xyz`).
Reported by BlackBishop in https://bugs.unrealircd.org/view.php?id=6325
Bram Matthys