While it really would be desirable to allow stream destruction during on_read()
callbacks, this does not work anymore since e49b2998. Until we have a proper
solution for this issue, use asynchronous disconnects for the only user doing
so.
Fixes#518.
Introduces a new configuration file layout. strongswan.conf is now only
very simple and mainly includes the config snippets from the strongswan.d
and strongswan.d/charon directories (the latter containing snippets for
individual plugins).
Config snippets with commented defaults are generated for all currently
defined settings and are installed if they don't exist yet and the
respective plugin/component is enabled. Similarly, the strongswan.conf(5)
man page, which documents all these settings, is automatically generated
from the same source.
The config snippets are also installed in $prefix/share/strongswan so
existing files can be compared to the most current defaults.
As an alternative to the non-extensible charon.load option, the plugins
to load can now be determined via the respective charon.plugins.<name>.load
setting. This functionality is enabled by the new default strongswan.conf
file (via the charon.load_modular option) and the load setting in the
generated config snippets of all enabled plugins. The load setting
optionally takes a numeric priority value that allows reordering the
plugins (plugins with the same priority are ordered according to the
default plugin order).
Additionally, all settings that were formerly defined in library
specific "global" sections are now application specific. For instance,
instead of configuring libstrongswan.plugins.random.random and affecting
charon, charon-cmd, pki, basically every application using libstrongswan,
the option can now be set individually for each application (e.g.
pki.plugins.random.random to affect only pki). The old options are still
supported though, which actually allows to define defaults for all
applications in the libstrongswan section.
The libtls options are mapped to <app>.tls. The libimcv and libtnccs options
are mapped to <app>.imcv and <app>.tnc, respectively (while their plugin's
options are now under <app>.plugins together with all the others).
Fixes#475.
Is a bit more memory efficient (also due to lazy instantiation) and
lookups for sections with lots of subsections/keys (e.g. charon.plugins) are
faster.
This now works because all plugins use the same config namespace.
If <ns>.load_modular is true, the list of plugins to load is determined
via the value of the <ns>.plugins.<name>.load options.
Using includes the following is possible:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
charon-cmd {
load_modular = yes
plugins {
include strongswan.d/charon-cmd/*.conf
}
}
Where each .conf file would contain something like:
<name> {
load = yes
<option> = <value>
}
To increase the priority of individual plugins load = <priority> can be
used (the default is 1). For instance, to use openssl instead of the
built-in crypto plugins set in strongswan.d/charon/openssl.conf:
openssl {
load = 10
}
If two plugins have the same priority their order in the default plugin
list is preserved. Plugins not found in that list are ordered
alphabetically before other plugins with the same priority.