- 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).
Previously this caused some really odd behavior. Backslashes are now
treated as-is, so no special escaping is necessary. Reported by DelGurth
(#0003002).
- Removed old dgets() function
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.
descriptors. Because of this, Unreal did not restart properly as you would
get an "Address already in use" error. This only seemed to happen when
logging to syslog.
- Fixed a similar issue with syslog (and debugmode) and closing fd's as well:
the first port we listened on would not open up, ircd did not log any error.
- 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()
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. Module
support for this feature must note the following:
- For is_ok function, the extban can either assign extban_is_ok_nuh_extban, which
will deal checking a chained extban (including checking for restricted extbans),
or it can call that function from its own is_ok routine. For the latter case,
remember to pass only the mask part of your ban format (ie, don't just pass para as
otherwise it'll just call your is_ok again).
- For conv_param function, the extban can either assign extban_conv_param_nuh_or_extban,
which will automatically call conv_param for a chained extban, or pretty up a n!u@h mask.
- For is_banned, the extban should call ban_check_mask with the mask part of the parameter.
This will automatically call is_banned for a stacked extban, or match against a n!u@h. n!u@h
is checked against the current user (ie, with the info in the globals ban_ip, etc), so things
can get weird if you call this outside a normal ban check.
Modules must keep in mind that chained extban support is not available (and neither are the three
functions above) if DISABLE_STACKED_EXTBANS is #defined (this is controled by Config). Modules will
not compile/load if they try to use them anyway.
This change should not break extban modules, and should need some more extensive testing.
- Misc fix for disabling extban chains, should've done stuff in our autoconf
stuff instead of hacking configure directly :P .
load (for example when the webserver is down), then the most recent
version of that remote include will be used, and the ircd will still boot
and be able to rehash. Even though this is quite a simple feature, it
can make a key difference when deciding to roll out remote includes on
your network. Previously, servers would be unable to boot or rehash when
the webserver was down, which would be a big problem (often unacceptable).
The latest version of fetched urls are cached in the cache/ directory as
cache/<md5 hash of url>.
Obviously, if there's no 'latest version' and an url fails, the ircd will
still not be able to boot. This would be the case if you added or changed
the path of a remote include and it's trying to fetch it for the first time.
To disable this new behavior, check out REMOTEINC_SPECIALCACHE in
include/config.h.
binki