This is the work from May 3rd.. need to commit it so i can merge the
flood protection that is related to this...
The final implementation will still need tweaking before pushed.
[skip ci]
no connect-delay restriction. Also remove the 'disable' option since
it is unneeded. You now simply use:
set {
restrict-commands {
somecommand {
}
}
}
...and the command is disabled.
And you add exempt-identified or exempt-reputation-score if needed.
See https://www.unrealircd.org/docs/Set_block#set%3A%3Arestrict-commands
Note that this also changes some command blocking logic, so I hope
I made no mistake there... only testing will tell.
When connecting, use slightly different wording (and use it consistently):
"Trying to activate link with server xyz"
When the connection is lost before synced:
"Unable to link with server xyz"
When the connection is lost after fully synced (eg: minutes later):
"Lost server link to xyz"
Important small changes (other than text):
* Log ERRORs from remote servers to the log (previously only shown to ircops)
* Some link errors could have been previously suppressed due to
old code assuming other parts of the code would send or log the error
(this would be the case for an error when calling SSL/TLS write functions)
* More?
connected users for technical reasons, so you will have to use double
whois to see it for remotes (/WHOIS Nick Nick) just like with idle time.
Suggested in https://bugs.unrealircd.org/view.php?id=5519
set::ident::connect-timeout for the read timeout also.
This could lead to failed ident lookups on higher latency connections
because it only gave 3 seconds for the entire ident lookup rather than
the (max) 10 seconds that was intended.
Now both values are properly obeyed (3 for connect, 7 for read
timeouts, by default).
when used on a multi-server network. This was due to the PART event
inadvertently not being sent towards the SAJOIN direction.
Bug reported by Cheiron in https://bugs.unrealircd.org/view.php?id=5616
form an insecure connection. There we explain a bit on the why and how to
configure some random IRC clients.
This also silently adds support for multi-line messages in
set::plaintext-policy::user-message (for warn) and
set::plaintext-policy::oper-message (for warn and deny).
Eg with anope with the KILL option turned ON, a minute after taking
a registered a nick.
Very similar to c9b88343e2 which was
fixed in 5.0.0-beta1 for non-forced nick changes.
and HOOKTYPE_REMOTE_CHANMODE are called from the SJOIN code.
We now set the samode argument to -1 if it is an SJOIN server sync,
so chanmodes/permanent won't destroy the channel while processing
the SJOIN. The SJOIN code already takes care of destroying at the end.
so they can fetch more history than the standard on-join history.
In the future we are also likely to implement IRCv3 CHATHISTORY
once that becomes an official specification. However, until it is
specified and until most major clients support it, several years
are likely to pass. It would be a shame to withhold channel
history to many end-users in the meantime when it takes so little
effort from us to provide an easy command.
See also
https://www.unrealircd.org/docs/Channel_history
And in particular the new section:
https://www.unrealircd.org/docs/Channel_history#Playback_frontends
which explains the relationship between on-join playback,
HISTORY and CHATHISTORY.
Release notes:
+* [Channel history](https://www.unrealircd.org/docs/Channel_history) used
+incorrect time internally, resulting in messages expiring too soon.
+The syntax is now really ```/MODE #chan +H lines:time-in-minutes```.
+To make clear that the time is in minutes, an 'm' will be added
+automatically by the server (eg ```+H 15:1440m```).
Bug reported by k4be.
set::oper-auto-join or tld::channel was broken. It worked for the
very first user since boot or rehash, but after that only the
first channel was joined. Reported by PeGaSuS in
https://bugs.unrealircd.org/view.php?id=5535
Bram Matthys