On Linux we still show the usage info as for "unrealircd" (not unrealircdctl)
since on Linux we have the "unrealircd" script that manages all this and
"unrealircdctl" is not really meant to be called directly by end-users.
What is a SVSMOTD? The SVSMOTD are MOTD lines that are shown at the end of
an existing MOTD. These lines are added remotely through services.
Previously the SVSMOTD lines were never shown in the MOTD-on-connect, which
was a bug. We were only supposed to hide it if a short motd is in use.
Reported by Valware in https://bugs.unrealircd.org/view.php?id=6070
The spec <https://datatracker.ietf.org/doc/html/draft-hardy-irc-isupport-00#section-4.8>
is a little unclear on the semantics, and Unreal interprets 'C<val' as
a request for all chans created before <val> minutes ago, ditto.
This is a legitimate interpretation, but I think the other on makes more
sense (ie. that 'C<val' means all chans created less than <val> minutes
ago).
Additionally, the documentation for T did not match the implementation
before this commit.
Before this commit, Unreal was consistent with Hybrid/Plexus4 on ELIST C.
After this commit, Unreal will be consistent with Charybdis/Solanum,
InspIRCd, and ircu2 (and Hybrid/Plexus4 on ELIST T).
Reported by Jaka in https://bugs.unrealircd.org/view.php?id=6077 and
Valware and buayadarat in https://bugs.unrealircd.org/view.php?id=6078
This commit also makes the halfop rules for +h/-h match the ones in U5:
Previously in 6.0.0 - 6.0.2 it was:
* halfops can set +h on others
* halfops cannot set -h on others
* halfops can set -h on themselves
Now in 6.0.3+ it matches 5.x behavior again:
* halfops cannot set -h or +h on others
* halfops can set -h on themselves
missing other functionality.
Reported by DarthGandalf in https://bugs.unrealircd.org/view.php?id=5918
The cause was that all fd's were closed, including 0/1/2. We now reopen
those and map them to /dev/null, like we do later again.
the server name. Nowadays we receive and log lines from remote servers
so without this extra information it can be unclear where events
(eg: problems) are happening which can be rather confusing.
rehash errors such as error: set::geoip-classic::ipv6-database:
cannot open file "/home/xxxx/unrealircd/data/https://www.unrealircd...
and possibly even a crash.
The initial boot of UnrealIRCd, however, was always fine, this only
happened when rehashing.
It also seemed to occur more with ftp:// includes or at least with
multiple parallel includes, that may or may not have different or
more latency. In any case it seemed to affect some remote includes
setups semi-consistently, and others not at all.
The root cause was a complex code path causing a read-after-free.
We now use a simplified code path which can no longer cause this.
The only downside is that rehashing may be delayed up to an extra
250ms (quarter of a second), but that should hardly be noticeable,
if at all.
Issue reported by Bun-Bun.
including version, description, author, flags. The output is
pretty much identical to "MODULE -all" on IRC as IRCOp.
Useful for the future if you want to verify a module has been
upgraded from the command line.
or another type of proxy request.
This fixes a problem where ban user { } or except ban { } is not working
for ~country:XX when the request comes via a WEBIRC or other proxy.
Reported by CaoS in https://bugs.unrealircd.org/view.php?id=6058
It should also fix security-group being incorrect for ~security-group bans
or exempts.
the rest of the hooks, most of which do not use the past tense.
Only affects HOOKTYPE_USERHOST_CHANGE / HOOKTYPE_REALNAME_CHANGE.
This does, however, make it inconsistent with the userhost_changed()
call, though :D.
synced by the server the user is on, and this way the country will be
consistently the same on all servers (and not BE on one, and NL on another,
which would be confusing for the ban matching code, giving different
results on each server).
When you set this to 'yes' you get more options...
See next (modified) copy-paste from April 2020, which had to be reverted
because PCRE2 was broken. Now it's an opt-in and hopefully matured a bit.
This means:
* Case insensitive matches work better in UTF8 now, such as extended Latin.
For example, a spamfilter on "ę" now also matches "Ę", while previously
it did not catch this.
* Other PCRE2 features such as https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC5
are now available. For example you can now set a spamfilter with the regex
\p{Arabic} to block all Arabic script, or
\p{Cyrillic} to block all Cyrillic script (such as Russian)
Use these new tools with care, of course. Blocking an entire language,
or script, is quite a drastic measure.
All of this was possible because of the new PCRE2_MATCH_INVALID_UTF
compile time option which was introduced in PCRE2 10.34. Now, that
version turned out to be buggy. As recent as PCRE 10.36 some major bugs
were fixed. This also means we now require at least PCRE2 10.36 version
so everyone can benefit from this new spamfilter UTF8 feature, IF they
enable set::spamfilter::utf8-support, that is.
Many systems come with older PCRE2 versions so this means we will
fall back to the shipped PCRE2 version in UnrealIRCd. This means
./Config will take a little longer to compile things.
For packagers (rpm/deb/ports): if you choose to patch configure to
not require such a recent PCRE2, then please do not allow enabling
of set::spamfilter::utf8-support since it will likely cause crashes
and misbehavior. Check PCRE2 changelog, CTRL+F at PCRE2_MATCH_INVALID_UTF
is done behind-the-scenes (the command is still ./unrealircd mkpasswd).
For Windows users it finally means they can generate passwords via the CLI
using: unrealircdctl mkpasswd pwdhere
dbuf->length to be unitialized.
This wasn't an actual problem until yesterday in UnrealIRCd code,
since the whole client struct was initialized to zero, including
client->local->sendQ(->length) etc.
However, now we use the dbuf code elsewhere too (on the stack) and
3rd party modules can use it too, so fix this bug.
"./unrealircd reloadtls" and there is now also a "./unrealircd status"
The output is colorized if the terminal supports it (just like on the
boot screen) and also the exit status is 0 for success and non-0 for
failure. The purpose of all this is that you can easily detect rehash
errors on the command line.
These three commands communicate to UnrealIRCd via the new control
UNIX socket, which is in ~/data/unrealircd.ctl.
This also does a lot of other stuff because we now have an internal
tool called bin/unrealircdctl which is called by ./unrealircd for
some of the commands to communicate to the unrealircd.ctl socket.
Later on more of the existing functionality may be moved to that
tool and we may also provide it on Windows in CLI mode so people
have more of the same functionality as on *NIX.
It was missing for a lot of extbans (removing too little) and
for ~t it was removing too much (eg quiet bans).
Bug reported and changes suggested by k4be.
Coders:
Setting extban.options to EXTBOPT_CHSVSMODE has no effect anymore,
just didn't want to remove it so modules would still compile.
We now purely match based on .is_banned_events including BANCHK_JOIN.
Various things still need to be done: a lot more testing, ability to
set permissions on the file, #ifdef's because of lack of support
on Windows (currently won't compile), etc.
One thing that I don't intend to change is that I chose not to display
the socket in the host but have clients show up as 'localhost' (and
ip '127.0.0.1'). Doing it this way keeps things easy, otherwise we risk
a lot of breakage for nearly nothing gained, really.
Things can be tested via:
listen {
file "/tmp/listen";
}
and then with netcat:
nc -U /tmp/listen
USER x x x x
NICK hai
etc...
Bram Matthys