in 6.0.2+ we can inform the user whether the rehash actually succeeded
or not. This was already shown in the output, but we now also change
the last few lines of output to make very clear if the rehash failed
that the currently running UnrealIRCd is not patched.
like /home/xyz/unrealircd/unrealircd hot-patch instead. In other words,
if the current working directory is not the location of the unrealircd
script. Then calling ./unrealircd rehash, so the last step in the patching
process, would fail. Reported by k4be.
[skip ci]
parts of the code later on, in particular the upgrade code.
Eg: a base path of "/home/xyz/unrealircd/"
Side note: this also assumes no path is / (root), which seems a
reasonable assumption.
./configure script from us. That is, using the correct private lib dir
and using --disable-tests and so on.
Should fix a bug on CentOS where c-ares could not be built due to
the test suite requirements from c-ares, 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
Bram Matthys