that was added late in 6.1.1 development to fix a crash with removing
websocket listeners. Now replaced with a generic HOOKTYPE_CONFIG_LISTENER
that is not only called for removed listeners, but for all listeners.
`PROTOCTL BIGLINES` is set. This will allow us to do things more
efficiently and possibly raise some other limits in the future.
This 16k is the size of the complete line, including sender,
message tags, content and \r\n. Also, in server-to-server traffic
we now allow 30 parameters (MAXPARA*2).
The original input size limits for non-servers remain the same: the
complete line can be 4k+512, with the non-mtag portion limit set
at 512 bytes (including \r\n), and MAXPARA is still 15 as well.
* I chose 16k because I don't want to first raise it to like 8k
and then realize later that 16k would be better and raise it again.
* To receive BIGLINES in a command, you need to `CommandAdd()` with
flags `CMD_BIGLINES`, without it you still get regular 512 max.
This is so, because a lot of the code does not expect longer than
512 bytes lines or in parameters, so we can gradually change that
(where needed).
unreal_duplicate_masks()
duplicate_nvplist()
duplicate_name_list()
And use this for when proxy::type is web, to duplicate the
exact criteria to the ban exception as mentioned in previous
commit.
depending on what we get from the proxy, so it can be used later
in the websocket module for setting the user secure or not
(the latter similar to what k4be already did in the old code).
a function called start_dns_and_ident_lookup(). This can then
be easily called from other places as well, like the code k4be
did in src/modules/websocket.c to handle proxies.
Side-effect is that ident lookups would now be done, if we are
configured to do so, for forwarded webirc stuff (not that I
think many people use that feature at the moment...).
It is now possible to override some set settings per-security group by
having a set block with a name, like `set unknown-users { }`
* You could use this to set more limitations for unknown-users:
```
set unknown-users {
max-channels-per-user 5;
static-quit "Quit";
static-part yes;
}
```
* Or to set higher values (higher than the normal set block)
for trusted users:
```
security-group trusted-bots {
account { BotOne; BotTwo; }
}
set trusted-bots {
max-channels-per-user 25;
}
```
* Currently the following settings can be used in a set xxx { } block:
set::auto-join, set::modes-on-connect, set::restrict-usermodes,
set::max-channels-per-user, set::static-quit, set::static-part.
the default set::max-channels-per-user (also called set::maxchannelsperuser).
This way you can give known-users a higher max-channels-per-user,
or even a special security group for trusted users (that you may
already have given a more lax flood setting and lower lag-penalty
etc. etc. so that fits in nicely)
And yeah this also:
* Makes it both in set and the anti-flood block accept both
maxchannelsperuser and max-channels-per-user.
* Removes old MAXCHANNELS= in 005, as we already have CHANLIMIT=
This does not:
* Re-announce the 005 CHANLIMIT= if someone transitions from a security
group with a different max-channels-per-user. We don't do that for
IRCOps either, and I think no IRCd does that actually...
To be honest i wonder if sending the limit in 005 is useful at all,
do client really track this and limit their GUI based on it?? Doubt it!
(or changing the port number). Reported by Nini.
Rather complex case: when the listen block is removed, obviously
the config hooks are not called for the (now non-existing) listen
block, and thus the websocket->request_handler and such are not
set to the new address of the websocket handler.
We now use a slightly silly workaround / new hook to fix this
corner case. Ideally there would be an extra layer in-between
like a handler lookup by name, or something like that.
(Or make the websocket module PERM but we don't want that!)
This so you can use throttling exceptions (eg in ELINE) on hostnames.
That is, the above is during normal circumstances. Similar to previous
commit we will turn this feature of during high connection rates.
That is a TODO item.
This is the start of "be more friendly to TLS users with disconnect
error messages" from https://bugs.unrealircd.org/view.php?id=5532
As that bug explains:
Consider doing the SSL/TLS handshake even for throttling errors and such
when the (reject) connection rate is below a certain amount per second. If
it is higher than a certain rate, then fall back to the original behavior to
reject the user instantly without handshake or looking at any data.
Rationale: the current/original behavior is there so the ircd can handle
floods, both in terms of traffic and in terms of CPU usage (the SSL/TLS
handshake is quite costly after all). The downside of the current behavior
is that TLS users don't see the error message, usually. This feature
request tries to find a middle ground.
Still a TODO item:
* We don't detect high rates yet, so we only do this new behavior atm
and not yet the old behavior during high connection rates.
* Verify that error messages/behavior hasn't changed (too) much,
like the throttling and the banning disconnect messages.
This adds user_can_see_member_fast() which is used in at least 3 places
now, more places may follow later. It has extra paramters for membership
and membership modes that is very likely already looked up by the caller
(or if not, it is worth doing so by the caller).
This is work in progress so if everything crashes or people mysteriously
seem not present in channels (or the other way around) i would not be
surprised :D.
When sending to channel members this will cache full IRC protocol
lines, including message tags and \r\n, for similar clients.
This avoid the need for many mtags_to_string() calls and also
entire parts of sendbuf_to_one() can be skipped as well.
The "Similar clients" cache entries are defined as clients that:
1) Are of the same type: normal local client, ircop local client
or remote client.
2) Have the same CAPs set, that is: we only look at CAPs that actually
have anything to do with message tags ('clicaps_affecting_mtag')
3) Optionally there can be an explicit line_opts. It is not used yet
but could be used when there are different type of lines sent
depending on other criteria, such as chanop status or something
else that doesn't fit in #1 and #2.
https://www.unrealircd.org/docs/Set_block#set%3A%3Ahandshake-boot-delay
which allows server linking autoconnects to kick in (and incoming
servers on serversonly ports), before allowing clients in. This
potentially avoids part of the mess when initially linking on-boot.
This option is not turned on by default, you have to set it explicitly.
* This is not a useful feature on hubs, as they don't have clients.
* It can be useful on client servers, if you `autoconnect` to your hub.
* If you connect services to a server with clients this can be useful
as well, especially in single-server setups. You would have to set
a low `retrywait` in your anope conf (or similar services package)
of like `5s` instead of the default `60s`.
Then after an IRCd restart, your services link in before your clients
and your IRC users have SASL available straight from the start.
This results in less write calls (lower load) and more data per packet
(more efficient network traffic). It helps for the webserver (JSON-RPC)
but should also help IRC traffic when returning more than a line or so.
Previously the first TCP packet was not always filled fully, eg it was
close to 512 bytes instead of being close to 1500 bytes (MTU). Strange
that this happened in the first place, by the way, as we don't set
TCP_NODELAY. But whatever...
other remote included files still being downloaded.
This issue exists both with and without cURL, so in both url interfaces.
Was finally able to reproduce this on my own machine. This bug exists
since at least 6.0.0 and perhaps even before that. Just doesn't get
triggered that often due to needing an error and a certain timing
condition (well, and ASan catches it, but on some systems it may
go unnoticed).
They are similar to sendnumeric/sendnumericfmt, but allow an array of message
tags are parameter.
sendnumeric/sendnumericfmt are now shorthands for sendtaggednumeric/sendtaggednumericfmt
which pass NULL as mtags.
(so listen::file). This way you can override the IP address that users come
online with when they use the socket (default was and still is `127.0.0.1`).
Add a new guide https://www.unrealircd.org/docs/Running_Tor_hidden_service_with_UnrealIRCd
which uses the new listen::spoof-ip and optionally requires a services account.
for the add, like: nick-change, quit, server terminating. Add logon time.
I also think i will move from user.get_whowas to a whowas.XXX since the
returned object is not a user object and getting more different each commit :D.
This way things like the TOPIC will keep their color codes if they have it.
Reported by armyn in https://bugs.unrealircd.org/view.php?id=6259
(And yeah i used a global to achieve this, otherwise it has too much
of a cascading effect in XYZ functions)
Suggested by Chris_dc in https://bugs.unrealircd.org/view.php?id=6252
This uses unrealircd.org/real-quit-reason internally, but is only
exposed to servers, never to users. It results in using that quit
reason for IRCOps, while using the regular quit reason for normal users.
can be used from +f/+F as an action. You need to specify for which
flood type your mode is, eg `cmode.flood_type_action = 'j';` for joinflood.
Currently a mode can only choose one flood type action due to +f/+F
timer fights that could otherwise occur, but that shouldn't be too
much of an issue since we can live with that in core as well.
Bram Matthys