and also for safety when redoing DNS and ident due to IP change,
we now:
ClearIdentLookupSent(client);
ClearIdentLookup(client);
ClearDNSLookup(client);
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).
This now requires a proxy { } block -- docs follow soon
This uses part of k4be's code still, to do the parsing,
so still only "Forwarded" and quick workaround for bug
when for=XXX is the final item.
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.
That file has such a clear warning in it but still people
manage to load old ones. That being said, usually it is not
deliberate, like an cp ../unrealircd.old/conf/* conf/
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.
a bug when two servers merge, you could see +beI items being set that
already exist, if the timestamp or setter differed between servers.
Now they are updated but no +beI is shown.
https://bugs.unrealircd.org/view.php?id=5681
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...
"Too many unknown connections from your IP".
Need to check 'c' in the loop, not 'client', duh!
If you have multiple tabs of the webpanel open and the panel is
not hosted on the same machine as the ircd (does not connect over
127.0.0.1) then you will experience this bug. Pages or content
will fail to load or will load very slowly.
conf/rpc.modules.default.conf. This because:
1) It matches the default in example.conf for ircd.log
2) It is a more privacy-friendly setting
3) The log entries are spammy / fill the memory log buffer quickly
Bram Matthys