This required two members on the same server and channel mode +H to be set
(or set::broadcast-channel-messages 'always', then also with -H).
The cause was a (normally harmless) optimization in
1473f52603 which meant we would loop
through remote servers for the case of +H.
And then the real cause a bug in the linecache system, which
caused servers to be seen as LCUT_NORMAL because locally
connected servers are MyConnect()->true.
And then on the wire (S2S) a message would look like..
:nick!user@host PRIVMSG ...
But nick!user@host is not valid in normal S2S traffic and on the receiving
server is seen as a nick@server message (and 'nick!user' is never found
on 'server' where server is actually a user host)... seems like an
old relic, but this aside.
This in turn, causing the message to be dropped (unknown source),
and the PRIVMSG handler is not called at all.
Bug reported by CrazyCat and then PeGaSuS managed to reproduce the
issue later on irc.unrealircd.org. Thanks!
As said, this only affects 6.1.2-rc2 and chmode +H.
Use extras/startup/unrealircd.service if you want a system-wide unit
file, which is normally what people tend to use. The benefit of this
is that it allows setting some security options.
Use extras/startup/unrealircd_user.service if you want a user unit
file. This works if you don't have root on the machine.
./unrealircd [start|stop|restart] commands if unrealircd is running
but without a pid, which will be the case if running through systemd.
The systemd example unit files will be in a future commit.
namely via "MODE #channel +F".
Enhance "MODE #channel +F" by explaining a bit more (like, actions a chanop
can do to change things).
Example of protection kicking in:
*** Channel CTCPflood detected (limit is 7 per 15 seconds), setting mode +C. Type "/MODE #test +F" to get more information on channel flood protection.
Then if you type "MODE #test +F":
Channel '#test' has effective flood setting '[7c#C15,30j#R10,10k#K15,40m#M10,8n#N15]:15' (flood profile 'normal')
-
You are currently using the default anti-flood profile normal.
If you want to change to a different anti-flood profile, for example because flood protection is kicking in too quickly
or too late, then you can use MODE #test +F <profile>. See the list of profiles below (ordered from lax to strict).
List of available flood profiles for +F:
off: []:0
very-relaxed: [7c#C15,60j#R10,10k#K15,90m#M10,10n#N15]:15
relaxed: [7c#C15,45j#R10,10k#K15,60m#M10,10n#N15]:15
normal: [7c#C15,30j#R10,10k#K15,40m#M10,8n#N15]:15
strict: [7c#C15,15j#R10,10k#K15,40m#M10,8n#N15]:15
very-strict: [7c#C15,10j#R10,10k#K15,30m#M10,5n#N15]:15
See also https://www.unrealircd.org/docs/Channel_anti-flood_settings
(And actually there is some bold text there too)
Indirectly suggested in https://bugs.unrealircd.org/view.php?id=6580
by rafaelgrether and PeGaSuS (being more clear to IRCOps what is happening).
(both AddressSanitizer and UndefinedBehaviorSanitizer)
This previously helped finding 8c26cec5fc
Also update the ./Config text a bit, eg about ASan not running OK on FreeBSD,
which only affects <14.2 as per https://bugs.unrealircd.org/view.php?id=6470#c23412
about an overflow with eg 'STATS maxperip' (IRCOp-only command).
Also, STATS maxperip failed to return 1 in the hook, resulting in
unnecessary STATS help output after the list.
We already run CI since 2014, first via Travis CI, then when it became
paid we switched to self-hosted BuildBot in 2019. Later that year
GitHub Actions came also in existence, but we already switched over to
BuildBot by then so didn't use it.
We will still use BuildBot on self-hosted to test various Ubuntu and
Debian distro versions, FreeBSD and Windows. Also, in the BuildBot we
have our own pre-build environment where we run Services tests (with
both anope and atheme), we run TLS there (again on all those distros
with various OpenSSL versions). And we also test both clang and gcc.
So what is new? Well, now we will also run a "quick test" via GitHub
Actions, like most projects out there on GitHub. Not the services test,
not the TLS tests, but simply latest Ubuntu and then clang+gcc.
The main benefit of this is that it will also show up on Pull Requests
and makes it "public" as our BuildBot page is restricted.
Previous was way too confusing where user was actually a client and
channels was actually a membership struct. And then you got like
user->user and channels->channel. No, let's make this conform to
the same style that we use elsewhere. Who the hell wrote this !??
Oh, it seems I did :D
1) Similar to sendto_local_common_channels() go through local_members
instead of all channel members
2) We have the membership info, so use user_can_see_member_fast()
This mainly affects MODE #channel +vhoaq and such. And as with all these
optimizations it mostly affects channels with more than 10 people (eg
hundreds or thousands).
Also did add_member_mode() and del_member_mode() but those are not
used by our own code because we always use fast versions anyway.
Oh yeah and the +D invisibility shit via set_user_invisible():
that one i didn't benchmark but should be better as well for
large channels.
Bram Matthys