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.
This replaces use_invex, use_except, and use_forward, although
those options are still used internally and will continue to work
for users, to maintain config compatibility between charybdis
and shadowircd.
Modeset files are modules stored in shadowircd/modes. All they do is initalize
a set of modes on load, and orphan said modes on unload.
All cmodes not included in ircd-ratbox are now located in modeset files, rather
than being in the core. These modes no longer simply use defines, their
locations are stored in a the new struct module_modes. Each of these is set
when intializing the mode in the modeset files, and set to 0 when orphaning
the mode upon unloading the modeset file.
In addition, use_forward has been removed, as it is now obsoleted by modesets.
to clients that don't send an ident and add a TODO item for 6.2 to
make ident timeout time configurable in the ircd.conf.
Currently it's only configurable in the include/defaults.h (ugly)
or on-the-fly with /set (doesn't persist, have to re-set it on each
restart/server).
Additionally, attempting to use too many modes or two times
the same letter is now detected and prevented.
Modules now request that a channel mode be added/orphaned,
instead of ugly manipulation from which that request had
to be guessed.
Slight changes are needed to modules that provide channel modes.
From the old API, one important function has been made static,
the other important function has been renamed, so loading old
modules should fail safely.
If this option is yes (default), KLINE by itself sets global (propagated) bans.
If this option is no, KLINE by itself sets a local kline following cluster{},
compatible with 3.2 and older versions.
Special modes like +j can be tracked easily just by adding the necessary
code to parse them to set_channel_mlock(). This will cover propagation
as well.
This has a separate enabling option channel::channel_target_change.
It applies to PRIVMSG, NOTICE and TOPIC by unvoiced unopped non-opers.
The same slots are used for channels and users.
* does not apply to NOTICE (as those may well be automated)
* mirrors +g behaviour so that no useless accept entries are added for services
* respects max_accept, if it would be exceeded the message is dropped with numeric 494
* check moved up so this is checked before floodcount/tgchange
Pulled from Charybdis upstream changeset 1388:b1ef26176350 done by jilles.
Such bans are not applied locally, but are propagated normally.
They can only be removed on a server that applies them.
Note that normally KLINE will not accept such bans.
This is mainly for services, differing min_wildcard and
ircd changes.
A KLINE command without the ON clause now sets a propagated
("global") ban. KLINE commands with the ON clause work as
before.
Propagated klines can only be removed with an UNKLINE command
without the ON clause, and this removes them everywhere.
In fact, they remain in a deactivated state until the latest
expiry ever used for the mask has passed.
Propagated klines are part of the netburst using a new BAN
message and capab. If such a burst has an effect, both the
server name and the original oper are shown in the server
notice.
No checks whatsoever are done on bursted klines at this time.
The system should be extended to XLINE and RESV later.
There is currently no way to list propagated klines,
but TESTLINE works normally.