if running multiple ircds from the same directory you sometimes get
weird messages otherwise (not that we really support such a thing
but i use it while dev'ing).
Not reported by anyone, but yeah.. who knows there is someone out there
that does this :D.
Also make it work the same like channeldb by spreading the event.
If a module returns 0 ("UnrealIRCd please do not process this packet")
then don't call the next module in line (also because that one might
then change the return value to something different, which is bad).
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/.
When booting no log files are open yet as we have not parsed any log { }
entries yet. On *NIX we log to stderr during that stage.
On Windows it varies: when running in GUI mode we save the log to a
buffer and display it after booting in a dialog.
When running as a service on Windows we previously wrote SOME entries
to service.log, but other entries were not logged or shown anywhere.
This makes both GUI and Service-mode on windows log all ircd_log()
calls with LOG_ERROR, instead of only config_status(), config_warn()
and config_error() messages.
This also removes config_progress() which isn't used by anything.
Oh, and it also fixes a memory leak in the Windows boot code, a leak
that nobody would have noticed anyway, but still.
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
The exempted ban types are only ones that will affect other connections as well,
such as gline, and/but not policy decissions such as bypassing qlines or maxperip.
Currently the list is: gline, kline, gzline, zline, shun, blacklist,
connect-flood, unknown-data-flood.
Suggested by PeGaSuS and others in https://bugs.unrealircd.org/view.php?id=5806
Previously it rejected ! for all type of *LINES to avoid users
making the mistake of banning nick!user@host in a *LINE.
Note that for non-extended-server-bans the ! is still forbidden.
* 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.
It is highly recommended that services pseudo users all have +o since
there are likely many places where ULines don't bypass a restriction while
opers do. But still, this particular issue has been fixed, it caused
unexplained loss of messages which looked rather mysterious.
Reported by severinmueller in https://bugs.unrealircd.org/view.php?id=5799
The reputation command (IRCOp-only) has been extended to make it
easier to look for potential troublemakers:
* ```REPUTATION Nick``` shows reputation about the nick name
* ```REPUTATION IP``` shows reputation about the IP address
* ```REPUTATION #channel``` lists users in channel with their reputation score
* ```REPUTATION <NN``` lists users with reputation scores below value NN
to the specified number of lines. This defaults to 1000.
This will prevent IRCOps from being flooded off ("Max SendQ exceeded")
if they list all *LINES and there are thousands.
In the newly introduced error message, after too many matches,
we also kindly point out to use filters like '/STATS gline +m *.nl'
Bram Matthys