snomasks, opers, global (remote), ..
For disk logs we currently ignore the sources and log everything.
NOTE: REHASH is untested and will memory leak for sure.
Also rename them to describe better what they do.
ConfigFile:
cf_filename -> filename
cf_next -> next
cf_entries -> items
ConfigEntry:
ce_fileptr -> file
ce_varlinenum -> line_number
ce_fileposstart -> file_position_start
ce_fileposend -> file_position_end
ce_sectlinenum -> section_linenumber
ce_varname -> name
ce_vardata -> value
ce_cond -> conditional_config
ce_entries -> items
ce_next -> next
ce_prevlevel -> parent
Also add doxygen docs for both structs.
Note that without such a block nothing will be sent to ircops at all
(anything that comes from unreal_log anyway).
In a later commit either a snomasks.default.conf will be added and/or
an internal default mapping.
This also moves the recursion trap to earlier in the logging code,
which has the side effect that debug traffic regarding snomasks is
no longer logged.
This will likely reduce performance, but this should not matter in modern times.
Also added flags to let modules know which one the entry belongs to, and what
to do with it.
Now modules should be able to add their own WATCH methods (like IRCv3 MONITOR),
or extend functionality to notify about other changes than the default log on,
log off and away statuses (like SETNAMEs).
that only set +r on people. To my knowledge, practically no services are
out there anymore that do not use proper SVIDs (and that can link with
UnrealIRCd 5).
I would like a bit more room for this in the future,
but until then we will keep sending UIDs of length 9 in
server to server traffic, so no change at all.
This also allows known-users to execute slightly more commands per second.
For people who want their trusted users/bots to allow even more commands
per second (eg 20cmds/sec) we now have a nice FAQ item that uses this:
https://www.unrealircd.org/docs/FAQ#high-command-rate
for "unknown-users" and "known-users".
As a reminder, by default, "known-users" are users who are identified
to services OR are on an IP that has been connected for over 2 hours
in the past X days.
See https://www.unrealircd.org/docs/FAQ#new-anti-flood-block
for more information on the layout of the new block.
NOTE: This actual feature, the relase notes and the documentation
are all work in progress.
See https://ircv3.net/specs/client-tags/reply for the draft.
Can be used by clients to indicate to which message they are writing
a reply. This can be especially useful for bots, to indicate that
a response belongs to a user request, eg a !trigger.
The new target type is called 'T' and we match against "name=value"
of each message tag (or just "name" if it is without value).
Example: SPAMFILTER ADD -simple T kill 0 this_is_a_test +typing=active
(No this is not a suggestion :D)
This probably won't be used much at all, but it is good to have the
option available in case there is some massive problem,
especially since more message tags may pop up sooner or later.
Caveat: this is actually a bit slow as we may have to check multiple
message tags for a single line.
If there are zero message-tag spamfilters then we will automatically
short-circuit and save all this CPU, which will be the most common case.
Suggested by Amiga600 in https://bugs.unrealircd.org/view.php?id=5784
This also fixes a bug with log::maxsize on Windows (cannot overwrite
existing file with .old).
It simplifies the logging code a little and makes it a tad more readable.
And it adds an unreal_strftime() function to make things easy.
notices to IRCOps and in ircd.log.
See the release notes for more details.
Module coders:
You can use HOOKTYPE_CONNECT_EXTINFO to add your own additional
information as well. See get_connect_extinfo() for inspiration.
Use nvplist_add() or nvplist_add_fmt() to easily add your info
to the list.
Module coders II:
Small note: this moves the sending of the far connect notice
to /under/ HOOKTYPE_REMOTE_CONNECT instead of /above/.
The handshake delay exists so results from DNSBL's can be checked before
the user is fully online. Whenever someone is exempt from DNSBL checking
it serves no purpose, so we mark it that the user has no handshake delay.
This will speed up connecting by up to 2 seconds (by default).
Also updated WebIRC example to suggest this now:
https://www.unrealircd.org/docs/WebIRC_block#UnrealIRCd-side
* There are two security groups by default: known-users and unknown-users.
See https://www.unrealircd.org/docs/Security-group_block
* New extended ban ~G:securitygroupname, with the typical usage being
MODE #chan +b ~G:unknown-users, which will ban all users from the
channel that are not identified to services and have a reputation
score below 25.
by armyn in https://bugs.unrealircd.org/view.php?id=5769.
The default behavior in 5.x is to continue matching:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*; password "iwantmore"; class clients; maxperip 10; }
This so users who provide a password get additional rights,
such as a higher maxperip or a different class, etc.
If the user connects without a password then we simply continue
to the next block and use the general block with only 2 maxperip.
However, some people want to use passwords to keep other users out.
That is entirely understandable as it is an 'allow block' after all.
For example:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*.nl; password "tehdutch"; class clients; maxperip 2; options { reject-on-auth-failure; } }
In this case anyone without the correct password will be rejected access.
That option specified a Diffie Hellman parameter file. Since
UnrealIRCd 5.0.0 we no longer process this option.
This option has never been documented in the wiki docs.
We prefer and use ECDHE/EECDH with SSL_OP_SINGLE_ECDH_USE since 2015
to provide Forward Secrecy in SSL/TLS. And indeed, by now in 2020,
any properly maintained software uses it and old DH(E) usage has
fallen to less than 1%.
What this patch does is remove the unused code (since Dec 2019) and
show a warning if you have a ::dh config directive, so that at least
you are informed that it is unused/ignored. Since it was undocumented
it probably hardly affects anyone, but still, it is proper to inform.
Bram Matthys