This should be:
security-group Syzop { certfp "1234etc."; }
As this is wrong:
security-group Syzop { mask { certfp "1234etc."; } }
Reported by Han`.
This also makes us throw a config error on the wrong case.
no longer expand shorter versions of a variable. It previously had some
unintended form of magic autocomplete where $serv was handled the same
way as if it was $server. This could cause issues in the long run when
variables are added and the meaning of the short form changes.
Reported by westor in https://bugs.unrealircd.org/view.php?id=6123
but it seems there were still a couple left. These are now gone as well.
There seem to be no issues with the ones that were left, but it is just
too easy to get it wrong. Declaring buf in function now. This should be
faster anyway, since it is located on nearby memory (stack).
Inspired by previous find from westor (c708a99955c034e842f913479cc597d87b311394).
Use the new options in the new ::except block, fix broken English
and trim down the text a bit.
This also lowers the threshold from 7 to 6. It was already 5 in
the example block on the wiki, now the wiki and this are the same
again.
if the oper block permits, the user does not have to send "OPER xyz".
Eg:
security-group Syzop { certfp "xyz"; }
oper Syzop {
auto-login yes;
mask { security-group Syzop; }
operclass netadmin-with-override;
class opers;
}
Then, if you connect with SSL with that certificate fingerprint,
you become IRCOp automatically.
and other selectors in 'mask'. This allows for things like:
security-group Syzop { certfp "xyz"; }
oper Syzop {
mask { security-group Syzop; }
operclass netadmin-with-override;
class opers;
}
except ban {
mask { security-group Syzop; }
type all;
}
allow {
mask { security-group Syzop; }
class special;
maxperip 32;
}
etc...
We do error on the obvious case of mask * and mask *@* when no password
is set, but otherwise try not to stop all cases of user stupidity
(there are just too many...).
Reported by ZarTek-Creole in https://bugs.unrealircd.org/view.php?id=6114
We now call HOOKTYPE_LOCAL_CHANMODE on the modes we set in modes-on-join,
where 'client' is '&me'. Should be fine, as we already did the same for
+P modes (indirectly) in channeldb.
across servers if they differed, however the individual IP of users
was not updated until next add_scores() run. So, there would be an
up to 5 minute delay during which scores for individual users were
possibly too low, with all the effects that it could possibly have
nowadays such as restrict-commands, more stringent flood limits, etc.
If your servers are all linked all the time then you would not have
noticed this issue. It mostly matters if you are linking in a new
server or if the server has been delinked or out of order for days
or weeks.
So you can just use mask { ip { 127.*; 192.168.*; } } without
having to worry about hostnames like 127.example.net.
(Of course you could also have used CIDR notation)
Another benefit is that, since we are dealing with IP's only,
the matching is faster than going through the more universal
match_user() routine.
So now the example in the release notes actually works:
except ban {
mask { security-group irccloud; }
type { blacklist; connect-flood; handshake-data-flood; }
}
The list of channels (which is an array) is limited to a total
of 384 characters after JSON expansion. If it is limited then
the last item will be "...".
Suggested by westor in https://bugs.unrealircd.org/view.php?id=6083
The "vhost" field is added if the visible host of the user differs
from the real hostname, such as +x with cloaking or +xt with a vhost.
The "cloakedhost" is always included, even if the user does not
currently have a cloaked host at all (eg is -x or using a vhost).
Both make it easier to search log files based on user reports.
Eg a user mentions a vhost or cloaked host from their user logs
and then a server admin searches the UnrealIRCd logs on this to
retrieve the real host / ip / user based on that.
Suggested by westor in https://bugs.unrealircd.org/view.php?id=6083
(It is not under "user" because the info can be useful before someone
is considered a user, eg when flooding/rejected/etc)
Bram Matthys