strongSwan

h1. Manual plugin load options

Many components of strongSwan have a modular design, features can be added or removed using a [[PluginList|growing list of plugins]]. This allows us to keep the footprint small while adding new functionality.

h2. Compile time plugin configuration

The recommended way to enable or disable plugins is during compile time. The [[AutoConf|./configure]] script has many --enable/--disable options to enable or disable specific plugins. The daemons and other tools automatically load the plugins enabled/disabled during ./configure; there is no need to manually specify the plugins to use during runtime. 

Using this compile-time generated plugin has some advantages, including:

* Proper load order of all plugin

* Gets updated automatically with new strongSwan releases: This is very important, as we might move core functionality you rely on to plugins. 

h2. Runtime plugin configuration

Most components can read the plugin list from [[strongswan.conf]], for example the IKE daemon charon reads the _charon.load_ key to load plugins. 

> 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.

h3. Disable warning

If you really need the manual plugin load directive, you can disable the warning by setting

<pre>

starter {

    load_warning = no

}

</pre>

in strongswan.conf or by providing the @--disable-load-warning@ option during [[InstallationDocumentation|configuration]].

h3. Strict Plugins

In the manual load directive, you can mark specific plugins as critical: If loading a critical plugin fails, the daemon does not start. To mark a plugin as critical, append a ! to its name.