1) Give an exact link to https://www.unrealircd.org/docs/UnrealIRCd_releases
which describes the supported versions and EOL stuff in more detail.
2) Make clear that we have better instructions on the wiki with regards to installation
and that users should use that one instead (the ones in the README are really meant as fall-back)
3) Some nicer formatting here and there (minor)
This module will work the same way as `userip-tag` or `userhost-tag` modules work now, the 90% of this code is part from these modules.
It will help especially the irc bots (AdiIRC/mIRC) to detect the geoip country code directly and easy when someone is talking on a channel and take actions, i hope this will help on most people.
Thanks @Valware for testing it out.
Short Example: `@unrealircd.org/geoip=GR;account=tester;msgid=tPTHDgymv9pgdGdYkI3WBd;time=2022-03-30T16:34:26.780Z :tester!Username@3765DB68:3AE9CB6C:B0540131:IP PRIVMSG #Test :test message`
This was caused by the transition from letter extbans (eg ~a) to
named extbans (eg ~account) and a combination of the bug fix in 6.0.2
(60a70acd86) and the 'channeldb' module
not checking for duplicates while reading the database.
Reported by PeGaSuS in https://bugs.unrealircd.org/view.php?id=6091
It often takes a while for the actual crash to occur but eventually an
attempt would be made to access inaccessible memory of the previously
freed .so module.
Reported by and traced with the help of both Wick and Krstarica.
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.
as it complicates things too much. The c-ares build options that we use in
UnrealIRCd cause curl not to recongize c-ares, and the other way around is not
good either. Also, self-compiled ("unrealircd shipped") c-ares may not be
used/required by main unrealircd (thus rm'd) while it is still needed by
self-compiled curled. Blehh, what a mess.
Now we simply don't compile curl with c-ares and rely on cURL to enable async
DNS support via system c-ares or via the another way, with the use of threads,
which is standard in curl now for many years and should work on most, if not
all platforms.
If this is somehow problematic for you then install libcurl/libcurl-dev(el)
on your system itself, via your package manager or other means.
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.
Bram Matthys