Plugin Load Options
Many strongSwan components have a modular design. Features can be added or removed using a growing list of plugins. This allows us to keep the footprint small while adding new functionality.
Currently Loaded Plugins
The list of loaded plugins is logged by the IKE
daemon and can also be seen in the output of
swanctl --stats
. Other tools often list the
plugins they load in the output of the --help
option like e.g.
pki
or swanctl
itself.
Compile Time Plugin Configuration
The recommended way to enable or disable plugins is during compile time. The
./configure
script has many --enable/--disable
options to enable or disable specific plugins. The daemon and other tools
automatically load the plugins enabled with
./configure
. There is no need to manually specify
the plugins to use during runtime.
Using this compile time generated plugin list has some advantages, including:
-
Proper load order of all plugin (since version 5.1.0, this has not been as important because the order only indicates the preference when two plugins provide the same feature).
-
Gets updated automatically with new strongSwan releases: This is important as we might move core functionality you rely on to new plugins.
Runtime Plugin Configuration
The plugins to load can be specified in
strongswan.conf
. There are two means to
do so.
Plugin-Specific Configuration
The plugin loader refers to plugin-specific load
settings to decide whether
a plugin is loaded at runtime:
charon.plugins.<plugin>.load = yes | no | <priority>
Besides simply enabling/disabling plugins, the setting accepts a numeric priority
value, which the plugin loader uses to decide in which order plugins are loaded.
Plugins with the same priority are loaded according to the compile time
load order. Priorities can also be negative to simplify moving a plugin to the
end of the list. The default priority is 1
.
By default, the setting modifies the compile time plugin list:
-
Plugins on that list don’t require an explicit
load
setting -
Plugins absent from that list are not loaded, even if
load = yes
is explicitly set
Modular Configuration
The above limitations may be avoided with the charon.load_modular
setting.
With load_modular
enabled, the list of plugins is constructed dynamically,
solely based on the plugin-specific load
settings. That list then completely
replaces the compile time list.
This means that only plugins with explicit load
setting are considered,
and plugins not on the default list may be loaded. Note that the compile time
list is still consulted when ordering plugins with equal priority. Unknown
plugins with the same priority are loaded in alphabetical order before known plugins.
The load_modular
setting can also be enabled for other components, but only
for charon
are the default configuration snippets
installed in strongswan.d/charon
and included
in the default strongswan.conf
file.
Additionally, the default snippets are also installed in the
${prefix}/share/strongswan/templates
directory for reference.
This feature is also useful for distributions if plugins are shipped in separate, optional packages, to avoid trying to load plugins that are not installed but still on the compile time list.
Static Load List
Most components can read the plugin list from
strongswan.conf
. For example, the IKE daemon
charon
reads the charon.load
key to load
plugins, but only if the charon.load_modular
option is disabled (see above).
It is not recommended to specify the plugin list manually unless you exactly know the implications! |
The load directive is helpful for developers or for testing frameworks. While you might get your scenario running with a manually specified plugin list, it might not work anymore after a strongSwan update. Use the generated plugin list instead.
For example, you see a lot of load statements in the strongswan.conf
files
of the example scenarios of our
testing environment because we enable all
strongSwan plugins during compile time but use only a small subset of them
while running an individual test scenario.
Static Plugin Features
Plugin features, which are usually loaded dynamically from a plugin via the
plugin_t::get_features
callback (see src/libstrongswan/plugins/plugin.h#L51
) may also be added statically
from a (modified) library or executable by using the
plugin_loader_t::add_static_feature
method (see src/libstrongswan/plugins/plugin_loader.h#L61
).