Note: the only change between 5.0.9 and 5.0.9.1 is:
* Build improvements on *NIX (faster compiling and lower memory requirements)
* Windows version is unchanged and still 5.0.9
Type: Parallel build: Non-parallel build:
Before change 92 seconds 304 seconds
After change 7 seconds 21 seconds
All this thanks to a simple --disable-tests being passed to c-ares' configure.
(that is, MemAvailable, not MemFree). The ./Config script with
all shipped libs compiled actually has a memory peak of 450M
in my tests with -j4, but let's err on the safe side...
Reason for all this:
This helps on shells with limited memory, especially if they
don't have swap.
We actually don't take swapping into account, so even if you
have plenty of swap but "low" on memory then we won't force a
parallel build. That's okay, since in such a case a parallel
build is not so useful anyway with (slow!) swapping.
This code only works on Linux. Let's hope *BSD guys are smart
enough to have a decent system setup.
need this and it slows things down for servers.
For clients it's not much of an issue, since traffic rates are low.
However, for server-to-server links it is an entirely different matter.
It is (only) noticeable if you have lots of traffic, such as when there
is a lot to sync while linking two servers, and especially when the two
servers are geographically further apart.
Tested with 100,000 G-lines on both sides being synced (20MB traffic):
* 20ms RTT (same country/state): speed up of x3
* 200ms RTT (transpacific): speed up of x6
We moved from LibreSSL 3.1.4 to 3.2.4.
Support for TLSv1.3 was added in LibreSSL 3.2.2 from Oct 2020,
but it had some issues, hopefully by now they are resolved.
[skip ci]
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.
the spamfilter. Only after a rehash it showed the me::name as the
setter. From now on we just display -config- in the setter field,
like we do for all the other TKLs as well (ELINE, ban xyz, etc).
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).
That is, when in "auto" mode, which is like for 99% of the users.
NOTE: the sytem may still limit the actual number of FD's to
a lower value, depending on the value of "ulimit -n -H".
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
And if it is actually used/installed then make it a little bit
harder to bypass the case where the digitale signature does not match.
And yes, the bypass option does exist because in the future we
may have a different signing key. Who knows from what old version
people may upgrade years from now, after all.
Bram Matthys