This will allow us to modularize message processing, e.g. having new modules to manipulate
channel and private messages in new ways.
Yes: it can be used to intercept messages, but such modules are already out in the wild for
charybdis anyway -- so this doesn't really change anything there.
If you are changing the text, then it is your responsibility to provide a pointer to a new
buffer. This buffer should be statically allocated and stored in your module's BSS segment.
We will not, and cannot, free your buffer in core, so dynamically allocated buffers will
cause a memory leak.
This will allow us to simplify m_message considerably, by moving channel mode logic out to
their own modules.
Note that you must have options ACCEPT_FILTER_DATA in your kernel
configuration or load the accf_data kernel module. The functionality is
not in the GENERIC kernel.
This allows for some further hardening against synflooding and connection flooding
where no data is actually sent, as the kernel will simply ignore those connections
(well, as far as the ircd is concerned anyway).
Arbitrarily prefer a forward channel to no forward channel and an
alphabetically higher forward channel to a lower one.
This is a simplistic implementation that generates one MODE message to
local clients for each ban removed (to be replaced).
For simplicity and to avoid amplification of incoming MODE messages,
regular modes may still desync the forward channel of a ban.
Add two mechanism for avoiding name-collisions in a system-wide
installation of charybdis. The ssld and bandb daemons, intended to be
directly used by ircd and not the user, install into libexec when
--enable-fhs-paths is set. For binaries which are meant to be in PATH
(bindir), such as ircd and viconf, there is now an option
--with-program-prefix=progprefix inspired by automake. If the user
specifies --with-program-prefix=charybdis, the ircd binary is named
charybdisircd when installed.
Add support for saving the pidfile to a rundir and storing the ban
database in localstatedir instead of in sysconfdir. This is, again,
conditional on --enable-fhs-paths.
Fix(?) genssl.sh to always write created SSL key/certificate/dh
parameters to the sysconfdir specified during ./configure. The
previous behavior was to assume that the user ran genssl.sh after
ensuring that his current working directory was either sysconfdir or a
sibling directory of sysconfdir.