- Added support for "stacked" extbans. Put simply this allows extban combinations
such as ~q:~c:#test to only silence users on #test, for example. This feature
is enabled by default, but can be disabled during ./Config -advanced.
This feature was suggested by Shining Phoenix (#0003193), was then coded
by aquanight for U3.3, and later on backported and partially redone by Syzop.
Module coders:
In an extban ~x:~y:something where we call ~x the 1st, and ~y the 2nd extban:
Since stacked extbans only makes sense where the 1st one is an action
extended ban like ~q/~n/~j, most modules won't have to be changed, as
their extban never gets extended (just like ~c:~q: makes no sense).
However, you may still want to indicate in some cases that the extban your
module introduces also shouldn't be used as 2nd extban.
For example with a textban extban ~T it makes no sense to have ~n:~T.
The module can indicate this by setting EXTBOPT_NOSTACKCHILD in
the ExtbanInfo struct used by ExtbanAdd().
For completeness I note that action modifier extbans are indicated by
EXTBOPT_ACTMODIFIER. However, note that we currently assume all such
extbans use the extban_is_ok_nuh_extban and extban_conv_param_nuh_or_extban
functions. If you don't use these and use EXTBOPT_ACTMODIFIER, then things
will go wrong with regards to stack-counting.
Module coders should also note that stacked extbans are not available if
DISABLE_STACKED_EXTBANS is defined.
- Added extended ban ~R:<nick>, which only matches if <nick> is a registered
user (has identified to services). This is really only useful in ban
exemptions, like: +e ~R:Nick would allow Nick to go through all bans if he
has identified to NickServ. This is often safer than using +e n!u@h.
- Added Extended Invex. This is very much like extended bans, in fact it
supports some of the same flags. Syntax: +I ~character:mask
Currently supported are: ~c (channel), ~r (realname) and ~R (registered).
This can be useful when setting a channel invite only (+i) and then
setting invite exceptions such as +I ~c:#chan (or even ~c:+#chan), while
still being able to ban users.
Because action modifiers (~q/~n/~j) make no sense here, extended invex
stacking (+I ~a:~b:c) makes no sense either, and is not supported.
Suggested by DanPMK (#0002817), parts based on patch from ohnobinki.
Module coders: set EXTBOPT_INVEX in the ExtbanInfo struct used by
ExtbanAdd() to indicate that your extban may also be used in +I.
- Invex (+I) now always checks cloaked hosts as well. Just like with bans,
it checks them also when the user is not currently cloaked (eg: did -x, or
is currently using some VHOST).
- Fixed client desynch caused by (un)banning, reported by Sephiroth (#2837).
- Separate m4 macros into *.m4 files (it is much easier to run aclocal now).
- Remove unused DOMAINNAME macro and --with-hostname= options as the DOMAINNAME macro isn't used anywheres and its use shouldn't be encouraged.
- autogen.sh to bootstrap the buildsystem. We now maintain setup.h with autoheader.
- --disable-blah now does the opposite of --enable-blah. The same for --with-blah and --without-blah. (This makes Gentoo users happier).
- Remote MOTD support. Not adequately tested. Required restructuring of the asynchronous download callback and handler.
- Added some consts throughout url.c, etc.
- Fix segfault where the an include directive specifies a URL and cURL follows redirects, resulting in a different resultant URL. The remote includes code would look for the an include block using the resultant URL and assume that it would be found. The new code searches differently, has new checks, and ignores the resultant URL.
- Removed duplicated m_motd() and friends that were both in modules and s_serv.c. The copies in s_serv.c (core) were overriding the in-module functions.
- IPv6: it seems some recent Linux dists decided to make IPv6 sockets
IPv6-only, instead of accepting both IPv4&IPv6 on them like until now.
FreeBSD (and other *BSD's) already did that move a few years back,
requiring server admins to sysctl.
We now make use of a new option to explicitly disable "IPv6-only".
This should work fine on Linux.
Whether it provides a complete solution for FreeBSD, I don't know, testing
is welcome! In theory setting net.inet6.ip6.v6only to 0 should no longer
be needed, but you might still need to enable ipv6_ipv4mapping.
- Fix stupid issue where current CVS would no longer link TO an earlier
Unreal server (eg: outgoing connect to a 3.2.8 hub). Reported by ohnobinki
(#0003901).
it to 'no', the default is 'yes' (on). Requested by Robin (#0003885) as
UHNAMES may increase the time of the nick list being loaded from 1 to 4
seconds when joining several channels with more than 1000 users. As this
problem is only present on some networks, we keep UHNAMES enabled by
default.
- Server protocol: added PROTOCTL EATH=servername, which allows us to
authenticate the server very early in the handshake process. That way,
certain commands and PROTOCTL tokens can 'trust' the server.
See doc/technical/protoctl.txt for details.
- Server protocol: between new Unreal servers we now do the handshake a
little bit different, so it waits with sending the SERVER command until
the first PROTOCTL is received. Needed for next.
- Server protocol: added PROTOCTL SERVERS=1,2,3,4,etc by which a server can
inform the other server which servers (server numeric, actually) it has
linked. See doc/technical/protoctl.txt and next for details.
- When our server was trying to link to some server, and at the same time
another server was also trying to link with us, this would lead to a
server collision: the server would link (twice) ok at first, but then a
second later or so both would quit with 'Server Exists' with quite some
mess as a result. This isn't unique to Unreal, btw.
This happened more often when you had a low connfreq in your link blocks
(aka: quick reconnects), or had multiple hubs on autoconnect (with same
connfreq), or when you (re)started all servers at the same time.
This should now be solved by a new server handshake design, which detects
this race condition and solves it by closing one of the two (or more)
connections to avoid the issue.
This also means that it should now be safe to have multiple hubs with low
connfreq's (eg: 10s) without risking that your network falls apart.
This new server handshake (protocol updates, etc) was actually quite some
work, especially for something that only happened sporadically. I felt it
was needed though, because (re)linking stability is extremely important.
This new feature/design/fix requires extensive testing.
This feature can be disabled by: set { new-linking-protocol 0; };
having to use a special SSL-only port, they can simply switch to SSL on
any port. This is currently only supported by few clients (such as KVIrc 4).
This functionality can be disabled by setting set::ssl::options::no-starttls,
for example if you don't want to offer SSL to your users and only want it
to be used for server to server links.
Naturally, the IRCd must be compiled with SSL support for STARTTLS to work.
- Fixed SSL_ERROR_WANT_READ in IRCd_ssl_write()
binki